> On 13 Apr 2018, at 12:19, Joe Shirk <j.b.sh...@gmail.com> 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. 
> 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. 

> On Apr 13, 2018 1:56 AM, "Benoit St-Jean via Pharo-users" 
> <pharo-users@lists.pharo.org> wrote:
> ---------- Forwarded message ----------
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: pharo-users@lists.pharo.org
> 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)

Reply via email to