It’s really unfortunate that the idea of a live coding remains niche, and most programmers haven’t had exposure to this style of development. Working in an environment where you can inspect and change any aspect of the system at runtime is the most satisfying coding experience in my opinion.
Coding hackers tell me they want to understand, change, and improve on anything they can get their hands on. The live coding systems let them do that to their whole, running system. It just seems like the two are a natural fit. It makes it so much stranger to me to see such people use tools that limit them so much.
It’s probably why people have tended to think of Emacs, Common Lisp, and Smalltalk (and Forth?) in relation to the “quality without a name” described in Zen and the Art of Motorcycle Maintenance, or the living quality of buildings described by Christopher Alexander.
I would also add Erlang to that list, but that might be controversial.
I mostly agree. It doesn’t have the same deep metaprogramming aspect, but the actor model is a much cooler form of concurrency than the languages I listed, and things like supervision hierarchies have quite a strong sense of being “alive.”
The tracing capabilities and the ability what process is doing what and which messages are being received is quite impressive.
Yeah, I don’t know if it fits since I don’t use it. I will say that making distributed, concurrent systems easier and more robust by design with ability to update running systems makes it pretty close to the idea. It’s kind of in its own category in my mind where the LISP’s were focused on max flexibility where things like Erlang or Ada are focused on max reliability. Erlang improved on things like Ada in its category by being more high-level, distributed, the updates, etc.
Now, it might be interesting to combine the two. I swore someone… (checks bookmarks) Oh yeah, it was LISP-Flavored Erlang. I can’t evaluate further about whether it truly has benefits of typical LISP workflow and Erlang since I don’t know Erlang or LFE. Looked really awesome conceptually when I found it. Anyone else chime in?
Pervasively dynamic environments are a two-edged sword: with great power comes great responsibility. It’s trivial to render a Smalltalk image completely unusable with something as simple as false become: true. PicoLisp has similar capabilities. Most Forths do too. There’s something to be said for isolating and stabilizing some basic parts of the system: such limitations give us a margin of safety!
false become: true
I tend to try to see my OS not as a programming language by as my development environment. By that, I mean I try to utilize the services my OS provides in programs rather than abstract them away. In this way, to butcher the analogy, my terminal becomes like my REPL. So, for example, I will use the file system as a key-value database when feasible. I’ll use other programs to do things for my program, like one might use microservices. This doesn’t get you something like Lisp or Erlang where you can go in to a running program and start playing with its memory, but I find it can work pretty well.
As an aside, I think Java has really destroyed a whole generation’s ability to appreciate utilizing the operating system rather than abstracting it away. Maybe in the beginning this made sense, but 99% of the Java programs I see are services running on one OS (Linux) running on one platform (x86). Sure, people might run unit tests locally on their Mac, but that’s POSIX anyways so not a huge jump and most of the people I run into are doing that sort of thing in docker anyways. The operating system has solved a lot of problems for you, use it!
Lisp, Smalltalk, and Oberon are all good examples of the programming-language-as-an-operating-system paradigm.
Today you still see it somewhat in the more enthusiastic Emacs users who haven’t seen the obvious superiority of vi: plenty of people enter Emacs on login and don’t leave it until logout.
At the other end of the complexity gradient, there are tiny self-hosting Forth systems with metacircular evaluation kernels. Beautiful, but delicate!
One practical distinction to draw between these systems is how easy or difficult it is to screw up the whole system (and, conversely, to recover from such screw-ups.) Most of ChromeOS by far is effectively sealed off from the user, even more so than a conventional OS. ChromeOS blurs the distinction between a browser and an OS, which makes some sense in the modern era: it’s a distinction that simply doesn’t matter to many users.