2 ms·
1: Cleaner and more concise. Perhaps safer, as the less code there is going to performing a task, the fewer places I can make a mistake. More importantly, it di
by stochastic_monk 8y ago
1: Cleaner and more concise. Perhaps safer, as the less code there is going to performing a task, the fewer places I can make a mistake. More importantly, it directs me to think about my problem from a higher level of abstraction.
2: I do mix both paradigms, so I’m not stuck without imperative features. That being said, there are times where I feel like my attempts to move a concept into FP forces me to make some less than ideal choices to fit it into the paradigm. If those are in inner loops, I forgo functional programming to do precisely what I need. (For example, managing exceptional cases or heterogeneous actions can be awkward.)
3: I would have used them more. I’ve always been a fan of comprehensions and map c/o Python, but my code would have been more efficient and concise had I started earlier.
The additions of cppitertools, range-v3, <algorithm> and <functional> make functional programming both easy and efficient in C++ in ways it was not prior to C++1[147]. I think Python made fp accessible by putting it in an imperative language which is concise and readable.
- agumonkey 8y agoabout 2, I remember some old lisp book (Queinnec L.I.S.P) said that if mutable state is entirely contained and invisible, you can forget about purity. It's cool that cpp is 'flattening' through fp idioms, you can avoid its complexity without leaving the country entirely.
- kazinator 8y agoE.g. a pure function can work internally by mutating some local variables. Locally constructed new objects such as conses can be mutated before being returned to the caller. Blackbox testing cannot tell.