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 <[hidden email]> wrote:
|
In reply to this post by Ben Coman
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
|
In reply to this post by Peter Uhnak
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). Andrew On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
|
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
|
In reply to this post by Richard O'Keefe
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:
|
In reply to this post by EstebanLM
On 13/04/2018 09:39, Esteban Lorenzano wrote: > > >> On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email] >> <mailto:[hidden email]>> 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 |
In reply to this post by EstebanLM
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. Andrew On Fri, 2018-04-13 at 14:39 +0200, Esteban Lorenzano wrote:
|
In reply to this post by Esteban A. Maringolo
> On 13 Apr 2018, at 14:47, Esteban A. Maringolo <[hidden email]> wrote: > > > > On 13/04/2018 09:39, Esteban Lorenzano wrote: >> >> >>> On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email] >>> <mailto:[hidden email]>> 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 > |
In reply to this post by alistairgrant
I am not complaining about these exchanges, which were interesting indeed. Just that P7 is still in flux and not something I can use in some way for my projects. No problem with that, just that I cannot afford using it in projects for clients, it is too much of a risk. So, I am not testing it as much as I'd like. I have found that the real issues show up with cases I face in such projects. Phil On Fri, Apr 13, 2018 at 11:39 AM, Alistair Grant <[hidden email]> wrote: On 13 April 2018 at 11:04, Sven Van Caekenberghe <[hidden email]> wrote: |
In reply to this post by aglynn42
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 <[hidden email]> wrote:
|
Administrator
|
In reply to this post by EstebanLM
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-tp5073597p5073663.html ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
In reply to this post by philippeback
On 13/04/2018 10:41, [hidden email] 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 |
Administrator
|
In reply to this post by EstebanLM
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
Cheers,
Sean |
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 |
In reply to this post by Esteban A. Maringolo
Esteban A. Maringolo wrote: > On 13/04/2018 10:41, [hidden email] 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 of "Fancy Merit Type". |
In reply to this post by Pharo Smalltalk Users mailing list
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 |
In reply to this post by Pharo Smalltalk Users mailing list
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 <[hidden email]> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <[hidden email]> > To: [hidden email] > Cc: > Bcc: > Date: Fri, 13 Apr 2018 05:53:46 +0000 (UTC) > Subject: Where do we go now ? > Hello guys, > > Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading. > > When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic. The promise of a new, clean & lean Smalltalk attracted a lot of people. And then... > > I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading. Every Pharo release gets bigger, and bigger, and bigger. I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated. > > Do we really need 2 code completion classes (NECController, NOCController) ? Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ? Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? Do we really need 2 inspectors (GTInspector, EyeInspector) ? Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera. I could go on, and on, and on... > > Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes. Can you see a trend? > > Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings. Can you see a trend? > > Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image. Can you see a trend? > > Add to that the fact that Pharo is a nightmare when you want to port code. Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes). > > You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway! > > You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements? > > UI speaking, what framework should anyone use ? Athens? Something else? > > You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ? Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway! > > So what's the plan? For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated? Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!" ? > > Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do? If you say Calypso is the official & supported browser, fine! Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel! > > Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer. Did we include Calypso to deprecate Nautilus later? Is Calypso just a proof of concept? Is it just an optional tool? What about all those delay schedulers? > > "I loaded this code from SqueakSource and it just doesn't work". Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo? > > Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us. > > > ----------------- > Benoît St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > |
Administrator
|
In reply to this post by HilaireFernandes
On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <[hidden email]> 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. 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
|
In reply to this post by Stephane Ducasse-3
Le 13/04/2018 à 19:49, Stephane Ducasse a écrit :
> 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. I don't see we are there yet. At least from my humble point of view the bootstrap still looks like WIP. Hilaire -- Dr. Geo http://drgeo.eu |
Free forum by Nabble | Edit this page |