This is a long post. It deals with tangential topics that may interest some greatly, and others not at all. Feel free to ignore.
After watching the video, I said that I would have to learn JavaScript. I got a lot of excellent suggestions for study, including various well-known videos. CoffeeScript, http://coffeescript.org/ is a revelation. That's the route I will take, eventually. But for now, I have code to get out the door. I'm certainly not going abandon Leo simply because it isn't lacks a bit of wow :-) ===== Reverse engineering the demo Lying in the tub last night, I realized my knowledge of JavaScript is already sufficient to reverse engineer Bret's tree demo. Kent is correct: it's about events, but that's not the way the Aha came to me. The Aha is simply this: *The editor is part of the game*. Doh! The editor must be hooked into the game: changing the editor must produce an *immediate* effect on the game. In other words, the game is "hot linked" to the editor. Clearly, this could be done in Python without any particular fuss. We can say that the editor is part of the game, but that only means that changing *the code being edited* changes the game instantly. It is *not* true that changing the editor *itself* is possible. We wouldn't want that! This picky distinction between the editor and the code being edited is important: it makes a *big* difference when thinking about the feasibility of various kinds of interactivity. In particular, we can not edit MooTools with the editor in the Tree demo! Armed with these new insights, it is easy to see where the "magic" comes from. It happens in TangleKit.js, a smallish file. This contains:: // TKAdjustableNumber // // Drag a number to adjust. // // Attributes: data-min (optional): minimum value // data-max (optional): maximum value // data-step (optional): granularity of adjustment (can be fractional) Presumably the connection with the game happens in the updateStyle code, which I presume is part of a base class. The point is simply this: once we think of the editor is being part of the game, it is no great magic to have the editor hot-link the code being run. Again, this can be done in Python. ===== Implications for Leo 1. Let me remind myself, and us all, of the danger of dismissing Bret's demos as being not applicable to "real" projects. It's so easy to fall into that kind of stupidity. For instance, it would be easy to dismiss Bret's contempt for unit tests in several ways. My favorite is: Leo's unit tests take about 15 seconds, even when run externally (without the Qt gui). Therefore (?!?) unit tests can not be run interactively, and furthermore [pious words about testing the "real" world omitted]. In fact, however, the demo challenges me to run *particular* unit tests whenever the associated code changes. Could we do this? I think we could, especially in Leo. I have often mentioned the connection between Leo's nodes and mathematical relation. In mathematics, a relation is *just* a tuple. Nothing more! In Leo, any node can be considered a tuple! The node "represents" the tuple, the contents of the tuple are the node's children. Clear? Thus, to associate code with unit tests, we need only create a convention for associating source code with nodes. But clones make this trivial to do! - @interactive-unit-tests - @itest - @test spam - (clone of) spam This is all we would need to "declare" that @test spam should be run whenever the spam node changes! These are just first thoughts, made up as I am writing this post. But clearly, Leo can do more in this area. 2. I learned a *lot* about CoffeeScript by using the "Try CoffeeScript" pane at http://coffeescript.org/ In particular, several of the examples are incomplete. I think they did this on purpose--it forced me to dive in and figure out how to correct/complete the examples. The pane is interactive in almost exactly the same way as Bret's demos. You type CoffeeScript on the left; the corresponding JavaScript code appears on the right. I learned things instantly using this demo that I would not have discovered *at all* just by reading documentation. Moreover, the demo was fun and compelling, much as Bret's demos are fun and compelling. Can we do something similar in Leo? Maybe. In this case, there is a long history of editors trying, and failing, to "protect" users against mistakes, especially syntactic mistakes. Often, these kinds of "helpful" editors become simply annoying. Another idea is to have Leo create some "deep structure" in the background automatically. However, I think this a risky project. Absent some major Aha, I don't see the way forward. The question is, "what could appear in the rendering pane that would really help me as I develop code?" I just don't know. Let's go back to unit tests, and see what they might provide in this context. The so-called stupendous Aha says that *any* assertion about a program can be embodied in a unit test. So it would seem that we need only create interactive unit tests for all important parts of Leo's code. This *might* work, but I have concerns. One one hand, we want interactive unit tests to be close (in the outline) to the code being tested, so that we can work on the unit test in tandem with the code being testing. Otoh, we *don't* want interactive unit tests to be close to the code being tested, because that would clutter the outline unbearably! Perhaps the solution is to put the unit tests near the code during initial development, and then file the unit tests away after the initial development is complete. I do something like this at present. ===== Summary Bret's tree demo works because the editor is "in on the game", at least in development mode. At the bare minimum, it would be good to have Leo run unit tests any time the associated code changes. Leo can do this, given a smallish amount of new infrastructure. Rather than dismissing Bret's demos as impractical, it is far more useful to think of them as challenges (as in a whack on the side of the head) to add more immediate feedback to Leo. There *are* limits to feedback. Just as Bret's tree demo does *not* allow the code for the editor itself to be edited, it would not be a good idea to hot link Leo's own sources while editing Leo! Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
