6 ms·

I thought there was some interesting history in the book and certain common lisp implementations like SBCL are incredibly fast and powerful (some real secret al

I thought there was some interesting history in the book and certain common lisp implementations like SBCL are incredibly fast and powerful (some real secret alien technology there), but I thought that I could generally make shorter and clearer programs in just about any common scripting language (Python, Perl, PowerShell...etc). Granted, I know those languages better, but the book honestly didn't want to make me write Lisp. Homoiconicity is insanely powerful, but I find that specific syntax for certain things is easier for me to read and write up to a certain point.

tomjakubowski 5y ago
The best part of Land of Lisp is learning to use SLIME. Except that learning it (and REPL-driven development) makes all other language/editor integrations seem inadequate! (one exception I know is CIDER for Clojure, also excellent)
- mbrodersen 5y ago
  Not my experience at all. I have spent enough time doing REPL-driven development to know that I most definitely do not prefer it. It might be superior for you. But that doesn’t automatically mean that it will also be superior for anybody else. We are all different, with different preferences and work styles.
  - marai2 5y ago
    Would you mind shedding some light on how you do development and the pros and cons you experienced comparing to REPL-driven development?
    - mjul 5y ago
      Not OP, but I would venture that REPL-driven development encourages a style that is essentially trial and error programming. This may be good for small scale, short lived scripts and projects but it does not scale. My experience from a somewhat large (400+ people) Clojure project is that people would be better off building a test suite as a checked-into-source-control REPL substitute to drive their experiments and make sure the expected application behaviour stays the same over time. REPLs may be useful, but don’t use them as your only tool.
      - mbrodersen 5y ago
        Yep a good match for how I am thinking. One of the large projects I work on is written in C++ and it has more than 90000 use case tests to make sure it is safe to deploy into production. I haven’t had a customer production bug in the last 5+ years.
    - Blackthorn 5y ago
      For me, the biggest problem with REPL-driven development is the handling of global state. That's why there's no fewer than 5 (!) actually-being-used Clojure libraries for handling it.
      - capableweb 5y ago
        What "handling of global state" are you referring to? The state of "vars" or the state of actual application data (a la "atom"s)? The former being solved with the various ns-* functions, the latter depends on the application and how state is being used. If you could, could you share the libraries you're referring to too?
        Blackthorn 5y ago
        > If you could, could you share the libraries you're referring to too? Component, Mount, Integrant, System, Clip.
    - mbrodersen 5y ago
      Sure. I think REPL-driven development is great for what I call exploratory programming. When you are playing around with ideas and want to quickly try out different approaches and quickly test if a new function is working. However the code that I normally deal with are very large code bases where a lot of the code is not written by myself. And I find it a lot easier to navigate and build a mental model of where things are and how it works using an IDE. It simply works better for my brain but of course YMMV.
      - mtrower 5y ago
        Why not both? Are the two concepts somehow incompatible? A REPL is a (very) powerful tool for testing, probing, inspecting (etc) code; but it is only one tool. It should be a part of your IDE (if you go for such things), not replace it.
        mbrodersen 5y ago
        Wouldn't it make more sense to automate the tests instead of doing it manually? I have 9000+ auto tests for the large complex C++ code base I am currently maintaining. And the result is zero customer production bugs in the last 5+ years. And I routinely refactor and rewrite large parts of the code without worrying about it.
        mtrower 5y ago
        Yes, automated test suites are great! I don’t know that they need all the things some people stuff into them, but the idea is a useful one. If you take my comment in the context of REPL-driven development, it’s going to seem tangential at best. But you mentioned that you prefer IDEs over REPLs; I’m merely suggesting that the two need not be exclusive. Unless you’re advocating for TDD, in a strict sense?
- ngcc_hk 5y ago
  Not as that book. In fact it is after nearly 1 decade after I finished that book and finally do this REPL and live code editing in lisp via https://susam.net/blog/lisp-in-vim.html https://susam.net/blog/lisp-in-vim.html It would be better if it was ihtroduced then.
mbrodersen 5y ago
My reaction as well. The exaggerated claims of Lisp programs being bug free and non-Lisp programmers being slaves/prisoners/drones etc. doesn’t give me confidence in anything the author claims. I know it is supposed to be funny, and I do enjoy the humour, but I would prefer some real life stories about how complicated problems were fixed in Lisp better than what I could have been done in other languages. Lisp has cool features, but that doesn’t necessarily result in better software being developed in Lisp. Certainly looking around there doesn’t seem to be a lot of successful software written in Lisp. The world runs on other languages.
- NateEag 5y ago
  Lilypond (http://lilypond.org/index.html http://lilypond.org/index.html) is music typesetting software that is not for everyone, but can be a joy to use if you have a software background. It makes extensive use of Scheme under the hood, because C++ proved "too inflexible". I've never looked at the details of what the authors meant by that. They have some notes on it here if you're curious: http://lilypond.org/doc/v2.22/Documentation/essay/building-software#flexible-architecture http://lilypond.org/doc/v2.22/Documentation/essay/building-s...
  - mbrodersen 5y ago
    Thanks for the link! That was a great read. And a good example I think of using Lisp embedded in a C++ program to give the user more power and flexibility. I think it is the right way to do it when your UI is basically code. A lot of games do something similar (using embedded Python, Lua or Lisp) to make it possible for gamers to extend the game. I think Factorio use Lua for this. But Lisp would have been another good choice I think.
    - NateEag 5y ago
      You're welcome! Glad to hear you enjoyed it. I'm familiar with game engines embedding scripting languages, but using Lisp for that honestly hadn't occurred to me (despite being an Emacser that has written several small elisp packages).

tomjakubowski 5y ago

The best part of Land of Lisp is learning to use SLIME. Except that learning it (and REPL-driven development) makes all other language/editor integrations seem inadequate! (one exception I know is CIDER for Clojure, also excellent)

mbrodersen 5y ago
Not my experience at all. I have spent enough time doing REPL-driven development to know that I most definitely do not prefer it. It might be superior for you. But that doesn’t automatically mean that it will also be superior for anybody else. We are all different, with different preferences and work styles.
- marai2 5y ago
  Would you mind shedding some light on how you do development and the pros and cons you experienced comparing to REPL-driven development?
  - mjul 5y ago
    Not OP, but I would venture that REPL-driven development encourages a style that is essentially trial and error programming. This may be good for small scale, short lived scripts and projects but it does not scale. My experience from a somewhat large (400+ people) Clojure project is that people would be better off building a test suite as a checked-into-source-control REPL substitute to drive their experiments and make sure the expected application behaviour stays the same over time. REPLs may be useful, but don’t use them as your only tool.
    - mbrodersen 5y ago
      Yep a good match for how I am thinking. One of the large projects I work on is written in C++ and it has more than 90000 use case tests to make sure it is safe to deploy into production. I haven’t had a customer production bug in the last 5+ years.
  - Blackthorn 5y ago
    For me, the biggest problem with REPL-driven development is the handling of global state. That's why there's no fewer than 5 (!) actually-being-used Clojure libraries for handling it.
    - capableweb 5y ago
      What "handling of global state" are you referring to? The state of "vars" or the state of actual application data (a la "atom"s)? The former being solved with the various ns-* functions, the latter depends on the application and how state is being used. If you could, could you share the libraries you're referring to too?
      - Blackthorn 5y ago
        > If you could, could you share the libraries you're referring to too? Component, Mount, Integrant, System, Clip.
  - mbrodersen 5y ago
    Sure. I think REPL-driven development is great for what I call exploratory programming. When you are playing around with ideas and want to quickly try out different approaches and quickly test if a new function is working. However the code that I normally deal with are very large code bases where a lot of the code is not written by myself. And I find it a lot easier to navigate and build a mental model of where things are and how it works using an IDE. It simply works better for my brain but of course YMMV.
    - mtrower 5y ago
      Why not both? Are the two concepts somehow incompatible? A REPL is a (very) powerful tool for testing, probing, inspecting (etc) code; but it is only one tool. It should be a part of your IDE (if you go for such things), not replace it.
      - mbrodersen 5y ago
        Wouldn't it make more sense to automate the tests instead of doing it manually? I have 9000+ auto tests for the large complex C++ code base I am currently maintaining. And the result is zero customer production bugs in the last 5+ years. And I routinely refactor and rewrite large parts of the code without worrying about it.
        mtrower 5y ago
        Yes, automated test suites are great! I don’t know that they need all the things some people stuff into them, but the idea is a useful one. If you take my comment in the context of REPL-driven development, it’s going to seem tangential at best. But you mentioned that you prefer IDEs over REPLs; I’m merely suggesting that the two need not be exclusive. Unless you’re advocating for TDD, in a strict sense?
ngcc_hk 5y ago
Not as that book. In fact it is after nearly 1 decade after I finished that book and finally do this REPL and live code editing in lisp via https://susam.net/blog/lisp-in-vim.html https://susam.net/blog/lisp-in-vim.html It would be better if it was ihtroduced then.

mbrodersen 5y ago

My reaction as well. The exaggerated claims of Lisp programs being bug free and non-Lisp programmers being slaves/prisoners/drones etc. doesn’t give me confidence in anything the author claims. I know it is supposed to be funny, and I do enjoy the humour, but I would prefer some real life stories about how complicated problems were fixed in Lisp better than what I could have been done in other languages. Lisp has cool features, but that doesn’t necessarily result in better software being developed in Lisp. Certainly looking around there doesn’t seem to be a lot of successful software written in Lisp. The world runs on other languages.

NateEag 5y ago
Lilypond (http://lilypond.org/index.html http://lilypond.org/index.html) is music typesetting software that is not for everyone, but can be a joy to use if you have a software background. It makes extensive use of Scheme under the hood, because C++ proved "too inflexible". I've never looked at the details of what the authors meant by that. They have some notes on it here if you're curious: http://lilypond.org/doc/v2.22/Documentation/essay/building-software#flexible-architecture http://lilypond.org/doc/v2.22/Documentation/essay/building-s...
- mbrodersen 5y ago
  Thanks for the link! That was a great read. And a good example I think of using Lisp embedded in a C++ program to give the user more power and flexibility. I think it is the right way to do it when your UI is basically code. A lot of games do something similar (using embedded Python, Lua or Lisp) to make it possible for gamers to extend the game. I think Factorio use Lua for this. But Lisp would have been another good choice I think.
  - NateEag 5y ago
    You're welcome! Glad to hear you enjoyed it. I'm familiar with game engines embedding scripting languages, but using Lisp for that honestly hadn't occurred to me (despite being an Emacser that has written several small elisp packages).