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. On Wednesday, August 19, 2015 at 8:38:05 AM UTC-4, Edward K. Ream wrote: > > 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 > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
