> The act of describing what you want the machine to do is interleaved with the machine actually doing what you have described, observing the results, and then changing the description of what you want the machine to do based on those observations.
That sounds really powerful and interesting, but wondering how often is that used in practice? I can imagine maintaining and understanding a large self-modifying program like that could get a bit complicated for a team.
I think he's describing interactive programming, not necessarily self-modifying programs. With that said, yes interactive programming is incredibly useful and I do it all the time.
It really shines on apps with a lot of state (such as a game) where normally you'd have to quit, change the code, recompile, run the app, and reproduce the original state as closely as possible. With lisp you can just replace the function you are debugging while the app is running.
That said, lisp can be used for self-modifying programs pretty easily. The idea that the default data structures it manipulates are the same as the code itself makes it easy to build data structures with the purpose of being evaled (not saying this is ever a good practice).
And essentially, macros are self-modifying programs that run before the actual program runs.
> I think he's describing interactive programming, not necessarily self-modifying programs. With that said, yes interactive programming is incredibly useful and I do it all the time
I do it too in python via ipython. Maybe what the author meant is "Why exploratory programming using a REPL is great".
Like any powerful technology, Lisp's interactivity and dynamism can be used for good or it can be used for evil. Yes, it takes a little discipline to keep things from spinning wildly out of control. But it's well worth the effort.
The powerful idea is the ability to modify the program as it is running rather than writing a self-modifying program which indeed would be much more complicated.
A good example would be the Emacs text editor. You can use it to modify the source of Emacs itself while it is running. You never need to reboot it to test new code because you can interactively evaluate new functions and replace existing ones.
As for working in teams, usually each developer runs their own REPL instance isolating them from the changes made by other developers. You can still pull a coworker's commit and evaluate it into your running instance without even restarting the program under development.
I think Ron was referring to the development process, rather than the finished program. The way Lisp languages and environments handle REPL-based interactive development is significantly more powerful and flexible than e.g., Rubython or even Haskell.
Modifying a running program to make a change as you develop it is an incredible speedup, relative to (recompiling and) restarting all the time, and even relative to reloading whole changed files.
That sounds really powerful and interesting, but wondering how often is that used in practice? I can imagine maintaining and understanding a large self-modifying program like that could get a bit complicated for a team.