9 ms·

> Lisp is a powerful language that allows one to mix multiple logical levels within a program (especially through it's homoiconicity). Statement like these are

> Lisp is a powerful language that allows one to mix multiple logical levels within a program (especially through it's homoiconicity). Statement like these are what make me suspect Lisp code would be a maintenance nightmare. I am regularly refactoring code to separate multiple logical levels so we can more easily maintain our codebases. If this is a misunderstanding, can someone clarify?

akvadrako 8y ago
I agree, strong barriers between layers are important. Right now the best way to build them is by using different languages or runtimes - it’s hard to mix layers if they require explicit network or shell calls. If everything was in lisp the layers are naturally blurred.
- p4bl0 8y ago
  Racket is a Lisp that makes these layers somewhat explicit.
reikonomusha 8y ago
Good SW engineering practice helps. Code review, collaborative design, etc.
varjag 8y ago
There are perhaps languages out there which are better than Lisp for maintenance in some respect, but it's none of the mainstream ones. Lisp code is not particularly harder or easier to maintain; most of that depends on the original author(s) as with any codebase.
- crdoconnor 8y ago
  It's the reason Aaron Swartz gave for rewriting reddit in python: >The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain. http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit I suspect the problem is that LISP is too powerful. Language power is inversely related to maintainability/readability, as per the greatly underrated rule of least power: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
  - vnorilo 8y ago
    This. I find Lisp optimal for the small band of coder heroes scenario. They must align on cs philosophy, and taste. Grow the team, or have divergent approaches: the efficacy of Lisp quickly disappears and problems appear.
    - lispm 8y ago
      Is that hearsay, experience or a guess? There have been a few projects with 10 to 100+ Lisp programmers. What was their experience?
      - oblio 8y ago
        Well, at some point we have to face reality. There have been hundreds if not thousands of successful projects with teams of hundreds if not thousands of developers working on them, at the same time or over time. These projects have been generally in Cobol (ok, we can chalk that up to brute forcing a tech from they didn't know any better), C, C++, Java, C#. There seems to be a connection between scaling a project regarding developer numbers and programming language "power". Having a smaller, shared vocabulary seems to greatly outweigh programming language "power" as the number of programmers goes up greatly. Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced.
        thaumasiotes 8y ago
        > Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced. It can take more than you might expect to "convince". > In 1601, an English sea captain did a controlled experiment to test whether lemon juice could prevent scurvy. He had four ships, three control and one experimental. The experimental group got three teaspoons of lemon juice a day while the control group received none. No one in the experimental group developed scurvy while 110 out of 278 in the control group died of scurvy. Nevertheless, citrus juice was not fully adopted to prevent scurvy until 1865. ( https://www.johndcook.com/blog/2008/03/25/innovation-ii/ https://www.johndcook.com/blog/2008/03/25/innovation-ii/ )
- knowingpark 8y ago
  I don't use it, but I'm not noticing any such backlash for Clojure
kamaal 8y ago
>>Statement like these are what make me suspect Lisp code would be a maintenance nightmare. After having maintained Java code bases that do 300 classes just to post a JSON to a REST end point, I'm fairly confident Lisp code can't be that hard to maintain.
d--b 8y ago
Yes, this is why macros have been abandoned in most entreprise languages (C#, Java)
- coldtea 8y ago
  As if they've tried them and then abandoned them? Java, fone one, didn't even have generics and closures when it came out. It didn't have macros because it was intended for the ho-hum enterprise programmer of the time, who, the thought was, would not know what to do with them. Instead, they re-invented all those things badly (e.g. through gobs of XML and ugly reflection based metaprogramming).
  - kamaal 8y ago
    Nobody still uses them, even if they are available. In fact anything that doesn't looks enterprisey enough never goes past code reviews. The adoption cycle for even the simplest of Syntactical features when it comes to Java enterprise is >10+ years. In some companies its never. The saddest part isn't even that. The sad part is a whole generation of programmers have been raised, and turned to be architect astronauts without ever using something like a lambda or a closure. The only hope for programming as a craft now is hoping Oracle kills Java(even if by mistake), and then some thing like Perl 6 comes along to replace it.
    - AnimalMuppet 8y ago
      I'm not sure that will help. I see a kind of "family resemblance" between COBOL and enterprise Java. I wonder if any language that is going to play in this space is destined to become a monstrosity - destined by the nature of the problem space rather than the nature of the language. I am aware that when I say this, I am basing my opinion on a sample size of two...
  - d--b 8y ago
    Nonsense, the enterprise programmer of the time was programming in C or C++ and was making heavy use of macros. Macros, unlike generics are super easy to implement, so there is no reason not implement them, unless you specifically don't want to implement them. Java didn't have macros because no one wanted the kind of dialect that macros allow, ie. re-learning a language every time you change company.
PurpleRamen 8y ago
The more power and liberty a language offers, the more likely you will end in the state of "write once, never understand again".

akvadrako 8y ago

I agree, strong barriers between layers are important. Right now the best way to build them is by using different languages or runtimes - it’s hard to mix layers if they require explicit network or shell calls. If everything was in lisp the layers are naturally blurred.

p4bl0 8y ago
Racket is a Lisp that makes these layers somewhat explicit.

reikonomusha 8y ago

Good SW engineering practice helps. Code review, collaborative design, etc.

varjag 8y ago

There are perhaps languages out there which are better than Lisp for maintenance in some respect, but it's none of the mainstream ones. Lisp code is not particularly harder or easier to maintain; most of that depends on the original author(s) as with any codebase.

crdoconnor 8y ago
It's the reason Aaron Swartz gave for rewriting reddit in python: >The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain. http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit I suspect the problem is that LISP is too powerful. Language power is inversely related to maintainability/readability, as per the greatly underrated rule of least power: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
- vnorilo 8y ago
  This. I find Lisp optimal for the small band of coder heroes scenario. They must align on cs philosophy, and taste. Grow the team, or have divergent approaches: the efficacy of Lisp quickly disappears and problems appear.
  - lispm 8y ago
    Is that hearsay, experience or a guess? There have been a few projects with 10 to 100+ Lisp programmers. What was their experience?
    - oblio 8y ago
      Well, at some point we have to face reality. There have been hundreds if not thousands of successful projects with teams of hundreds if not thousands of developers working on them, at the same time or over time. These projects have been generally in Cobol (ok, we can chalk that up to brute forcing a tech from they didn't know any better), C, C++, Java, C#. There seems to be a connection between scaling a project regarding developer numbers and programming language "power". Having a smaller, shared vocabulary seems to greatly outweigh programming language "power" as the number of programmers goes up greatly. Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced.
      - thaumasiotes 8y ago
        > Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced. It can take more than you might expect to "convince". > In 1601, an English sea captain did a controlled experiment to test whether lemon juice could prevent scurvy. He had four ships, three control and one experimental. The experimental group got three teaspoons of lemon juice a day while the control group received none. No one in the experimental group developed scurvy while 110 out of 278 in the control group died of scurvy. Nevertheless, citrus juice was not fully adopted to prevent scurvy until 1865. ( https://www.johndcook.com/blog/2008/03/25/innovation-ii/ https://www.johndcook.com/blog/2008/03/25/innovation-ii/ )
knowingpark 8y ago
I don't use it, but I'm not noticing any such backlash for Clojure

kamaal 8y ago

>>Statement like these are what make me suspect Lisp code would be a maintenance nightmare. After having maintained Java code bases that do 300 classes just to post a JSON to a REST end point, I'm fairly confident Lisp code can't be that hard to maintain.

d--b 8y ago

Yes, this is why macros have been abandoned in most entreprise languages (C#, Java)

coldtea 8y ago
As if they've tried them and then abandoned them? Java, fone one, didn't even have generics and closures when it came out. It didn't have macros because it was intended for the ho-hum enterprise programmer of the time, who, the thought was, would not know what to do with them. Instead, they re-invented all those things badly (e.g. through gobs of XML and ugly reflection based metaprogramming).
- kamaal 8y ago
  Nobody still uses them, even if they are available. In fact anything that doesn't looks enterprisey enough never goes past code reviews. The adoption cycle for even the simplest of Syntactical features when it comes to Java enterprise is >10+ years. In some companies its never. The saddest part isn't even that. The sad part is a whole generation of programmers have been raised, and turned to be architect astronauts without ever using something like a lambda or a closure. The only hope for programming as a craft now is hoping Oracle kills Java(even if by mistake), and then some thing like Perl 6 comes along to replace it.
  - AnimalMuppet 8y ago
    I'm not sure that will help. I see a kind of "family resemblance" between COBOL and enterprise Java. I wonder if any language that is going to play in this space is destined to become a monstrosity - destined by the nature of the problem space rather than the nature of the language. I am aware that when I say this, I am basing my opinion on a sample size of two...
- d--b 8y ago
  Nonsense, the enterprise programmer of the time was programming in C or C++ and was making heavy use of macros. Macros, unlike generics are super easy to implement, so there is no reason not implement them, unless you specifically don't want to implement them. Java didn't have macros because no one wanted the kind of dialect that macros allow, ie. re-learning a language every time you change company.

PurpleRamen 8y ago

The more power and liberty a language offers, the more likely you will end in the state of "write once, never understand again".