Pharo Chronicles: time for a break
Edward K. Ream
john lunzer
Offray Vladimir Luna Cárdenas
Hi,
An answer on a particular point. I hope to come back with a more
detailed response in a couple of weeks.
Pharo is a good enough language, with advantages I have already described. However, it is not clearly superior to Python in any significant way. The syntax is worse, the libraries are unlikely to be better, and the browsers are inferior to Leo and other Python IDE's. Pharo's windowing system is not likely better than Qt.
Without any explicit reference on how to measure superiority for syntax or libraries or browsers or windowing system, this just fall in personal preference. I think that Mattew Butterick's text on Lisp and Racket, shared recently[1], makes a pretty good example on how give a more balanced reading of a technology without falling in just flattery (or the opposite) by making explicit the context.
[1] https://practicaltypography.com/why-racket-why-lisp.html
The big advantage of Leo is the way to (de)construct a text file and impose order the way you want and the idea of a self-referential document where @button nodes can access the whole outline and program it. I think that this ability to bring emergent structure over other files is unbeaten by any other environment. As I have said several times. The big disadvantage is moldability and dealing with incidental complexity of the Python/OS approach to technology (that why we have 433 Mb of downloads for just installing it, without thinking in extending o changing the system).
Pharo/Smalltalk combination of liveness and moldability on one hand and active fight against incidental complexity is not beaten by any other environment I know of (Racket, Clojure, Red Lang, are in such radar).
On browsers, yes, Smalltalk employs a lot of screen real state, but that's because it doesn't gives you only a metaphor for writing the system, but also for reading and understanding it: you don't deal with flat files in a arbitrary folder, but with packages that have objects, that have protocolos, that have methods, that contain code. It's an standard way of reading and writing the system. We could think in other metaphors for traversing the Pharo system as AltBrowser or Edward's exploration showed and they are really needed, but for a system with a particular organization, to use a browser that showcase such structure for reading, writing and extending the system seems a sensible approach (if you are not thinking in screen space). In my case I start with a quick Grafoscopio document that allow me to mix prose with code and then I reified that to the browsers, bridging too much preexisting structure (from Pharo Browser) with too little (Grafoscopio). Context switching is the approach I use to understand the advantage of each one.
On syntax, I usually think that is a personal matter. I didn't like Lisp parenthesis at the beginning, but they are kind of growing on me. I liked Python white space and apparent simplicity, but is not good enough to keep me there. I like Smalltalk keywords and blocks and I find them far more expressive and clear that other things I have used. So if a "objective" metric for syntax should be used, I just point to the amount of reserved words of each language, to express similar complexity: Smalltalk 6. Python 33.
On external windowing systems, I would like to see better integration with the OS, but meanwhile I keep Pharo's over Qt, Gtk, Xul, etc, because it provides moldability while keeps complexity at bay.
This is just to emphasize that context matters to make any conversation on alternatives fruitful. In my context, flexibility outweighs stability, because I care more about the first and I have dealt with a lot of stable and inflexible solutions already, with incidental complexity[2] so I'm willing to experiment on the opposite, for a change.
[2]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html
The explorations on Pharo Chronicles have been interesting so far. I think that there is a lot to learn from crosspollination of Leo with Lisps (Racket, Pollen, Clojure), Pharo and others and I don't know if after the exploration on other waters, "Leo is good enough" should be the place to always come back. Don't misunderstand me, I think Leo and this community are superb, but maybe if Leo is always good enough, it doesn't have much to learn from any other place, and is fine to keep it as finished software with support. And if it does have stuff to learn, that should be showcased on future releases embodying such learning (via live coding, web rendering/integration or whatever is considered worthy of such other systems).
For me, what Leo and its ideas have to offer is just starting,
and the best way to communicate this is via future releases. Maybe
Leo is done, and it will be an important finished part of a
ecosystem of new tools exploring how we change the way we write,
code and visualize. I want to help in building the unfinished
parts of such ecosystem.
Cheers,
Offray
Edward K. Ream
Hi,
An answer on a particular point. I hope to come back with a more detailed response in a couple of weeks.
On 26/2/19 8:09, Edward K. Ream wrote:
Pharo is a good enough language, with advantages I have already described. However, it is not clearly superior to Python in any significant way. The syntax is worse, the libraries are unlikely to be better, and the browsers are inferior to Leo and other Python IDE's. Pharo's windowing system is not likely better than Qt.Without any explicit reference on how to measure superiority for syntax or libraries or browsers or windowing system, this just fall in personal preference.
Offray Vladimir Luna Cárdenas
I never though that Leo would change its base language or
libraries. I was just addressing the fact that without context is
difficult to have a fruitful conversation on the merits of one
tool/ecosystem over the other.
Exploring other technologies, ecosystems and ways to program it
mostly about bringing ideas, collaboration and crosspollination,
not about changing core technologies and erasing history.
Offray