Seeking juicy new problems

[Edward K. Ream]

This thread continues the discussion in the "Future of Leo" thread.

> I wrote Leo for my own uses, primarily to aid the design, construction and understanding of complex computer programs such as Leo itself.

Leo was a direct result of the following problem: "how can I better understand literate programs?"  The key insight was "webs are outlines in disguise".  Everything since then has been a riff on outline-based programming.

Imo, @clean completes Leo in this regard.  Leo now can interface gracefully with teammates who may not even be aware that we are using Leo.

So I am looking for a new problem to solve, one that is more interesting to me personally.  Making Leo easier to install, use or understand are all worthy goals, but they are not the kind of problem I live for, and they are not the kind of problems that have fully engaged me about Leo for the past 20+ years.

Here is a problem I am presently considering.  Leo deals with static (outline) structure.  But complex algorithms (like mypy's type-inference algorithm) can not be fully understood by reading the static code, even in outline form.  Something more is required, something that is not static.

One possibility is to use unit tests to build up some kind of representation of the problem.  I have largely ignored unit tests as a "unit" of understanding.  Is there some way to tease out understanding from each unit test?  What kind of tools would help?

This might be a juicy problem.  Real insight and invention will be required.  Understanding mypy would be useful for many people.  Ditto for any new tools that might be the result.

Having said that, I am not in a great rush to find just any new problem.  I am considering other ideas, including drawing back from programming.  But recent experience shows me, once again, that I am happiest when trying to solve juicy programming problems.

Edward

[Don Dwiggins]

On 8/19/15 5:38 AM, Edward K. Ream wrote:

One possibility is to use unit tests to build up some kind of representation of the problem.  I have largely ignored unit tests as a "unit" of understanding.  Is there some way to tease out understanding from each unit test?  What kind of tools would help?

This might be a juicy problem.  Real insight and invention will be required.  Understanding mypy would be useful for many people.  Ditto for any new tools that might be the result.

I'd suggest that the focus in this "problem" should be the mindset of Test-Driven Development, rather than the unit tests themselves.

--

Don Dwiggins
Advanced Publishing Technology

[john lunzer]

I think it is a mixture of amusing and sad that this thread has been met with crickets. I personally consider your level to be out of my league. My cricket has been due to not feeling capable of real insight and invention in this arena. I am an electrical engineer by education thrown haphazardly into software development in my current profession. Every day I feel in over my head just waiting for somebody to call me out on taking four times longer to accomplish a task they could have done. 

I feel fortunate that I found Leo and that I have been able to participate in your enthusiasm about outline based programming. When I discovered how Leo could help me I felt a sudden surge of excitement and a new found level of control and understanding of programming. Leo helps me scrape by every day where previously I felt I was drowning. I think these feelings are why I want more for Leo.

I would be delighted to participate in your next "juicy" problem, though at the moment I'm not sure I can help give any direction. I selfishly hope it's explored and developed inside Leo so that Leo can continue to grow and benefit from your passion. 

Perhaps my only insight comes from another tool which has truly changed how I program. The pudb debugger has provided me insight into programs where again, previously I felt like I was drowning in a sea of code. I'm not sure if this is what you meant by the other side of the static code but being given a graphical representation of where I am in a program and the stack and what's happening to the variables has been very powerful to me. Obviously Leo isn't a debugger but traversing "live" code is to me another "view" into a program that provides insight. The author of pudb himself said wrote that pudb is often his first weapon in understand an algorithm. So the question is, can you transform "static" code into something else... that would be a tricky problem. 

Your mention of unit tests is interesting. I see code existing in three forms: static, live, results. You have shown us through outline's that static code can be represented in different ways and that those different representations can aid our understanding of the code. I've discussed the live aspect, which helps gain further understanding of the static code. The results of a program having ran (past tense) could provide great insight into how code works. That is, can unit tests be designed to provide insight into the static code rather than just a confirmation that your code is working as you expect it to? I believe the answer is yes, on a case by case basis. Perhaps a "juicier" question is, can unit tests be written/generated generically to provide insight into arbitrary static code. 

Just my morning musings. 

[Edward K. Ream]

On Wed, Aug 26, 2015 at 1:07 PM, Don Dwiggins <ddwi...@advpubtech.com> wrote:

On 8/19/15 5:38 AM, Edward K. Ream wrote:

I'd suggest that the focus in this "problem" should be the mindset of Test-Driven Development, rather than the unit tests themselves.

​Leo already supports TDD in several ways.  There is @test, of course.  Command history (Alt-UpArrow & Alt-DownArrow) is surprisingly useful because it can be used to re-execute @test nodes (or @button nodes) easily.

Furthermore, the cheekily-named "Stupendous Aha"
https://groups.google.com/d/msg/leo-editor/R9-y4XZ9LNo/uWj6TjoQg2gJ
and
http://edreamleo.blogspot.com/2010/02/stupendous-aha-haiku-version.html

should allow any form of TDD to be supported in Leo comfortable.

I've just made a note to myself to document his Aha/work-flow.

Edward

[Edward K. Ream]

On Thu, Aug 27, 2015 at 6:56 AM, john lunzer <lun...@gmail.com> wrote:

​> ​

I think it is a mixture of amusing and sad that this thread has been met with crickets.

​I am not sad.  These are exciting times. My mantra these days is "something good will come of this."  This is a statement of intent, not an idiotic assertion of the universe's (provably false) benevolence :-)

​> ​

Perhaps my only insight comes from another tool which has truly changed how I program. The pudb debugger has provided me insight into programs where again, previously I felt like I was drowning in a sea of code. I'm not sure if this is what you meant by the other side of the static code but being given a graphical representation of where I am in a program and the stack and what's happening to the variables has been very powerful to me.

​This is indeed what I meant.  I'll look into pudb.  It's all about tools, for me.

I am giving myself permission to look 5, 10 or 20 years in the future.  I want a project that will take that long.  Sure, there are plenty of 1-day to 2-week projects that can be done in Leo.  Instead, I am looking for a major new kind of tool, or a major re-imagining of an existing tool such as pudb.

​> ​

I see code existing in three forms: static, live, results. You have shown us through outline's that static code can be represented in different ways and that those different representations can aid our understanding of the code. I've discussed the live aspect, which helps gain further understanding of the static code. The results of a program having ran (past tense) could provide great insight into how code works. That is, can unit tests be designed to provide insight into the static code rather than just a confirmation that your code is working as you expect it to? I believe the answer is yes, on a case by case basis. Perhaps a "juicier" question is, can unit tests be written/generated generically to provide insight into arbitrary static code.

​Thanks for these interesting thoughts and distinctions.  I had not thought of the results as a separate entity before.  Please don't disparage your abilities.  Your comments come closest to what I have been thinking about.

Edward

[Don Dwiggins]

Ed,

Thanks for the pointers and the Aha!

Here's another problem, although it may not be juicy enough for you (or just outside your realm of interest):

As I've mentioned, I've been using Ecco as a PIM for many years, with generally good results.  Now, however, I'm involved in several new projects in my personal iife, and finding myself getting swamped trying to manage my time.  This has led me to pick up David Allen's "Getting Things Done". 

I'm working though ways to use Ecco in service of GTD, Dwig-style, but it's different enough from what I've been doing that it occurred to me that I might just as well use Leo for the purpose.  SO, looking at Leo from the PIM perspective, what might be the challenges in making it "sing" with GTD or some variation thereof?

Any related thoughts welcome ...


Don

--
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Jacob Peck]

Hi Don,

I don't know if it helps any, but I was using Leo in a GTD-style way for a while.  I used a suite of scripts, along with a few plugins I wrote, to automate most tasks.

It worked for me for over a year, and I might just have to get back into it soon.  I lapsed because, ironically, too many large projects happened at once, and I didn't really have the time to track them all!  And then, you know, bad habits form quickly...

Here's a blog post on how I made it work for me: http://blog.suspended-chord.info/2013/11/18/leo-things-done-revised/

Might not help you at all, but I thought I'd share.

-->Jake

[Edward K. Ream]

On Mon, Sep 7, 2015 at 9:17 PM, Don Dwiggins <ddwi...@advpubtech.com> wrote:

SO, looking at Leo from the PIM perspective, what might be the challenges in making it "sing" with GTD or some variation thereof?

​Interesting question.  I have a tree called GTD in a personal planning file.​

 

​ It has various node relating to GTD, the most important, for me, is the Next Actions node.  The Next Action node has various child nodes to help organize things.

For me, the most important part of GTD is weekly review.  I haven't felt the need for any special features: Leo is already more than adequate to represent all Next Actions.

Edward