ENB: Moving on from Sherlock
Edward K. Ream
My Sherlock product predated Leo by several years. It was a commercial and practical failure. Yesterday, I removed the SherlockTracer class from Leo:
- It likely did not work with recent Python versions.
- It was way too slow.
- It was overly complex in concept.
This Engineering Notebook post discusses what I wanted Sherlock to do and discusses various alternatives.
Exploring dynamic data
We programmers write static text, but our programs deal with dynamically generated data. I've often wanted better tools to study the data that flows through our programs.
I've been studying mypy recently. I created a small test file to help me in my studies.
A cff shows that mypy contains 111 methods named "accept"! I want to know which ones mypy calls when handling the test file. Single-stepping through the code would be tedious and error-prone. The code is just too complicated.
A Sherlock-like idea would be add trace statements to all the "accept" methods. Leo issue #3562 suggests writing a script to insert these traces.
Preliminary work showed that Leo's Python importer can help discover the desired code reliably. It's a clever idea. The script analyzes guide lines just as the importer does.
But on second thought, the script seems like an overly complicated solution to what should be a straightforward problem—just like Sherlock was. Instead, I could use a cff to find all the nodes containing "def accept." A simple regex will then place the cursor the "def" lines. I can then insert the desired traces manually or with a regex replace.
A problem arises that a script might help solve. Leo's searches know nothing about p.h! That's a pity because headlines contain valuable context.
Suppose we allow replacement text to contain an Easter Egg, say {p.h}. This convention would not execute code; it would simply be a marker indicating that p.h should be part of the replacement text.
Summary
I rarely want to insert many tracing or debugging statements. When I do, neither Sherlock nor similar scripting helpers will help much.
Instead, a cff followed by a regex search/replace will work. Such searches might be clumsy, especially when the replacement text is variable.
We might consider adding an Easter Egg: in replacement patterns {{p.h}} would insert p.h into the replacement text without executing any code.
I'll try adding traces manually to see how clumsy that would be. I'll also continue working on #3562 to see where it leads. However, I suspect it is a dead end.
All of your comments are welcome.
Edward
Edward K. Ream
Summary
I rarely want to insert many tracing or debugging statements. When I do, neither Sherlock nor similar scripting helpers will help much.
Instead, a cff followed by a regex search/replace will work.
repl: \1 g.trace(self.__class__.__name__, visitor.__class__.__name__) ###\n
Offray Vladimir Luna Cárdenas
Hi,
Regarding the gap between static text and dynamic data, its
explorers and possible bridges, I think that the Smalltalk
tradition makes a good case for writing dynamic data instead of
static text. Some years ago, I talked about Pharo[1], my own, Leo
inspired, outliner called Grafoscopio[2] and now, there dynamic
writing and exploration of dynamic data/systems within such
systems have a Glamorout Tolkit[3] which improves on user
interface and notebooks, while being a Pharo based system.
Bridging the gap between static text and dynamic data systems is
maybe one of the most important problems in informatics and user
experience/empowerment. Hopefully the Smalltalk tradition and
ideas like the one in Stop writing dead programs[4] will gain
broader mindset. It is good to see how such ideas are explored
with Leo Editor.
[1] https://pharo.org/
[2] https://mutabit.com/grafoscopio/en.html
[3] https://gtoolkit.com/
[4] https://www.youtube.com/watch?v=8Ab3ArE8W3s
Cheers,
Offray
HaveF HaveF
Regarding the gap between static text and dynamic data, its explorers and possible bridges, I think that the Smalltalk tradition makes a good case for writing dynamic data instead of static text. Some years ago, I talked about Pharo[1], my own, Leo inspired, outliner called Grafoscopio[2] and now, there dynamic writing and exploration of dynamic data/systems within such systems have a Glamorout Tolkit[3] which improves on user interface and notebooks, while being a Pharo based system.
Edward K. Ream
Regarding the gap between static text and dynamic data, its explorers and possible bridges, I think that the Smalltalk tradition makes a good case for writing dynamic data instead of static text.
Bridging the gap between static text and dynamic data systems is maybe one of the most important problems in informatics and user experience/empowerment. Hopefully the Smalltalk tradition and ideas like the one in Stop writing dead programs[4] will gain broader mindset. It is good to see how such ideas are explored with Leo Editor.
[1] https://pharo.org/
[2] https://mutabit.com/grafoscopio/en.html
[3] https://gtoolkit.com/
[4] https://www.youtube.com/watch?v=8Ab3ArE8W3s
Edward K. Ream
Edward K. Ream
Regarding the gap between static text and dynamic data, its explorers and possible bridges, I think that the Smalltalk tradition makes a good case for writing dynamic data instead of static text.
I'm unconvinced by these links.
The video "Stop writing dead programs" is condescending, even insulting. Modern software includes the Mars lander and rover, avionics for commercial airliners, large cad-based engineering systems, browsers and their graphics engines, IDEs such as vs-code, and AI software, such as the software for robots made by Boston Dynamics. The video (and others like it) implies that hundreds of thousands of engineers and scientists don't know what they are doing. Maybe some of these projects use lisp, etc., but the rationales for doing so had nothing to do with cute demos.
Let's move on. Pharo is a clever system. The main idea seems to be that an app and its development environment can be the same. Alas, there are many negatives.
Python is my dream language. I'm only interested in improving it. Otoh, it's good to consider how we can improve our programming practice. The Pharo videos stimulated those ideas.
For example, I'd like to make it easier to create unit tests. I didn't write such tests for recent spelling-related PRs. That seems like a mistake. An hour noodling about how to make unit tests for gui code may have had a big payoff. I'm going to take another look.
Summary
I'm not interested in Pharo, but nobody needs my permission to use a platform they love.
Thinking about Pharo has encouraged me to think about making Leo's development less cumbersome.
Edward
HaveF HaveF
Python is my dream language. I'm only interested in improving it. Otoh, it's good to consider how we can improve our programming practice. The Pharo videos stimulated those ideas.
It allows you to easily view variables on the right panel and provides the ability to delve deeper into objects. This feature seems to be more convenient than Jupyter Notebook
Sincerely,
HaveF
Edward K. Ream
It allows you to easily view variables on the right panel and provides the ability to delve deeper into objects. This feature seems to be more convenient than Jupyter Notebook
Edward K. Ream
I'd like to make it easier to create unit tests. I didn't write such tests for recent spelling-related PRs.
Offray Vladimir Luna Cárdenas
Yes. Start from it, or from "plain" Pharo. But be ready for a
different developer experience (DX) as happens with most Smalltalk
based systems, where writing text files as a way to develop a
dynamic system, instead of modifying a dynamic system to build the
next one is the norm.
Videos, instead of static documentation maybe a better way to see the live system in action:
1. The Pharo MOOC: https://mooc.pharo.org/
2. The feenk channel, with several videos about GT:
https://www.youtube.com/channel/UClLZHVq_-2D2-iI4rA2O8Ug
Cheers,
Offray
Offray Vladimir Luna Cárdenas
Edward,
I'm happy to see that you have move on, finding value in Pharo
(an hopefully other links) despite of finding the "Stop writing
dead programs" condescending and even insulting.
Of course, the fact that robust and modern systems have been
massively constructed in a particular way, doesn't mean that is
the only or best one. Every culture (i.e. developers) has its
blind spots and usually people from other cultures (i.e. artist)
can point them more easily (it could happen in the other way
also). The tradition of live coding that is so... well alive in
performative arts (like music or in Smalltalk) I think that have
relevant blind spots to point.
In my case, as a non-professional programmer I have found several truisms in the developer community that are fiercely defended (use Git, start with the "Hello world" example, write static text to represent a dynamic system and so on). And I think that the acknowledge of not knowing what we are doing can be seen not as as condescending critique, but as an empowering practice/mindset (like the newbie mindset). I find that resonant with Bret Victor's Future of Programming talk [1] and the hypothesis of 70's innovation mostly driving by an exploring attitude distant from truisms.
[1] http://worrydream.com/#!/TheFutureOfProgramming
Anyway the focus on the inspector seems a good starting point. My main scripting language before was Python, and trying to find more interactivity I used Jupyter (since the times where it was only IPython notebook) and, in my case, being able to deepen into data/objects with the inspector created a more fluent writing/exploring experience to work with dynamic systems in Pharo/Lepiter than in Python/Jupyter. It could provide inspiration for what is available in Leo, as Leo for me has inspired what I would like to see of a outlining/writing experience in Pharo/Lepiter (what I tried to prototype with Grafoscopio). And there are places where Leo is still second to none (like in reading/deconstructing complex code bases and/or documents).
Cheers,
Offray
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/65762cea-6f99-4480-8620-955fce13435dn%40googlegroups.com.
HaveF HaveF
I find that resonant with Bret Victor's Future of Programming talk [1] and the hypothesis of 70's innovation mostly driving by an exploring attitude distant from truisms.