> 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) > >
