Event Sourcing • Greg Young • GOTO 2014

What people said

Leftium · 2023-02 · Recommendation

It depends on what your goals are... I haven't read 'Practice and Principles', but I assume it focuses mostly on the OOP programming paradigm. I'd explore the functional programming paradigm. I say paradigm because it's possible to implement the functional paradigm in a traditionally imperative/OOP language like C++. (And it's possible to implement OOP/imperative paradigm in traditionally functional languages like Scheme/Lisp.) So learning functional concepts can improve your C++ programming, at both the "strategic" (program design) and "tactical" levels (implementation in code). Quick summary of the promises of functional programming: 1. Program design/code that is easier to reason about/debug. 2. Programs that are shorter, yet more descriptive. 3. Programs that are more performant. 4. Programs that can be easily parallelized. I believe SICP teaches functional concepts (via Scheme/Lisp), but recently I found more accessible/practical resources. (My university's intro to programming class used parts of SICP, mostly the beginning but FP didn't truly "click" until I found the resources below.) Here is my short list of best introductions to practical FP, strategies and tactics: - [LINK] - [LINK] - [VIDEO] - More: [LINK] --- How to Design Programs is also a good book: [LINK]

Read the original HN comment ↗

Leftium · 2026-01 · Reference

There are forms of state that are reversible: essentially, you store read-only events instead of writing to existing state. The main disadvantages are more complexity and performance issues. Examples: - Event sourcing: [VIDEO] - CRDT - At the DB layer: [LINK] - You can also do it at the code level (but this is more like keeping copies of the old state): [LINK]

Read the original HN comment ↗

Leftium · 2024-03 · Reference

I think your specific question can be answered by this video. It explains how all branching was removed by refactoring an imperative-style function into functional-style. The original code is on the top, the refactored code is on the bottom: [LINK] Besides being shorter and easier to reason about, functional-style can be easier to test because there are fewer logical paths to test (statement/condition/branch/etc coverage). Of course, it's still totally possible to write bad code in a functional-style! Some little advantages of creating arrays in functional-style TS (vs declaring an empty array [] and filling it imperatively with `push()`): - TS can autumatically infer the type of the array; no need to explicity type. - Can declare the array as const/readonly if it doesn't change --- The OP question was at the code-level, the small scale. However FP can be used at both the large and small scales. (And via traditional "non-functional", "inperative" languages.) "Functional programming" is a paradigm and way of thinking; not just a programming language. In fact, many of the good parts of FP have been borrowed by non-FP languages to the point people don't consider them "functional programming" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class lambda functions[1].) Another major pillar of FP is immutability (functional purity). Actually Grokking Simplicity[2] states it most elegantly: it's not about avoiding mutation because "mutation is bad."

Read the original HN comment ↗