The Pharo Chronicles: First impressions

[Edward K. Ream]

I am now actually using Pharo, as opposed to reading about it and executing a few lines in the playground.  The "Pharo Chronicles" threads will be notes to myself, and possibly to others down the road.

This post will be pre-writing for various Pharo bug reports.  Nobody knows better than I how irritating it can be for devs to deal with unjustified criticisms from clueless newbies. I welcome any corrections Offray or others may have.

The most important first impression

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, exploring how this happens is worth any amount of work, regardless of problems with Pharo. Please keep this in mind as you read on.

The good

The Pharo launcher is a VM manager.  The ability to create specialized images easily is a big plus. Especially since newbies like me are prone to having to recreate them frequently ;-)

The language is good to excellent. Moreover, the browser/runtime integrates reports quality (linting) problems automatically.  And it's easy to configure (enable or disable) those message in a flexible manner.

The not so good...

For such a supposedly powerful system, Pharo suffers too many problems.  I suspect the Pharo devs have either gotten used to these problems, or have work flows that minimize them.  But newbies surely will be aware of the following...

The IDEs suffer from Alzheimer's

1. The Launcher has a "quit on launch" checkbox, but there seems to be no way to remember what it should be on the next launch.  Certainly it is not saved automatically.  Using the Settings Browser (in the launcher) to change this also has no effect.

2. Neither the Launcher nor Pharo images remember the save status.  Quitting immediately after a save still brings up the "Do you want to save" dialog.  It's bush league.

Bugs

1. There seems to be no way to configure what a plain click in an open area does.  Imo, the first click (of any kind) should set the focus if focus is not already in the Pharo pane.  But no, the first click brings up the "World" menu.  This is wretched interface design.  At the very least, the user should be have the option to configure what plain clicks do.

2. On Windows (and possibly other platforms) colons in image names confuse the launcher.

3. The Pharo file dialogs are wretched. The native file dialogs on Windows and Linux are much better.

4. I just got bit by a serious bug.  An image suddenly started complaining that it doesn't have the proper write permissions to save itself...

Pharo browsers are clumsy

For me, this is the big one. The Pharo community is putting up with an ancient interface design for browsing. A Leonine browser would solve a lot of problems.  Naturally, this creates a big opportunity for me to contribute to the Pharo world.

Pharo browsers show you what they want to show you, not what you want to see.  Leo is a template for a much better way. 

The general idea is simple:  use a single outline for everything.  Instead of dragging in the entire browser view, the Leonine view would use references to only those objects that the user wants to see.  These references would be a behind-the-scenes "artifact".  They may well exist in existing browsers. Unless I am completely mistaken, references (or their equivalent) must be possible in Pharo.

The Leonine browser would, of course, also support Leo's clones.

An example will clarify what Leo has to offer.  Suppose you want to create a new class, along with its test class.  You would create those classes in the Leo browser, and that's all you would see. You would use real organizer nodes, as usual, not as a special case but as a natural part of creating your classes.  You would use clones to focus on the methods of interest.  You could put related methods in the same node.  Etc.

This would be an earth shaking development in the Pharo world.  No more filters.  No more wretched side-by-side browser panes.  Much better use of screen real estate.  No more special cases.  Any Leonine node could refer to any Pharo object, including tracebacks.  Which brings me to...

Exception handling in the transcript

The ui may be able to represent exceptions, say in the Transcript.  The analogy is Terry's clickable error messages generated by pylint and other parts of Leo. For sure the user could use a more permanent way of understanding what has already happened.

Summary

My initial impressions of the Pharo code are not very good.  That will not deter me from studying Pharo intensely, and in detail.

One of my first Pharo projects will be to create a Leonine browser, along with experiments to make exceptions editable parts of the ui.

I'll also fix the ui bugs mentioned above.

All comments welcome.

Edward

[Edward K. Ream]

On Saturday, February 23, 2019 at 6:19:29 AM UTC-6, Edward K. Ream wrote:

> For such a supposedly powerful system, Pharo suffers too many problems.

I forgot to mention, there is no obvious way to create a new window for your own use. 

This is so bizarre.  Here we have this incredible system, and no way to keep notes!

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Thanks for your Pharo chronicles. They remember me other notes you have
been sharing with us about your exploration of other technologies. I
hope to answer them in more detail, but for the moment just quick responses.

Grafoscopio is my way to create notes on Pharo and save them outside the
image as STON notebooks on plain text files (STON is Pharo's take on
JSON, but with circular references and other advantages). I just install
it on almost any image I'm using and take my notes there, including
starting code snippets, that after a while get reified into classes and
methods inside the system.

Cheers,

Offray

PS: ATM Grafoscopio only supports text and code nodes and supposes that
text is Markdown (but not syntax there highlighting yet, hopefully
arriving on March once I have time again).

[Offray Vladimir Luna Cárdenas]

Hi,

Again, quick answers...

On 23/2/19 7:19, Edward K. Ream wrote:

The IDEs suffer from Alzheimer's

1. The Launcher has a "quit on launch" checkbox, but there seems to be no way to remember what it should be on the next launch.  Certainly it is not saved automatically.  Using the Settings Browser (in the launcher) to change this also has no effect.

Strange. On Linux it works for me. It's happening only on Windows? Could you report this in the Launcher repository? [1]

[1] https://github.com/pharo-project/pharo-launcher/issues

2. Neither the Launcher nor Pharo images remember the save status.  Quitting immediately after a save still brings up the "Do you want to save" dialog.  It's bush league.

I use "Save and Quit" from the Pharo to tell the image I want to perform both actions (some few times I just want to quit the image without saving, which is why I think that the "Quit" and its question are still there).

Bugs

1. There seems to be no way to configure what a plain click in an open area does.  Imo, the first click (of any kind) should set the focus if focus is not already in the Pharo pane.  But no, the first click brings up the "World" menu.  This is wretched interface design.  At the very least, the user should be have the option to configure what plain clicks do.

Never thought of that. For me this kind of Pharo menu seems like the one you get on Linux windows manager like Enlightenment, Openbox and others, that bring the environment main menu once you choose an empty area. Perhaps because those WM where my comparison starting point, the current behavior seemed natural.

3. The Pharo file dialogs are wretched. The native file dialogs on Windows and Linux are much better.

It's true. Support for native operative system windows is coming, but it will not happen at least after Pharo 8. People at feen[2] is making some test on native MacOS windows for their Pharo based platform [2]

[2] https://feenk.com/

4. I just got bit by a serious bug.  An image suddenly started complaining that it doesn't have the proper write permissions to save itself...

Pharo browsers are clumsy

For me, this is the big one. The Pharo community is putting up with an ancient interface design for browsing. A Leonine browser would solve a lot of problems.  Naturally, this creates a big opportunity for me to contribute to the Pharo world.

Pharo browsers show you what they want to show you, not what you want to see.  Leo is a template for a much better way. 

The general idea is simple:  use a single outline for everything.  Instead of dragging in the entire browser view, the Leonine view would use references to only those objects that the user wants to see.  These references would be a behind-the-scenes "artifact".  They may well exist in existing browsers. Unless I am completely mistaken, references (or their equivalent) must be possible in Pharo.

Yes, those references should be possible.

The Leonine browser would, of course, also support Leo's clones.

An example will clarify what Leo has to offer.  Suppose you want to create a new class, along with its test class.  You would create those classes in the Leo browser, and that's all you would see. You would use real organizer nodes, as usual, not as a special case but as a natural part of creating your classes.  You would use clones to focus on the methods of interest.  You could put related methods in the same node.  Etc.

This would be an earth shaking development in the Pharo world.  No more filters.  No more wretched side-by-side browser panes.  Much better use of screen real estate.  No more special cases.  Any Leonine node could refer to any Pharo object, including tracebacks.  Which brings me to...

I really think that this Leo way for browsing Pharo, combined with the live coding and development support that the environment provides would be pretty useful. There are some alternative browsers that take into account screen spaces and alternative ways to extend the system. You should check AltBrowser by Thierry Goubier[3][4][5], which seems pretty unmaintained, but explore similar ideas.

[3] http://smalltalkhub.com/#!/~ThierryGoubier/AltBrowser
[4] https://www.youtube.com/watch?v=pyhqTzIxyRY
[5] https://duckduckgo.com/?q=thierry+goubier+AltBrowser&t=ffsb&atb=v76-7&ia=web

Exception handling in the transcript

The ui may be able to represent exceptions, say in the Transcript.  The analogy is Terry's clickable error messages generated by pylint and other parts of Leo. For sure the user could use a more permanent way of understanding what has already happened.

Could you elaborate more? I think that exception handling is very good at Pharo.

Summary

My initial impressions of the Pharo code are not very good.  That will not deter me from studying Pharo intensely, and in detail.

One of my first Pharo projects will be to create a Leonine browser, along with experiments to make exceptions editable parts of the ui.

I'll also fix the ui bugs mentioned above.

All comments welcome.

Thanks for this. I'm pretty intrigued to see what happen when Pharo and Leo ideas get mixed. Grafoscopio is just one approach, but having you around Pharo system and community could be really transformative.

Cheers,

Offray

[Edward K. Ream]

On Saturday, February 23, 2019 at 6:19:29 AM UTC-6, Edward K. Ream wrote:

> Nobody knows better than I how irritating it can be for devs to deal with unjustified criticisms from clueless newbies.

This statement is always in the back of my mind.  It obligates me to do the following:

1. Prove whatever assertions I make.

2. Actually create a better way.

I claim that Pharo's browsers are feeble, and that Leo would be the foundation of something significantly better.

grafoscopio.leo proves this assertion, to my satisfaction. Now the real work begins. No way would I bother Pharo devs until I have a working Leonine browser in Pharo. It's simple courtesy.

Edward

[Edward K. Ream]

On Saturday, February 23, 2019 at 9:56:43 AM UTC-6, Offray Vladimir Luna Cárdenas wrote:

Exception handling in the transcript

The ui may be able to represent exceptions, say in the Transcript.  The analogy is Terry's clickable error messages generated by pylint and other parts of Leo. For sure the user could use a more permanent way of understanding what has already happened.

Could you elaborate more? I think that exception handling is very good at Pharo.

This is a ui suggestion.  The idea is to remember the exception somewhere, with a graphical element.  The user could then examine the traceback at a later time.

Edward

[john lunzer]

I don't think I dug far enough to notice the bugs, but I had a similar impression about Pharo's browsers, and after some consideration clumsy is the right word. I felt like if there was a powerful system of live coding somewhere in Pharo the browsers weren't revealing it to me in an elegant or efficient manner.