I used to think that the jargon is stupid. Nowadays I think it is just impractical and prone to abuse. Haskell (or Elm) is not going to become an industry language because the barrier is too high and people love building their tiny islands of expertise. Lowest common denominators are actually a feature of programming languages used by industry. It's why we have languages like Go or Javascript.

> Haskell (or Elm) is not going to become an industry language

I'm not really sure what this means. At Riskbook we have about 50,000 lines of Haskell and about 20,000 lines of Elm running in production. It's working great for us.

Prezi was the first major adopter of Elm in industry. They hired the language author to work on it full-time.

A few years later, they laid him off and deprecated their Elm codebase.

That may be true (I'm not actually sure), but it's not at all clear to me why that matters.

Elm won't be used in industry because the language designer used to work at a company and now he doesn't work there anymore? Perhaps I'm being obtuse, but this is a total non sequitur to me.

Prezi was the first major investor in Elm (because they hired Evan) but definitely not the first major adopter.

Source: back in 2015 I was personally in a meeting at Prezi's San Francisco office where Prezi employees were asking me (and two of my coworkers) about our experiences having adopted Elm at work, because they were considering doing so for the first time!

It seems kind of... hubristic? for a company like Prezi to go out on a limb for an obscure language. Did they read PG's old essays about lisp and plan on repeating a fluke?

Yep, vanity is the mark of the CTO who cares more about the elegance of their code, than the effectiveness of their business.

Funnily enough, the next company that hired the maintainer and went all in on Elm makes even less money than Prezi and has even less of a name-brand.

I think it’s usually a state issue due to stateless HTTP.

If you don’t care about recovering steps or entering mid step from existing data (routing) it’s still pretty straightforward IMO.

Could you point out which part of the article uses "category theory jargon"?

The whole part about lenses.

Lenses are not a concept from category theory and to understand them no knowledge of category theory is required. Category theory just gives you generalizations (other 'optics') and better encodings, but none of that is mentioned in this post.

The use of lenses here is just one approach to solving a specific problem. It is still possible to write code with the same behaviour without lenses.

Do you have a better suggestion for updating deeply-nested record fields?

Still lenses, but have you looked at https://package.elm-lang.org/packages/bChiquet/elm-accessors...?

I hadn't seen it until you linked to it from one of your earlier comments. I have no particular attachment to elm-monocle, and I appreciate you sharing :)