[em-bee]

with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required.

smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. when i fixed the error, the download of the request resumed in the browser as if nothing had happened other than a delay.

[Blackthorn]

> with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required.

We like to make sure everything running in prod is verifiably built from source in-repo. So that's the thing, while it's a really snazzy feature for sure, the value over the rest of the world is on the questionable side. At least for our use case, but I think it's true for most use cases.

edit: Also really curious about your smalltalk and pharo experience. Sounds fascinating!

[em-bee]

once you fixed the problem you of course commit the change to the code on disk. there is nothing in the workflow that prevents you from doing that. you are not going to just fix apps in production without running your tests and what not. at worst you fix an error in a production system, and run the tests afterwards to make sure everything is clean. but mostly this feature is used during development when your code is still incomplete. not having to restart every time there is an error simply speeds up your development loop.

[behnamoh]

I am really curious about your experience with Smalltalk and Pharo!

[em-bee]

i am really just a beginner with smalltalk and CL. as a vim user i didn't really have a good integration of the CL repl with the editor (there were tools, but they weren't as straightforward to set up as slime would have been). and when i encountered the breakloop i didn't really know what do to and just tried to get out of it as quickly as i could. (exiting vim is easier ;-) the thing that bothered me was that when i change code in the repl without an integrated editor, then how do i keep track of the changes and make sure i don't loose them? but then, i just never tried to set up a proper environment.

in smalltalk on the other hand you get a nice IDE with all the comforts of a GUI. you have your windows where you browse your code neatly structured in classes and methods. there is a window where you run your app and manage your tests which light up red or green if they fail or pass, another which logs error or other print messages, and if an error happens while an app is running a new window pops up, showing you a trace of what was running and a text field with the code that failed, like in a debugger, and right there you can edit the code and resume.

the code is written to your class, and when you go back to your code browser the change is reflected there, and you can commit it to a version control system. pharo btw has pretty good integration with git, and already a few years ago it almost acted like a git gui. it's probably even better now. the primary downside is that the text editor in pharo is simple, like a browser text area, and not a sophisticated editor like emacs or vim.

[maxwelljoslyn]

> [Lisp] the thing that bothered me was that when i change code in the repl without an integrated editor, then how do i keep track of the changes and make sure i don't loose them

> [Smalltalk] the code is written to your class, and when you go back to your code browser the change is reflected there

I feel your pain. "writing the changes back to the source code definition" seemed like a no-brainer desirable feature of a Lisp REPL, yet I could not find a way to do that out of the box using Slime. I'm sure one could program it, however! Bet someone has...

[pritambaral]

> ... yet I could not find a way to do that out of the box using Slime.

Here's what I use: edit code, save file, tell slime to eval current defun. I haven't yet suffered indiscipline to hook `slime-eval-defun` to call `save-buffer`. Would that work for you?