axelerator

Definitely some good reminders in there!

> But the converse: that successful outcomes are also the result of gambles; is not widely appreciated.

This statement however I would challenge: There is the whole ‘build fast and break shit’ culture that bets exactly on that outcome.

There are bunch of good UX principles baked into HTML and CSS. Plus to become good at HTML and CSS you will be exposed to a lot of UX talk as well.

So one could argue it's really hard to get really good at HTML and CSS and not care about UX at all.

But yes, a fool with a tool is still a fool - if that's the point you're trying to make.

> Well... no. Engineers are more efficient in their own styles. Realistically, I've wasted hours setting up my editor at each new job / each project to get on board with the style

I disagree for two reasons:

1. Optimizing for what each dev is used to is optimizing for a local maximum. If they’re THAT good it won’t take them long to adjust to new defaults. Good engineers should be able to pick up a new lang quickly so some changes in the context of a language should not bog them down significantly in the long term.

2. The overly long time it took to set up tooling in a particular company or language do not outweigh the bigger advantage of being able to quickly get a grasp about what a piece of completely unfamiliar code does.

I always say my appreciation for functional programming comes from having spent enough time in imperative hell.

That being said I think learning programming in an "expressions only" environment can enable the student to deal with more complex problems earlier, merely by making certain types of errors impossible.

I think the Elm programming language is the sweet spot for that.

- it does have elegant (Haskell like) syntax

- it has still a simple syntax because it deliberately omits certain features (namely typeclasses, do-notation)

- it has a self contained build system (compiler, package manager, repl, dev server) with a rich ecosystem of libraries

- it is comparatively easy to ship something tangible because it compiles to JS for the browser

But keyboards are not. Even if I’d be able to convince the maintainers of my favorite programming language to also accept some Unicode glyph as synonym to ‘==‘ how do I type it? Ligatures might not be ‘the right’ solution, but they are a highly efficient approximation. Also the cost of reversing the decision to use them is basically zero.

The irony:

"I write this not because I expect to break any new ground—all the techniques I use here are long-documented in the literature, and Haskell veterans will probably find little new in this post"

Yet I can't get rid of the feeling the article is written in a way only "Haskell veterans" are able to follow it :-)

I think the first step here is to put your expectations into perspective. Functional programming also is a range of complexity. If you're not used to functional programming and try to read articles targeted at the high-end you'll naturally struggle to understand them.

I still remember "not getting" OO in university in my first lecture. I had programmed BASIC, C, Pascal, PHP before. And if someone would have tried to explain me the idea by means of the visitor pattern, it would surely have made me say "eh?!?" too. So allow yourself to start slowly.

I'm also still dabbling in functional programming - at least that's what it feels like reading about monoids etc - but by actually using functional programming languages in my more serious spare time projects I feel I get a better and better understanding. And "those" articles start to speak more to me.