Leo and Eve

[Kent Tenney]

(gotta be a Genesis joke in there somewhere ...)

FYI

I'm not sure how best to link to posts to other lists, so I've copied and pasted

So, Leo appeared on the Eve mailing list. Eve is a project of Chris Granger,
author of the Light Table IDE which had lots of buzz a while ago

http://witheve.com/

The post bringing up Leo was from
0joshua...@gmail.com who's posted a couple times here
========================================================
0joshua...@gmail.com

Apr 30 (6 days ago)

"Leo is a project I follow. Although it's built on Python scripting
and IPython integration, the reason I brought it up here is how it
builds a text/data workflow around extremely configurable views of an
underlying (directed acyclic) graph. So it's like a semantic wiki
where the user specifies the semantics and filters, the external
files, etc."

2 replies:
========================================================
Zubair Quraishi z...@nemcv.com via googlegroups.com

May 4 (2 days ago)
to Eve, 0joshua.olson1
I took a look at Leo. looks very interesting, but I think they need to
work on their presentation if they want to catch a wider audience. It
is amazing how many great tools never see the light of day as they are
released without any "polish" (as in Shine) . I just hope that Eve has
the right shine to it when released, but after seeing Light Table I am
sure that Eve will be a polished product!

========================================================

Chris Granger <ibd...@gmail.com>

11:47 AM (26 minutes ago)
to Zubair, Eve, 0joshua.olson1
Sorry for the slow response here, we've been heads down getting a demo together.

When I was doing research for LT, I came across Leo and looked into
it. It definitely exhibits some of the original tenants of LT :) I
didn't actually play around with too much as it seemed to be
positioned in kind of a weird way and it seemed like SmallTalk's
browsers were a better implementation of what Leo tries to present.
That being said, I'd love to hear what someone who really uses it
thinks about it.


Cheers,
Chris

[john lunzer]

Oh boy! Posted over there if anyone is interested in my diatribe. 

[Kent Tenney]

Nice advocacy!

> --
> 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.

[Joshua Olson]

That was me! I was just GitHub surfing and saw that Eve hadn't made much progress on the documentation side. Leo on the other hand has plenty of documentation, but its organization to me is more historical than efficient, as Zubair said.

[Edward K. Ream]

On Fri, May 6, 2016 at 12:21 PM, Kent Tenney <kte...@gmail.com> wrote:

(gotta be a Genesis joke in there somewhere ...)

​Thanks for these pointers, Kent.  I've been busy on other things this last week.  I've just finished Joshua's superb summary of Leo, and I'll be studying the Eve materials before joining the Eve's conversation myself.

Edward

[Edward K. Ream]

On Fri, May 6, 2016 at 3:44 PM, Joshua Olson <0joshua...@gmail.com> wrote:

That was me! I was just GitHub surfing and saw that Eve hadn't made much progress on the documentation side. Leo on the other hand has plenty of documentation, but its organization to me is more historical than efficient.

Many thanks for your summary of Leo, Joshua.  I especially like the mini-story about your colleagues wondering how you got such a good memory.  Programming may be, as Chris Granger says, incidentally complex, but while we are stuck with text that complexity doesn't look like disappearing ;-)

I'll say more on the Eve list when I've had a chance to thoroughly digest what they are saying.

EKR

[Joshua Olson]

 mini-story about your colleagues wondering how you got such a good memory

That wasn't me, but thanks for your thanks!...?

On Friday, May 6, 2016 at 1:21:38 PM UTC-4, Kent Tenney wrote:

[Edward K. Ream]

On Fri, May 6, 2016 at 12:21 PM, Kent Tenney <kte...@gmail.com> wrote:

So, Leo appeared on the Eve mailing list. Eve is a project of Chris Granger,

​ ​

author of the Light Table IDE which had lots of buzz a while ago

​We'll have to see what Eve is like.

However, most of the supposed rationale for Eve seems dubious to me:

1. programming is hard because our computers are organized around text.  Until that changes, our programs will be built on text.  Sure, there will be tools that hide that fact.  Think, for example, of Boeing's cad systems. Deep Mind's Alpha go was a breakthrough not because of better programming, but because it used neural networks.

2. Tool building will continue to be essential for the foreseeable future. My friend Lloyd Smith, a co-inventor of the gene sequencer, says that most Nobel Prizes are awarded for new tools and techniques. Denigrating tools by calling them self-licking ice cream cones is way off the mark.

3. We can imagine platforms for math, or games, or whatever. What's harder to imagine is a platform that makes creating such platforms substantially simpler.  I've been programming for 45+ years.  I've heard lots of similar claims in the past. None have been earth shaking, despite initial enthusiasm.

To summarize, starting from grand ambition is seldom the way toward the unglamorous incremental improvements that turn the Wright Flyer into the SR-71.  Boeing's software no doubt was ambitious.  It took a ton of text to make it happen.

Closer to home, I think Leo's clone-find commands are a real breakthrough. They are much more useful than anything in the light-table world.  It's probably fairly common that such breakthroughs surprise even their creators.

In short, I am leery of grand, nebulous claims. My guess is that if they had something they would be talking differently. We'll see...

Edward

[john lunzer]

Sorry for the delayed response here, the "summary" of Leo was from me. I believe Joshua was the one who started the thread.

[john lunzer]

For Eve this diary of a former developer is perhaps the most telling. Only the very beginning is relevant to Eve, here is an interesting snippet:

However, it's [Eve] not yet useful for me. I spend my days building compilers and IDEs, tasks which are not exactly a core focus for Eve. So if Eve is an experiment in 'programming for knowledge workers' then Imp is an experiment in 'programming for people who make things like Eve'

This enforces the general tone I got from reading about Eve. It's clear from the above mentioned diary and Eve's rationale document that Eve is not designed for programming at all and so is only slightly related to Leo in the world of (idea/story/design) management. And yet in the same rationale document they list in detail the "problems" with programming. So it's slightly confusing as to what their ultimate goals are. 

I am interested in seeing what Eve looks like when she steps out of the shadows.

[Edward K. Ream]

On Fri, May 13, 2016 at 6:42 AM, john lunzer <lun...@gmail.com> wrote:

Sorry for the delayed response here, the "summary" of Leo was from me. I believe Joshua was the one who started the thread.

​A great summary.  People remember stories like the one you told about your colleagues wondering how you have such a great memory.

EKR

[Edward K. Ream]

On Fri, May 13, 2016 at 7:19 AM, john lunzer <lun...@gmail.com> wrote:

​> It's clear 

​[from] Eve's rationale document that Eve is not designed for programming at all and so is only slightly related to Leo in the world of (idea/story/design) management. And yet in the same rationale document they list in detail the "problems" with programming.

It sounds suspiciously like hype ;-)

EKR

[Edward K. Ream]

On Fri, May 13, 2016 at 4:26 AM, Edward K. Ream <edre...@gmail.com> wrote:

1. programming is hard because our computers are organized around text.  Until that changes, our programs will be built on text. 

​One more thing.  Imo, Python​'s classes and other features are all that is needed to build up any desired framework.  That is, Python is a great way to get farther and farther from the nitty-gritty (text) details and closer and closer to the domain the user sees.

For example, c.p (a python property) is a beautiful front end for Leo's position class.  There is no way to do better than that in the text world.  Similarly for Leo's generators, etc. etc.

EKR

[Offray Vladimir Luna Cárdenas]

Hi,

Some people ask me about my memory. Curiuosly is pretty bad for birthdays and names, but good for stories and "structure". I think my good memory is empowered by this outlining approach that software like Leo or Freemind/Freeplane gives, which lets you build kind of modern mind/memory palaces [1], where a multimodal approach that requieres visualization, reading and writing creates a structure that "belongs to you" (was not automatically created by something).

[1] https://en.wikipedia.org/wiki/Method_of_loci

The answer that mentions Smalltalk in this Leo and Eve thread is evocative. I have made some previous connections of Smalltalk and Leo in this list in the past and my outliner trying to combine part of the experiences of Leo + IPython in a intractive outliner, writing and visualizing tool tries to expand such possible connection of ideas. Here is a screenshot of how looks the interface today (more details of this screenshot on [2]):


[2] http://mutabit.com/offray/blog/en/entry/panama-papers-1


I will try to add more about this Smalltalk - Leo bridges soon.

Cheers,

Offray

[Offray Vladimir Luna Cárdenas]

Hi,

On programming basically based on text and the idea that other metaphors for organizing thinking could improve the way we think (even if they have text, but uses tools like classes for organizing it). I strongly recommend:

[1] The Future of Programming https://vimeo.com/71278954 (please see it all, it's half an hour worth).
[2] Media for Thinking the Unthinkable https://vimeo.com/67076984 (10 minutes longer and also worth :-).

In my case, when I found Squeak almost 10 years ago I felt it interesting and empowering for me and my students, but also it imposing to much pre-existing structure on me, while Leo with its emerging outlining structure was a liberating experience, particularly because most of what I do is writing plus scripting. Then I see the improvements on IPython notebook and thought some ideas about integrating them [3], but there was a lot of (accidental?) complexity on the technologies behind, so I took a new approach not with the specific technologies (Leo + IPython), but with the ideas (outlining + live coding / interactive writing and visualization) in Pharo[4]. In this way I'm getting the core of what these technologies bring to me and still I'm using them for specific purposes (Leo for deconstructing others textual code is unbeatable).

[3] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[4] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

There is still a lot of work to do and things to be improved, but I think that the big problem with "disruptive technologies for the future" is the idea of reimagining all from zero, without looking from interesting ideas of the past (Smalltalk) and present (Leo, Pharo, IPython) and trying to combine them[*]. Crosspollination seems the best approach for innovation, but is difficult to get with such specialized self-centered communities and technologies of current times.

Cheers,

Offray

[*] Of course my own crosspollination exercise of interesting ideas is not the best example, it's just the best I know.

[Edward K. Ream]

On Friday, May 13, 2016 at 9:11:10 AM UTC-5, Edward K. Ream wrote:

And one more "last" thing. The statement that breakpoint debuggers are the best debugging tool is misleading:

1. In Leo, I use g.trace-based tracing much more often than g.pdb.

2. Any significant project will use unit tests as a debugging tool, and most will defined their own domain-specific debugging tools.  This should go without saying.

3. The "stupendous Aha", combined with Leo's clones, is a great way to test code as it evolves without the need to use imp.reload.  Simply clone the code under test as a child of the @test node and "include" the code with @others. After that, I can insert calls to g.trace (or rather, enable the trace constant in any particular def) without having to reload anything.  A big time saving.

EKR

[Edward K. Ream]

On Friday, May 13, 2016 at 9:45:09 AM UTC-5, Offray Vladimir Luna Cárdenas wrote:

> Curiosity is...good for stories and "structure". I think my good memory is empowered by this outlining approach that software like Leo or Freemind/Freeplane gives.

And Leo continuously reinforces our memory for structure by making the structure always visible.

> I will try to add more about this Smalltalk - Leo bridges soon.

Presumably it's possible to export Smalltalk projects to text.  I wonder whether a smalltalk importer/exporter would be a good thing to have.

EKR

[Edward K. Ream]

On Fri, May 13, 2016 at 10:17 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

the big problem with "disruptive technologies for the future" is the idea of reimagining all from zero, without looking from interesting ideas of the past (Smalltalk) and present (Leo, Pharo, IPython) and trying to combine them[*]. Cross-pollination seems the best approach for innovation, but is difficult to get with such specialized self-centered communities and technologies of current times.

​I agree.  That's why importers/exporters have high priority in Leo. ​Have you tried Leo's new Jupyter integration?

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

On 13/05/16 10:26, Edward K. Ream wrote:
> On Friday, May 13, 2016 at 9:45:09 AM UTC-5, Offray Vladimir Luna
> Cárdenas wrote:
>
> > Curiosity is...good for stories and "structure". I think my good
> memory is empowered by this outlining approach that software like Leo
> or Freemind/Freeplane gives.
>
> And Leo continuously reinforces our memory for structure by making the
> structure always visible.
>

Yes. Seeing detail and the whole is a big win for Leo and outliners as
metaphor for thinking.

> > I will try to add more about this Smalltalk - Leo bridges soon.
>
> Presumably it's possible to export Smalltalk projects to text. I
> wonder whether a smalltalk importer/exporter would be a good thing to
> have.
>

Don't think so. Smalltalk has a strong and old tradition about how to
organize the code, cristalized in its code browser (its being
deconstructed including even trees cards and other experiments). If I
could bring one feature of Smalltalk to Leo it would be live coding (the
idea of making some Leo nodes, IPython cells).

Cheers,

Offray

[Offray Vladimir Luna Cárdenas]

Not yet. I think that interaction between Leo and IPython shouldn't be centered around file importers/exporters, but on "services". The question would be how to make a node of Leo become behaves/becomes like a cell talking with IPython (with code completion, graphics, etc.)

Cheers,

Offray

[Edward K. Ream]

On Fri, May 13, 2016 at 10:45 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

​I agree.  That's why importers/exporters have high priority in Leo. ​Have you tried Leo's new Jupyter integration?

Not yet. I think that interaction between Leo and IPython shouldn't be centered around file importers/exporters, but on "services". The question would be how to make a node of Leo become behaves/becomes like a cell talking with IPython (with code completion, graphics, etc.)

​Maybe, but that's a lot of work.  Jupyter is really good a code completion & graphics, and the first step is just to use that capability.  Two notes:

1. IPython does really good code completion because all the Python objects are "live".  Leo's livecode and valuespace plugins have similar capabilities.

2. IPython gets its cool graphics capabilities from matplotlib, which is easily done in Leo too. 

So Leo already has live completion, graphics and Jupyter integration.  Yes, service-oriented integration would be great.  Perhaps your students could do it ;-)

Edward

[Edward K. Ream]

On Fri, May 13, 2016 at 10:17 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

​> ​

I strongly recommend:

[1] The Future of Programming https://vimeo.com/71278954 (please see it all, it's half an hour worth).

​I enjoyed this.  It's cutesy and glib, but the main message is right on target: we should always be aware that there are creative, new ideas ready to be discovered.

Otoh, it is misleading.  Engineering has its own logic. The talk wildly underestimates how hard engineering can be.

There is a reason we still have text. The information content of text is much bigger than pictures, even though a picture is said to be worth a thousand words.

I have said many times that we are not using the stupendous processing power at hand.  Otoh, it is innumerate to imply that because computers are x times faster it should be easy to harness that power.  Calculations can easily explode faster than Moore's Law.

Only now, as of 2014, do we have a parallel computer architecture that doesn't require its own dedicated Gigawatt power plant:

A million spiking-neuron integrated circuit with a scalable communication network and interface

http://science.sciencemag.org/content/345/6197/668

And science is no less challenging.  Yes, we now have Alpha Go.  It took decades of research before the way to train neural nets became apparent.  See my blog post:
http://edreamleo.blogspot.com/2012/12/deep-learning-sensational-theorem-and.html

In short, this talk challenges us all to use the computing power that is available to us.  It is short on usable hints about how to do this.

Edward

[Terry Brown]

On Fri, 13 May 2016 11:43:28 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> There is a reason we still have text. The information content of text
> is much bigger than pictures, even though a picture is said to be
> worth a thousand words.

I always feel this way about command line / shell vs. "graphical" file
manager / gui programs. People (non-coders, typically) express
surprise at the use of the shell, but they always express this
surprise with words, not gestures or graphical representations. Sign
language aside, humans choose words for communication. The use of
word based languages probably shaped the evolution of the human brain.

The top level summary of a piece of code can / should be a series of
commented function calls (or whatever) - the comments are in a human
language.

(haven't looked at the Eve software / list at all)

Cheers -Terry

[Offray Vladimir Luna Cárdenas]

Hi,

On 13/05/16 11:21, Edward K. Ream wrote:

On Fri, May 13, 2016 at 10:45 AM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

​I agree.  That's why importers/exporters have high priority in Leo. ​Have you tried Leo's new Jupyter integration?

Not yet. I think that interaction between Leo and IPython shouldn't be centered around file importers/exporters, but on "services". The question would be how to make a node of Leo become behaves/becomes like a cell talking with IPython (with code completion, graphics, etc.)

​Maybe, but that's a lot of work. 

Yes... that was I started a new project to have kind of outlining + live coding, but in Pharo.

Jupyter is really good a code completion & graphics, and the first step is just to use that capability. 

Having outlining in one tool and code completion & graphics (and other live coding features) in another makes the explorative computing experience really indirect.

Two notes:

1. IPython does really good code completion because all the Python objects are "live".  Leo's livecode and valuespace plugins have similar capabilities.

2. IPython gets its cool graphics capabilities from matplotlib, which is easily done in Leo too. 

So Leo already has live completion, graphics and Jupyter integration.  Yes, service-oriented integration would be great.  Perhaps your students could do it ;-)

I don't have students for enough time for complex projects. They're from freshmen (but not much this days) or (mostly) without programming backgrounds and in such cases the outlining + visualization + live coding of Pharo have demostrated to be a better learning environment in my teaching experiences.

Anyway some of the ideas of Leo would be cross with the ones of those other environments, even with other technology instead of python for implementation.

Cheers,

Offray

[Offray Vladimir Luna Cárdenas]

Hi,

On 13/05/16 12:08, 'Terry Brown' via leo-editor wrote:
> On Fri, 13 May 2016 11:43:28 -0500
> "Edward K. Ream" <edre...@gmail.com> wrote:
>
>> There is a reason we still have text. The information content of text
>> is much bigger than pictures, even though a picture is said to be
>> worth a thousand words.
> I always feel this way about command line / shell vs. "graphical" file
> manager / gui programs. People (non-coders, typically) express
> surprise at the use of the shell, but they always express this
> surprise with words, not gestures or graphical representations. Sign
> language aside, humans choose words for communication. The use of
> word based languages probably shaped the evolution of the human brain.

In fact we have multimodal brain expressing a lot including surprise in
multimodal ways (gestures *and* words *and* images) and we should use
this complementary ways of communication and understanding. Computers
have privileged just the symbolic part of human thinking/expression.
This talk, also from Brett Victor, is interesting about this:

https://vimeo.com/115154289

Cheers,

Offray

[Edward K. Ream]

On Friday, May 13, 2016 at 10:17:12 AM UTC-5, Offray Vladimir Luna Cárdenas wrote:

> I strongly recommend:

[1] The Future of Programming https://vimeo.com/71278954 (please see it all, it's half an hour worth).
[2] Media for Thinking the Unthinkable https://vimeo.com/67076984 (10 minutes longer and also worth :-).

I enjoyed the second video.  Much more convincing because more concrete. I especially enjoyed the first (mathematical) example. It's great to see the "translation" of the symbols into pictures. Very much in the style of Edward Tufte. The last example could and should be applied to the World3 model. The world has done its absolute best to ignore it, and this will have dire consequences.

It would be good to have interactive modelling tools for programs.  At present, mypy is looks like the state of the art for analyzing Python programs, but it is not interactive.  I speculate that we don't have nearly enough computing power to do interactive checking without a massive investment in behind-the-scenes infrastructure.

But that's good news!  It invites us to see how we can short-circuit computations to allow them to be done quickly.  In turn, this invites us to consider "medium-data" databases.  I'll have a think about this. I have, over the past several years, given this problem a lot of thought without a huge return on investment.  The state of the art at present, imo, is that mypy stub files represent a useful distillation of knowledge.  But this is very far from a proper design-level view of Leo, or any other program.  There are various modelling tools that may be worth investigating...The point is that program design is every bit as challenging, if not more so, than modelling circuits or bridges or whatever.

I've just started following Bret Victor on twitter.  I think he's worth listening to.

Edward

[Kent Tenney]

Do you follow Ville? @vivainio news from the bleeding edge of coding.

Pieter Hintjens @hintjens brilliant code and writing,
Has cancer which will take him out soon, but tweeting about the process.

Edward, I bet you'd enjoy @pickover

I mostly just retweet jokes @ktenney

[Edward K. Ream]

On Fri, May 13, 2016 at 6:57 PM, Kent Tenney <kte...@gmail.com> wrote:

Do you follow Ville?

​Yes.​

 

Pieter Hintjens @

​​

hintjens brilliant code and writing,

​Thanks.  I do now.

EKR

[Edward K. Ream]

On Friday, May 13, 2016 at 10:17:12 AM UTC-5, Offray Vladimir Luna Cárdenas wrote:

In my case, when I found Squeak almost 10 years ago I felt it interesting and empowering for me and my students, but also it imposing to much pre-existing structure on me, while Leo with its emerging outlining structure was a liberating experience, particularly because most of what I do is writing plus scripting. Then I see the improvements on IPython notebook and thought some ideas about integrating them [3], but there was a lot of (accidental?) complexity on the technologies behind, so I took a new approach not with the specific technologies (Leo + IPython), but with the ideas (outlining + live coding / interactive writing and visualization) in Pharo[4]. In this way I'm getting the core of what these technologies bring to me and still I'm using them for specific purposes (Leo for deconstructing others textual code is unbeatable).

I've been thinking about these topics.

Two days ago I installed Pharo and played with it a bit.  There are a few pluses with Pharo, especially for students.  But there are also minuses, compared with Python and Leo. For starters, Python is a much better language for beginners, imo of course.

Later in this thread you said, "I think that interaction between Leo and IPython shouldn't be centered around file importers/exporters, but on "services". The question would be how to make a node of Leo become behaves/becomes like a cell talking with IPython (with code completion, graphics, etc.)"

I replied that this would be a lot of work.  On second thought, this "lot of work" might be an excellent new direction for Leo.

And you also said, "If I could bring one feature of Smalltalk to Leo it would be live coding (the idea of making some Leo nodes, IPython cells)."

I'm not sure exactly what this means, but it might be easy to do.  At present, whenever you run a script (with Ctrl-B, execute-script), Leo creates (on purpose) a new Python namespace.  It would take just one or two lines of extra code to use a common namespace for a new command, say execute-script-in-common-namespace, or maybe, execute-ipython-script.

This isn't exactly IPython cells, but it would retain "live" objects (in the common namespace).

On my walk yesterday I had what seems like an exciting idea.  I wonder if you would be interested.  It might be possible to have Leo do everything that can now be done in Pharo.  And it might not take much additional work:

- A common namespace for certain kinds of exploratory programming.
- A graphics canvas for (student) drawing projects, and a Qt turtle graphics library.  At present, Python's turtle graphics is based on Tk, but there is Qt-based turtle-graphics app called pynguin.
- Some kind of "service-based" integration with IPython.  Don't know what this would entail, but Jupyter already has a client-server architecture, which I used while developing Leo's .ipynb import/export commands.
- Some kind of debugging environment.  The simplest would just be Python's pdb module with Leo running in a console window.  It would be good to be able to connect Leo to a console after starting Leo, but that's a frill. It may also be possible to use parts of spyder to improve Leo's debugging.
- A Python tutorial, integrated into Leo by opening, say, PythonTutorial.leo from Leo's Help menu.
- An easy way to install everything.  I think Anaconda should work.

These are just my guesses about what you might want for your students.

If this kind of project interests you, please let me know.  I think it would be possible to do all this for the start of your autumn semester.

This project interests me because it is a new way to make Leo popular.  If we could train a generation of students to use Leo, Python and IPython, some of those students would continue to use Leo and would tell the world about it.

What do you think?

Edward

[john lunzer]

I realize this was not aimed at me, but this direction you speak of is exciting. 

I already use Leo + IPython to perform some form of "live coding", even manipulating Leo which is helpful in understanding Leo. But I mainly perform all of that interaction from the IPython console. It appears to be the opposite to the vision of live coding that Offray has. 

A common feature in Pharo as well as Spyder and the pudb python debugger is the object explorer. This I believe is a useful pillar of the live coding environment. 

[Edward K. Ream]

On Mon, May 16, 2016 at 8:02 AM, john lunzer <lun...@gmail.com> wrote:

A common feature in Pharo as well as Spyder and the pudb python debugger is the object explorer. This I believe is a useful pillar of the live coding environment. 

​pudb is not part of the Anaconda distros, but pip2/3 install pudb works.​

 

​Alas, pudb requires cygwin on Windows, so this will be a a bit more of a challenge for Offray's newbies.​..

EKR

[Edward K. Ream]

The problem is worse than having to install cygwin: you have to run from a cygwin console to get fcntl:
http://stackoverflow.com/questions/1422368/fcntl-substitute-on-windows/1422436#1422436

Imo, this is a killer for pudb on windows.  I wonder whether Offray is using Linux or Windows or MacOS.

EKR

[john lunzer]

It is a true shame that pudb is non-windows only. I wasn't exactly implying that pudb itself should be integrated, just that namespace object browsers are an integral part of "live coding". Having an object that you created that presented to you to browse and manipulate visually gives a tangible feel to code.

[Edward K. Ream]

On Mon, May 16, 2016 at 10:49 AM, john lunzer <lun...@gmail.com> wrote:

It is a true shame that pudb is non-windows only.

​

Perhaps there is a workaround.
​

I wasn't exactly implying that pudb itself should be integrated, just that namespace object browsers are an integral part of "live coding". Having an object that you created that presented to you to browse and manipulate visually gives a tangible feel to code.

​I've never been a fan of fancy debuggers.  pdb works well for the little mysteries, and tracing works well for more global issues.

EKR

[john lunzer]

Most of the the time I use pudb as a trace. A stack trace widget window is part of the default view of the program.

Secondly I use it because I can then very easily go into the object browser and start viewing the namespace with a tree (which as a Leo user is very comfortable).

Thirdly I use it because I can drop into any of the popular python REPLs and interact with the namespace with the comfort that those REPLs provide. IPython is the most common but ptpython is easily as awesome. 

I was never really into debuggers, pudb changed that completely. 

[Offray Vladimir Luna Cárdenas]

Hi,

It's really nice to have this conversation. Long time ago I talked about Leo and computers as "cognitive devices" for (de)construction adn how it makes for files what Smalltalk mades for objects. But at that time I hadn't the proper language and examples for a better discourse. Putting this into talk with the Bret Victor's ideas and the recent developments on IPython/Jupyter notebook or my own prototype with Grafoscopio[1] and the new energy /routes Leo is exploring seems to create a promising time for this conversation. More comments below.

[1] http://mutabit.com/grafoscopio/index.en.html

On 16/05/16 07:24, Edward K. Ream wrote:

On Friday, May 13, 2016 at 10:17:12 AM UTC-5, Offray Vladimir Luna Cárdenas wrote:

In my case, when I found Squeak almost 10 years ago I felt it interesting and empowering for me and my students, but also it imposing to much pre-existing structure on me, while Leo with its emerging outlining structure was a liberating experience, particularly because most of what I do is writing plus scripting. Then I see the improvements on IPython notebook and thought some ideas about integrating them [3], but there was a lot of (accidental?) complexity on the technologies behind, so I took a new approach not with the specific technologies (Leo + IPython), but with the ideas (outlining + live coding / interactive writing and visualization) in Pharo[4]. In this way I'm getting the core of what these technologies bring to me and still I'm using them for specific purposes (Leo for deconstructing others textual code is unbeatable).

I've been thinking about these topics.

Two days ago I installed Pharo and played with it a bit.  There are a few pluses with Pharo, especially for students.  But there are also minuses, compared with Python and Leo. For starters, Python is a much better language for beginners, imo of course.

I thought the same for long time and in fact I taught under that conviction. But I was making the wrong comparison. Smalltalk/Pharo should be compared to Operative Systems (Unix and its *philosophical* descendants: Gnu/Linux, Mac and yes, Windows). It's is a full discourse about how interact with computers and how they should work.  A long explanation why is in [1].

[1] https://open.library.ubc.ca/cIRcle/collections/ubctheses/831/items/1.0055157

The fact is that you don't only teach/learn python syntax, but also how to program (paradigms, problem solving), where to program (dev tools: IDE, debugger, source code management) and why to program ("contexts for programming", where interactive notebooks and tools for data narratives and visualization become important). There is a lot of moving parts and when you're a teacher/learner the responsibility/burden on their integration is on your shoulders. Pharo + Grafoscopio gives me all that in a single, easy to install, update & learn integrated package with: IDE + Live Coding + Data Visualization + Interactive documentation. The big concession you have to do at the start is objects all the way down, without tricks, mixtures. No functional + imperative + declarative + objects + etc. Which for me was too big at the beginning because I lack of the emergent free from structure given by outlining. With Grafoscopio I'm trying to solve that.

My path was something like this:


That being said, I would like to see live coding + Leo working. And that why next your proposal seems so interesting to me:

Later in this thread you said, "I think that interaction between Leo and IPython shouldn't be centered around file importers/exporters, but on "services". The question would be how to make a node of Leo become behaves/becomes like a cell talking with IPython (with code completion, graphics, etc.)"

I replied that this would be a lot of work.  On second thought, this "lot of work" might be an excellent new direction for Leo.

And you also said, "If I could bring one feature of Smalltalk to Leo it would be live coding (the idea of making some Leo nodes, IPython cells)."

I'm not sure exactly what this means, but it might be easy to do.  At present, whenever you run a script (with Ctrl-B, execute-script), Leo creates (on purpose) a new Python namespace.  It would take just one or two lines of extra code to use a common namespace for a new command, say execute-script-in-common-namespace, or maybe, execute-ipython-script.

This isn't exactly IPython cells, but it would retain "live" objects (in the common namespace).

A shared namespace to all of what is computed in Leo would be a good start. I envision something like this namespace being talking with a IPython kernel via ZeroMQ (BTW thanks Ken for the reference to its author @hintjens). I don't know the details but in that scenario you can have the liveness of IPython plus emergent structure and a self-referential programmable DOM of Leo.

On my walk yesterday I had what seems like an exciting idea.  I wonder if you would be interested.  It might be possible to have Leo do everything that can now be done in Pharo.  And it might not take much additional work:

- A common namespace for certain kinds of exploratory programming.
- A graphics canvas for (student) drawing projects, and a Qt turtle graphics library.  At present, Python's turtle graphics is based on Tk, but there is Qt-based turtle-graphics app called pynguin.
- Some kind of "service-based" integration with IPython.  Don't know what this would entail, but Jupyter already has a client-server architecture, which I used while developing Leo's .ipynb import/export commands.
- Some kind of debugging environment.  The simplest would just be Python's pdb module with Leo running in a console window.  It would be good to be able to connect Leo to a console after starting Leo, but that's a frill. It may also be possible to use parts of spyder to improve Leo's debugging.
- A Python tutorial, integrated into Leo by opening, say, PythonTutorial.leo from Leo's Help menu.
- An easy way to install everything.  I think Anaconda should work.

These are just my guesses about what you might want for your students.

If this kind of project interests you, please let me know.  I think it would be possible to do all this for the start of your autumn semester.

This project interests me because it is a new way to make Leo popular.  If we could train a generation of students to use Leo, Python and IPython, some of those students would continue to use Leo and would tell the world about it.

What do you think?

Advancing Leo in that direction is interesting for me also, but the problem is that now I'm making my PhD studies and hoping to submit my final thesis writing at the end of this year or the beginning of next one. So I'm not giving long semester courses anymore. Just small/intensive workshops/seminars and I have made my bet for Pharo/Grafoscopio for my research already. Anyway, when I present grafoscopio to more techie public, they ask me if something like that is available in the python world and is good to be able to answer that Leo would be exploring that path. Crosspollination of these ideas is more important and having implementations in several technologies helps to spread them. I have a lot in Leo documents that I could use for testing the live coding outlining environment and we can keep sharing ideas about this two implementations of it in Pharo and Python.

Thanks, as always.

Offray

[Offray Vladimir Luna Cárdenas]

Hi,

On 16/05/16 12:06, Offray Vladimir Luna Cárdenas wrote:

Hi,

It's really nice to have this conversation. Long time ago I talked about Leo and computers as "cognitive devices" for (de)construction adn how it makes for files what Smalltalk mades for objects.

I meant "Long time ago I talked about Leo and computers as "cognitive devices" for (de)construction and how Leo makes for files what Smalltalk mades for objects".

[Edward K. Ream]

On Mon, May 16, 2016 at 12:06 PM, Offray Vladimir Luna Cárdenas <off...@riseup.net> wrote:

>It's really nice to have this conversation.

I agree. Making Leo suitable for the classroom is a new way to have Leo take over the world ;-)

> I would like to see live coding + Leo working. And that why next your proposal seems so interesting to me:

[snip]
> A shared namespace to all of what is computed in Leo would be a good start. I envision something like this namespace being talking with a IPython kernel via ZeroMQ...in that scenario you can have the liveness of IPython plus emergent structure and a self-referential programmable DOM of Leo.

We'll see what we can do ;-)

> When I present grafoscopio to more techie public, they ask me if something like that is available in the python world and is good to be able to answer that Leo would be exploring that path.

Thanks for the mentions.

Edward