13 ms·

A common complaint about Lisp code in general is that programmers tend to write code that is idiosyncratic [ED: I previously used the word "idiomatic" here in r

A common complaint about Lisp code in general is that programmers tend to write code that is idiosyncratic [ED: I previously used the word "idiomatic" here in reply to the OP but was conflating terms, making this post rather irrelevant but at least it provoked a discussion] (i.e. rather than looking like templated design patterns with standard names, the program is heirarchically built of modules in a domain-specific language of the programmer's own design). This is both one of Lisp's greatest strengths to those who like it, and (I think, based on comments I've seen here and elsewhere) one of the greatest reasons it doesn't have more widespread adoption.

mike_ivanov 9y ago
"rather than looking like templated design patterns" - that is, the code goes straight to the point instead of being littered with incidental noise and ceremony? How that could possibly be a bad thing? Well, in certain software development subcultures ceremony might be a norm, but not in general.
- deleted 9y ago
  [deleted]
- Koshkin 9y ago
  From what I have seen, code that "goes straight to the point" is usually poorly thought out, is unmaintanable, has bugs, is difficult to extend to new use-cases, and the developer who wrote it is long gone.
  - hellofunk 9y ago
    That might be (perhaps) true in other languages, but that is not the point in Lisp.
    - Koshkin 9y ago
      Best practices, patterns, idioms are all important no matter what language. Lisp is not special in this regard (although, I admit, Lisp developers may stick around a bit longer).
      - hellofunk 9y ago
        There is a big difference between language idioms and design patterns.
      - flavio81 9y ago
        >Lisp is not special in this regard In reality, yes, at least because of two differences: 1. Lisp is a significantly more powerful language, compared to most non-Lisp languages. Thus, many patterns and practices that are needed in other languages, are simply not needed at all in Lisp, or become far simpler. 2. Lisp is a "programmable programming language" where code is a "first class citizen" and can be manipulated as well as any other kind of data such as numbers. This opens a very different approach to programming, with its own, different "best practices".
      - TeMPOraL 9y ago
        Best practices, patterns and idioms are all tools, not religious symbols. If you treat them as the latter, you end up with things like JavaScript one-line projects that have 1kb worth of grunt/gulp/webpack config files, or with HelloWorldFactoryLightweightBridgeBuilderAbstractFacade in Java.
  - TeMPOraL 9y ago
    No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs. The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor). Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics. I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html.
    - flavio81 9y ago
      You should expand this into an article or blog post!
      - TeMPOraL 9y ago
        You know what? I might actually do just that; I just need to collect my thoughts and outline some examples.
felideon 9y ago
I know what you are saying, but that is not what is meant by idiomatic Lisp. Not by Lispers at least. Non-idiomatic Lisp is typically written by beginners whose code looks more like the language they are accustomed to using previously. For instance, leaning heavily on a procedural style. And not just beginners, but also seasoned programmers that write object oriented Lisp more akin to static OOP. In other words, designing class hierarchies rather than protocols (using generic functions). What you describe is more of a side effect of the Bipolar Lisp Programmer[1]: > This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something. I haven't read Land of Lisp yet, so I can't really comment as to whether I'd consider it idiomatic Lisp or not. (OP meant "idiosyncratic" anyway, it seems.) Not that I'd be a good judge, anyway. [1] http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipolar.htm http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipo...
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- sverige 9y ago
  God, that link and the comic strip for the Land of Lisp are both so great! I might have to try Lisp again. >Writing in C is like building a mosaic out of lentils using a tweezer and glue. I cannot describe the memories and associated feelings this evokes....
hellofunk 9y ago
> rather than looking like templated design patterns Speaking about another lisp, Clojure, it is a goal that each program finds its own design pattern. That's kinda the whole idea. Design patterns can really get in the way, unless your language requires them, which some languages do (i.e. Java where everything must be an object, so OO it is, or Apple's platforms where the MVC pattern is deeply interwoven into all the APIs). Lisp in general is about exploring a particular problem using only the constraints of that problem, without concern for how different problems get solved. By contrast, design patterns are about forcing a common solution onto a range of different problems.
- flavio81 9y ago
  >By contrast, design patterns are about forcing a common solution onto a range of different problems. This is one of the best criticisms of Design Patterns i've ever read. Great point.
- sbov 9y ago
  > By contrast, design patterns are about forcing a common solution onto a range of different problems. I always viewed design patterns as providing a shared name for common solutions to common problems. And that forcing a common solution to a range of different problems was a misuse of them. But maybe I'm wrong.
  - bitwize 9y ago
    I like to think of design patterns as "TV Tropes for programming". The GoF probably intended their book to be taken in that spirot. But then design patterns became something that computer science students and job candidates got quizzed on...
  - kbp 9y ago
    > I always viewed design patterns as providing a shared name for common solutions to common problems. And that forcing a common solution to a range of different problems was a misuse of them. Exactly, a design pattern is just that: a pattern of design, that shows up organically after you have enough systems designed in the same language. Many of the design patterns that occur in languages like C++ and Java don't show up in Lisp because Lisp is a rather different language, but then we have our own design patterns as well, things like with- macros.

mike_ivanov 9y ago

"rather than looking like templated design patterns" - that is, the code goes straight to the point instead of being littered with incidental noise and ceremony? How that could possibly be a bad thing? Well, in certain software development subcultures ceremony might be a norm, but not in general.

deleted 9y ago
[deleted]
Koshkin 9y ago
From what I have seen, code that "goes straight to the point" is usually poorly thought out, is unmaintanable, has bugs, is difficult to extend to new use-cases, and the developer who wrote it is long gone.
- hellofunk 9y ago
  That might be (perhaps) true in other languages, but that is not the point in Lisp.
  - Koshkin 9y ago
    Best practices, patterns, idioms are all important no matter what language. Lisp is not special in this regard (although, I admit, Lisp developers may stick around a bit longer).
    - hellofunk 9y ago
      There is a big difference between language idioms and design patterns.
    - flavio81 9y ago
      >Lisp is not special in this regard In reality, yes, at least because of two differences: 1. Lisp is a significantly more powerful language, compared to most non-Lisp languages. Thus, many patterns and practices that are needed in other languages, are simply not needed at all in Lisp, or become far simpler. 2. Lisp is a "programmable programming language" where code is a "first class citizen" and can be manipulated as well as any other kind of data such as numbers. This opens a very different approach to programming, with its own, different "best practices".
    - TeMPOraL 9y ago
      Best practices, patterns and idioms are all tools, not religious symbols. If you treat them as the latter, you end up with things like JavaScript one-line projects that have 1kb worth of grunt/gulp/webpack config files, or with HelloWorldFactoryLightweightBridgeBuilderAbstractFacade in Java.
- TeMPOraL 9y ago
  No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs. The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor). Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics. I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html.
  - flavio81 9y ago
    You should expand this into an article or blog post!
    - TeMPOraL 9y ago
      You know what? I might actually do just that; I just need to collect my thoughts and outline some examples.

felideon 9y ago

I know what you are saying, but that is not what is meant by idiomatic Lisp. Not by Lispers at least. Non-idiomatic Lisp is typically written by beginners whose code looks more like the language they are accustomed to using previously. For instance, leaning heavily on a procedural style. And not just beginners, but also seasoned programmers that write object oriented Lisp more akin to static OOP. In other words, designing class hierarchies rather than protocols (using generic functions). What you describe is more of a side effect of the Bipolar Lisp Programmer[1]: > This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something. I haven't read Land of Lisp yet, so I can't really comment as to whether I'd consider it idiomatic Lisp or not. (OP meant "idiosyncratic" anyway, it seems.) Not that I'd be a good judge, anyway. [1] http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipolar.htm http://www.shenlanguage.org/lambdassociates/htdocs/blog/bipo...

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
sverige 9y ago
God, that link and the comic strip for the Land of Lisp are both so great! I might have to try Lisp again. >Writing in C is like building a mosaic out of lentils using a tweezer and glue. I cannot describe the memories and associated feelings this evokes....

hellofunk 9y ago

> rather than looking like templated design patterns Speaking about another lisp, Clojure, it is a goal that each program finds its own design pattern. That's kinda the whole idea. Design patterns can really get in the way, unless your language requires them, which some languages do (i.e. Java where everything must be an object, so OO it is, or Apple's platforms where the MVC pattern is deeply interwoven into all the APIs). Lisp in general is about exploring a particular problem using only the constraints of that problem, without concern for how different problems get solved. By contrast, design patterns are about forcing a common solution onto a range of different problems.

flavio81 9y ago
>By contrast, design patterns are about forcing a common solution onto a range of different problems. This is one of the best criticisms of Design Patterns i've ever read. Great point.
sbov 9y ago
> By contrast, design patterns are about forcing a common solution onto a range of different problems. I always viewed design patterns as providing a shared name for common solutions to common problems. And that forcing a common solution to a range of different problems was a misuse of them. But maybe I'm wrong.
- bitwize 9y ago
  I like to think of design patterns as "TV Tropes for programming". The GoF probably intended their book to be taken in that spirot. But then design patterns became something that computer science students and job candidates got quizzed on...
- kbp 9y ago
  > I always viewed design patterns as providing a shared name for common solutions to common problems. And that forcing a common solution to a range of different problems was a misuse of them. Exactly, a design pattern is just that: a pattern of design, that shows up organically after you have enough systems designed in the same language. Many of the design patterns that occur in languages like C++ and Java don't show up in Lisp because Lisp is a rather different language, but then we have our own design patterns as well, things like with- macros.