The one about Lisp interactivity
blog.fogus.me
The one about Lisp interactivity
1–10 of 51 posts
Re: The one about Lisp interactivity
#2No post body was provided.
Re: The one about Lisp interactivity
#3Nice writeup! Interesting comparison of OCaml (fast tooling but not connected to running program and data).
Lisp REPLs are something I use every day, but I also enjoy REPL development that is connected to look I've program and data with Python with Emacs, Ruby (when I used to use it), Haskel,and Julia.
The REPL is a way of life.
Re: The one about Lisp interactivity
#4The 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. To me, the understanding that some set of things may be replaced right under you adds a great deal of additional engineering complexity. I've gotten various answers about how one deals with this. One being "yes add the machinery" or "just yolo it, yes it's a race condition but it's rarely an issue," neither of which I find particularly satisfying.
Concerning state, I've occasionally found myself developing a long-lived lisp image, and then I need to restart the VM for one reason or another, and then found that nothing works. The state of the in-memory image had gotten totally out of sync with the codebase. Perhaps this is a manner of discipline in lisp, but I greatly appreciate the replacement of discipline (be it memory management or the aforementioned situation) with machinery of the language itself.
Re: The one about Lisp interactivity
#5The 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…
On LispWorks REPL, I use the Threads and Processes Viewer.
Re: The one about Lisp interactivity
#6In 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...
Re: The one about Lisp interactivity
#7The 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 create a public named ETS table (basically, a thread-safe dictionary) and put "global settings" in there instead (and read them from there, too). I'd imagine LISP has something similar.
And mind you, I personally prefer the ECRPL instead of REPL, even when working in Python.
Re: The one about Lisp interactivity
#8This seems to leave out the existence of debuggers in IDEs.
These days I tend to run most new code in the debugger, and step through it so I can see what’s going on. This works great in say, Rust, Python, or Swift. I haven’t used Java for a while, but I don’t see why it wouldn’t work well there too.
I feel very connected to the code.
Re: The one about Lisp interactivity
#9In 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 post by David Vujic actually mentioned the significant difference - REPL-driven in the way Clojure programmers understand it is not simply interpreting snippets of code in a separate process, but interacting with a running program, including all it's state and modifying it on the fly if needed.
Clojure programs listen on a extra port that you can connect your editor to and modify the program as it running.
Things like tests and notebooks may run the same code, but don't have the exact state and environment as your running program, be it running locally a staging env or even production.
This is not unique to Clojure, a Common Lisp program was famously running on a space probe and REPLed into decades ago, and Smalltalk code is stored in VM images, but few mainstream languages nowadays allow such interaction with a running program
Re: The one about Lisp interactivity
#10This seems to leave out the existence of debuggers in IDEs. These days I tend to run most new code in the debugger, and step through it so I can see what’s going on. This works great in say, Rust, Python, or Swift. I haven’t used Java for a while, but I don’t see why it wouldn’t work well there too. I feel very connected to the code.
The author does mention debuggers. But you don't normally run a debugger on production or a testing environment and with a REPL you can. A debugger situates a program differently than it is normally used, a REPL connects to your code/state/environment in any stage of development.