3 ms·
> 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 happ
by 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 agoDoing 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 agoAnother way to deal with that is patching the running Lisp and "undefine" no longer needed functions, variables, classes, ...
- kaveh808 4y agoI 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 agoCan'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 agoC-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 agoyes 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.
- kaveh808 4y agoBeginner CL video showing the use of Emacs & Slime: https://youtu.be/nSJcuOLmkl8 https://youtu.be/nSJcuOLmkl8
- JonChesterfield 4y agoWriting 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.