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. :( 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 <bstjean@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)
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@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 <bstjean@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)
On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@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.
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
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is? On 13 April 2018 at 23:01, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@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.
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 Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub. Peter
On 13/04/2018 09:18, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com <mailto:raoknz@gmail.com>> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google.
Yes, there needs to be a package tool that enables discoverability, Catalog is not enough.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
True, and it's also giving visibility to Pharo and Smalltalk as active technologies. Regards, -- Esteban A. Maringolo
I was not talking about additional subsystems *for* Pharo, but subsystems already *in* Pharo. For example, when I hover the mouse over "Epicea" in the leftmost browser panel, there is a pop-up that explains what is otherwise a rather opaque word. But when I hover the mouse over "Fuel", nothing happens. "Grease" => pop-up, "Growl", no. Actually there are three possibilities. The third is that there's no pop-up but if you click, there is a package comment. On 14 April 2018 at 00:18, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
How many subsystems that do pretty much the same thing exist in Java? Â Or Programmable Hyperlinked Pasta? Â Try this: Â do a set of Moose queries on a largish Pharo subsystem, say GLORP, then do the same on EclipseLink, Toplink or Hibernate, either with or without the JPA interfaces. Â Even with the tools in Moose the Java frameworks make little to no sense compared to GLORP. Â Neither do the names mean much other than Hibernate, which itself could be taken n different ways. Â And JavaScript, well, what can you say about a language with prototypes but no types to proto? Most enterprise software is proof positive the Pastafarians are right - I've seen plenty of flying spaghetti monsters. AndrewOn Sat, 2018-04-14 at 00:31 +1200, Richard O'Keefe wrote:
I was not talking about additional subsystems *for* Pharo, but subsystems already *in* Pharo. For example, when I hover the mouse over "Epicea" in the leftmost browser panel, there is a pop-up that explains what is otherwise a rather opaque word. But when I hover the mouse over "Fuel", nothing happens. "Grease" => pop-up, "Growl", no. Actually there are three possibilities. The third is that there's no pop-up but if you click, there is a package comment.
On 14 April 2018 at 00:18, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
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. Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too bland), or SystemBrowserGear (why not), SystemBrowserRig (this one sounds cool actually)). Now, I am back to liking the current naming. Phil On Fri, Apr 13, 2018 at 2:43 PM, Andrew Glynn <aglynn42@gmail.com> wrote:
How many subsystems that do pretty much the same thing exist in Java? Or Programmable Hyperlinked Pasta?
Try this: do a set of Moose queries on a largish Pharo subsystem, say GLORP, then do the same on EclipseLink, Toplink or Hibernate, either with or without the JPA interfaces.
Even with the tools in Moose the Java frameworks make little to no sense compared to GLORP. Neither do the names mean much other than Hibernate, which itself could be taken n different ways.
And JavaScript, well, what can you say about a language with prototypes but no types to proto?
Most enterprise software is proof positive the Pastafarians are right - I've seen plenty of flying spaghetti monsters.
Andrew
On Sat, 2018-04-14 at 00:31 +1200, Richard O'Keefe wrote:
I was not talking about additional subsystems *for* Pharo, but subsystems already *in* Pharo. For example, when I hover the mouse over "Epicea" in the leftmost browser panel, there is a pop-up that explains what is otherwise a rather opaque word. But when I hover the mouse over "Fuel", nothing happens. "Grease" => pop-up, "Growl", no. Actually there are three possibilities. The third is that there's no pop-up but if you click, there is a package comment.
On 14 April 2018 at 00:18, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
On 13/04/2018 10:41, phil@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
Esteban A. Maringolo wrote:
On 13/04/2018 10:41, phil@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.
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".
Hi, On this matter, when I named my project, "Grafoscopio" I thought in something evocative and unique, because of the Spanish words "grafo" (graph) and grafÃa[1][2] (graphy, related with writing like in "ortografÃa" "orthography". After naming it I discover there was a old device related with writing and visualization, also called Grafoscopio[3][4], but I got good search rankings because of the uniqueness of the word[5][6]. Being my first project and lacking any programming style, the "Smalltalk with Style" book didn't make any sense at that time, but now, with more experience, I wonder, from time to time, how I could/should (re)name the software and its classes. [1] http://www.wordreference.com/definicion/graf%c3%ada [2] http://www.wordreference.com/es/en/translation.asp?spen=graf%C3%ADa [3] https://www.museodelprado.es/actualidad/multimedia/el-grafoscopio/722c13b2-8... [4] https://www.museodelprado.es/en/whats-on/exhibition/the-graphoscope/81bfb972... [5] https://duckduckgo.com/?q=grafoscopio&t=ffsb&atb=v76-7&ia=web [6] https://www.google.com/search?hl=en&q=grafoscopio Cheers, Offray On 13/04/18 09:01, Esteban A. Maringolo wrote:
On 13/04/2018 10:41, phil@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.
On this matter, when I named my project, "Grafoscopio" I thought in something evocative and unique, because of the Spanish words "grafo" (graph) and grafÃa[1][2] (graphy, related with writing like in "ortografÃa" "orthography". After naming it I discover there was a old device related with writing and visualization, also called Grafoscopio[3][4], but I got good search rankings because of the uniqueness of the word[5][6].
Obviously and well done! I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... May be we should rename Pharo: programming language. And Voyage: Layer And Athens, Cairo: Canvas And git: versioning system Hibernate? JavaFX?, Graddle?, Travis?, Bintray? Do you want more Docker? So guys can we focus our energy on positive things. Stef
Being my first project and lacking any programming style, the "Smalltalk with Style" book didn't make any sense at that time, but now, with more experience, I wonder, from time to time, how I could/should (re)name the software and its classes.
[1] http://www.wordreference.com/definicion/graf%c3%ada [2] http://www.wordreference.com/es/en/translation.asp?spen=graf%C3%ADa [3] https://www.museodelprado.es/actualidad/multimedia/el-grafoscopio/722c13b2-8... [4] https://www.museodelprado.es/en/whats-on/exhibition/the-graphoscope/81bfb972... [5] https://duckduckgo.com/?q=grafoscopio&t=ffsb&atb=v76-7&ia=web [6] https://www.google.com/search?hl=en&q=grafoscopio
Cheers,
Offray
On 13/04/18 09:01, Esteban A. Maringolo wrote:
On 13/04/2018 10:41, phil@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.
Stephane Ducasse-3 wrote
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... So guys can we focus our energy on positive things.
IHMO this is certainly a positive subject because it highlights the as-yet-to-be-resolved tension regarding understandability of the system between having a unique name (good for googling, distinguishing between versions) and a name that reveals what the project does/is for. What is the plan to resolve this because it is a real problem? Nike and Levis are designed to stand on their own in front of the consumer market. Is this true of Nautilus, Calypso, or Epicea? A more relevant example of products that are geared to be presented to consumers as /part of/ another more-uniquely-named product come to mind: OS release codenames: - Mac - OS X 10.11: El Capitan and macOS 10.12: Sierra. Note that they didn't just invent a random-seeming fabricated name and tell people to get over it, they also provide a number which situates it in its domain. - Interestingly Windows has moved back to boring release numbers and has dropped the fantasy names Possible solutions: - Make project tags /the primary view for new users when searching the system. There is a lot of talk about students and having to explain confusing things to them. Would it not be more straightforward to look for a "Class Browser" or "SCM" category?! - If projects are designed just-for-pharo, maybe borrow another trick from OS X - have a codename for development (like Fuji for Sierra) and then change it to something more generic on release, like Browser3, although now that we seem to be keeping tools in their own project repos, that might be problematic I summary, IMHO it is important to provide both: - A clear, searchable, pragmatic way to navigate/understand the system - As well as the unique, google-able, but usually undescriptive way we have now ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I concur with Sean's comments. The problem is not using names : the problem is for new users. A very quick look at what's in Pharo 7 shows the following names : Iceberg, Ombu, Calypso, Flashback, Nautilus, Renraku, Zodiac, Shift, Zinc, Hermes, Beacon, Cargo, Hermes, Opal, Shoreline, Epicea, Balloon, BlueInk, Commander, Fuel, Glamorous, Glamour, Gofer, Hiedra, Metacello, Moose, Ring, Rubric, Shout, Spec, etc... How many Pharo *users* (not regular contributors!) know what those tools/frameworks/packages do ??? Make the test and tell us how many out of 30 names you were able to identify correctly ! Unless we *clearly* publicize/describe what those names are, there's no way in a thousand years you could tell that BlueInk is not a package dealing with fonts (that was my first guess) ! Newcomers and (developers in general) expect a few things. For instance, there's a gazillion UI frameworks out there and, most of the time, the name used for them is one of a famous painter. VisualWorks had Chagall for instance. Or you'd expect some kind of hint from the name, e.g. XStreams, ScriptManager, RefactoringBrowser. Or somethings as simple as Regex, the regex package from Bykov. Or Announcements from the same guy. Or names that reveals something from an etymology standpoint, e.g. TelePharo. The simple fact that someone had to create a file to describe all those names/projects/framework on GitHub tells us a lot (https://github.com/AdamSadovsky/pharo-family/blob/master/catalog.txt) ! Unless we make it *EXTRA* clear and easily searchable and obvious what those names represent, it's just more confusion for the newcomer. Do you know what Celery is? Probably not! But if I ask you the same question for RabbitMQ, ActiveMQ, MQSeries, StormMQ, SnakeMQ, IronMQ, ZeroMQ, MQTT and MSMQ, you probably figured out it's related to message queues, right? Well, Celery is also related to message queues... See? There's nothing worse or more confusing than a bad/weird/unrelated name. For example, the biggest company in Canada is called "Canadian Tire". If you think you're gonna end up in a place specialized in tires, you're off for a big surprise !!!! On the other end of the spectrum, you have something like iTunes. Everybody knows iTunes. And I guess, even if you didn't know, you can kinda easily guess it's related to music. Your grandma might not exactly remember the name but she'll remember "Was it xTunes? zTunes? yTunes? It was something 'tunes', to music" ! And comparing other "names" with Pharo names makes no sense. Nike, Hibernate, Jenkins, Docker and Oracle cannot be compared to Epicea, BlueInk, Flashback and Opal. They just don't have the same visibility and public exposure. That is hopefully a problem that will vanish as Pharo gets more and more attention and users and gets known more and more. But in the meantime, those names merely help us differentiate implementations of solutions, for us the *regulars*. Was it really that hard to replace the old workspace with Workspace2 or WhateverWorkspace ? Or even better : get rid of the old Workspace and replace it with Playground while retaining the name "Workspace" ??? Did we really need to call it Playground and confuse every new Smalltalker out there that has seen the term "Workspace" for Dolphin, Smalltalk/X, VisualAge, VisualWorks, ObjectStudio, GNU Smalltalk, Amber, PharoJS, Smalltalk MT and every other Smalltalk around *EXCEPT* Pharo? Why are we trying to complicate things when we could just make it soooooooooooooo simple? Let's make it easy for **newcomers** to get their way around and know what the named tools/frameworks do. Get rid of duplicate tools (do we need more than one kind of Inspector? Do we need 2 compilers? Do we need 8 Delay schedulers? Do we need 2 system browsers? Do we need the duo Workspace/Playground) ? Make these extra tools available somewhere it can be loaded from if a user *really* wants them in their image, but let's keep those OUT of the image! ----------------- 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 Friday, April 20, 2018, 10:09:13 a.m. EDT, Sean P. DeNigris <sean@clipperadams.com> wrote: Stephane Ducasse-3 wrote
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... So guys can we focus our energy on positive things.
IHMO this is certainly a positive subject because it highlights the as-yet-to-be-resolved tension regarding understandability of the system between having a unique name (good for googling, distinguishing between versions) and a name that reveals what the project does/is for. What is the plan to resolve this because it is a real problem? Nike and Levis are designed to stand on their own in front of the consumer market. Is this true of Nautilus, Calypso, or Epicea? A more relevant example of products that are geared to be presented to consumers as /part of/ another more-uniquely-named product come to mind: OS release codenames: - Mac - OS X 10.11: El Capitan and macOS 10.12: Sierra. Note that they didn't just invent a random-seeming fabricated name and tell people to get over it, they also provide a number which situates it in its domain. - Interestingly Windows has moved back to boring release numbers and has dropped the fantasy names Possible solutions: - Make project tags /the primary view for new users when searching the system. There is a lot of talk about students and having to explain confusing things to them. Would it not be more straightforward to look for a "Class Browser" or "SCM" category?! - If projects are designed just-for-pharo, maybe borrow another trick from OS X - have a codename for development (like Fuji for Sierra) and then change it to something more generic on release, like Browser3, although now that we seem to be keeping tools in their own project repos, that might be problematic I summary, IMHO it is important to provide both: - A clear, searchable, pragmatic way to navigate/understand the system - As well as the unique, google-able, but usually undescriptive way we have now ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote:
Stephane Ducasse-3 wrote
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... So guys can we focus our energy on positive things.
IHMO this is certainly a positive subject because it highlights the as-yet-to-be-resolved tension regarding understandability of the system between having a unique name (good for googling, distinguishing between versions) and a name that reveals what the project does/is for. What is the plan to resolve this because it is a real problem?
Nike and Levis are designed to stand on their own in front of the consumer market. Is this true of Nautilus, Calypso, or Epicea?
Sean, Thank you for this clarification! I read Stef's message this morning and I honestly thought that my name ("lewis") might have something to do with pants. That probably would not be a good thing. But now I see that we are talking about "levis" so I feel much better now :-) Dave (Lewis, not Levis)
How a project is named is a choice of the author. Nobody gets to demand how someone should name their projects. Now how project is actually named is not a issue if it is properly handled on pharo side, which in some places is, in some places isn't. For instance, there's a gazillion UI frameworks out there and, most of the
time, the name used for them is one of a famous painter.
We have Magritte, which is a meta-data description framework, not UI framework. :) How many Pharo *users* (not regular contributors!) know what those
tools/frameworks/packages do ???
Probably not many, because they never encounter them, nor care about whether they exist or not. A very quick look at what's in Pharo 7 shows the following names : Iceberg,
Ombu, Calypso, Flashback, Nautilus, Renraku, Zodiac, Shift, Zinc, Hermes, Beacon, Cargo, Hermes, Opal, Shoreline, Epicea, Balloon, BlueInk, Commander, Fuel, Glamorous, Glamour, Gofer, Hiedra, Metacello, Moose, Ring, Rubric, Shout, Spec, etc...
Calypso + Nautilus: as a user you don't get to encounter the names, there's only "System Browser" Did you know that there are other code browsers you can install? (e.g. Code Panels, Alt Browser, ...) Iceberg: as someone pointed out, this would be nice to have a "(Git) Versionner" or whatever entry instead Metacello: npm => "Package manager 1", pip => "Package manager 2", ... Ombu/Epicea: you access it via "Code Changes", names are hidden from the user Flashback, Renraku, Hermes, Opal, Shoreline, BlueInk, Hiedra, Ring, Rubric, Shout, Glamorous, Glamour: not something a regular user ever encounters directly, and if they need to, the unique name helps a lot in finding information/docs about it Moose: are you serious? should Pharo be called "Programming Language 28301" too? Commander: Commander is a library to implement commands. You literally cannot have a more descriptive name and yet you still complain. Spec: ... maybe we can rename * Morphic "UI 1" * Baloon "UI -1" * Spec "UI 2" * Rubric "UI 3" * Tx "UI A" * Bloc "UI ×" * Athens "UI ε" * Cairo "UI Щ" * Sparta "UI ã" and then try to find any information about anything. Was it really that hard to replace the old workspace with Workspace2 or
WhateverWorkspace ? Or even better : get rid of the old Workspace and replace it with Playground while retaining the name "Workspace" ???
Well I could claim that "Workspace" is a very confusing name, because it is not actually workspace, just a trivial Text Box. If anything, Playground is a much more fitting name. Or somethings as simple as Regex, the regex package from Bykov. Which variant of regular expressions though? Unless we *clearly* publicize/describe what those names are, there's no way
in a thousand years you could tell that BlueInk is not a package dealing with fonts (that was my first guess) !
I fully agree with this, and as I've mentioned (here, or maybe in another thread), this has improved greatly with move to GitHub, as people finally started to care about describing their projects. But the transition takes time. Btw BlueInk is a "pretty printer", so the name isn't really misleading once you know what it is. But being "clever" with names is sure way to get it misinterpreted. (E.g. "grafoscopio" which has nothing to do with graphs or visualizations, as it is text/nodes/code snippets organization tool.) (For the record I tend to name projects with the most boring name I can come up with (tonel-migration, IconFactory, file-dialog, xml-magritte-generator, uml-xmi, ...), but it only works if there's only one such thing... if there are competing projects, than sharing the name doesn't help anyone.) Peter On Sat, Apr 21, 2018 at 1:34 AM, David T. Lewis <lewis@mail.msen.com> wrote:
On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote:
Stephane Ducasse-3 wrote
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... So guys can we focus our energy on positive things.
IHMO this is certainly a positive subject because it highlights the as-yet-to-be-resolved tension regarding understandability of the system between having a unique name (good for googling, distinguishing between versions) and a name that reveals what the project does/is for. What is the plan to resolve this because it is a real problem?
Nike and Levis are designed to stand on their own in front of the consumer market. Is this true of Nautilus, Calypso, or Epicea?
Sean,
Thank you for this clarification! I read Stef's message this morning and I honestly thought that my name ("lewis") might have something to do with pants. That probably would not be a good thing. But now I see that we are talking about "levis" so I feel much better now :-)
Dave (Lewis, not Levis)
What I find sad is that people spent hours talking instead of doing. This is why Smalltalk is for them. Personally I prefer Pharo. Let me migrate another Seaside chapter so that people can complain after all. Stef On Sat, Apr 21, 2018 at 11:48 AM, Peter Uhnák <i.uhnak@gmail.com> wrote:
How a project is named is a choice of the author. Nobody gets to demand how someone should name their projects.
Now how project is actually named is not a issue if it is properly handled on pharo side, which in some places is, in some places isn't.
For instance, there's a gazillion UI frameworks out there and, most of the time, the name used for them is one of a famous painter.
We have Magritte, which is a meta-data description framework, not UI framework. :)
How many Pharo *users* (not regular contributors!) know what those tools/frameworks/packages do ???
Probably not many, because they never encounter them, nor care about whether they exist or not.
A very quick look at what's in Pharo 7 shows the following names : Iceberg, Ombu, Calypso, Flashback, Nautilus, Renraku, Zodiac, Shift, Zinc, Hermes, Beacon, Cargo, Hermes, Opal, Shoreline, Epicea, Balloon, BlueInk, Commander, Fuel, Glamorous, Glamour, Gofer, Hiedra, Metacello, Moose, Ring, Rubric, Shout, Spec, etc...
Calypso + Nautilus: as a user you don't get to encounter the names, there's only "System Browser" Did you know that there are other code browsers you can install? (e.g. Code Panels, Alt Browser, ...)
Iceberg: as someone pointed out, this would be nice to have a "(Git) Versionner" or whatever entry instead
Metacello: npm => "Package manager 1", pip => "Package manager 2", ...
Ombu/Epicea: you access it via "Code Changes", names are hidden from the user
Flashback, Renraku, Hermes, Opal, Shoreline, BlueInk, Hiedra, Ring, Rubric, Shout, Glamorous, Glamour: not something a regular user ever encounters directly, and if they need to, the unique name helps a lot in finding information/docs about it
Moose: are you serious? should Pharo be called "Programming Language 28301" too?
Commander: Commander is a library to implement commands. You literally cannot have a more descriptive name and yet you still complain.
Spec: ... maybe we can rename * Morphic "UI 1" * Baloon "UI -1" * Spec "UI 2" * Rubric "UI 3" * Tx "UI A" * Bloc "UI ×" * Athens "UI ε" * Cairo "UI Щ" * Sparta "UI ã"
and then try to find any information about anything.
Was it really that hard to replace the old workspace with Workspace2 or WhateverWorkspace ? Or even better : get rid of the old Workspace and replace it with Playground while retaining the name "Workspace" ???
Well I could claim that "Workspace" is a very confusing name, because it is not actually workspace, just a trivial Text Box. If anything, Playground is a much more fitting name.
Or somethings as simple as Regex, the regex package from Bykov.
Which variant of regular expressions though?
Unless we *clearly* publicize/describe what those names are, there's no way in a thousand years you could tell that BlueInk is not a package dealing with fonts (that was my first guess) !
I fully agree with this, and as I've mentioned (here, or maybe in another thread), this has improved greatly with move to GitHub, as people finally started to care about describing their projects. But the transition takes time. Btw BlueInk is a "pretty printer", so the name isn't really misleading once you know what it is. But being "clever" with names is sure way to get it misinterpreted. (E.g. "grafoscopio" which has nothing to do with graphs or visualizations, as it is text/nodes/code snippets organization tool.)
(For the record I tend to name projects with the most boring name I can come up with (tonel-migration, IconFactory, file-dialog, xml-magritte-generator, uml-xmi, ...), but it only works if there's only one such thing... if there are competing projects, than sharing the name doesn't help anyone.)
Peter
On Sat, Apr 21, 2018 at 1:34 AM, David T. Lewis <lewis@mail.msen.com> wrote:
On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote:
Stephane Ducasse-3 wrote
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants.... So guys can we focus our energy on positive things.
IHMO this is certainly a positive subject because it highlights the as-yet-to-be-resolved tension regarding understandability of the system between having a unique name (good for googling, distinguishing between versions) and a name that reveals what the project does/is for. What is the plan to resolve this because it is a real problem?
Nike and Levis are designed to stand on their own in front of the consumer market. Is this true of Nautilus, Calypso, or Epicea?
Sean,
Thank you for this clarification! I read Stef's message this morning and I honestly thought that my name ("lewis") might have something to do with pants. That probably would not be a good thing. But now I see that we are talking about "levis" so I feel much better now :-)
Dave (Lewis, not Levis)
On 20/04/18 02:14, Stephane Ducasse wrote:
On this matter, when I named my project, "Grafoscopio" I thought in something evocative and unique, because of the Spanish words "grafo" (graph) and grafÃa[1][2] (graphy, related with writing like in "ortografÃa" "orthography". After naming it I discover there was a old device related with writing and visualization, also called Grafoscopio[3][4], but I got good search rankings because of the uniqueness of the word[5][6]. Obviously and well done!
I like when developers are talking about names: They use a mac and not a computer, they were nike, lewis and not shoes and pants....
May be we should rename Pharo: programming language. And Voyage: Layer And Athens, Cairo: Canvas
And git: versioning system
Hibernate? JavaFX?, Graddle?, Travis?, Bintray? Do you want more Docker?
So guys can we focus our energy on positive things.
Stef
Thanks Stephan. I think most of the community is working on positive thinks (like you). Naming preferences and conventions shouldn't be a place for holy wars. And in fact I would like to learn more about Smalltalk Style, for example, how to use prefixes in classes without loosing the "branding" behind names and tools. Cheers, Offray
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do?  Electron is as obscure as Phobos (although a phobia with web pages turned into desktop apps may be appropriate). AndrewOn Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
On 13 Apr 2018, at 14:33, Andrew Glynn <aglynn42@gmail.com> wrote:
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?). Grunt, Gulp, etc., how do the names relate to what they do?
yes⦠but we actually have a problem there. I would like to be able to add âtags" to tools, to be able to say: Calypso -> a class browser -> some more info etc. Esteban
Electron is as obscure as Phobos (although a phobia with web pages turned into desktop apps may be appropriate).
Andrew
On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com <mailto:raoknz@gmail.com>> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
On 13/04/2018 09:39, Esteban Lorenzano wrote:
On 13 Apr 2018, at 14:33, Andrew Glynn <aglynn42@gmail.com <mailto:aglynn42@gmail.com>> wrote:
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?). Â Grunt, Gulp, etc., how do the names relate to what they do? Â
yes⦠but we actually have a problem there. I would like to be able to add âtags" to tools, to be able to say:Â
Calypso -> a class browser -> some more info etc.
But isn't that what the Catalog currently does? Of course the catalog is not for a "package" (as in npm, apt, yum, etc). Regards, -- Esteban, the other one. :P
On 13 Apr 2018, at 14:47, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
On 13/04/2018 09:39, Esteban Lorenzano wrote:
On 13 Apr 2018, at 14:33, Andrew Glynn <aglynn42@gmail.com <mailto:aglynn42@gmail.com>> wrote:
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?). Grunt, Gulp, etc., how do the names relate to what they do?
yes⦠but we actually have a problem there. I would like to be able to add âtags" to tools, to be able to say:
Calypso -> a class browser -> some more info etc.
But isn't that what the Catalog currently does?
Iâm talking about what is *inside* the image. Esteban
Of course the catalog is not for a "package" (as in npm, apt, yum, etc).
Regards,
-- Esteban, the other one. :P
Agreed, just pointing out that other systems have similar issues, and do because it's not easy to do originally or to fix later on. Â But I'm just a Pharo user, not a Pharo developer. Â I'm leaning on the shoulders of much better developers. It takes time to learn any system. I've spent 21 years programming Java and there's still plenty I don't know. Â I've spent 16 years with Eclipse and the current version bears little resemblance to the original. Â Rebasing all of Eclipse on OSGi was done in an incremental update, Â between 3.3 and 3.4 if I remember correctly.
From the user perspective, at least the changes in Pharo provide more caveats, given they've taken place in full version changes with alpha versions preceding beta and stable versions. AndrewOn Fri, 2018-04-13 at 14:39 +0200, Esteban Lorenzano wrote:
On 13 Apr 2018, at 14:33, Andrew Glynn <aglynn42@gmail.com> wrote:
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do?  yes⦠but we actually have a problem there. I would like to be able to add âtags" to tools, to be able to say:Â
Calypso -> a class browser -> some more info etc.
Esteban
Electron is as obscure as Phobos (although a phobia with web pages turned into desktop apps may be appropriate).
Andrew
On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe m> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
EstebanLM wrote
I would like to be able to add âtags" to tools, to be able to say: Calypso -> a class browser -> some more info
Yes! That is what I was trying to get at in the other thread [1], but not explaining very well. The thing is that this should be *the default view* of the system for new users. The left browser pane could have at least three views of the system: - Packages - What we have now - Least generally important (really only matters for modularity when you're adding code) - Projects - What's been proposed because many packages could be collected under one project node - Better than the above, but still falls prey to the problems being mentioned (i.e. WTH is a Seashell/Coral/SandCastle/FishingPole - what are they *for*) - Purpose/Category/Tag - This was the function of the original System categories and what I think Esteban is proposing. Of course in the browser and other tools the arrows would flow differently: 'Browser' -> #(Calypso Nautilus) -> some more info 1. http://forum.world.st/Why-can-t-we-use-in-protocol-for-package-extension-tp5... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Or just expand the names to be descriptive. CalypsoClassBrowser would be cool
On Apr 13, 2018, at 5:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 13 Apr 2018, at 14:33, Andrew Glynn <aglynn42@gmail.com <mailto:aglynn42@gmail.com>> wrote:
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?). Grunt, Gulp, etc., how do the names relate to what they do?
yes⦠but we actually have a problem there. I would like to be able to add âtags" to tools, to be able to say:
Calypso -> a class browser -> some more info etc.
Esteban
Electron is as obscure as Phobos (although a phobia with web pages turned into desktop apps may be appropriate).
Andrew
On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <raoknz@gmail.com <mailto:raoknz@gmail.com>> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
Until we have mature package manager (similar to Cargo or npm), you have to use google. On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.
Peter
"I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do? " iirc, Abt was for "Application Builder Toolkit", Cw was for "Common Widgets", "Cfs was for "Common File System", Sst was for "Server Smalltalk", etc. There used to be a list of VAST prefixes on the IBM website but I couldn't find it... ----------------- 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)
Unfortunately there probably isn't one list. Its hard to unlearn what is accumulated and easy to take for granted what we know is obvious to everyone. Maybe we need a "Glossary" at https://github.com/pharo-project/pharo/tree/master/wiki where newcomers can add items for others to fill in. cheers -ben On 13 April 2018 at 20:05, Richard O'Keefe <raoknz@gmail.com> wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
On 13 April 2018 at 23:01, Marcus Denker <marcus.denker@inria.fr> wrote:
On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@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.
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 14:23, Ben Coman <btc@openinworld.com> wrote:
Unfortunately there probably isn't one list. Its hard to unlearn what is accumulated and easy to take for granted what we know is obvious to everyone. Maybe we need a "Glossary" at https://github.com/pharo-project/pharo/tree/master/wiki <https://github.com/pharo-project/pharo/tree/master/wiki> where newcomers can add items for others to fill in.
this is part a debate Stef and I have since years. I think we need to put generic names to our tools: - System browser - Source Version Control - etc. while Stef supports fantasy names: - Calypso - Iceberg - etc. you know who won this debate ;) but at least I would like to add an option for special menu to show what is suck tool. cheers, Esteban
cheers -ben
On 13 April 2018 at 20:05, Richard O'Keefe <raoknz@gmail.com <mailto:raoknz@gmail.com>> wrote: There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
On 13 April 2018 at 23:01, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@gmail.com <mailto:j.b.shirk@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.
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 04/13/2018 07:33 AM, Esteban Lorenzano wrote:
On 13 Apr 2018, at 14:23, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
Unfortunately there probably isn't one list. Its hard to unlearn what is accumulated and easy to take for granted what we know is obvious to everyone. Maybe we need a "Glossary" at https://github.com/pharo-project/pharo/tree/master/wiki where newcomers can add items for others to fill in.
this is part a debate Stef and I have since years. I think we need to put generic names to our tools:
- System browser - Source Version Control - etc.
while Stef supports fantasy names:
- Calypso - Iceberg - etc.
you know who won this debate ;)
but at least I would like to add an option for special menu to show what is suck tool.
cheers, Esteban
Personally I have wished for a long time that Pharo used standard names for the default tools or libraries in the image. I think the fancy names can lead to confusion as to what am I supposed to use. Which one is the default one, which one is the development one. One shouldn't have to ask the mailing list to determine such things. If one plans on developing in Pharo for years or for decades. The constant turnover of names makes things cognitively more challenging and I would think it would also make bringing older code forward more difficult. I ask these questions as one who doesn't know the answer, but only has an opinion. This is not what I do everyday. What works best for the long view of our system? At some point we know the constant churn will be reduced and we will have a clean, as small as reasonable and stable system. When this is the case, what is best for Pharo in naming of tools and libraries? New names every time implementation changes? Or stable common understandable names, names which represent what the class is? I think the fancy name is okay for the development version. And when upgraded to becoming the default, the name becomes the default name. I think it would be nice to have stable names which can provide a stable api of class names and public messages which can be around for decades. I think innovation and creativity belong in better places than what's the new name for the System Browser, etc. It seems this would be nicer on us bears of very little brain. :) Jimmie
On 13/04/2018 09:05, Richard O'Keefe wrote:
There are a lot of subsystems in Pharo, and being a bear of very little brain, I have a hard time relating Zinc, Calypso, &c &c to, well, whatever they are. I presume there is somewhere a list of topic/name/PFX triples for guidance. Can some kind soul tell me where it is?
I think it's not a matter of brain, and unless I also have a bear brain I find it hard to know what each thing means, in particular when there is a "flagship" framework (like Seaside) and the related extensions/libraries are called something different instead of, it is harder when the names are completely unrelated to the domain. I've been thinking of collecting the package names, what they do, an which class prefixes they use. But never had the willingness to actually do it, maybe now is a good moment. Regards, -- Esteban.
2018-04-13 13:01 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
On 13 Apr 2018, at 12:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Apr 2018, at 12:19, Joe Shirk <j.b.shirk@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.
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).
At some point we should force rule "All packages have comments". And indication with icon like we do for classes. With Calypso the package comment is always available. So it would be easy to find description. 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
"At some point we should force rule "All packages have comments". And indication with icon like we do for classes."  +1 ----------------- 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)
Le 13/04/2018 à 14:27, Denis Kudriashov a écrit :
At some point we should force rule "All packages have comments". And indication with icon like we do for classes. With Calypso the package comment is always available. So it would be easy to find description.
I would like to force this rule too but it'll need some work because some packages are not only loaded in Pharo (as Alien) and PackageManifest is not present in Squeak image. -- Cyril Ferlicot https://ferlicot.fr
participants (20)
-
Andrew Glynn -
Ben Coman -
Benoit St-Jean -
Cyril Ferlicot D. -
David T. Lewis -
Denis Kudriashov -
Esteban A. Maringolo -
Esteban Lorenzano -
Herbert VojÄÃk -
Jimmie Houchin -
Joe Shirk -
Marcus Denker -
Offray Vladimir Luna Cárdenas -
Peter Uhnák -
phil＠highoctane.be -
Richard O'Keefe -
Sean P. DeNigris -
Stephane Ducasse -
Sven Van Caekenberghe -
Todd Blanchard