8 ms·

The IDE as a value

116 points by mcrittenden 14y ago

krosaen 14y ago
I like this trend towards values instead of objects, Rich's talk is really worth watching too http://www.infoq.com/presentations/Value-Values http://www.infoq.com/presentations/Value-Values. Using this approach in UIs is stretching the idea even further into a realm where I previously thought OO had a sweet spot. I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach. My current line of reasoning is that while having well defined services and interfaces can help organize a software system, the actual arguments and return values of these end points are really better thought of as values - and the expected structure of these values can certainly be part of the API. You just don't force people to construct and destruct objects for everything you are passing around. A couple of related resources on this topic: "Stop writing classes" from PyCon http://www.youtube.com/watch?v=o9pEzgHorH0 http://www.youtube.com/watch?v=o9pEzgHorH0 Rob Pike's reflection on using data vs OO: https://plus.google.com/101960720994009339267/posts/hoJdanihKwb https://plus.google.com/101960720994009339267/posts/hoJdanih...
- snprbob86 14y ago
  > I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach. I've become a 100% believer that Values are preferable to Objects & Encapsulation, full stop. However, I don't think that means you abandon objects, state, encapsulation 100%. I think that just means that you minimize them significantly. I just watched a talk by Stuart Halloway [1] on Datomic where he makes a little "play at home" fill in the blanks table of design decisions and implications. He makes the assertion that if you take "program with values" to be the only given filled in table cell, you can make some arbitrary decisions for one or two other spots and the rest of the spots will fall out trivially with interesting properties. I guess the point is that programming with Values just affords you so much freedom and flexibility. [1] http://www.infoq.com/presentations/Impedance-Mismatch http://www.infoq.com/presentations/Impedance-Mismatch
- chipsy 14y ago
  I agree with the trend, and also with the sentiment around interfaces. Mutable/encapsulated approaches(which don't end at OOP, but rather continue into language design) act to define protocols. Protocols have a necessarily stateful nature; in the best case, the state is a single value at a single time, but in many real-world situations, state change events are frequent and need careful attention. Source code itself tends to need hundreds of changes to reach application goals, regardless of the language. Functional and immutable style, on the other hand, acts on processes that are inherently computative, and this is the "nitty gritty" of most business logic. Even if the system is designed in an imperative fashion, it can bolster itself through a combination of a few "key methods" that apply functional style, and a type system that imposes a substantial amount of immutability. The tricky part with OOP as we know it is to recognize when you're making a protocol, and when you're making an immutable computation. Many of the OO type systems used in industry lack the expressiveness to distinguish the two, and rush the natural life cycle of the architecture by imposing classes too early.
- seanmcdirmid 14y ago
  I don't really get it. From the blog post, Granger is describing a very imperative object system, but you seem to be claiming that it is somehow a value-oriented functional system. What am I missing?
  - krosaen 14y ago
    That's a good question - there are still objects, or groupings of data, and even tags that identify which behaviors or functions apply to them in various contexts. What strikes me as different is the entire hierarchy is a nested data structure that is easy to reason about and modify at runtime without the use of a fancy debugger. The use of 'encapsulation' that hid the underlying data in each grouping and also bind functions / methods directly to each object in this case would only make it harder to work with. Why? Because to view, construct, augment at runtime or serialize the hierarchy would require constructors, serializers, deserializers etc, instead of having something that is just a data structure, ready to be viewed, put on a queue, sent over the wire etc. The idea of 'behaviors' also provides flexibility in what functions can act on any grouping of data - the key value pairs needn't be associated with a 'class' which dictates what the associated functions will be adds more flexibility. As the author hints, there are other ways of achieving this agility - dynamic mixins. Finally, while having a well defined protocol (or API or endpoint or whatever you want to call it) is valuable and helps organize code, I think taking this idea to the extreme and saying that every single object or piece of data you pass around as arguments or return values from these end points needs to be expressed as an abstract protocol itself is where you really start to lose. An expected format of the data structures of the arguments and return values can and should be part of an API, but needing to wrap them in objects doesn't really help - and that's where this trend I speak of begins to seem like progress to me.
    - seanmcdirmid 14y ago
      This is quite the standard dynamic languages argument, I'm not seeing much new here but this wasn't meant to be new. However, my point is that this is heavily object-oriented and heavily imperative. It is just a different kind of object system that people might not be used to. If this ever catches on, we'll just need another Treaty of Orlando to re-harmonize the object community. To be honest, a lot of the object system seems to be confused and muddled. I mean, there are a million different ways to get the kind of flexibility in what the author call "behaviors" (a term incredibly overloaded, BTW), protocols, traits, type classes, etc...dynamic mixins are nothing new here also (I've designed a couple of research languages with dynamic mixin inheritance, fun stuff). As an academic, I want to see reasons why X was chosen and comparisions with previous systems that chose Y instead; but I know I won't get this from most of the people who do the interesting work in this field, so I have to figure it out for myself. Calling this an object system opens up a floodgate of related systems that I can compare it against.
metajack 14y ago
This was an excellent talk at the Conj, and the talk was the best explanations of entity systems I've yet found. I also recommend his Anatomy of a Knockout which also covers more of this topic: http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou... with discussion: http://news.ycombinator.com/item?id=4907791 http://news.ycombinator.com/item?id=4907791
martinced 14y ago
First let me say that I really don't want to be mean here: I'll try to do constructive criticism. I've worked professionally in the video-game industry and I must say that I'm a bit disappointed by all these blogs / videos trying to promote tools and/or languages by using very poorly conceived games. Take ChromaShift for example: it's terribly bad. We're in 2013 and the thing draws less "pixels" and yet is slower than any 2D scroller from the 80s running on a C64. Sure, it was done in 48 hours and kudos for that... But back in the nineties we'd enter 48 hours or 24 hours "demo" competition and come up with stuff incredibly better looking than that. The author of ChromaShift made a talk about the "Component Entity System" he's using. And that's where the "suspension of disbelief" simply doesn't work for me: everytime he shows the game, it's freakin' ugly and slow as molasses. Then comes the disappointment: if you want to run at a reasonable framerate you, of course, need to perform quite some logic in about 16 milliseconds (the author correctly mentions it in its talk). And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that. Not to mention that if you create objects at every frame then at one point the GC shall have to kick in and your real-time performance will suddenly drop (the author says that in the talk I watched about CES/Chromashift). But why oh why use a language that is very arguable not meant to write video games in (Clojure) to... write a game in it as an example of what can be done!? (or as an example of how powerful an IDE supposedly is!?) The "problem" is that they're talking about that "CES" as it was the one way to create games. But how many games written in Clojure have been shipped? Heck, how many games written in Clojure are even playable? There are, today, lots of people writing games (either professionals or amateurs) and selling them (or giving them away for free). And not a single one of these game is using that "Component Entity System". And hardly any of them is using Clojure (there may be one or two exceptions but that's about it). And every single of these real games (even the simplest smartphone game) is looking better and is more responsive than the poor examples we see in Clojure talks. So how are we, Clojure believers (I'm a big Clojure fan and investing lots of time and energy learning it), supposed to take any of this seriously? Once again, I don't want to be mean: these guys are typically good programmers but, to be honest, they don't know anything about game programming and that is a bit saddening. EDIT: I won't even start talking about the "quality" of the "text editor" part of Light Table. I like the concept of LT but I do wan't a client/server mode where I can plug in vim or Emacs (or Sublime Text 2 or whatever) as my text editor. Otherwise I'm never going to take LT seriously.
endlessvoid94 14y ago
Code editor, modifiable at runtime, built on a dialect of Lisp... ;-) I'm a fan of Light Table. Just had to point it out.
- felideon 14y ago
  Sounds like you're looking for Emacs: http://www.gnu.org/software/emacs/ http://www.gnu.org/software/emacs/
  - endlessvoid94 14y ago
    That was the joke :-P
- seanmcdirmid 14y ago
  Light Table is Emacs for the 21st century. Emacs lacks reactivity and doesn't support liveness (you have to manually refresh).
agumonkey 14y ago
I've screamed this elsewhere already, it feels like smalltalk is back, and maybe even GeneraOS ?
- shaunxcode 14y ago
  I hope it is a scream of "FINALLY!!".
- seanmcdirmid 14y ago
  This is much better than smalltalk. In Smalltalk, you could just edit code on the fly, but nothing would happen if that code wasn't continuously executing in an infinite loop. LightTable, on the other hand, supports real liveness. Its something that we never got in Smalltalk or Lisp. Edit: Morphic (from Self) does support liveness, but only when it is being edited at the graphical level. If you are editing code, you are stuck in the same refresh trap as Smalltalk or Lisp, but to be fair, morphs are continuously updating themselves in infinite loops so it doesn't matter :)
  - agumonkey 14y ago
    Fine, I forgot Self, forgive me :p That's what I'm waiting for anyway, lazy reactive systems
- klibertp 14y ago
  I'm sad that this comment is the last on this page and not the first. I imagine that - after LT is complete - some Smalltalkers will hold a competition to replicate it in 48 hours. I believe they would succeed - building on top of Smalltalk environment with Morphic[1] this shouldn't be too hard. For those who don't know why: go grab Pharo[2] Smalltalk and "Pharo By Example"[3] book and play with it. It's absolutely beautiful, an experience well worth a few days of time. [1] As already noted Morphic was first implemented for Self and is not a neccessary part of any Smalltalk. [2] http://www.pharo-project.org/home http://www.pharo-project.org/home [3] http://pharobyexample.org/ http://pharobyexample.org/
  - agumonkey 14y ago
lispm 14y ago
Behaviors? Methods. Tags? Classes. Just data? In Lisp the code, the functions, the symbols, etc. already are data. Sure one can build another dynamic object system and use fancy names for it. It is really difficult to count the number of times this had been done in the past. A typical Lisp-based system which does that was Object Lisp: http://lispm.dyndns.org/docs/ObjectLisp-Manual.pdf Used by LMI for their user interface and by Coral for Macintosh Common Lisp (until Object Lisp was replaced by CLOS). The idea that a) one can add and remove behaviors (methods) and b) add and remove tags (classes / mixins / ...) at runtime is found in almost every Lisp-based object system. Operations for that are available in every system. Lisp-based object systems are not that much a language, but more a collection of objects and classes which interact in a defined way. Called a 'system'. That's also we have the Common Lisp Object SYSTEM, and not the Common Lisp Object Language. CLOS is described in terms of objects and their interactions (classes and generic functions are objects themselves) - not so much as a grammar of language constructs.
- seanmcdirmid 14y ago
  This isn't very fair. Yes, Granger is describing another kind of object system and yes it is OOP. And yes, this is in the long tradition of CLOS. But all of these sytems are fairly unique and deserves its own description, in this case reactivity is extremely important.
  - lispm 14y ago
    what is unique about it?
    - seanmcdirmid 14y ago
      As mentioned, the reactivity makes this interesting to me. The amount of reactivity required for a project like LightTable is pretty ambitious, which we don't really see in most Lisp object systems (or any object systems for that matter).
      - lispm 14y ago
seanmcdirmid 14y ago
I would love to see more context about the architecture of the system; e.g. how are the objects organized and what are they reacting to? I've seen many reactive object systems and I can't easily place this one in context, but maybe I'm spoiled by academic publishing (where we understand a new system in relation to older systems). It seems like this object system is related to Rodney Brooks' behavior-based subsumption architecture (used mostly in robotics and games) or not? It uses much of the same terminology, but doesn't actually have subsumption (as conflict resolution). Strange. It also seems to be very imperative, in the sense that behaviors and behavior/object relationships seem to be managed very discretely as opposed to using any kind of declarative continous abstraction (say data binding or guarded connections). This bothers me a bit, as I have found these systems to be very unmanageable as they scale. But I still like where this is going, I can't wait to learn more!

116 points by mcrittenden 14y ago

I like this trend towards values instead of objects, Rich's talk is really worth watching too http://www.infoq.com/presentations/Value-Values http://www.infoq.com/presentations/Value-Values. Using this approach in UIs is stretching the idea even further into a realm where I previously thought OO had a sweet spot. I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach. My current line of reasoning is that while having well defined services and interfaces can help organize a software system, the actual arguments and return values of these end points are really better thought of as values - and the expected structure of these values can certainly be part of the API. You just don't force people to construct and destruct objects for everything you are passing around. A couple of related resources on this topic: "Stop writing classes" from PyCon http://www.youtube.com/watch?v=o9pEzgHorH0 http://www.youtube.com/watch?v=o9pEzgHorH0 Rob Pike's reflection on using data vs OO: https://plus.google.com/101960720994009339267/posts/hoJdanihKwb https://plus.google.com/101960720994009339267/posts/hoJdanih...

snprbob86 14y ago
> I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach. I've become a 100% believer that Values are preferable to Objects & Encapsulation, full stop. However, I don't think that means you abandon objects, state, encapsulation 100%. I think that just means that you minimize them significantly. I just watched a talk by Stuart Halloway [1] on Datomic where he makes a little "play at home" fill in the blanks table of design decisions and implications. He makes the assertion that if you take "program with values" to be the only given filled in table cell, you can make some arbitrary decisions for one or two other spots and the rest of the spots will fall out trivially with interesting properties. I guess the point is that programming with Values just affords you so much freedom and flexibility. [1] http://www.infoq.com/presentations/Impedance-Mismatch http://www.infoq.com/presentations/Impedance-Mismatch
chipsy 14y ago
I agree with the trend, and also with the sentiment around interfaces. Mutable/encapsulated approaches(which don't end at OOP, but rather continue into language design) act to define protocols. Protocols have a necessarily stateful nature; in the best case, the state is a single value at a single time, but in many real-world situations, state change events are frequent and need careful attention. Source code itself tends to need hundreds of changes to reach application goals, regardless of the language. Functional and immutable style, on the other hand, acts on processes that are inherently computative, and this is the "nitty gritty" of most business logic. Even if the system is designed in an imperative fashion, it can bolster itself through a combination of a few "key methods" that apply functional style, and a type system that imposes a substantial amount of immutability. The tricky part with OOP as we know it is to recognize when you're making a protocol, and when you're making an immutable computation. Many of the OO type systems used in industry lack the expressiveness to distinguish the two, and rush the natural life cycle of the architecture by imposing classes too early.
seanmcdirmid 14y ago
I don't really get it. From the blog post, Granger is describing a very imperative object system, but you seem to be claiming that it is somehow a value-oriented functional system. What am I missing?
- krosaen 14y ago
  That's a good question - there are still objects, or groupings of data, and even tags that identify which behaviors or functions apply to them in various contexts. What strikes me as different is the entire hierarchy is a nested data structure that is easy to reason about and modify at runtime without the use of a fancy debugger. The use of 'encapsulation' that hid the underlying data in each grouping and also bind functions / methods directly to each object in this case would only make it harder to work with. Why? Because to view, construct, augment at runtime or serialize the hierarchy would require constructors, serializers, deserializers etc, instead of having something that is just a data structure, ready to be viewed, put on a queue, sent over the wire etc. The idea of 'behaviors' also provides flexibility in what functions can act on any grouping of data - the key value pairs needn't be associated with a 'class' which dictates what the associated functions will be adds more flexibility. As the author hints, there are other ways of achieving this agility - dynamic mixins. Finally, while having a well defined protocol (or API or endpoint or whatever you want to call it) is valuable and helps organize code, I think taking this idea to the extreme and saying that every single object or piece of data you pass around as arguments or return values from these end points needs to be expressed as an abstract protocol itself is where you really start to lose. An expected format of the data structures of the arguments and return values can and should be part of an API, but needing to wrap them in objects doesn't really help - and that's where this trend I speak of begins to seem like progress to me.
  - seanmcdirmid 14y ago
    This is quite the standard dynamic languages argument, I'm not seeing much new here but this wasn't meant to be new. However, my point is that this is heavily object-oriented and heavily imperative. It is just a different kind of object system that people might not be used to. If this ever catches on, we'll just need another Treaty of Orlando to re-harmonize the object community. To be honest, a lot of the object system seems to be confused and muddled. I mean, there are a million different ways to get the kind of flexibility in what the author call "behaviors" (a term incredibly overloaded, BTW), protocols, traits, type classes, etc...dynamic mixins are nothing new here also (I've designed a couple of research languages with dynamic mixin inheritance, fun stuff). As an academic, I want to see reasons why X was chosen and comparisions with previous systems that chose Y instead; but I know I won't get this from most of the people who do the interesting work in this field, so I have to figure it out for myself. Calling this an object system opens up a floodgate of related systems that I can compare it against.

metajack 14y ago

This was an excellent talk at the Conj, and the talk was the best explanations of entity systems I've yet found. I also recommend his Anatomy of a Knockout which also covers more of this topic: http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou... with discussion: http://news.ycombinator.com/item?id=4907791 http://news.ycombinator.com/item?id=4907791

martinced 14y ago

First let me say that I really don't want to be mean here: I'll try to do constructive criticism. I've worked professionally in the video-game industry and I must say that I'm a bit disappointed by all these blogs / videos trying to promote tools and/or languages by using very poorly conceived games. Take ChromaShift for example: it's terribly bad. We're in 2013 and the thing draws less "pixels" and yet is slower than any 2D scroller from the 80s running on a C64. Sure, it was done in 48 hours and kudos for that... But back in the nineties we'd enter 48 hours or 24 hours "demo" competition and come up with stuff incredibly better looking than that. The author of ChromaShift made a talk about the "Component Entity System" he's using. And that's where the "suspension of disbelief" simply doesn't work for me: everytime he shows the game, it's freakin' ugly and slow as molasses. Then comes the disappointment: if you want to run at a reasonable framerate you, of course, need to perform quite some logic in about 16 milliseconds (the author correctly mentions it in its talk). And... Drumrolls: simply "iterating" over a seq made of a hundred elements in Clojure apparently takes more time than that. Not to mention that if you create objects at every frame then at one point the GC shall have to kick in and your real-time performance will suddenly drop (the author says that in the talk I watched about CES/Chromashift). But why oh why use a language that is very arguable not meant to write video games in (Clojure) to... write a game in it as an example of what can be done!? (or as an example of how powerful an IDE supposedly is!?) The "problem" is that they're talking about that "CES" as it was the one way to create games. But how many games written in Clojure have been shipped? Heck, how many games written in Clojure are even playable? There are, today, lots of people writing games (either professionals or amateurs) and selling them (or giving them away for free). And not a single one of these game is using that "Component Entity System". And hardly any of them is using Clojure (there may be one or two exceptions but that's about it). And every single of these real games (even the simplest smartphone game) is looking better and is more responsive than the poor examples we see in Clojure talks. So how are we, Clojure believers (I'm a big Clojure fan and investing lots of time and energy learning it), supposed to take any of this seriously? Once again, I don't want to be mean: these guys are typically good programmers but, to be honest, they don't know anything about game programming and that is a bit saddening. EDIT: I won't even start talking about the "quality" of the "text editor" part of Light Table. I like the concept of LT but I do wan't a client/server mode where I can plug in vim or Emacs (or Sublime Text 2 or whatever) as my text editor. Otherwise I'm never going to take LT seriously.

endlessvoid94 14y ago

Code editor, modifiable at runtime, built on a dialect of Lisp... ;-) I'm a fan of Light Table. Just had to point it out.

felideon 14y ago
Sounds like you're looking for Emacs: http://www.gnu.org/software/emacs/ http://www.gnu.org/software/emacs/
- endlessvoid94 14y ago
  That was the joke :-P
seanmcdirmid 14y ago
Light Table is Emacs for the 21st century. Emacs lacks reactivity and doesn't support liveness (you have to manually refresh).

agumonkey 14y ago

I've screamed this elsewhere already, it feels like smalltalk is back, and maybe even GeneraOS ?

shaunxcode 14y ago
I hope it is a scream of "FINALLY!!".
seanmcdirmid 14y ago
This is much better than smalltalk. In Smalltalk, you could just edit code on the fly, but nothing would happen if that code wasn't continuously executing in an infinite loop. LightTable, on the other hand, supports real liveness. Its something that we never got in Smalltalk or Lisp. Edit: Morphic (from Self) does support liveness, but only when it is being edited at the graphical level. If you are editing code, you are stuck in the same refresh trap as Smalltalk or Lisp, but to be fair, morphs are continuously updating themselves in infinite loops so it doesn't matter :)
- agumonkey 14y ago
  Fine, I forgot Self, forgive me :p That's what I'm waiting for anyway, lazy reactive systems
klibertp 14y ago
I'm sad that this comment is the last on this page and not the first. I imagine that - after LT is complete - some Smalltalkers will hold a competition to replicate it in 48 hours. I believe they would succeed - building on top of Smalltalk environment with Morphic[1] this shouldn't be too hard. For those who don't know why: go grab Pharo[2] Smalltalk and "Pharo By Example"[3] book and play with it. It's absolutely beautiful, an experience well worth a few days of time. [1] As already noted Morphic was first implemented for Self and is not a neccessary part of any Smalltalk. [2] http://www.pharo-project.org/home http://www.pharo-project.org/home [3] http://pharobyexample.org/ http://pharobyexample.org/
- agumonkey 14y ago

lispm 14y ago

Behaviors? Methods. Tags? Classes. Just data? In Lisp the code, the functions, the symbols, etc. already are data. Sure one can build another dynamic object system and use fancy names for it. It is really difficult to count the number of times this had been done in the past. A typical Lisp-based system which does that was Object Lisp: http://lispm.dyndns.org/docs/ObjectLisp-Manual.pdf Used by LMI for their user interface and by Coral for Macintosh Common Lisp (until Object Lisp was replaced by CLOS). The idea that a) one can add and remove behaviors (methods) and b) add and remove tags (classes / mixins / ...) at runtime is found in almost every Lisp-based object system. Operations for that are available in every system. Lisp-based object systems are not that much a language, but more a collection of objects and classes which interact in a defined way. Called a 'system'. That's also we have the Common Lisp Object SYSTEM, and not the Common Lisp Object Language. CLOS is described in terms of objects and their interactions (classes and generic functions are objects themselves) - not so much as a grammar of language constructs.

seanmcdirmid 14y ago
This isn't very fair. Yes, Granger is describing another kind of object system and yes it is OOP. And yes, this is in the long tradition of CLOS. But all of these sytems are fairly unique and deserves its own description, in this case reactivity is extremely important.
- lispm 14y ago
  what is unique about it?
  - seanmcdirmid 14y ago
    As mentioned, the reactivity makes this interesting to me. The amount of reactivity required for a project like LightTable is pretty ambitious, which we don't really see in most Lisp object systems (or any object systems for that matter).
    - lispm 14y ago

seanmcdirmid 14y ago

I would love to see more context about the architecture of the system; e.g. how are the objects organized and what are they reacting to? I've seen many reactive object systems and I can't easily place this one in context, but maybe I'm spoiled by academic publishing (where we understand a new system in relation to older systems). It seems like this object system is related to Rodney Brooks' behavior-based subsumption architecture (used mostly in robotics and games) or not? It uses much of the same terminology, but doesn't actually have subsumption (as conflict resolution). Strange. It also seems to be very imperative, in the sense that behaviors and behavior/object relationships seem to be managed very discretely as opposed to using any kind of declarative continous abstraction (say data binding or guarded connections). This bothers me a bit, as I have found these systems to be very unmanageable as they scale. But I still like where this is going, I can't wait to learn more!