3 ms·

Wild guess here (not a Lisp programmer). When I hear people talking about the practical benefits of Lisp, not just the nice theoretical stuff like homoiconicity

Wild guess here (not a Lisp programmer). When I hear people talking about the practical benefits of Lisp, not just the nice theoretical stuff like homoiconicity and macros, I hear about interactivity. In Lisp it sounds like you can be pretty successful with a more experimental, on-the-fly development process. That might help a crack team push out features faster, but they might produce code that is proven to work more by experiment than by logic, which might mean it's harder to understand and keep building on. This leads to small Lisp shops that beat their competition in a niche but have trouble scaling it to Amazon size.

mtreis86 3y ago
That is remarkably accurate for a wild guess. Lisp code tends to be built from the inside. Working in a REPL, modifying the system state as you go, storing code into a buffer then recompiling and loading it into the image with a keystroke. Recompiling functions as you modify them, without recompiling the rest of the file, updating the code behind some classes without taking the system down, and the interactivity you get from the tooling for debugging and error handling. It all adds up.
relaxing 3y ago
> In Lisp it sounds like you can be pretty successful with a more experimental, on-the-fly development process. That’s a side effect of having a REPL.
- civilized 3y ago
  By itself this doesn't seem like a distinctive advantage of Lisp anymore. Lots of languages have REPLs. But I'm told that Lisp is more advanced in some way. Better debugging, breakloops, everything can be modified in-flight, etc.
  - lispm 3y ago
    Interactive interfaces (command line interfaces, etc.) are long available: BASIC, Smalltalk, Prolog, APL, UNIX shells, etc. Some of them also used source level interpreters. One simple difference is that the READ EVAL PRINT LOOP of Lisp works with code and data in similar ways. It makes it easy to process lists which are data and also to process lists which are programs. READ reads lists, EVAL evaluates lists & other values (and can be rewritten in itself) and PRINT prints lists. Code is lists and programs are lists, too. In the moment where the REPL uses a source level interpreter, debugging can go very deep, incl. modifying the running source code. That's kind a second nature when one is interactively developing Lisp code: every error stays in the error context and provides a break loop to explore/change/repair the current state - including that each additional error in a break loop just gets us into another break loop level, another level deeper.

mtreis86 3y ago

That is remarkably accurate for a wild guess. Lisp code tends to be built from the inside. Working in a REPL, modifying the system state as you go, storing code into a buffer then recompiling and loading it into the image with a keystroke. Recompiling functions as you modify them, without recompiling the rest of the file, updating the code behind some classes without taking the system down, and the interactivity you get from the tooling for debugging and error handling. It all adds up.

relaxing 3y ago

> In Lisp it sounds like you can be pretty successful with a more experimental, on-the-fly development process. That’s a side effect of having a REPL.

civilized 3y ago
By itself this doesn't seem like a distinctive advantage of Lisp anymore. Lots of languages have REPLs. But I'm told that Lisp is more advanced in some way. Better debugging, breakloops, everything can be modified in-flight, etc.
- lispm 3y ago
  Interactive interfaces (command line interfaces, etc.) are long available: BASIC, Smalltalk, Prolog, APL, UNIX shells, etc. Some of them also used source level interpreters. One simple difference is that the READ EVAL PRINT LOOP of Lisp works with code and data in similar ways. It makes it easy to process lists which are data and also to process lists which are programs. READ reads lists, EVAL evaluates lists & other values (and can be rewritten in itself) and PRINT prints lists. Code is lists and programs are lists, too. In the moment where the REPL uses a source level interpreter, debugging can go very deep, incl. modifying the running source code. That's kind a second nature when one is interactively developing Lisp code: every error stays in the error context and provides a break loop to explore/change/repair the current state - including that each additional error in a break loop just gets us into another break loop level, another level deeper.