Comment by hcarvalhoalves
12 years ago
I think the author uses the term in the same way as the LISP quote, since he doesn't propose that we abolish BBoM, but rather manage it, as it solves practical problems and is a fact of life.
12 years ago
I think the author uses the term in the same way as the LISP quote, since he doesn't propose that we abolish BBoM, but rather manage it, as it solves practical problems and is a fact of life.
He uses big ball of mud is a software system that lacks a perceivable architecture.
Lisp BBoM is not lacking architecture. In the Lisp use of the term it means that you can extend the system incredibly without losing the "Lispiness". It looks and feels the same after extensions (if those extensions are done right). In Lisp building complex framework don't suddenly turn your programming xml-file configuration and annotating for code generators.
Wouldn't you agree that what gives LISP unbounded extensibility without changing it's form is exactly because it lacks an "architecture", the code is the AST itself?
It's not like McCarthy purposefully architected LISP to be minimal and immensely flexible, it naturally followed from implementing the simplest thing possible capable of manipulating lambda calculus; it's extensibility is a desirable emerging characteristic.