Event Sourcing • Greg Young • GOTO 2014

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] - [this video] - More: [link] --- How to Design Programs is also a good book: [link]

> But if someone can explain the problem better, I'm all ears. Assuming you mean it... Here's a youtube video about the benefits and attributes of event-sourcing. [this video] Though the demo project is presented in the browser, I'm trying to demonstrate that I can model the game of Tic-Tac-Toe using a much smaller and comprehensible (I hope) graph. Additionally - because these are mathematical graphs I'm speaking of - it means the 'program' that the graph represents - can be expressed as pure math ( which is nifty to say the least ) A classic DFA would have to represent all the permutations of the board like so: [link]

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."

Learning Functional Programming can provide immediate benefits. However, FP practitioners tend to be bad at teaching/explaining (to non-mathematicians) and even worse at marketing[0]. I've attached a list of good resources on FP at the end of this comment. I also wrote an article on the benefits of functional programming: [link] Functional programming is more of a spectrum; not an "all or nothing" concept. You can write FP-style programs in non-FP languages. (And you can use non-FP style in FP languages.) Understanding FP will help you write better non-FP code. Simple example: I have switched from declaring an empty array [], then filling it via a loop to declaring the same array with values from a functional expression (like map). This has two benefits: 1. The array can be declared const, and its contents possibly even declared read-only. 2. TypeScript can automatically infer the type/shape of the array contents. The other example usually cited is that FP will help you understand recursion better, even in non-FP languages. FP is a paradigm that can be applied at many levels. You can apply it: - at the code level: removing logical branching in code ( [link] ) - at the high-level design level: event sourcing ( [this video] ) Although FP languages make it more convenient to write functional-style code, notice the examples above don't need "functional" programming languages. In fact, many "non-functional" languages have borrowed the best parts of functional languages (first-class (la