On 10/21/2013 8:00 PM, Steve Litt wrote:
Hi all,
I think this has some bearing on the recent discussion about increasing
Leo's mindshare.
Today I successfully completed Gatesphere's Leo "Hello World", and you
know what I discovered? Leo, as it's documented currently, is
impenetrable to all but the most determined.
Take a look at this:
http://leoeditor.com/tutorial-scripting.html#hello-world
Compare the text there to Gatesphere's expression of the same thing:
1) Create a node
2) Fill it's body with the following text:
g.es('hello, world!')
3) Ctrl-B (execute-script) on that node. Output should appear in the
log pane.
Gatesphere's steps make it crystal clear that g.es('hello, world!')
goes in the body of the node. The leoeditor.com hosted hello world
didn't make it quite as clear, and for awhile I was putting it in the
headline. Finally I went back to Gatesphere's description and got it
running in 45 seconds.
You might think I failed to notice the obvious. But it's a lot more
obvious to a Leo user than to a guy who thinks "hey, I wonder if this
thing really works, let's try."
I agree. I found breaking into the Leo scripting world non-trivial and
had to write several practice scripts to get myself up to speed. In the
process I learned python :p
Not to invalidate your point, it does state "Ctrl-B (execute-script)
executes the body text of the selected node as a Python script." I
think that's Edward's way of saying your code needs to lie in the body
of the node. Additionally, scripts that aren't one-liners could never
work with their code stored in headlines. But that's all obvious to
those of us who *can* script Leo, so I can totally see why it would be
missed by a newbie. Been there myself!
So next I figured, hmmm, let's try getting the thing to make some
Python files. Well, I got as far as putting @others into a headline,
and just stone gave up. It was impenetrable as currently documented.
Keep pushing! Here's another step-by-step:
1) Create a node, headline named "@file myfile.py" (henceforth "node A")
2) In the body of that node, put the following:
@language python
<< docstring >>
@others
if __name__ == '__main__':
main()
3) Create a child node of "node A", headline named "<< docstring >>"
4) In the body of that node, type this:
'''
This is a docstring. It explains what this python module does.
'''
5) Create a child node of "node A", headline named "main"
6) In the body of that node, type this:
def main():
print "hello, world!"
7) Save your .leo. It should create myfile.py automatically.
8) Open myfile.py in an external editor. Observe the structure. Run it
with a python interpreter if you want to make sure it's valid.
9) Experiment more!
Then I tried having three subnodes, each with a different g.ex(), and
seeing if I could Ctrl+B their parent. No dice. However one does
functional decomposition in Leo, it takes quite a bit of reading to
find out.
Agreed. A third step-by-step is in order, perhaps?
1) Create a node, headline anything you want.
2) In the body write the following:
@language python
x = 1
@others
3) Create a child node of that node, headline anything you want.
4) In that node's body, write the following:
g.es('test# ', x)
5) Clone that node a few times so that it is it's own sibling (i.e. hit
Ctrl-` with the node selected a few times)
6) Ctrl-B the parent node (from step 1). Observe the magic!
That example uses clones to show how they can be used to reduce code
repetition. It does not touch functional decomposition, but that is
simple: each node under a parent node is a separate function.
Here's how a lot of Geeks learn:
http://www.troubleshooters.com/bookstore/rl.htm#flowchart
Start with a proof of concept (Hello World), then keep adding one small
thing at a time, so there's never confusion. This is what current Leo
docs lack, or at least do poorly. Perhaps everyone who documents Leo is
just too familiar with Leo.
Agreed on both points! Incremental revision is the best way to learn,
and unfortunately the docs are (always, it seems) written by those
closes to the project. I run into the same issue constantly with
ConTeXt, as an aside... so this isn't a Leo-specific problem.
-->Jake
This is excellent news for Leo. The reason Leo doesn't have the
mindshare to be in daily Geek conversation isn't because it has a flaw,
or because it's a lousy way to create computer programs, or because
everyone wants drag and drop.
The reason is that, for all but the most determined Leo newbies, the
documentation, and therefore the software, is impenetrable. Think of all
the times in the past when an Infoworld writer explored Leo thinking of
the possibility of writing about it (and you know they've all heard
about it and tried it), and just ran out of time because it just took
too long to discover each step along the way. Think of the next
Infoworld writer who tries that, with a step by step (and I mean tiny,
obvious, completely described, can't miss steps) tutorial that ends with
him having made a small but meaningful application. If he likes that
software construction method better than Java or whatever IDE Microsoft
is using these days, he'll shout it from the rooftops.
If Leo is capable of creating a piece of software like Leo itself, Leo
is a few tutorials and a couple videos away from fame and ubiquitous
usage.
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
