5 ms·

I often hear about lisp but never actually figured out what tooling you need Is it interpreted or compiled language? Why should I use it instead of any other la

by Geof25 1mo ago

I often hear about lisp but never actually figured out what tooling you need Is it interpreted or compiled language? Why should I use it instead of any other languages?

stackghost 1mo ago
"Lisp" refers to several different languages in the same family, which contributes to the confusion. Perhaps the default choice is Common Lisp which itself is specified in an ANSI standard and has several competing implementations. Some are compiled, some are interpreted. Arguably the best is SBCL, which has a mature compiler and garbage collection. If you lean on implementation-specific features you can produce extremely fast code that approaches the performance of C in some benchmarks, but idiomatic and portable lisp is slower in practice. >Why should I use it instead of any other languages? The killer feature used to be the REPL. You can write the application function by function, and test the functions, data structures, or classes you write in the REPL as you're actively building the app. Nowadays with LLMs writing all the code, I honestly don't see much reason to reach for lisp. Agents don't require a REPL, and other languages have vastly superior library support.
- red_admiral 1mo ago
  > You can write the application function by function ... and then use JUnit or TestNG in Java, or similar features in other languages. Which you can automatically run, including showing code coverage, both with a button in your IDE and as part of the CI/CD process when you commit.
  - Zak 1mo ago
    Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state. If you've already thought out the whole program before you start writing it, that may not be as valuable. In my experience, software often isn't that way and the ease of exploration a REPL and long-running process provide are unmatched.
    - bluGill 1mo ago
      yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work. There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
      - stackghost 1mo ago
        >I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way. That does not match my experience with lisp.
        jottinger 1mo ago
        Mine, either.
        bluGill 1mo ago
        My last experience with lisp was assignments in college which are too small to count as anything more than a toy problem. For real world code in other languages I've worked with the complexity of the problems demands so much code that the REPL cannot keep up.
        Zak 1mo ago
        > the complexity of the problems demands so much code that the REPL cannot keep up. Now we disagree, at least in part. REPL-driven development is in part about incrementalism. You wouldn't run all the complex code every time you want to examine some state or try out an experiment. You would run it once at the start of your session, then compile just the definition you're editing with your editor's equivalent of `compile-defun`. Of course that breaks if you're making changes that touch a bunch of different areas of your program and require rebuilding all the state, but it's usually a mistake to design programs in a way that would make such an issue frequent.
- guenthert 1mo ago
  > The killer feature used to be the REPL. The killer (hah!) feature is arguably its homoiconicity, allowing to modify the language easily within itself ("macros"). This has the obvious advantage that you can add missing features (usually) easily yourself; and exactly that causes headaches for those tasked with maintaining other people's code. > Nowadays with LLMs writing all the code Oh, you came all the way from the future and that's what you bring us?
  - stackghost 1mo ago
    I never said I liked the future, but it is what it is. If you're building products without LLMs today you're going to get outcompeted by people who do, and can iterate faster. I have written a fair bit of lisp and when it isn't refusing to fix security bugs because openai are cowards, 5.6-Sol can do in hours what would take me days.
- pjmlp 1mo ago
  The best is kind of debatable as it lacks the IDE tooling from LispWorks and Allegro.
  - stackghost 1mo ago
    >The best is kind of debatable I used the word "arguably" in the very first word of that sentence: >Arguably the best is SBCL The word arguable is a synonym for the word debatable.

by Geof25 1mo ago

I often hear about lisp but never actually figured out what tooling you need Is it interpreted or compiled language? Why should I use it instead of any other languages?

stackghost 1mo ago

"Lisp" refers to several different languages in the same family, which contributes to the confusion. Perhaps the default choice is Common Lisp which itself is specified in an ANSI standard and has several competing implementations. Some are compiled, some are interpreted. Arguably the best is SBCL, which has a mature compiler and garbage collection. If you lean on implementation-specific features you can produce extremely fast code that approaches the performance of C in some benchmarks, but idiomatic and portable lisp is slower in practice. >Why should I use it instead of any other languages? The killer feature used to be the REPL. You can write the application function by function, and test the functions, data structures, or classes you write in the REPL as you're actively building the app. Nowadays with LLMs writing all the code, I honestly don't see much reason to reach for lisp. Agents don't require a REPL, and other languages have vastly superior library support.

red_admiral 1mo ago
> You can write the application function by function ... and then use JUnit or TestNG in Java, or similar features in other languages. Which you can automatically run, including showing code coverage, both with a button in your IDE and as part of the CI/CD process when you commit.
- Zak 1mo ago
  Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state. If you've already thought out the whole program before you start writing it, that may not be as valuable. In my experience, software often isn't that way and the ease of exploration a REPL and long-running process provide are unmatched.
  - bluGill 1mo ago
    yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work. There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
    - stackghost 1mo ago
      >I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way. That does not match my experience with lisp.
      - jottinger 1mo ago
        Mine, either.
      - bluGill 1mo ago
        My last experience with lisp was assignments in college which are too small to count as anything more than a toy problem. For real world code in other languages I've worked with the complexity of the problems demands so much code that the REPL cannot keep up.
        Zak 1mo ago
        > the complexity of the problems demands so much code that the REPL cannot keep up. Now we disagree, at least in part. REPL-driven development is in part about incrementalism. You wouldn't run all the complex code every time you want to examine some state or try out an experiment. You would run it once at the start of your session, then compile just the definition you're editing with your editor's equivalent of `compile-defun`. Of course that breaks if you're making changes that touch a bunch of different areas of your program and require rebuilding all the state, but it's usually a mistake to design programs in a way that would make such an issue frequent.
guenthert 1mo ago
> The killer feature used to be the REPL. The killer (hah!) feature is arguably its homoiconicity, allowing to modify the language easily within itself ("macros"). This has the obvious advantage that you can add missing features (usually) easily yourself; and exactly that causes headaches for those tasked with maintaining other people's code. > Nowadays with LLMs writing all the code Oh, you came all the way from the future and that's what you bring us?
- stackghost 1mo ago
  I never said I liked the future, but it is what it is. If you're building products without LLMs today you're going to get outcompeted by people who do, and can iterate faster. I have written a fair bit of lisp and when it isn't refusing to fix security bugs because openai are cowards, 5.6-Sol can do in hours what would take me days.
pjmlp 1mo ago
The best is kind of debatable as it lacks the IDE tooling from LispWorks and Allegro.
- stackghost 1mo ago
  >The best is kind of debatable I used the word "arguably" in the very first word of that sentence: >Arguably the best is SBCL The word arguable is a synonym for the word debatable.