Re:Lisp: it's not about macros, it's about READ (2012)
by nnq on Monday July 18, 2016 @06:38AM
(#12114237)
Is this based on real world examples (like, Lisp projects that you know have failed because the code has turned into an unmaintainable mess), or just using your intuition to extrapolate along the lines of "uh, this language is very flexible, most people are idiots and use excessive flexibility to hang themselves ergo this language would lead to unmaintainable code"?
...because by the same reasoning you could reach the conclusion that all dynamic languages lead to unmaintainable code, therefore nobody should use them :)
Re:Lisp: it's not about macros, it's about READ (2012)
by marcosdumay on Monday July 18, 2016 @01:48PM
(#12116764)
To some extent, that is true.
Take some Python lib that does heavy use of reflection and peek at it's source code.
Those features do make code harder to maintain. But with Lisp you not only have more powerful metaprogramming features, you also have a community that embraces and recommends their use, instead of weighting their usefulness against their maintenance cost.
Re:Lisp: it's not about macros, it's about READ (2012)
by HelloNurse on Monday July 18, 2016 @01:20PM
(#12116506)
The unfathomable DSL is a problem with undocumented code in very important places, not with LISP. LISP is merely powerful enough that people can have this problem.
You can force the "bearded hackers" to write documentation and not make a mess in any language.
The list could go on and on. I'm not a big Lisp fan, but you have to give credit where it's due. Most newer languages do not even have half of the features that modern CommonLisp implementations offer. You're right about memory consumption, of course, but using Lisp for embedded devices has always been a stupid idea.
The problem of Lisp is certainly not expressivity, and also not speed, memory consumption, or the syntax. It's not even the dynamic typing as long you use a good unit testing framework. The real problem is that every program becomes a DSL and even seasoned Lisp hackers cannot read other programmers' code. Large Lisp programs too easily become a big hacky mess that nobody but the original inventor understands. And the community aggravates this problem, because they really are nasty, bearded hackers who'd just write their own OOP implementation over the weekend when they aren't in the mood for using one of a hundred already existing ones.
Lisp code is just not maintainable enough. My 2 cents.