4 ms·

The "discipline" is to put the source code into a source file, the same thing you do with every other language. Don't do this and expect positive results: SO

The "discipline" is to put the source code into a source file, the same thing you do with every other language. Don't do this and expect positive results: SOME-PACKAGE> (defun a-critical-function (...) ...) The discipline to instead do this: ;; some-package.lisp or whatever (defun a-critical-function (...) ...) Is table stakes for other languages, and Lispers are no worse programmers than programmers in other languages so why would they be incapable of this basic discipline? Only fools would write that in the REPL, never commit it to a source file, and be surprised when they couldn't reproduce the system state later on. Same with loading data. It comes from a database, file, or other source. Preserve the method of loading the data in source like all other code.

sillysaurusx 4y ago
> Only fools would write that in the REPL, never commit it to a source file, and be surprised when they couldn't reproduce the system state later on. This happened a few times while I was developing https://laarc.io https://laarc.io. It’s so addictive to just paste new functions into a repl and see the changes instantly that it’s easy to go a few hours without committing and realize your changes rely on a now-deleted function. :) Wouldn’t trade that workflow for the world though. C++ compile/run separation makes it horribly obvious how much productivity you lose. It feels like walking into a pit of molasses. But even Python isn’t much better — I’m constantly tabbing to the repl, typing ctrl-R “reload” <enter>, then pressing the up arrow twice to evaluate the previous function example I was working on. I wish there was an auto reload feature that would just reload everything every time I evaluate a repl expression. (I’ve been writing Bel lisp in Python, and I put in some code to do just that for bel.interact()’s repl. It’s so much nicer not having to reload manually all the time.)
- tonyarkles 4y ago
  > It’s so addictive to just paste new functions into a repl and see the changes instantly that it’s easy to go a few hours without committing and realize your changes rely on a now-deleted function. :) I think Slime is a pretty happy middle ground. Instead of just pasting, the function gets written in a source file and then C-c C-c to evaluate it in the repl. I did once or twice run into similar issues though from depending on older or newer versions of functions that changed but weren’t completely reflected until a clean restart. But that’s been pretty rare and definitely wasted way less time than “make clean all” before committing C++ code :D
  - lokedhs 4y ago
    Doing a full reload of the system once in a while (especially after large changes) also helps. Just because you can keep a REPL open for days doesn't mean that's always the best idea.
    - lispm 4y ago
      Another way to deal with that is patching the running Lisp and "undefine" no longer needed functions, variables, classes, ...
      - kaveh808 4y ago
        I have always found that a weak point. Is there an "opposite" key binding to C-c C-c than will undefine/unintern an entity?
        lispm 4y ago
        Can't remember what SLIME supports, but LispWorks has Undefine as an Editor command and in its Editor menus. It can undefine more than just functions.
        Jtsummers 4y ago
        C-c C-u is bound to `slime-undefine-function`, though it prompts you for the name of the function and doesn't determine it by the present context. `slime-unintern-symbol` is also present but not bound by default and also prompts for the name.
  - weikju 4y ago
    yes this is the correct way, this IS repl-driven development.. The REPL is a entrypoint into the world of the running program, and ideally the editor is connected to the program via the REPL, but you still write code in the editor. Most Lisp beginner tutorials - the ones that don't start with teaching emacs - will ask the reader to just paste code into the REPL. This sets up bad habits... Perhaps we'll have better AND easier tutorials one day.
- JonChesterfield 4y ago
  Writing stuff in the repl directly is good. I'd like to have the repl track everything that gets entered and serialise it to a log file of some sort, preferably a loadable one, so that there's an option to dig the useful parts back out when finished experimenting.

sillysaurusx 4y ago

> Only fools would write that in the REPL, never commit it to a source file, and be surprised when they couldn't reproduce the system state later on. This happened a few times while I was developing https://laarc.io https://laarc.io. It’s so addictive to just paste new functions into a repl and see the changes instantly that it’s easy to go a few hours without committing and realize your changes rely on a now-deleted function. :) Wouldn’t trade that workflow for the world though. C++ compile/run separation makes it horribly obvious how much productivity you lose. It feels like walking into a pit of molasses. But even Python isn’t much better — I’m constantly tabbing to the repl, typing ctrl-R “reload” <enter>, then pressing the up arrow twice to evaluate the previous function example I was working on. I wish there was an auto reload feature that would just reload everything every time I evaluate a repl expression. (I’ve been writing Bel lisp in Python, and I put in some code to do just that for bel.interact()’s repl. It’s so much nicer not having to reload manually all the time.)

tonyarkles 4y ago
> It’s so addictive to just paste new functions into a repl and see the changes instantly that it’s easy to go a few hours without committing and realize your changes rely on a now-deleted function. :) I think Slime is a pretty happy middle ground. Instead of just pasting, the function gets written in a source file and then C-c C-c to evaluate it in the repl. I did once or twice run into similar issues though from depending on older or newer versions of functions that changed but weren’t completely reflected until a clean restart. But that’s been pretty rare and definitely wasted way less time than “make clean all” before committing C++ code :D
- lokedhs 4y ago
  Doing a full reload of the system once in a while (especially after large changes) also helps. Just because you can keep a REPL open for days doesn't mean that's always the best idea.
  - lispm 4y ago
    Another way to deal with that is patching the running Lisp and "undefine" no longer needed functions, variables, classes, ...
    - kaveh808 4y ago
      I have always found that a weak point. Is there an "opposite" key binding to C-c C-c than will undefine/unintern an entity?
      - lispm 4y ago
        Can't remember what SLIME supports, but LispWorks has Undefine as an Editor command and in its Editor menus. It can undefine more than just functions.
      - Jtsummers 4y ago
        C-c C-u is bound to `slime-undefine-function`, though it prompts you for the name of the function and doesn't determine it by the present context. `slime-unintern-symbol` is also present but not bound by default and also prompts for the name.
- weikju 4y ago
  yes this is the correct way, this IS repl-driven development.. The REPL is a entrypoint into the world of the running program, and ideally the editor is connected to the program via the REPL, but you still write code in the editor. Most Lisp beginner tutorials - the ones that don't start with teaching emacs - will ask the reader to just paste code into the REPL. This sets up bad habits... Perhaps we'll have better AND easier tutorials one day.
JonChesterfield 4y ago
Writing stuff in the repl directly is good. I'd like to have the repl track everything that gets entered and serialise it to a log file of some sort, preferably a loadable one, so that there's an option to dig the useful parts back out when finished experimenting.