Yesterday's work on two @button scripts for Leo reminded me just how good Leo and Python are. Further work on Pharo does not make sense. This decision will surely disappoint some people. This post explains this decision in detail.
*The overall goal* In the first impressions post <https://groups.google.com/d/msg/leo-editor/NEUxZk0HPtI/zUKs7LuoBgAJ> I said, "There is *only one reason* why I am interested in Pharo, namely that it provides a "live" environment that can be changed without reloading." Imo, this goal is not worth pursuing. In fact, I doubt that it could be done (safely) in any environment. Even if it could be done, the benefits would be small, or even non-existent: 1. Stability easily outweighs flexibility. In Pharo its fairly easy to destroy a crucial member/message. 2. It's not clear what live update of Leo would mean. Does it mean recreating all (or some) windows? If so, when? Surely this can not be done automatically. 3. Leo already has live update features. The file-in/out @button code is self contained. @buttons create commands, so after executing the file-in command, Ctrl-P (repeat-complex-command) recompiles and re-executes the code, instantaneously. At all times my attention was on the code, not the process. 4. Leo's viewrendered pane can (or could) demonstrate live update of complex graphics, much like the Pharo demo. *About Pharo* Here are my impressions, admittedly as a newbie: 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. Both Pharo and Python are dynamic, lisp-like, languages. The differences between lisp, Pharo and Python are smallish. My strong preference is for Python. Imo, Python's syntax, data structures, generators and comprehensions are all clearly superior to both Pharo and lisp. *About Leo in Pharo* There are serious questions about how to make a Leonine browser. I've been aware of them from day one. A way forward surely could be found, but it would take real invention. Most importantly, there is no real incentive to do Leo in Pharo, nor to improve Pharo's browsers. Doing so would be a large task, without any personal payoff. *Competition among development environments* Using Pharo is a high risk decision. There is fierce competition between development environments. The JS world almost certainly gets the most attention. Python, Jupyter and IPython are bigger, more important than Pharo. There is a clear path for Leo in the JS world. I've already prototyped Leo in the browser. I hope Joe Orr is continuing to develop his vision. Finally, WebAssembly <https://webassembly.org/> that will soon support Python program in browsers. *Summary* @button is an excellent simulation of live code. The goal of live coding Leo *itself *seems neither feasible nor desirable. Evaluating Pharo has been fun and useful. However, I personally see no advantages in using Pharo. It's time to take a break from Pharo and examine other interesting projects. As always, your comments are greatly appreciated. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
