April 2018 - Pharo-users - lists.pharo.org

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

by Richard Sargent

On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Sometime Pharo frustrate me a lot, I felt it too in the message from > Benoit, in the other hand its community is very kind and always helpful. So > it is not about blaming people. > > In my opinion, there are too much things pushed at the same time in Pharo. > You can't push too much things into the box, then when people complain > about it to be overfull and bugged request them to fix it, I don't think it > can work that way, at this scale of changes. In the other, this is not > really what happen here, I very likely exaggerate this trait but you get > the idea. > > For example, I developed DrGeo for several years on P3. Why sticking to > P3? It gave me the opportunity to fine craft DrGeo to be stable and > predictable in the way it behaves to its end users, and a lot of releases > occurred. When I started to look at porting to newer image last June, I > realized DrGeo will become unstable and oversized, so can of turning from > A+ grade to a D- grade, just by the magic of porting it. My plan was to > port it during the summer to get it ready end of August to deploy in local > schools, it does not happen. And I can write it: it is s-u-p-e-r > f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a > casual developer, but it makes developing well crafted and reliable Pharo > application a bit expensive to my taste. To such a scale that I started to > evaluate alternative to Pharo as the underneath system, idea I finally gave > up after several weeks of evaluations. All in all I still have this felling > Pharo is not developer friendly, I fell DrGeo is not secure there. See when > porting to newer image, I end up using P7-32bits alpha on Linux because it > was the most comfortable situation comparing to P5/P6/P6.1, is it not > strange? > > In the other hand this struggle occurs at image change. Ok, may be it is a > pattern specific to Smalltalk. Is it the case with commercial Smalltalk > vendors? Hi Hilaire, Thanks for articulating this. I've been mostly watching Pharo rather than using it, so I haven't been affected by the changes between versions. With respect to commercial products versus Pharo *at the present time*, I think we have different driving forces shaping things. In my opinion, VA Smalltalk has been the one most strongly driven by the importance of backward compatibility and ease of migration to a new version. VisualWorks has been pretty good about providing a path forward with minimal pain, although the more major version numbers difference, the harder it is to transition. Likewise, GemStone/S has a strong emphasis on keeping our customers' existing applications running with minimal changes. That being said, I have no doubt that the earliest versions of all these products had substantial incompatibilities between versions. I am also pretty sure there is a threshold beyond which the adoption of Pharo in business applications will compel Pharo development to facilitate migration to newer versions and to better maintain API compatibility. [And that may be simply because, as more businesses rely on Pharo, they will be financially supporting its development.] A second consideration is the size of the product teams (measured in full-time staffing). I think the commercial products had a much larger staffing in their early days than Pharo has even now. And I think the consequence of that is that the changes between v1 and v2 or between v2 and v3 of the commercial products *may* have been comparable to the differences between Pharo v(n) and v(n+3). Richard > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

April 13, 2018

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

by Stephane Ducasse

We know where we go (we have a roadmap) and this is always the same and we are getting there. Tell me one smalltalk that is bootstrapped. And only bad OOP programmers count number of classes!!!! Now I will not reply to provocation. So I just trashed this thread because it goes nowhere. Sorry constructivism criticisms from people that already commited and helped is something positive. But in this thread I only read in inverse and I will let you with it and keep my good energy for it . Stef On Fri, Apr 13, 2018 at 7:53 AM, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: pharo-users(a)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) >

April 13, 2018

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

by Hilaire

Sometime Pharo frustrate me a lot, I felt it too in the message from Benoit, in the other hand its community is very kind and always helpful. So it is not about blaming people. In my opinion, there are too much things pushed at the same time in Pharo. You can't push too much things into the box, then when people complain about it to be overfull and bugged request them to fix it, I don't think it can work that way, at this scale of changes. In the other, this is not really what happen here, I very likely exaggerate this trait but you get the idea. For example, I developed DrGeo for several years on P3. Why sticking to P3? It gave me the opportunity to fine craft DrGeo to be stable and predictable in the way it behaves to its end users, and a lot of releases occurred. When I started to look at porting to newer image last June, I realizedÂ DrGeo will become unstable and oversized, so can of turning from A+ grade to a D- grade, just by the magic of porting it. My plan was to port it during the summer to get it ready end of August to deploy in local schools, it does not happen. And I can write it: it is s-u-p-e-rÂ f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a casual developer, but it makes developing well crafted and reliable Pharo application a bit expensive to my taste. To such a scale that I started to evaluate alternative to Pharo as the underneath system, idea I finally gave up after several weeks of evaluations. All in all I still have this felling Pharo is not developer friendly, I fell DrGeo is not secure there. See when porting to newer image, I end up using P7-32bits alpha on Linux because it was the most comfortable situation comparing to P5/P6/P6.1, is it not strange? In the other hand this struggle occurs at image change. Ok, may be it is a pattern specific to Smalltalk. Is it the case with commercial Smalltalk vendors? Hilaire -- Dr. Geo http://drgeo.eu

April 13, 2018

Re: [Pharo-users] [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

by Guillermo Polito

On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 April 2018 at 21:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> On 13 Apr 2018, at 15:04, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> >> Can you make the video available online? >> >> >> https://youtu.be/A9H8jsSnBKM >> > > I like the new "New Repo", particularly additional of GitHub alternative > (not that I use them, but options is good) > Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo" > entry or similar > which presets *everything* required to clone the Pharo repo. > The thing is that the best way to do it is to clone your own fork... And each one has her/his one. > > Later, here you might even go as far as letting uses entry an Issue and > pre-create the branch > that a fix will be submitted on. But for now... one step at a time. > That's already there > > cheers -ben > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

April 13, 2018

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

by Herbert VojÄÃk

Herbert VojÄÃk wrote: > Just a bit of a bikeshedding here: > >> But I prefer these names: >> * Calypso System Browser > > Calypso Browser Display > >> * Calypso Debugger > > Calypso Debugger Display > Calypso Debugger Gear > >> * Iceberg Source Control Management\ > > Iceberg SCM Display > Iceberg SCM Gear > >> * Zinc HTTP Client > > Zinc Web Client Gear > >> * Zinc HTTP Server > > Zinc Web Server Gear > >> * Fuel Serialization > > Fuel Serialization Gear > >> * Glamorous Spotter [*] > > Spotter Search Display > Spotter Search Gear > >> * etc. >> >> [*] I particularly dislike "Glamorous" adjective. >> >> In the case of wrapper for libraries I'm hesitant to decide whether to >> indicate pharo name in it or not. >> I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of >> calling "Salty". > > NaCl Adapter Maybe "Salty NaCl Adapter" here, to be consistent with the previous ones of "Fancy Merit Type".

April 13, 2018

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

by Herbert VojÄÃk

Esteban A. Maringolo wrote: > On 13/04/2018 10:41, phil(a)highoctane.be wrote: >> A somewhat unique name makes it easier to google for it (like Roassal >> Pharo, or DeepTraverser Pharo, or Zinc Pharo). >> These will give us hits that are relevant. >> >> Try System Browser, Inspector... Just a bit of a bikeshedding here: > But I prefer these names: > * Calypso System Browser Calypso Browser Display > * Calypso Debugger Calypso Debugger Display Calypso Debugger Gear > * Iceberg Source Control Management\ Iceberg SCM Display Iceberg SCM Gear > * Zinc HTTP Client Zinc Web Client Gear > * Zinc HTTP Server Zinc Web Server Gear > * Fuel Serialization Fuel Serialization Gear > * Glamorous Spotter [*] Spotter Search Display Spotter Search Gear > * etc. > > [*] I particularly dislike "Glamorous" adjective. > > In the case of wrapper for libraries I'm hesitant to decide whether to > indicate pharo name in it or not. > I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of > calling "Salty". NaCl Adapter Ending with "... Display", "... Gear" and "... Adapter" high-level categorization. Question, is separation of UI and underlying machinery always possible. >> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too >> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one >> sounds cool actually)). > > Fortunately in the past the lack of namespaces caused the use of > prefixes instead of suffixes. > > With time prefixes become invisible. > > A suffix, instead, will get into all your names, bothering with other > existing suffixes like `Component`, `Model`, `Collection`, and so on.

April 13, 2018

Re: [Pharo-users] [TechTalk] April 12: GIT with Iceberg

by Ben Coman

On 13 April 2018 at 21:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 13 Apr 2018, at 15:04, Andrei Stebakov <lispercat(a)gmail.com> wrote: > > Can you make the video available online? > > > https://youtu.be/A9H8jsSnBKM > I like the new "New Repo", particularly additional of GitHub alternative (not that I use them, but options is good) Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo" entry or similar which presets *everything* required to clone the Pharo repo. Later, here you might even go as far as letting uses entry an Issue and pre-create the branch that a fix will be submitted on. But for now... one step at a time. cheers -ben

April 13, 2018

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

by Esteban A. Maringolo

On 13/04/2018 11:12, Sean P. DeNigris wrote: > EstebanLM wrote >> I dream with even more classes: Selector, Protocol (we already have it, >> but we need to use it), etc., etc., etc. >> I will always prefer a class that defines a concept than a non-reified >> usage of generic classes. "Objects all the way down". Most problems surge from the lack of proper abstractions. -- Esteban A. Maringolo

April 13, 2018

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

by Sean P. DeNigris

EstebanLM wrote > I dream with even more classes: Selector, Protocol (we already have it, > but we need to use it), etc., etc., etc. > I will always prefer a class that defines a concept than a non-reified > usage of generic classes. Yes!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 13, 2018

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

by Esteban A. Maringolo

On 13/04/2018 10:41, phil(a)highoctane.be wrote: > A somewhat unique name makes it easier to google for it (like Roassal > Pharo, or DeepTraverser Pharo, or Zinc Pharo).Â > These will give us hits that are relevant. > > Try System Browser, Inspector... > > And Apple has worked with NSObject and stuff like that without too much > trouble (at a much larger scale for whatever XyzKit they released). > Ah, yes, they used the "Kit" suffix. Maybe can we have something like > that with Pharo. Like SystemBrowserKit ( nah, too Appleish. But I prefer these names: * Calypso System Browser * Calypso Debugger * Iceberg Source Control Management * Zinc HTTP Client * Zinc HTTP Server * Fuel Serialization * Glamorous Spotter [*] * etc. [*] I particularly dislike "Glamorous" adjective. In the case of wrapper for libraries I'm hesitant to decide whether to indicate pharo name in it or not. I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of calling "Salty". > Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too > bland), or SystemBrowserGear (why not), SystemBrowserRig (this one > sounds cool actually)). Fortunately in the past the lack of namespaces caused the use of prefixes instead of suffixes. With time prefixes become invisible. A suffix, instead, will get into all your names, bothering with other existing suffixes like `Component`, `Model`, `Collection`, and so on. -- Esteban A. Maringolo

April 13, 2018