3 ms·

> And then I realized how horribly inefficient it is at being that. This depends a lot on the user. In the right hands it's extremely efficient.

TeMPOraL 10y ago
It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.
- sdegutis 10y ago
  Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk. That said, you get a lot of similar behavior to this in things like Clojure + CIDER, but due to the nature of the underlying JVM, you still have to restart it every once in a while. Part of me still wonders what we could come up with if we took the principles behind a true interactive IDE + REPL (like Emacs + CIDER) but removed the concept of "wrapping" a VM that was designed for a "programming language", and added the concept of a longer-lived "VM". Not quite what LispMs were, nor even Smalltalk (which relied too heavily on a GUI and a monolithic "image state" rather than individual persist-able files).
  - imtringued 10y ago
    >but due to the nature of the underlying JVM, you still have to restart it every once in a while. The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.
sedachv 10y ago
> This depends a lot on the user. In the right hands it's extremely efficient. IMO the inefficiency is more due to the fundamental brokenness of the Unix process model. A Unix process is sort of like a VM with none of the security, and all of the stuff that has been added to it over the years (signals, IPC, dynamic linking) just makes it worse and worse. Things like full machine virtualization and now over the past 15 years namespaces/cgroups/containers are very complicated, brittle ways of trying to work around the shortcomings of Unix processes. This IMO is the biggest advance plan9 made over Unix.

TeMPOraL 10y ago

It's a powerful lever, yes, but if we talk efficiency, then it very much sucks. You get a crappy pseudo-programming language (shell) that spawns a new process (!) for almost every function call, and communicates with unstructured text that has to be parsed and reparsed every step of the way. The only benefits of this system are that it's already there with batteries included, and that it became a de-facto standard.

sdegutis 10y ago
Well also that it's entirely dynamic. You can create and edit "functions" on the fly, which will exist immediately, and are persisted across "sessions". But despite how convenient this is, there's basically no way to make it a whole lot more efficient. Especially the automatic "persisting" feature, there's no other way to do that than writing to disk. That said, you get a lot of similar behavior to this in things like Clojure + CIDER, but due to the nature of the underlying JVM, you still have to restart it every once in a while. Part of me still wonders what we could come up with if we took the principles behind a true interactive IDE + REPL (like Emacs + CIDER) but removed the concept of "wrapping" a VM that was designed for a "programming language", and added the concept of a longer-lived "VM". Not quite what LispMs were, nor even Smalltalk (which relied too heavily on a GUI and a monolithic "image state" rather than individual persist-able files).
- imtringued 10y ago
  >but due to the nature of the underlying JVM, you still have to restart it every once in a while. The DCEVM project almost removed any limitations on hotswapping code in the JVM until oracle hired the people behind it and then never integrated it into their JVM.

sedachv 10y ago

> This depends a lot on the user. In the right hands it's extremely efficient. IMO the inefficiency is more due to the fundamental brokenness of the Unix process model. A Unix process is sort of like a VM with none of the security, and all of the stuff that has been added to it over the years (signals, IPC, dynamic linking) just makes it worse and worse. Things like full machine virtualization and now over the past 15 years namespaces/cgroups/containers are very complicated, brittle ways of trying to work around the shortcomings of Unix processes. This IMO is the biggest advance plan9 made over Unix.