I have nothing but immense respect for these people who built a Slack client for Windows 3.1, turning retro computing into retro programming.
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);
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.
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:
- The Mostly Adequate Guide to Functional Programming
- Learn You a Haskell for Great Good
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.
Such a well-written and cogent argument by Dave Mangot about how it definitely does matter whether you choose to deploy on Fridays or not and also that that choice is fully your own.
Figma’s multiplayer support is fantastic and something similar should be a part of every creative application. Now they’ve also written a very understandable high-level overview of their implementation (with CRDTs).
An accessible and highly educational overview of the most important lines of code ever written.
“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.
Twenty-four survival tips for women by Patricia Aas that I wholeheartedly support but wish were not necessary.
Berlin is finally thinking of fixing its totally and utterly broken website. That’s good news but a shame that we have had to use this monstrosity for the past ten years.
Ten principles for how to grow as an engineer that are as true as the day they were written.