Types and Functions 3: Composing

Then we get at Chapter 05: Composing and I really don’t understand the need to faff around so much when it comes to such a mathematically simple subject.

Composing is really easy, it’s just that programming languages make it hard. Especially if you look at this:

const compose = (...fns) => (...args) => fns.reduceRight((res, fn) => [fn.call(null, ...res)], args)[0];

That curried function is left unexplained and I’m still not sure I can read it.

I’m documenting this because every chapter is spawning off one too many bunny trails for my taste. That also makes it clear how learning functional programming is a reclusive undergrad’s game.

Types and Functions 1: Introduction

I got sick of it and I want to learn the weirder stuff of functional programming seriously now.

I’m under the impression that these are fundamentally very simple things that people overcomplicate either because they don’t really understand them or because they are poor communicators.

I think it should be possible to explain the concepts and their use without any jargon, so I asked for sources:

I’m now working with the Mostly Adequate Guide which starts of really good but at some point also dives off into mathematical weirdness. Let’s see how far I get.

“the resilience of a system corresponds to its adaptive capacity tuned to the future.”

“While counterfactual reasoning helps restore our feeling that the world makes sense, the problem with it is that it doesn’t help us get better at avoiding or dealing with future incidents. The reason it doesn’t help is that counterfactual reasoning gives us an excuse to avoid the messy problem of understanding how we missed those obvious-in-retrospect actions and signals in the first place.”

The writings of Lorin Hochstein about resilience engineering are immensely valuable and illuminating. It’s nice to be able to read the thinking of people who are current with the cutting edge of a profession.