5 ms·

Common Lisp was finalized in the 90s. And it's not its fault that the other languages haven't caught up yet.

by Grue3 8y ago

maze-le 8y ago
Still, its a trip to hell to maintain any lisp codebase -- especially if it contains macros. I think it is actively hostile to collaborative programming, and that is a structural problem where there is no remedy but obscure programming patterns (which are amplifying these problems in some instances). With that in mind -- boasting about 'the most advanced language' is a bit of a stretch -- to say the least...
- 4thaccount 8y ago
  They're looking at it from the point of one to a few coders and you're looking at it from an industrial view with larger teams. I think it probably shines more in the former. If macros aren't overused, it's probably not all that different from other dynamic languages like Python that work fine with larger teams.
  - sametmax 8y ago
    It is very different than Python. In Lisp, they say "here is a tool that can do anything. Have fun". In Python they say: "here are many tools that are specific and limited to that purpose. Also you gona take bad decisions, so we limited it some more". The first approach is appealing to very good programmers. The second one, to anybody who had to work with the vast majority of normal programmers. I prefer the second one. People abuse macros, make way to long lambdas, don't document their magic and indent poorly if they are not forced to. Since tooling is something people always learn too late, I'm going with the language with sane defaults.
    - kyancey 8y ago
      The first approach is also appealing to very bad programmers who think they're good programmers.
    - lispm 8y ago
      Yet Common Lisp nicely scales to very large programs, some which have been maintained for decades. MLOC range.
      - sametmax 8y ago
        And I bet you $10k that mostly 10x programmers work on the code base. In fact, I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. And there is a limited pool of that. We, humans, also have work to do.
        lispm 8y ago
        > I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that one needs to be a 10x programmer to use Lisp - many of those 10x programmers are not programming in Lisp, since the 10x programmer gets hired because he/she might be able to cope with enterprise Java architectures. Since Lisp is a programmer amplifier, you might think that these Lisp users are 10x programmers, when in fact they are not. But there are domains where people are using Lisp, who are not focused on programming. For example there are various Lisp-based music apps + literature which are used by composers. Example: https://opusmodus.com https://opusmodus.com
        vram22 8y ago
        >Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)
        8y ago
- PuercoPop 8y ago
  Do you say that out of experience? That is certainly not my _experience_. Lisp codebases tend to be easily "appropiable"
  - varjag 8y ago
    It sounds more like someone's musing of why Lisp should be bad idea rather than anything practical. Doubly so when they don't seem to know what Common Lisp is.
    - PuercoPop 8y ago
      I agree it _sounds_ like an armchair critic, but I prefer to give the benefit of the doubt. Maybe they had a bad experience involving Lisp? The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.
      - fiddlerwoaroof 8y ago
        Yeah, and the other thing is that the macrostep expander in slime makes it fairly straightforward to understand how an unfamiliar macro works: you just expand it a couple steps and see how its mapping the surface syntax to utilities you know. In fact, I often find function calls harder to grok now than custom macros :)
  - fiddlerwoaroof 8y ago
    Yeah, Common Lisp is one of the few languages where I feel comfortable diving into a foreign code base and submitting patches.
- lispm 8y ago
  http://www.greghendershott.com/fear-of-macros/fear-of-macros.jpg http://www.greghendershott.com/fear-of-macros/fear-of-macros... Which would easily make decades old and still maintained Lisp implementations unmaintainable, since they contain zillions of macros themselves.
- arethuza 8y ago
  Macros are fine - 'creative' use of reader macros can result in something similar to C pre-processor abuse - opening a file and going "what language is this?".
- cracauer 8y ago
  Well, keep in mind that "macros" in Lisp are really compile-time computing. In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types. So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose. I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-1-d4d96099cea0 https://medium.com/@MartinCracauer/a-gentle-introduction-to-... I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.
  - pjmlp 8y ago
    > I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types. There is Boost.Hana and the older Boost MPL and brigand. C++20 will have more constexpr improvements. Although I do conceed they require a C++ Wizard hat, and aren't not even close of Lisp's macros friendliness.

Common Lisp was finalized in the 90s. And it's not its fault that the other languages haven't caught up yet.

by Grue3 8y ago

Common Lisp was finalized in the 90s. And it's not its fault that the other languages haven't caught up yet.

Still, its a trip to hell to maintain any lisp codebase -- especially if it contains macros. I think it is actively hostile to collaborative programming, and that is a structural problem where there is no remedy but obscure programming patterns (which are amplifying these problems in some instances). With that in mind -- boasting about 'the most advanced language' is a bit of a stretch -- to say the least...

4thaccount 8y ago
They're looking at it from the point of one to a few coders and you're looking at it from an industrial view with larger teams. I think it probably shines more in the former. If macros aren't overused, it's probably not all that different from other dynamic languages like Python that work fine with larger teams.
- sametmax 8y ago
  It is very different than Python. In Lisp, they say "here is a tool that can do anything. Have fun". In Python they say: "here are many tools that are specific and limited to that purpose. Also you gona take bad decisions, so we limited it some more". The first approach is appealing to very good programmers. The second one, to anybody who had to work with the vast majority of normal programmers. I prefer the second one. People abuse macros, make way to long lambdas, don't document their magic and indent poorly if they are not forced to. Since tooling is something people always learn too late, I'm going with the language with sane defaults.
  - kyancey 8y ago
    The first approach is also appealing to very bad programmers who think they're good programmers.
  - lispm 8y ago
    Yet Common Lisp nicely scales to very large programs, some which have been maintained for decades. MLOC range.
    - sametmax 8y ago
      And I bet you $10k that mostly 10x programmers work on the code base. In fact, I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. And there is a limited pool of that. We, humans, also have work to do.
      - lispm 8y ago
        > I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that one needs to be a 10x programmer to use Lisp - many of those 10x programmers are not programming in Lisp, since the 10x programmer gets hired because he/she might be able to cope with enterprise Java architectures. Since Lisp is a programmer amplifier, you might think that these Lisp users are 10x programmers, when in fact they are not. But there are domains where people are using Lisp, who are not focused on programming. For example there are various Lisp-based music apps + literature which are used by composers. Example: https://opusmodus.com https://opusmodus.com
        vram22 8y ago
        >Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)
        8y ago
PuercoPop 8y ago
Do you say that out of experience? That is certainly not my _experience_. Lisp codebases tend to be easily "appropiable"
- varjag 8y ago
  It sounds more like someone's musing of why Lisp should be bad idea rather than anything practical. Doubly so when they don't seem to know what Common Lisp is.
  - PuercoPop 8y ago
    I agree it _sounds_ like an armchair critic, but I prefer to give the benefit of the doubt. Maybe they had a bad experience involving Lisp? The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.
    - fiddlerwoaroof 8y ago
      Yeah, and the other thing is that the macrostep expander in slime makes it fairly straightforward to understand how an unfamiliar macro works: you just expand it a couple steps and see how its mapping the surface syntax to utilities you know. In fact, I often find function calls harder to grok now than custom macros :)
- fiddlerwoaroof 8y ago
  Yeah, Common Lisp is one of the few languages where I feel comfortable diving into a foreign code base and submitting patches.
lispm 8y ago
http://www.greghendershott.com/fear-of-macros/fear-of-macros.jpg http://www.greghendershott.com/fear-of-macros/fear-of-macros... Which would easily make decades old and still maintained Lisp implementations unmaintainable, since they contain zillions of macros themselves.
arethuza 8y ago
Macros are fine - 'creative' use of reader macros can result in something similar to C pre-processor abuse - opening a file and going "what language is this?".
cracauer 8y ago
Well, keep in mind that "macros" in Lisp are really compile-time computing. In Lisp you have the same language at your disposal at runtime and at compile time. In C/C++ you have the preprocessor, which is a really lousy language. And in C++ templates. Remember the "template metaprogramming" hype about 10 years ago? How far did they go? Compute some prime numbers? I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types. So, "macros" in Lisp are really a new capability, and they can make code very dense. But think about the alternative - rolling out all this code with generating it at compile time from a single point of origin. That is the real maintenance nightmare. Every time you make an assumption during programming you want to contain that assumption in a single place. So that when the assumption changes later (otherwise known as "always" when other people are involved in telling you what the program is supposed to do in the end) you change a single place, and the rest of the dependent code is generated at compile time - using the full programming language you chose. I started a web series on compile-time computing. Didn't get as far as I wished for now, but here is some: https://medium.com/@MartinCracauer/a-gentle-introduction-to-compile-time-computing-part-1-d4d96099cea0 https://medium.com/@MartinCracauer/a-gentle-introduction-to-... I actually plan to use some of the chemical code I write (for the above mentioned Cando/Clasp chemical package) to make more parts of that series.
- pjmlp 8y ago
  > I mean C++ templates are a compile-time language, but they are a language that has only one type - types and no real iterations over collection types. Wait, they have no collection types. The one and only type is types. There is Boost.Hana and the older Boost MPL and brigand. C++20 will have more constexpr improvements. Although I do conceed they require a C++ Wizard hat, and aren't not even close of Lisp's macros friendliness.