This was a wonderful comment that added a lot of value to the article for me. I have a random curiosity if this was generated by a model or human written. I'm hoping for the later as this seems too well processed to be a LLM, but I'd like to check my assumption.
All human lol. I was very into Haskell when I was in college, and Scrap Your Typeclasses was always one of my favorite articles.
There has always been a sort of fascination with effect systems and dependency inversion in the Haskell community. You cannot throw a stone in any discussion board without hitting someone currently noodling on the problem of "man, typeclasses are cumbersome and don't compose well. What if we had something better?"
Transformers and mtl were the name of the game for a long time. Then for a while there was a LOT of hype around free monads and algebraic effect systems. When I was deeply into Haskell, at the time it sometimes felt like a new effect system library was being released every week.
Then there was also this counter-movement of people going "all this new-fangled stuff is overly complicated. Why don't we just use plain functions?" (see [0]).
And there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze" (see [1]).
Meanwhile, this whole time we have had distant voices in the back pointing out that OCaml has already solved this problem, and Haskell should just introduce a feature for first-class modules. Well, now it's here, and it's called Backpack.
> there were also a lot of people saying "well, if you just write your whole application in ReaderT IO, you can get 90% of the effects juice for only 10% of the complexity squeeze"
I think 90% is an overestimate because you don't get any encapsulation. Maybe 50% is a more reasonable number. If you want 99% of the effects juice for 1% of the complexity squeeze, my effect system, Bluefin0[1], as well as the effectful[2] effect system
My recent talk "A History of Effect systems"[3] explains this in more detail, as does the "Why even use an effect system"[4] section of the latest Bluefin documentation.
I think the ideal scenario is usually two paired programmer using a shared set of AI agents on the same working branch together. It's an ideal feedback loop of paired planning, reviewing, building, and testing.
Mort, Elvis, Einstein, Amanda does seem to fit well with my experience. While people are a mix, generally I think its fair that there is a primary focus/mode that fits on career goals.
- Mort wants to climb the business ladder.
- Elvis wants earned social status.
- Einstein wants legacy with unique contributions.
- Amanda just wants group cohesion and minimizing future unpredictability.
I don't really like the axes Mort/Elvis/Einstein are on, they all seem like obviously pathological examples.
I think if I were to make three strawmen like this I would instead talk about them as maximizing utility, maintainability, and effectiveness. Utility because the "most business value" option doesn't always make the software more useful to people. (And I will tend to prioritize making the software better over making it better for the business.) Maintainability because the thing that solves the use case today might cause serious issues that makes the code not fit for purpose some time in the future. Effectiveness because the basket of if statements might be perfect in terms of solving the business problem as stated, but it might be dramatically slower or subtly incorrect relative to some other algorithm.
Mort is described as someone who prioritizes present business value with no regard to maintainability or usefulness.
Elvis is described as someone who prioritizes shiny things, he's totally a pejorative.
Einstein is described as someone who just wants fancy algorithms with no regard for maintainability or fitness to the task at hand. Unlike Elvis I think this one has some value, but I think it's a bit more interesting to talk about someone who is looking at the business value and putting in the extra effort to make the perfectly correct/performant/maintainable solution for the use case, rather than going with the easiest thing that works. It's still possible to overdo, but I think it makes the archetype more useful to steelman the perspective. Amanda sounds a bit more like this, but I think she might work better without the other three but with some better archetypes.
I think the personas have some validity but I don't agree with the primary focus/mode.
For example, I tend to be a mort because what gets me up in the morning is solving problems for the enterprise and seeing that system in action and providing benefit. Bigger and more complex problems are more fun to solve than simpler ones.
reply