Is TEA a comonad?

[rtfeldman]

@MarkHamburg

I’ve worked with engineers who would say that they were just trying to use a control bar and clearly Elm sucks compared to whatever they came from before. Code exists in a social context as well as a technical context.

Sure, but I think the social key here is buy-in.

If some people on a team want to use [Elm/React/Vue/Angular] but others on the team prefer the way [a different technoloy] solves a particular problem, there’s going to be friction!

None of these technologies will ever be all things to all people; I think they’re all best served by playing to their own strengths, and leaving teams to figure out which strengths appeal most to them.

@MarkHamburg

What I suspect is an example of why API minimalism isn’t always the right choice: Have you actually had cause to use everything in your CSS library?

Well no, because I don’t use everything in CSS.

One of the design goals of elm-css is to provide a typed interface to the CSS API. The minimal API to achieve that goal is quite large!

@MarkHamburg

At this point the pendulum swings toward avoiding fractal decomposition and pushing more things into the top-level model because there’s a reason people have been drawn for years to just sticking stuff in global variables which is essentially what tossing everything into one big model is essentially doing.

Model is practically the opposite of global mutable variables!

Any code in a program can read and write to global mutable variables. In stark contrast, permission to both read and write Model are extremely strictly controlled. view and subscriptions get read-only access; to them, Model is an immutable constant. Only update has permission to modify Model, and it can create more granular permissions by delegating to functions that work with subsets of Model. Outside of those 3 pure functions, the rest of the program can’t even read it!

It’d be more accurate to say that Model has nothing in common with global mutable variables.

@MarkHamburg

Elm’s relative lack of sophisticated mechanisms that would reduce boiler plate [of nested Model/view/update triplets]

The implication here is that “structuring Elm programs as nested M/V/U triplets is a reasonable choice, but how to do it nicely is an unsolved design problem,” even though the language’s foundational design, Occam’s Razor, and a mountain of historical evidence all say the reality is actually that “structuring Elm programs as nested M/V/U triplets is a mistake.”

The most recent case in point is earlier in this thread. I showed how to refactor an API that used a nested Model/View/Update design into a much simpler API that did not use it. How lucky was I that out of the 1 (one) motivating code example for nested M/V/U, it turned out there was a simpler, nicer API within reach…that was obtained by doing nothing more than declining to use nested M/V/U in the first place?

This was not a lucky coincidence; I’ve seen this so many times, I’ve lost count! Nested M/V/U turning out to be a mistake in practice is normal.

As an aside, I never could have imagined the teaching challenge that our industry’s OO monoculture would create for Elm. It’s nobody’s fault—people come from OO backgrounds and reflexively follow OO design patterns. I know that feeling well, since I did it myself when I was starting out!—but it’s surprising nonetheless.