So overly complicated. The "state of the art" of FP now means heavy type systems and heavy machinery to deal with them. The 80/20 pareto of FP is just pure functions + composing those functions and it works in any language. Here is all of it in python: from __future__ import print_function import json struct = json.loads(open('staff.json','r').read()) staff = struct['staff'] salaries = struct['salaries'] def visit_pe…
1. let the compiler reason about my code to catch errors when the requirement changes (say, when some record fields change their names or types),
2. thus lower my cognitive load, and
3. allow me to reason about more important aspects of the project.
At work, the use of a powerful and expressive type system allowed me to work on multiple projects at once, achieving at least 2 times boost in productivity (definitely more than 20% gain).
Moreover, if optics is not well-known to everyone, I can just link to this blog post as a documentation, and give more examples if needed (I think people underestimate how coworkers could be productive without completely understanding everything).
It is hard to explain the experience of “pair-programming with the compiler”, but such complication is worthwhile for the productivity gain (and developer happiness).