The remark that composing TEA-shaped units isn't what Elm is designed for raises the question of whether we should then be expecting Cmd.map and friends to be going away since that would seem to be exactly what they are designed for.
Having read the reddit thread about just starting big and breaking things down, it reminds of arguments I've heard for years about how monolithic programs are easier to work with. They are. That's how we end up with them. It's almost always easier to tack a little more onto an existing ball of mud. If you've never worked in a statically-typed language then maybe Elm's type checking seems like a revelation, but it isn't so revolutionary as to throw out the experience that even static type-checking only gets you so far. Everything that can change the model can violate the constraints on the model that fall beyond the capabilities of the type system. Everything that sees the full model is a potential dependency for each and every piece of the model. Abstraction barriers are what make big programs possible. I don't think there is any magic in Elm that changes this fundamental lesson of 60 years of software development. It may make you feel you can move the boundaries relative to what some other languages afford, but if your architecture comes down to saying at the surface we have these few concepts but inside that we just have a big ball of type-checked mud, that's not really an architecture. The rest of the world has looked st TEA and seen value in it and is looking to extend it. It's sad to see Elm itself — which really is a nice language — potentially treating it as little more than a veneer. I welcome efforts like Marek's to try to figure out how to build something other than a ball of mud with Elm. Mark On Tue, Apr 18, 2017 at 10:04 AM Richard Feldman < [email protected]> wrote: > 2. This isn't really about defining components — a hot button word with >> some people (go read the elm-dev thread) — so much as it is about defining >> embeddings of one TEA-shaped unit within another. >> >> Side note on TEA: In Elm 0.16, TEA was all about being composable. >> > > I really like this phrasing. > > Crucially, between 0.16 and today, *we learned that a Model-View-Update > triplet is the wrong unit of composition for Elm applications.* > > It's important that people understand the historical context here: many of > us have tried this, and found that composing individual functions was both > simpler and consistently led to a much better experience. I've laid out my > advice for specifically how to do that here > <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/> > . > > In any event, I recommend that those interested in ways to structure large >> Elm programs go look at this. It doesn't radically change anything but it >> could be a better way to express the composition of TEA-shaped units. >> > > I'll reiterate that thinking about application organization as "composing > TEA-shaped units" is neither officially recommended nor what Elm is > designed for, and many folks have tried to fit that round peg into the > square hole and reported that it led to pain at scale. Specifically I've > had many people tell me that refactoring according to this advice > <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbkpgbd/> > led > to a much better experience. > > Exploring can be fun, but if you're looking for a good way to organize > your Elm applications, be aware that this particular path has been explored > before - and there's a signpost next to it labeled "WARNING: PIT OF > SNAKES AHEAD." ;) > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
