My advice going forward is to draw up a comparison of how the same Task might be written in a languge with first-class transactions, noting the modularity differences.
One point you did not make explicit is that progressions, etc. are a form of attribute-tagged code.
Tangent: I was recently looking at the research done on Starfish (serialization tables, etc.) and it reminded me a lot of your ‘style’, even if the ideas are not the same.
I wonder if this would not help also with parallel execution on multiple cores…
Yes, Laurian, it would. I have avoided going down that path because it is not relevant to improving programmability, but it might improve marketability.
Responding to MVC comments in the video…
There was actually a really weird/interesting chapter in the book Beautiful Architecture that argued Emacs was MVC at its heart, but argued it was all just very hard to see. It attributed this “hard to see” explanation to the fact all the views are hardcoded in the C programming language, the only model is a text file, and all extension is done through adding new controllers.
I had never heard this take on MVC before, primarily because I was so determined to hate MVC as a whole. I still dislike both approaches, but it does explain what I find nice about Emacs, even if it is completely counter-intuitive to common design wisdom (people always complain about ‘fat’ controllers and ‘thin’ controllers are seen as good design)
Thought experiment: What would an Emacs-style buffer editor look like in Subtext/Coherence?
Right, so Emacs has a hardwired model and view, and all the code is in the controllers. Giant pile of spaghetti. This is a good thing?
How to build a word processor out of modular updatable views is a very interesting question. The word processor was the first WYSIWYG app (Simonyi’s Bravo). Maybe it should be the first Coherent app? Nah – need something cooler.
There was an example Luke Breuer and I were going to share with you back in January, but didn’t (because we weren’t really sure how “open” your research really was – and to what extent we would get to HACK on stuff):
OCR Software usually synchronizes the scanned documented with a WYSIWYG editor, and can do updates on-demand based on actions the user takes to clarify the meaning of a character.
ALSO; RE: “This is a good thing?”
NO! Emacs is evil! Controller-stuffing is very bad, and is the antithesis of modular program composition. Among other things, this limits alternate views of models.
I just had never heard such a weird argument before. And the fact Ralph Johnson liked the argument is scary and confirms what I’ve always believed: Smalltalk’ers don’t understand semantics, because they live a blury world where imaging is continuous and oft tangled in self-referential, non-exportable ways.
I think an editor would be very interesting. Especially if it functions as an IDE for the language you are designing, and since the language is live, the feature-set of the editor should be live as well. I’d love to see how this would be “done right.” (Especially if I could actually understand the execution model.) A great video would be how you can develop the editor in itself and how the interdependency detection makes this easier/more modular. Is that something you envision as an application?
Thanks for sharing, very interesting ideas. I can see how this would be useful as an alternative to data binding systems like those in Adobe’s Flex and am trying to get my head around the efficiency/complexity benefits. I’ve looked at a few of these data binding architectures and there are some common patterns. They tend to declaratively connect the view directly to the model but do not handle the types of dependency problems you are talking about here. You get ambiguous execution orders, perhaps inconsistent results or perhaps just multiple firings to get to the final result. That certainly limits their applicability.
Back in 1991, I built a system called AVS/Express (www.avs.com) which uses a slightly different data binding approach. It supports both push and pull style expression bindings. It also supports read/write dependencies between listeners to avoid duplicate firings when there are no cycles in the data dependencies. This made data binding suitable for long computations – a superset of the data flow case but it required manually specifying read and write data dependencies which was a burden on the component developer.
Right now, I’m trying to modernize some of those ideas in new language I’m experimenting with based on Java. My current design supports events for both the get and set, supports read, write and read/write bindings, binding against most Java expression types. Bindings are queued and executed in a dependency order based on the dependencies I can detect through the binding expression. I also want to support an option for a lazy-binding, i.e. one that is executed when you call the “get” versus the “set”. All of that plus good tracing and debugging tools and I think this becomes a robust set of tools that eliminate bulky inflexible controller code and improve workflows between developers and designers.
I must say though that after watching your talk I’m going to rethink the execution phase as there are good ideas here. Do you have a handle on when coactions versus simple dependency sorting would be a difference that makes a difference? I will not support += as a bindable operation and think cycles in bindings are easy to detect and avoid. That eliminates some challenges but not all I suspect.
Thanks,
Jeff
Great, I’d like to see your new language when it’s ready.
Great stuff. Very pithy presentation. I read some of your paper and still plan on finishing it, but I think this presentation does a great job demonstrating those ideas.
A similar project Trellis by Phillip J. Eby was already mentioned in the comments before, so I just wanted to mention that that work is being continued in Reaction. I’m the initiator of that fork and have to say there is a great deal of similarity between work of Jonathan and ours. We also want to implement some of his great ideas like “latches”. But still, I think we are ahead in terms of actual implementation. For example Reaction powers a couple real, shipping applications and you can actually read the source, use the library or participate in development. The real-world use gives absolutely critical feedback on shortcomings of the approach and allows us to make better decisions on what the features and limitations should be to make Reaction as useful as it can be, to make client libraries/apps less error-prone and such. Another great benefit of Reaction is that it is a Python library not an entire new language.
Anyway, if you’re interested in this kind of stuff, drop by our mailing lists or just have a look at what we’ve got so far.
@Laurian: there’s definitely a way to use this tech for automatic concurrency (within transaction), but there’s even more to it. It turns out it can make concurrent transactions work with minimal locking, which is fantastic. I was writing an article that deals with this matter, bit it’s still unfinished. You can read the draft here. Also, if you can read Russian, here are my thoughts on Reaction+multicore.
And Jonathan, thanks again for your ideas and best of luck bringing them to reality! I’m certainly looking forward to it.
Latches are actualy electrical engineering / computer engineering circuit design constructs. To this day, I still don’t know who the genius is that invented the RS Latch.
Sergey,
It’s great that you are taking these ideas forward. Please stay in touch, and let me know if you write up any docs. Where can I find out more about the apps using Reaction?
It has to be said there aren’t too many apps yet, but I’ve heard of at least two apps in the finance industry that do use it in production. Automatic trading / data graphing /alerting are a good match for these kind of libraries. But those apps aren’t available to the public, so the only app to show at the moment would me my S3 Backup. It’s in a transitional period now as I’m replacing its older components with newer ones and all of the new GUI code from the layout and event management to logic is Reaction-based. There are a couple more I can’t talk about yet, but I can mention that I’m also successfully using Reaction for network programming and have working FTP and HTTP servers implementations. The interesting part about the HTTP server is that it supports so called COMET in the most transparent way possible. If some Reaction-managed data structure changes and there’s an open COMET connection that tracks it,
it will be waked up and client will get an update. Reaction (well, Trellis initially) proved to be a great match for network programming because, surprisingly, it made things like timeout policy implementation extremely flexible with very little work while still keeping that code easy to understand and out of the way.
Unfortunately both the GUI and network programming frameworks are proprietary because they are the competitive advantage, but I tend to move some of the most general and useful parts from them to Reaction itself, so eventually they will probably be open-sourced for the most part or even entirely.
I ask because I am searching for good examples for this kind of approach. It would be nice to have an example problem that could be solved with each of the different event management proposals out there to compare them. Please let me know if you think of any good examples.
Jonathan,
Just on the off-chance that you haven’t heard of these, they might be of interest…
Clojure is a new dialect of Lisp that runs on the JVM and has software transactional memory (ostensibly for transparent concurrency) and efficient immutable data structures
Thanks, I have heard of those. Cells is dataflow. Coherence is “dataflow without the wires”. The programmer does not have to specify the interdependencies – they are figured out automatically based on what gets read and written.
Clojure is a very nice language design. I would like to do something like that with co-actions.
My advice going forward is to draw up a comparison of how the same Task might be written in a languge with first-class transactions, noting the modularity differences.
One point you did not make explicit is that progressions, etc. are a form of attribute-tagged code.
Tangent: I was recently looking at the research done on Starfish (serialization tables, etc.) and it reminded me a lot of your ‘style’, even if the ideas are not the same.
I wonder if this would not help also with parallel execution on multiple cores…
Yes, Laurian, it would. I have avoided going down that path because it is not relevant to improving programmability, but it might improve marketability.
Responding to MVC comments in the video…
There was actually a really weird/interesting chapter in the book Beautiful Architecture that argued Emacs was MVC at its heart, but argued it was all just very hard to see. It attributed this “hard to see” explanation to the fact all the views are hardcoded in the C programming language, the only model is a text file, and all extension is done through adding new controllers.
But then at the end of the chapter the author really flipped the discussion on its head by comparing Emacs *component system* to other component systems, such as Eclipse. The author points out Eclipse plug-ins don’t agree on a single, canonical model, but rather create individual models. Ralph Johnson has a really good review of this chapter. http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=true&printTitle=EMACS:_Creeping_featurism_is_a_strength&entry=3431848835
I had never heard this take on MVC before, primarily because I was so determined to hate MVC as a whole. I still dislike both approaches, but it does explain what I find nice about Emacs, even if it is completely counter-intuitive to common design wisdom (people always complain about ‘fat’ controllers and ‘thin’ controllers are seen as good design)
Thought experiment: What would an Emacs-style buffer editor look like in Subtext/Coherence?
Right, so Emacs has a hardwired model and view, and all the code is in the controllers. Giant pile of spaghetti. This is a good thing?
How to build a word processor out of modular updatable views is a very interesting question. The word processor was the first WYSIWYG app (Simonyi’s Bravo). Maybe it should be the first Coherent app? Nah – need something cooler.
There was an example Luke Breuer and I were going to share with you back in January, but didn’t (because we weren’t really sure how “open” your research really was – and to what extent we would get to HACK on stuff):
OCR Software usually synchronizes the scanned documented with a WYSIWYG editor, and can do updates on-demand based on actions the user takes to clarify the meaning of a character.
ALSO; RE: “This is a good thing?”
NO! Emacs is evil! Controller-stuffing is very bad, and is the antithesis of modular program composition. Among other things, this limits alternate views of models.
I just had never heard such a weird argument before. And the fact Ralph Johnson liked the argument is scary and confirms what I’ve always believed: Smalltalk’ers don’t understand semantics, because they live a blury world where imaging is continuous and oft tangled in self-referential, non-exportable ways.
I think an editor would be very interesting. Especially if it functions as an IDE for the language you are designing, and since the language is live, the feature-set of the editor should be live as well. I’d love to see how this would be “done right.” (Especially if I could actually understand the execution model.) A great video would be how you can develop the editor in itself and how the interdependency detection makes this easier/more modular. Is that something you envision as an application?
Thanks for sharing, very interesting ideas. I can see how this would be useful as an alternative to data binding systems like those in Adobe’s Flex and am trying to get my head around the efficiency/complexity benefits. I’ve looked at a few of these data binding architectures and there are some common patterns. They tend to declaratively connect the view directly to the model but do not handle the types of dependency problems you are talking about here. You get ambiguous execution orders, perhaps inconsistent results or perhaps just multiple firings to get to the final result. That certainly limits their applicability.
Back in 1991, I built a system called AVS/Express (www.avs.com) which uses a slightly different data binding approach. It supports both push and pull style expression bindings. It also supports read/write dependencies between listeners to avoid duplicate firings when there are no cycles in the data dependencies. This made data binding suitable for long computations – a superset of the data flow case but it required manually specifying read and write data dependencies which was a burden on the component developer.
Right now, I’m trying to modernize some of those ideas in new language I’m experimenting with based on Java. My current design supports events for both the get and set, supports read, write and read/write bindings, binding against most Java expression types. Bindings are queued and executed in a dependency order based on the dependencies I can detect through the binding expression. I also want to support an option for a lazy-binding, i.e. one that is executed when you call the “get” versus the “set”. All of that plus good tracing and debugging tools and I think this becomes a robust set of tools that eliminate bulky inflexible controller code and improve workflows between developers and designers.
I must say though that after watching your talk I’m going to rethink the execution phase as there are good ideas here. Do you have a handle on when coactions versus simple dependency sorting would be a difference that makes a difference? I will not support += as a bindable operation and think cycles in bindings are easy to detect and avoid. That eliminates some challenges but not all I suspect.
Thanks,
Jeff
Great, I’d like to see your new language when it’s ready.
Great stuff. Very pithy presentation. I read some of your paper and still plan on finishing it, but I think this presentation does a great job demonstrating those ideas.
A similar project Trellis by Phillip J. Eby was already mentioned in the comments before, so I just wanted to mention that that work is being continued in Reaction. I’m the initiator of that fork and have to say there is a great deal of similarity between work of Jonathan and ours. We also want to implement some of his great ideas like “latches”. But still, I think we are ahead in terms of actual implementation. For example Reaction powers a couple real, shipping applications and you can actually read the source, use the library or participate in development. The real-world use gives absolutely critical feedback on shortcomings of the approach and allows us to make better decisions on what the features and limitations should be to make Reaction as useful as it can be, to make client libraries/apps less error-prone and such. Another great benefit of Reaction is that it is a Python library not an entire new language.
Anyway, if you’re interested in this kind of stuff, drop by our mailing lists or just have a look at what we’ve got so far.
@Laurian: there’s definitely a way to use this tech for automatic concurrency (within transaction), but there’s even more to it. It turns out it can make concurrent transactions work with minimal locking, which is fantastic. I was writing an article that deals with this matter, bit it’s still unfinished. You can read the draft here. Also, if you can read Russian, here are my thoughts on Reaction+multicore.
And Jonathan, thanks again for your ideas and best of luck bringing them to reality! I’m certainly looking forward to it.
Latches are actualy electrical engineering / computer engineering circuit design constructs. To this day, I still don’t know who the genius is that invented the RS Latch.
Sergey,
It’s great that you are taking these ideas forward. Please stay in touch, and let me know if you write up any docs. Where can I find out more about the apps using Reaction?
It has to be said there aren’t too many apps yet, but I’ve heard of at least two apps in the finance industry that do use it in production. Automatic trading / data graphing /alerting are a good match for these kind of libraries. But those apps aren’t available to the public, so the only app to show at the moment would me my S3 Backup. It’s in a transitional period now as I’m replacing its older components with newer ones and all of the new GUI code from the layout and event management to logic is Reaction-based. There are a couple more I can’t talk about yet, but I can mention that I’m also successfully using Reaction for network programming and have working FTP and HTTP servers implementations. The interesting part about the HTTP server is that it supports so called COMET in the most transparent way possible. If some Reaction-managed data structure changes and there’s an open COMET connection that tracks it,
it will be waked up and client will get an update. Reaction (well, Trellis initially) proved to be a great match for network programming because, surprisingly, it made things like timeout policy implementation extremely flexible with very little work while still keeping that code easy to understand and out of the way.
Unfortunately both the GUI and network programming frameworks are proprietary because they are the competitive advantage, but I tend to move some of the most general and useful parts from them to Reaction itself, so eventually they will probably be open-sourced for the most part or even entirely.
I ask because I am searching for good examples for this kind of approach. It would be nice to have an example problem that could be solved with each of the different event management proposals out there to compare them. Please let me know if you think of any good examples.
Jonathan,
Just on the off-chance that you haven’t heard of these, they might be of interest…
Kenny Tilton’s Cells
http://smuglispweeny.blogspot.com/2009/02/cells-secret-transcript.html
Clojure is a new dialect of Lisp that runs on the JVM and has software transactional memory (ostensibly for transparent concurrency) and efficient immutable data structures
http://clojure.org/
Thanks, I have heard of those. Cells is dataflow. Coherence is “dataflow without the wires”. The programmer does not have to specify the interdependencies – they are figured out automatically based on what gets read and written.
Clojure is a very nice language design. I would like to do something like that with co-actions.