[fonc] [talk] Cool Code - Kevlin Henney
Although programming is a discipline with a very large canon of existing work to draw from, the only code most programmers read is the code they maintain. This topic came up a few times on this mailing list so I thought I would share this talk I found interesting. https://yow.eventer.com/yow-2012-1012/cool-code-by-kevlin-henney-1181 - Benoit ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Publish/subscribe vs. send
Hi Cornelius, thanks a lot for the links, I will look into these. Also, thanks for clarifying the issue I was referring to: Essentially what gets lost with pub-sub and likely any event-based integrative (EBI) architecture is that interactions are no longer explicit and less visible, but implicit and so it becomes hard to reason about the behavior of the system at a higher level. On Tue, Mar 20, 2012 at 8:58 AM, Cornelius Toole cornelius.to...@gmail.comwrote: Benoit, Have you looked at the DCI(Data, Context and Interaction) architecture stuff from Trygve Reenskaug and James O. Coplien? I don't know if this is the best link for it, but I'm in transition(or should be): http://www.artima.com/articles/dci_vision.html Essentially what gets lost with pub-sub and likely any event-based integrative (EBI) architecture is that interactions are no longer explicit and less visible, but implicit and so it becomes hard to reason about the behavior of the system at a higher level. DCI is aimed at making interactions a first class citizen. Also check out Orit Shaer's dissertation, chapter 4, section 3 (there's a journal paper that is probably more succinct, but I'm on the run): http://books.google.com/books?id=MQc6WTtulJQCprintsec=frontcoverhl=en#v=onepageqf=false In it, she discusses using high-level states to describe the behavior of interactive systems that incorporate physical representations (tangible user interfaces). It's not so much about messaging and pub-sub, but the model presented in the document relates a UI dialogue (both user-system and system-system) to a set of interaction patterns that are supported by system (see https://skitch.com/corntoole/8miq9/cs.wellesley.edu-oshaer-tuiml.pdf). Perhaps, a similar model could be used to encapsulate the relationships between certain message patterns and high-level behavior. (I see that google books omits part of the book germane to this discussion, so here's a link to the journal paper: http://cs.wellesley.edu/~oshaer/TUIML.pdf, see section 2.1.2 ) -- Cornelius Toole Sent with Sparrow http://www.sparrowmailapp.com On Monday, March 19, 2012 at 6:33 PM, Benoît Fleury wrote: Hi Casey, the decoupling of the event emitters and receivers is what I find the most interesting in a pub/sub model. The publisher raises an event (in its semantic domain) and does not know what subscribers are going to receive it or what they're going to do with it. One of the advantage of this decoupling is that you can extend a system without modifying existing parts. Practically, I also encountered systems where a pub/sub model helped reducing the amount of code. A lot of objects needed to be aware of events happening in the system and instead of having to call all these objects every time something interesting was happening in the system, we raised an event for each one of them and had the objects subscribe to these events. The other advantage I also felt while using pub/sub model is that it helped me create better object-oriented design: - because you can't send direct messages, you don't use your objects as data structures - and consequently, all the code that changes the state of your object is located in the object which makes the system easier to understand The issue I have with the event systems I encountered so far is that you gain the decoupling but lose the expressiveness of message passing. The code in the subscribers often looks like this: cause = effect cause = effect cause = effect If you want to implement a complex behavior, you need to maintain state and that becomes quickly harder to understand. That's why I was wondering if you could interleave the causes and effects in a grammar to describe the behavior of an object in a more readable way, be able to reuse rules, having higher-order rules... Benoit On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger casey.obrie...@gmail.com wrote: Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc
Re: [fonc] Publish/subscribe vs. send
Hi Casey, the decoupling of the event emitters and receivers is what I find the most interesting in a pub/sub model. The publisher raises an event (in its semantic domain) and does not know what subscribers are going to receive it or what they're going to do with it. One of the advantage of this decoupling is that you can extend a system without modifying existing parts. Practically, I also encountered systems where a pub/sub model helped reducing the amount of code. A lot of objects needed to be aware of events happening in the system and instead of having to call all these objects every time something interesting was happening in the system, we raised an event for each one of them and had the objects subscribe to these events. The other advantage I also felt while using pub/sub model is that it helped me create better object-oriented design: - because you can't send direct messages, you don't use your objects as data structures - and consequently, all the code that changes the state of your object is located in the object which makes the system easier to understand The issue I have with the event systems I encountered so far is that you gain the decoupling but lose the expressiveness of message passing. The code in the subscribers often looks like this: cause = effect cause = effect cause = effect If you want to implement a complex behavior, you need to maintain state and that becomes quickly harder to understand. That's why I was wondering if you could interleave the causes and effects in a grammar to describe the behavior of an object in a more readable way, be able to reuse rules, having higher-order rules... Benoit On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] new document
Unless I missed it, there is no mention of Dynabook Junior in the last report. Has it been abandoned? replaced? On Wed, Nov 9, 2011 at 3:27 AM, Steve Taylor s...@ozemail.com.au wrote: -1 David Barbour wrote: `+1`? Really? I seriously do not appreciate having my mail spammed in this manner. If you're offering an opinion on the article, try to say something specific and relevant to those who might have skimmed it. Which parts interested you? If you're referring to Sean's comment for recording the outreach events, please consider moving it to another topic. __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alan Kay talk at HPI in Potsdam
So, i think it is more a lack of vision, than technical/security issues. There might not have been a technical vision in the www but there is I think a political statement which is that the information must be open. Papers like The Rule of Least Power [1] make it very clear. This is, in my opinion, the essence of the web and companies like Google are built on it. I think we're moving away today from this vision with technologies like HTML5/JavaScript to respond to the application model of the iPhone/iPad (more business friendly). I don't know if it will allow us to keep this open philosophy or not. - Benoit [1] http://www.w3.org/2001/tag/doc/leastPower.html On Mon, Jul 25, 2011 at 11:20 AM, Igor Stasenko siguc...@gmail.com wrote: On 25 July 2011 19:01, Dethe Elza de...@livingcode.org wrote: On 2011-07-25, at 9:25 AM, Igor Stasenko wrote: But don't you see a problem: it evolving from simple 'kiddie' scripting language into a full fledged system. First off, JS was done in a hurry, but by Brendan Eich who was hired by Netscape because he had implemented languages before and knew something about what he was doing (and could work fast). JS itself had a marketing requirement to be have C-like syntax (curly braces), but the language itself was influenced more by Self and Lisp than any of the C lineage. And the JS we use today has been evolving (what's wrong with evolving?) since 1995. What is in browsers today was not designed in 10 days, it has been beaten through the wringer of day to day use, standardization processes, and deployment in an extremely wide range of environments. That doesn't make it perfect, and I'm not saying it doesn't have it's warts (it does), but to disparage it as kiddie scripting reeks to me of trolling, not discussion. There was no intent of any disrespect or disparage. For me, its a fact that the original implementation were started (as many other popular projects) in a form of kiddie scripting and then evolved into something bigger/better. After all, a starting point defines the way you go. It is of course a good direction and i welcome it. But how different our systems would be, if guys who started it 20 years back would think a bit about future? I don't think we would even be having this discussion if they didn't think about the future, and I think they've spent the intervening years continuing to think about (and implement) the future. Why all those emerging technologies is just reproducing the same which were available for desktop apps for years? Security, for one. Browsers (and distributed systems generally) are a hostile environment and the ability to run arbitrary code on a user's machine has to be tempered by not allowing rogue code to erase their files or install a virus. In the meantime, desktops have also become distributed systems, and browser technology is migrating into the OS. That's not an accident. Yeah.. And the only difference i see today in systems is before running a downloaded executable a system asking are you sure you want to run something downloaded from internet?. So, we're still not there. Our systems are still not as secure as we want them to be (otherwise why asking user such kind of questions?). :) From today's perspective, how you would explain to people, why drawing on canvas (as in HTML5) are available only today but not starting from HTML1.0? As Julian said before in this thread, 20 years ago we had almost same requirements.. So, assuming that 20 years back we wanted to deliver dynamic content which draws things on screen, why it took 20 years to implement it? I think the only answer could be, that we're changed the view on what 'web content' are. While 20 years back it was mostly static content with simple markup text and couple of images, today it is completely different. So, i think it is more a lack of vision, than technical/security issues. Doesn't it rings a bell that it is something fundamentally wrong with this technology? Well, I doubt we could name a technology there isn't something fundamentally wrong with. I've been pushing Javascript as far as I could for more than a decade now. Browsers (and JS) really were crap back then, no doubt about it. But they are starting to become a decent foundation in the past couple of years, with more improvements to come. And there is something to be said for a safe language with first-class functions that is available anywhere a web browser can run (and further). Yes. But wait. Why if i want to run something on a web page it has to be a javascript? Is javascript an universal answer to every possible problems we have? I doubt it. Because now, i have to rewrite own applications in javascript, just because it is the only technology which allows you to reach your user base. Everyone jumps into wagon and follows a hype. Without even considering alternatives. And its a pity. So, it is
Re: [fonc] HotDraw's Tool State Machine Editor
Hi Dr Kay, thank you for the pointer to Newman's work I was not aware of. Regarding the state machine, Engelbart already pointed out that it was not a good model for user control language in [1]. In the first attempt, the control language was described as a finite state machine, and the language allowed a formal textual definition of such a machine. [...] It was originally thought that such an approach was adequate for the definition of user-system control languages. But, to paraphrase John McCarthy, the model is metaphysically adequate, but epistemologically inadequate. Implementation revealed that the dialogue is a non-Markovian (nonstochastic, historically dependent) process on the part of both the machine and the user, and accurate characterization as a finite state machine results in so many states that the model is useless. A better model is a two-stack automaton with a small number of immediate-access storage registers. I didn't encounter a lot of systems like NLS/AUGMENT during my time at a french engineer school. I guess the situation is similar to US universities. I'm trying now to catch up and was wondering if there are other software systems built using the same principles and techniques (collection of domain specific languages). I, of course, know already about Franck and the STEPS project. Thank you again for the pointers. - Benoit [1] Development of a multidisplay, time-shared computer facility and computer-augmented management-system research (Final Report), http://bitsavers.org/pdf/sri/arc/Development_of_a_Multidisplay_Time-Shared_Computer_Facility_Apr68.pdf On Sat, Jul 23, 2011 at 11:39 PM, Alan Kay alan.n...@yahoo.com wrote: The idea of using a grammar to create a user interface goes back at least as far as Engelbart's AHI group. They used a distant past cousin of OMeta (called Tree Meta) to do this. Ca. 1966. One of the first systems to specify and make graphical grammars (and UIs) via user interactions was William Newman's The Reaction Handler PhD thesis about the same time. (William is the Newman of Newman and Sproull). It's worthwhile to contemplate that a state machine (recursive or not) is the opposite of modeless -- it is the epitome of modes. So this is not a great way to specify a really nice modeless interface (because you have to draw arrows outward from pretty much every state to pretty much every other state). Modeless at PARC meant you don't have to explicitly back out of your current 'mode' to initiate any other command. Cheers, Alan From: Benoît Fleury benoit.fle...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sat, July 23, 2011 11:05:49 PM Subject: [fonc] HotDraw's Tool State Machine Editor Hi, I found HotDraw's tool state machine editor [1] very interesting as a graphical editor for a syntax-directed translator. The state machine transforms a stream of mouse events into a stream of commands on the structured drawing. Did I push the analogy too far? I was wondering if anyone knows similar examples of graphical editor for grammars? Moreover, we didn't find (yet) a good metaphor for writing programs in general purpose programming language in a graphical editor. Do you think that might change with domain specific languages? Thank you to everyone on this list for the very interesting discussions and links. - Benoit [1] http://st-www.cs.illinois.edu/users/brant/HotDraw/Conversion.html ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
Hi Scott, I tend to agree with you. The uniform interface of the web (reduced set of HTTP verbs, links...) is what make all these applications possible. We know what to do when we have the URL to the flickr image. But we could do so much more. A simple multi-media document definition language with a protocol to manipulate these documents (similar to AtomPub but at a lower level, maybe like MIME) would allow us to create much more powerful applications. In particular, it would automatically give us addressing of any part of a document. The different applications would not have to define their own addressing scheme like it is the case today with DOM, CSS, URL fragments... Regarding the graphics rendered in NativeClient, I don't think it would necessarily require to have a web service alongside of the application to make the data available to other services. Your application (UI part) can be built on top of the structured document model and protocol mentioned above. A set of view rules would render the output of a process (structured data) to the user and transform user input into a set of commands in the underlying uniform protocol. Of course, these view rules would also be documents that can be managed using this same protocol. I imagine this architecture as a gigantic mesh of independent processes exchanging structured data using a uniform protocol. As a user, I can change the state of the mesh by observing and changing data at some points of the mesh. -- benoit On Fri, Jun 3, 2011 at 10:58 AM, C. Scott Ananian csc...@laptop.org wrote: On 31 May 2011 16:30, Alan Kay alan.n...@yahoo.com wrote: There are lots of egregiously wrong things in the web design. Perhaps one of the simplest is that the browser folks have lacked the perspective to see that the browser is not like an application, but like an OS. i.e. what it really needs to do is to take in and run foreign code (including low level code) safely and coordinate outputs to the screen (Google is just starting to realize this with NaCl after much prodding and beating.) The web is not *only* an OS. It also provides the backing data for a very large unstructured database. Google of course realize this, as their company rests on a search engine. The semantic web folks have tried in vain to get people to add more structure to the database. What the web OS must do is allow the efficient export of additional *unstructured and ad hoc* data. HTML+CSS web applications today are moderately good at this -- the images stored in flickr (say) are still in standard crawlable formats, and they show up in search results. Google's Native Client (as well as prior sandbox technologies, such as Java, etc) is *not* good at this (yet?). The graphics rendered in NativeClient are completely invisible to search engines -- and thus resources created in these apps are impossible to index. You can build a web app *alongside* Native Client in order to export data created in the sandboxed app -- but now you're just doubling the effort. Like it or not, the messy stew of HTML+CSS is the closest we have to a universal GUI canvas, loaded with equally-messy semantics -- but enough that I can take the source code for a (say) flickr or youtube page and extract the comment text and photos/video. No rival web application or web as OS framework (which is not itself built on HTML+CSS) can do that. --scott ps. the closest rival to HTML is RSS/Atom -- a more limited format, but it had it's own search engines and tools (see http://www.opensearch.org). A web OS which could still export its underlying data structures/files as a indexable/sharable/browsable RSS feed would be more competitive than a pure sandbox. Another possible avenue is exporting from your web OS something close to a filesystem -- ie, a list of downloadable documents, nothing more -- and letting the search engine peek inside the standard format of the documents to construct an index, as Google can currently do with PDF, XLS, and other common file formats. But this gives up the idea of the 'hyperlink' -- now I know there's a binary blob somewhere with information relevant to my search, but it comes without any code to edit/view/collaborate. (For a little more detail on the export as RSS aspect of this, you might check out The Journal, Reloaded at http://cscott.net/Publications/) -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
