Code Academy: how to learn Leo, or python, or anything ;-)

[Edward K. Ream]

The docs for the new importer are a personal Aha. Imo, they are some of best docs ever because they consciously avoid all detail. The Notes section is an exception: it discusses things that appear nowhere in the source code! The docs don't explain the code, they invite the reader to explore the code.

Two principles emerge:

1. The less said, the better.
2. Invite people to learn for themselves.

Let's put these principles into practice. Let's think of the Code Academy not as explanations, but as puzzles to be solved by the student. The puzzles themselves need no lengthy explanations.  They can even be cryptic.

Puzzles for the Code Academy

1. Pick a real, worthy, programming task that you (the student) personally want/need to do in Leo.

This step is essential! It's useless to try to learn in a vacuum.

EKR's first python program was C2Py. Note: @c confuses markdown.  I'll revise the script soon.

2. Overcome fear of crashes and mistakes.

- Run Leo from a console.
- Single-step through your code with g.pdb()
- Deliberately put a crasher in your code and see what happens.

The only way to hard crash Leo is to pass bad pointers to PyQt.  Python should catch all other problems.  If it doesn't, report a bug to the python people ;-)

3. Discover how Leo's code works:

- Where is Leo's source code? Hint: look for leoPy.leo in LeoDocs.leo.
- Look at Leo's demote command.
  - What are three ways of finding the demote command?
  - How does demote change the outline?
  - How does demote handle undo?
- Study any other Leo command that relates to your project.
- Use the cff command to find all definitions of x.
- Use the cff command to find all uses of x.

4. Start using Leo for real:

- Add a new command using @button.
- Create an external file containing your real-world project. Execute it outside of Leo.
- Write a Leo plugin.
- Advanced: fix one of Leo's bugs.

Edward

P.S. This post is a direct result of our recent discussions here.

P.P.S The importer docs mostly just explain the shape of the code. But in Leo, such overviews are typically not needed!  Provided the author of code takes a bit of care, the outline already shows the shape of the code. That's why we love Leo. Furthermore, he shape of the code persists, not just in our memory, but in the outline.

EKR

[Edward K. Ream]

On Tuesday, December 6, 2016 at 7:29:38 AM UTC-6, Edward K. Ream wrote:

Two principles emerge:

1. The less said, the better.
2. Invite people to learn for themselves.

Students should always feel free to ask for help, but it is struggle that teaches us the most. It's about attitude...

It doesn't matter how long it takes to learn something

In our culture, we value quickness. But that is a trap. The typical learning progression builds momentum:

- Put 10 units of effort in, get 1 unit of results out
- Put 1 in, get 1 out
- Put 1 in, get 10 out

There is no way to alter this sequence ;-) How many times have we given up just because things were not easy or clear at first?

That which we learn, we learn by doing

Reading about and thinking about are useful, but not nearly good enough.  That is why students must have a project that is important to them.  The project will put them into action.

Edward

[Edward K. Ream]

On Tuesday, December 6, 2016 at 7:29:38 AM UTC-6, Edward K. Ream wrote:

> EKR's first python program was [leo/scripts/c2py.md]

I have deleted this file. It quickly become apparent that converting a Leo script to a markdown file is a bad idea, for at least two reasons:

1. Leo's markup isn't compatible with markdown.
2. Flat text, no matter how well formatted, will never be as clear as the corresponding Leo outline.

Furthermore, I want to leave c2py exactly as it was when I first wrote it.  No docstrings, sub-optimal use of Python's string split/join functions, etc. Newbies take note: your first efforts don't have to be perfect.

EKR

[Edward K. Ream]

​​

On Tue, Dec 6, 2016 at 9:25 AM, Edward K. Ream <edre...@gmail.com> wrote:

Furthermore, I want to leave c2py exactly as it was when I first wrote it.  No docstrings, sub-optimal use of Python's string split/join functions, etc. Newbies take note: your first efforts don't have to be perfect.

​Heh.  The thing about posting is that the background mind immediately starts to second guess it :-)

I do want to revise the code.  The old code can be retained somewhere for reference, probably in the attic.  But revising this code would be instructive:

- Python 3 compatibility.

- g.trace instead of print.

- Docstrings instead of @...@c.

- Use lines = s.splitlines(False) throughout, eliminating related cruft.

- @test instead of ad-hoc test code.

Not urgent, but it's been on my mind our discussion of s.splitlines and s.isspace.

EKR

[Zoom.Quiet]

WoW ! very very suggest record type for later pythonista learnning ;-)

> --
> 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+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.



--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

[Edward K. Ream]

On Tue, Dec 6, 2016 at 10:18 AM, Zoom.Quiet <zoom....@gmail.com> wrote:

WoW ! very very suggest record type for later pythonista learning ;-)

​It's on the to-be-document list.

EKR

[Edward K. Ream]

On Tuesday, December 6, 2016 at 9:39:05 AM UTC-6, Edward K. Ream wrote:

> I do want to revise [c2py].

Never mind.  I've already done so. Leo has an integrated c-to-python command, customizable via @data nodes.

EKR