5 ms·
I agree that there are times where you want to nail things down so they cannot be changed. It's just that it's easier to restrict the behavior of a live system
by gbracha 9y ago
I agree that there are times where you want to nail things down so they cannot be changed. It's just that it's easier to restrict the behavior of a live system than to customize a "dead" one. Hence liveness needs to be at the foundation.
- brudgers 9y agoI had not yet listened to the QA portion of the talk when I wrote my comment, so maybe I did not entirely account for how much my take might have been a response to what was said for effect...and now I have also had a bit of time away from my comment to think a bit more. Openness may be a third axis that relates the design of platforms/systems intended for liveness and literacy. A sketch of contrasting approaches to openness might be between Emacs and a traditional Smalltalk IDE. Emacs is open in the sense that the designers designed the tool around user customization and extension. Smalltalk IDE's tend not to have that as a first order design principle. Over the long haul (openness in Smalltalk seems to happen at a different layer of abstraction). I think it may be more practical to add liveness to a programming tool with openness as a primary design goal than openness to a programming tool with liveness as a primary design goal (with the premise that openness is not also a primary design goal of a particular programming tool).