Nobody is advocating for a ball of mud. Richard is describing incremental design via refactoring. This is a standard component of agile/extreme programming methodologies. I have seen it work. And it can be done using modules and functions as your only abstraction tools.
Disagree about what abstractions are the most useful. But throwing around the term "ball of mud" is nothing but name-calling. On Tuesday, April 18, 2017 at 3:39:25 PM UTC-7, Rupert Smith wrote: > > On Tuesday, April 18, 2017 at 9:13:58 PM UTC+1, Mark Hamburg wrote: >> >> 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. >> > > Well said. I kind of wanted to say something along these lines but you > articulated better than I could have. Parnas' modular design principles are > my principal guide. > > There is room for the mud-ball and the pristine encapsulated architecture. > I usually do some mud-ball hacking then figure out how I can tidy it up a > bit better with a view to encapsulating data models and operations so that > they are both well documented and can only be manipulated to produce legal > states, as well as how to improve a data model using the type system to > eliminate representations of illegal states. > > Learn both (or all) approaches, I guess. Nested TEA is working very nicely > for me and feels appropriate in many situations, but just not as a blanket > approach for everything. > -- 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.
