Getting value from Bret Victor's video
Edward K. Ream
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
Edward K. Ream
I forgot to ask for your comments about the entire post. I would
welcome any ideas you might have for how to build more interactivity
into Leo.
> 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.
time the text will not be syntactically correct.
It would, however, be possible to run the test when the body pane *is*
syntactically correct, but I have my doubts about whether this would
be desirable. Another idea is to extend the run-selected-unit-tests-
locally command so that it looks for a clone of the selected node that
is a direct child of an @itest node.
Experiments would show which approach is most convenient in practice.
Edward
P.S. Running unit tests locally might work *better* in the @itest
world because the *present* body text of the code under test is
available to the unit test. We had best be careful: we don't want to
hot-change Leo by running unit tests locally! I'll have to give this
puzzle some more thought...
EKR
Kent Tenney
> On Feb 22, 7:16 am, "Edward K. Ream" <edream...@gmail.com> wrote:
>
> I forgot to ask for your comments about the entire post. I would
> welcome any ideas you might have for how to build more interactivity
> into Leo.
I'd guess everyone has a different idea what 'interactivity' means.
Bret's demo is _probably_ a case of tailoring a nail to match his hammer.
My tendency is to gather tools and materials which inform what I
build, as apposed to visualizing a destination, figuring out a route.
So I consider Leo to be a language or platform, its mandate is to make
more things easier to do, the easier it is to do something, the more people
will do it, the more energy is available to do the _next_ thing. So, I harp on
ease of event hooking, ease of key assignment, ease of command definition ...
as the barrier to customization keeps becoming lower, more inventions will
appear.
I think Leo has a head start in all of these things. It sounds like your recent
work has resulted in a lot of simplification, making 'core' Leo more accessible
to more of us.
As far as big ideas, maybe an inter-process layer: hide the complexity of
pushing and pulling from other applications.
Thanks,
Kent
>
>> 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.
>
> We don't want to run unit tests on every keystroke because most of the
> time the text will not be syntactically correct.
>
> It would, however, be possible to run the test when the body pane *is*
> syntactically correct, but I have my doubts about whether this would
> be desirable. Another idea is to extend the run-selected-unit-tests-
> locally command so that it looks for a clone of the selected node that
> is a direct child of an @itest node.
>
> Experiments would show which approach is most convenient in practice.
>
> Edward
>
> P.S. Running unit tests locally might work *better* in the @itest
> world because the *present* body text of the code under test is
> available to the unit test. We had best be careful: we don't want to
> hot-change Leo by running unit tests locally! I'll have to give this
> puzzle some more thought...
>
> EKR
>
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
tfer
(not just for python).
I'm considering just doing it under a, say:
@code&test <codeFile> <testFile>
The subtree would have code nodes with say:
@testF
nodes to hold tests.
A script would collect the code nodes under an '@file <codeFile>'
node, the tests under an '@file <testFile>' node, perhaps in a
chapter, perhaps evoked automatically on a save, (before the regular
save code is run).
Might be integrated with the one plugin I attempted to write that
stored incrementally written code away in a chapter as kind of
development history, while leaving the current code in the main
outline, (with swap in & out commands). Never finished as the logic
and special cases got away from me.
Tom
Matt Wilkie
> 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.
This reminds me of the concepts of structure vs presentation in html and
css. It sounds like what might be useful here are different
"stylesheets" depending on the activity. I'm changing a function, draw
unit test (and real time results?) right next to me. I'm just reading and
browsing, don't draw them at all, or at least subdue them. In either
case the actual storage position of the nodes somewhat irrelevant.
cheers,
-matt
HansBKK
Chris Granger: Connecting to your creation and Light Table - a new IDE concept