Languages don't create unmaintainable code, people do. I don't get why there's such hate against Lisp. (Granted, as others have noted, the author of this paper obviously drank from the Lisp kool-aid fountain)
Have you ever seen so-called academic code? If your developers are PhDs without a programming background, you're bound to get programs that reflect the complexity of their own throught process plus the subject they are dealing with. I don't think encouraging that through something as unbound as Lisp is a good idea, as much as I love how unbound Lisp is.
Python probably hits a sweet spot in this regard.
It's possible to write horrible python code. But it's way harder
Even without an editor, you are forced to indent. You can't use macro or make huge anonymous functions. The whole language is designed around readability.
Like in Python, we have context managers (with statements), they're cool but we can't do much inside them. I wanted to use them to add logs to a list and automatically return it from my api. I couldn't, I had to do that manually everywhere.
Now enters a new developer. In Python he would learn the base style, function names, the use of our custom context manager plus the need to manually feed and return the list of logs. In Lisp he would learn that our context manager (a macro) handles the logs.
---
This thread gets comparisons to Python, so let's enlarge the comparison spectrum: Lisp has a better REPL (enjoy ipython ? You'll love a Lisp REPL !), better type inference, it is a compiled language, making it a breeze to build an executable of your web app and deploy it to your server, a better object system (method combination, polymorphism, methods not bound to classes,…), Lisp is stable,…
I think I see the problem.
100 line functions, aside from methods in DAOs, are a code smell in any language.
Being able to apply the resulting work to the real world is very hard, because for a programmer - you have to package it up in a way that's easily digestible to people who don't want to have to go through the process of reinventing the wheel from scratch in order to understand it (or just don't have the time to).
Lisp doesn't have to be complicated with a billion bells and whistles to be good lisp code. If you approach learning it from there, you build your own, don't have to compare it to PhD level research. It might one day get to that point, where no one can understand or wants to understand what you've created, but that's the other side - the isolation that comes with being an academic.
The subtlety here is that there is the complexity inherent to the problem domain, which is what you are referring to, and code complexity that arises from translating that complexity to a programming context.
Environments like SciPy, Matlab, R, and Julia get rid of a lot of the latter while still forcing certain conventions to follow that make the code easier to read for outsiders, leaving the complexity of the algorithm itself.
And I probably should have used Julia instead of Python as an example, since it aims and IMO succeeds as a "goldilocks" language that combines a lot of great ideas from all aforementioned languages plus Lisp[0]. IIRC, it is sometimes jokingly referred to as "secretly a Lisp" because part of the compiler is writting in... I think Scheme?
[0] https://docs.julialang.org/en/release-0.4/manual/metaprogram...
Femtolisp, created by Jeff Bezanson who is also a co-creator of Julia.
and
>>Python probably hits a sweet spot in this regard.
Willing to learn more on how Python magically converts PhD level quantum mechanics, and related Math to easily understandable stuff.
Also Im all ears, please explain to me how the crappiest and the most competent programmers all become same by the mere use of Python.
Well yeah but guns make it much easier.