5 ms·

I'd like to hear your opinion about the following vision of language comparisons: Lisp as a language is much more malleable to the problem at hand. This will

I'd like to hear your opinion about the following vision of language comparisons: Lisp as a language is much more malleable to the problem at hand. This will mean it will attract a small group of smarter people, but create code which is harder to read and hence harder to give to other people. Hence, lisp programs tend be smaller, more creative, better quality, faster to create, but also to stagnate when their creators leave. Java, more recently Go, and maybe even Cobol, attract a bigger group of more average people. They'll write in a simpler, more standardized style. The programs tend to be more bureacratic, average, less optimized, but also much more readable. They are the better choice when you need maintainability over a long time by a varied group of programmers. I don't remember where this came from, it's certainly not my own idea. It doesn't sound completely bollocks, but have no idea if its true or not.

fiddlerwoaroof 5y ago
I’m not the person you’re asking, but I’ve spent a bunch of time fixing bugs in other people’s lisp libraries and haven’t found this to be true at all. If anything, because Lisp encourages you to adapt the language to the problem domain, others people’s code tends to be easier to understand because the code tends to use names and constructs that makes sense to someone that understands the problem domain.
- lisper 5y ago
  Yes, I agree with this. Lisp is tremendously powerful, and like all power, it can be abused. But when used properly it can produce some very easy-to-read and maintainable code precisely because of its malleability. Take a look at this for example: https://flownet.com/ron/lisp/djbec.lisp https://flownet.com/ron/lisp/djbec.lisp In that code I used an embedded an infix parser and macros to allow me to write modular bignum arithmetic expressions as infix. That lets me cut-and-paste the infix versions of elliptic curve point addition algorithms and use them directly without translating them into s-expressions, which eliminates the possibility of transcription errors. The resulting code is much easier to read than if I'd had to actually translate all the modular math into standard Common Lisp.
- deleted 5y ago
  [deleted]
fungiblecog 5y ago
The Java program may be more readable in small snippets but a large Java program is often completely incomprehensible because the overall structure doesn't map well to the problem being solved. A lisp program with comparable functionality can be much smaller and more comprehensible due to the ability to mould the language to the business problem.
- pharmakom 5y ago
  Yes!! Java programs often have so many classes, methods and interfaces that it’s hard to comprehend the overall flow of the application. Terse languages (lisps and MLs come to mind) can often solve the same problem in a single page.
  - quantified 5y ago
    +1. “Let’s distribute all our algorithms in tiny chunks everywhere” seems to be the goal of some code bases. It’s unnecessary, you can control data and algorithm differently in most cases.
    - taeric 5y ago
      I cringe at how many code reviews are essentially, take this 40 line function that does things we don't need anywhere else, and split it into 5 other abstractions. I mean... the review isn't wrong. You can totally split the functionality in ways that are very logical. But... did it really make THIS program easier?
      - pjmlp 5y ago
        The dashboards used for QA code complexity metrics to assess project delivery now look nicer.
      - pkolaczk 5y ago
        It should make it definitely easier to read, if names of the extracted functions are good, signatures are simple and you can understand well what they do without looking at their implementations. The main point of abstraction is not reusability, but the ability to understand code without a need to read all of it. Therefore it doesn't really matter if these extracted pieces aren't used anywhere else. But after splitting, now someone has to read and understand only 5 lines instead of 40, which reduces the cognitive load.
ssivark 5y ago
Something I’m struck by in reading such discussions (esp on forums) is how often people’s choice of programming languages (and tools, more generally) is from a defensive stance. I understand that when working on problems where better technology is unlikely to lead to significant advantages (so you’d prefer to cap the potential downsides), but I’m still surprised by the sheer paucity of examples where people are willing to make aggressive technology choices to get leverage on their goals. I wonder whether that’s another manifestation of the blub paradox.
erik_seaberg 5y ago
A good domain-specific language is much easier to read than a general-purpose language that forces you to continually restate the basics of the problem. But defining and then learning that DSL are time investments. If you find yourself working in a tarpit that rewrites everything every year or two, they can’t trust that the investment will get a chance to pay off before they throw it away. But I at least want to master the most powerful general-purpose language they’ll let me use, because that investment will keep paying off until I find one that’s better still.

fiddlerwoaroof 5y ago

I’m not the person you’re asking, but I’ve spent a bunch of time fixing bugs in other people’s lisp libraries and haven’t found this to be true at all. If anything, because Lisp encourages you to adapt the language to the problem domain, others people’s code tends to be easier to understand because the code tends to use names and constructs that makes sense to someone that understands the problem domain.

lisper 5y ago
Yes, I agree with this. Lisp is tremendously powerful, and like all power, it can be abused. But when used properly it can produce some very easy-to-read and maintainable code precisely because of its malleability. Take a look at this for example: https://flownet.com/ron/lisp/djbec.lisp https://flownet.com/ron/lisp/djbec.lisp In that code I used an embedded an infix parser and macros to allow me to write modular bignum arithmetic expressions as infix. That lets me cut-and-paste the infix versions of elliptic curve point addition algorithms and use them directly without translating them into s-expressions, which eliminates the possibility of transcription errors. The resulting code is much easier to read than if I'd had to actually translate all the modular math into standard Common Lisp.
deleted 5y ago
[deleted]

fungiblecog 5y ago

The Java program may be more readable in small snippets but a large Java program is often completely incomprehensible because the overall structure doesn't map well to the problem being solved. A lisp program with comparable functionality can be much smaller and more comprehensible due to the ability to mould the language to the business problem.

pharmakom 5y ago
Yes!! Java programs often have so many classes, methods and interfaces that it’s hard to comprehend the overall flow of the application. Terse languages (lisps and MLs come to mind) can often solve the same problem in a single page.
- quantified 5y ago
  +1. “Let’s distribute all our algorithms in tiny chunks everywhere” seems to be the goal of some code bases. It’s unnecessary, you can control data and algorithm differently in most cases.
  - taeric 5y ago
    I cringe at how many code reviews are essentially, take this 40 line function that does things we don't need anywhere else, and split it into 5 other abstractions. I mean... the review isn't wrong. You can totally split the functionality in ways that are very logical. But... did it really make THIS program easier?
    - pjmlp 5y ago
      The dashboards used for QA code complexity metrics to assess project delivery now look nicer.
    - pkolaczk 5y ago
      It should make it definitely easier to read, if names of the extracted functions are good, signatures are simple and you can understand well what they do without looking at their implementations. The main point of abstraction is not reusability, but the ability to understand code without a need to read all of it. Therefore it doesn't really matter if these extracted pieces aren't used anywhere else. But after splitting, now someone has to read and understand only 5 lines instead of 40, which reduces the cognitive load.

ssivark 5y ago

Something I’m struck by in reading such discussions (esp on forums) is how often people’s choice of programming languages (and tools, more generally) is from a defensive stance. I understand that when working on problems where better technology is unlikely to lead to significant advantages (so you’d prefer to cap the potential downsides), but I’m still surprised by the sheer paucity of examples where people are willing to make aggressive technology choices to get leverage on their goals. I wonder whether that’s another manifestation of the blub paradox.

erik_seaberg 5y ago

A good domain-specific language is much easier to read than a general-purpose language that forces you to continually restate the basics of the problem. But defining and then learning that DSL are time investments. If you find yourself working in a tarpit that rewrites everything every year or two, they can’t trust that the investment will get a chance to pay off before they throw it away. But I at least want to master the most powerful general-purpose language they’ll let me use, because that investment will keep paying off until I find one that’s better still.