In P7 scrpt variable to tmp when in debugger

---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: [hidden email]
Cc: 
Bcc: 
Date: Fri, 13 Apr 2018 05:53:46 +0000 (UTC)
Subject: Where do we go now ?

Hello guys,

Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading.

When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic.  The promise of a new, clean & lean Smalltalk attracted a lot of people.  And then...

I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading.  Every Pharo release gets bigger, and bigger, and bigger.  I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated.

Do we really need 2 code completion classes (NECController, NOCController) ?  Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?  Do we really need 2 inspectors (GTInspector, EyeInspector) ?  Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.  I could go on, and on, and on...

Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes.  Can you see a trend?

Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?

Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image.  Can you see a trend?

Add to that the fact that Pharo is a nightmare when you want to port code.  Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes).

You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ?  Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway!

You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements?

UI speaking, what framework should anyone use ?  Athens?  Something else?

You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ?  Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway!

So what's the plan?  For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated?  Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!" ?

Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do?  If you say Calypso is the official & supported browser, fine!  Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel!

Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer.  Did we include Calypso to deprecate Nautilus later?  Is Calypso just a proof of concept?  Is it just an optional tool?  What about all those delay schedulers?  

"I loaded this code from SqueakSource and it just doesn't work".  Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo?

Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us.

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

> On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>
>> On 13 Apr 2018, at 12:19, Joe Shirk <[hidden email]> wrote:
>>
>> I've been a lurk-fan for a long time but this brings up something that distressed me. Richard Eng, Smalltalk Renaissance hero loves to say Smalltalk's grammar/syntax fits on a postcard.
>>
>> But the vocabulary doesn't. There is nothing English-like about the always expanding bewildering   library namespaces.
>>

The package names that just use the “project name” can be problematic… too many words. e.g. “Hiedra”? No idea. (there are ideas of how to improve, I will not list them here as this should
not turn into discussion about this issue).

The way we present packages (and their granularity) is not “right”.  Namespaces are a problem in addition…

So yes: we have a lot of thing to improve!
.
>> GT what? Oh a newbie might eventually figure out it means Glamorous Toolkit. These are meaningless brands. In this drive to come up with creative names for "just objects" that explain nothing at all, Smalltalk is becoming like Java or PHP hell.
>> Just look at those examples through the eyes of a novice. The purity is nowhere to be found.
>> :(
>
> You are right, but in 'the real world' it is no longer possible to reserve the nice, simple names for just one variant. The prefixes are a poor mans namespace mechanism. You have to read over them.
>
> Inspector, EyeInspector, GTInspector, ...
>
> I rather have cool alternatives and the development of new ideas than 'one ring to rule them all' or no/slow progress. Remember that we develop in a live system, changing things while testing them, this is often hard. Alternative subsystems help a lot.

It should be clear that what we have is what we managed to do, not what we dreamed about… I, too, would like to have this clean, nice, small, amazing system… but it is not always easy.

There is a lot we can (and will!) improve!

        Marcus

On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users <[hidden email]> wrote:

From: Benoit St-Jean <[hidden email]>

Subject: Re: [Pharo-users] Where do we go now ?

Date: 13 April 2018 at 11:26:09 CEST

To: Esteban Lorenzano <[hidden email]>

Cc: Any question about pharo is welcome <[hidden email]>

Reply-To: Benoit St-Jean <[hidden email]>

BTW, why put an .exe installer for Windows available when it crashes right from the start? It just doesn't work at all.  Period.  For everyone.

And I thought looking for senders of a method was something we mastered a long time ago, like starting with Smalltalk-76.  Am I supposed to assume that everything, even basic functionalities, are all broken because it's labeled "alpha” ?

We have already a issue tracker entry with a description of a fix:

https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-to-tagsForMethods

TODO: turn that description into code and make a Pull Request.

Marcus