31–40 of 51 posts
The thing I still don't understand about REPL driven development is how you manage state, and how you manage threads. If I have a task running and it depends on a collection of global variables, those global variables now need some machinery around them so that they can be edited from the REPL thread. If you replace a function, there now needs to be decisions made about when you now begin usage of the new function. T…
Earlier quoted context omitted.
> 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 . 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. :) Wo…
> 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 de…
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.
The map is not the territory. The code is not the program.
Earlier quoted context omitted.
But if your tail recursion gets compiled down into the standard "label whatever, code blablabla, set address register to label whatever, jump" type-code, how do you change the address that the register gets set to? Unless you do a lookup in the environment every time you recur to find where you have to jump to, but that would kill your performance stone dead.
I suspect (but cannot prove) that environment lookups are cached, so that when the new definition is loaded with the same name as the previous jump target, the compiled code is invalidated and switches back to interpreted mode. But now that I talk through it, that sounds pretty hard. Occasionally I dive into racket’s good old C code for masochistic pleasure (it’s good code, just … very C, and very old). I always come…
Still, it's a good thing you mentioned Racket's old C codebase, I'll have to dive into that some time to see if there's anything interesting to learn from it.
Earlier quoted context omitted.
> 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 de…
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 AN…
Smalltalk only got a mention in the footnotes but I think it deserves a bigger entry when talking about ways to interact with programs. If a REPL is talking to and conversing with a program then environments like Pharo take it a step further by letting you interactively and graphically look under the hood as well. It's an amazing way to interact with software once you get used to it and I think well worth checking ou…
The thing I still don't understand about REPL driven development is how you manage state, and how you manage threads. If I have a task running and it depends on a collection of global variables, those global variables now need some machinery around them so that they can be edited from the REPL thread. If you replace a function, there now needs to be decisions made about when you now begin usage of the new function. T…
> how you manage state It's already done for you by the runtime: it holds the state in the process memory. Now, with edit-compile-run-print loop if you want your state to persist between runs, you gotta implement some scheme of data persistence. > it depends on a collection of global variables, those global variables now need some machinery around them so that they can be edited from the REPL thread. In Erlang, you c…
Smalltalk only got a mention in the footnotes but I think it deserves a bigger entry when talking about ways to interact with programs. If a REPL is talking to and conversing with a program then environments like Pharo take it a step further by letting you interactively and graphically look under the hood as well. It's an amazing way to interact with software once you get used to it and I think well worth checking ou…
I can certainly be mistaken but I don’t know if you can connect a typical modern Smalltalk workspace to a remote image. Nothing to stop someone from whipping up a straightforward socket listener to a ST image, but it’s not at all the same thing as what the desktop experience is.
Obviously not impossible just a distinction between them.
ST also solves the disparity between the image and the source code by logging all changes made to an image automatically. So it’s straightforward to roll forward an older image to a recent state by replaying the changes file.
In the opening paragraphs, this post indicates that this other post of David Vujuc [1] falls victim to common misconceptions about what a REPL is. I'm not sure what misconceptions this post is referring to; perhaps I also have these misconceptions. But I also don't think this post clarifies that. Could anyone here make it more explicit? [1]: https://davidvujic.blogspot.com/2022/08/joyful-python-with-r...
The Vujic post describes repl-driven development as "[evaluating] variables, code-blocks, functions, or an entire module [to] get instant feedback, just by hitting a key combination in your favorite code editor." Speaking from the perspective of long experience with Lisp and Smalltalk environments, I agree with fogus here: this is a misconcpetion--or at least an impoverished version of repl-driven development. The ex…
While it’s trivial to add words, do testing, etc. in Forth, none of those changes necessarily have direct impact. For example, in Lisp if you change a definition, the impact of that change affects not only new code, but existing code. If you redefine ‘foo’, not only will all new references reflect the new definition, but so will the old references.
Whereas in Forth, only new code is affected. If you want to see the impact of your new routine on the existing codebase you’ll need to reload it all. The typical workflow is ‘FORGET XXX’ to reset the dictionary and reload.
This means that any changes made at the prompt are fleeting. You have a great sandbox to play in, but you’ll need to migrate the code to the base source to see the real impact.
Also consider something like the classic BASIC environment. Here you have an interactive environment, and the code cycle can be very fast. You have some introspection to your running system (using STOP or keyboard interrupt, PRINT, assignments, and CONT), not the granular access that Lisp and ST offer.
For example in BASIC, typically, if you change the code at all, the existing variables get reset. So you can’t really make changes to a live program. But the turn around is quite fast to making this less of an issue.
Smalltalk only got a mention in the footnotes but I think it deserves a bigger entry when talking about ways to interact with programs. If a REPL is talking to and conversing with a program then environments like Pharo take it a step further by letting you interactively and graphically look under the hood as well. It's an amazing way to interact with software once you get used to it and I think well worth checking ou…
In todays world a distinction between Smalltalk and a Lisp listener is remote connectivity. Lisp needs a simple socket, whereas Smalltalk requires the full GUI. I can certainly be mistaken but I don’t know if you can connect a typical modern Smalltalk workspace to a remote image. Nothing to stop someone from whipping up a straightforward socket listener to a ST image, but it’s not at all the same thing as what the de…
It nearly happened: