https://en.m.wikipedia.org/wiki/Big_ball_of_mud
To say, the architectural guidance is to decompose things with functions is essentially no guidance (architecture) at all since functions are what one would be building with anyway in a functional language. TEA did outline a way to build Elm programs. If you discard the nested aspects, then it's just the API to the program function. That said, I used the term being also aware of its more positive usage with regard to LISP. Mark On Tue, Apr 18, 2017 at 5:05 PM Nicholas Hollon <[email protected]> wrote: > 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. > > > -- 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.
