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

[Offray Vladimir Luna Cárdenas]

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

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
>What I find sad is that people spent hours talking instead of doing.
>This is why Smalltalk is for them.
>Personally I prefer Pharo.

Well, I guess I don't belong here anymore since "Pharo is NOT Smalltalk" as you 
keep saying!  

And since I've been a Smalltalker for only 25+ years, I guess Smalltalk is 
really for me as you wrote!  Every Smalltalker is a moron as you so often imply 
(especially in private emails incidentally): only Pharoers "do it right"...  So 
I'll go back to that moronic programming language!

P.S.  I'll let you handle the questions in #pharo on IRC as I'll no longer be 
on the channel : you'll see, it'll be really instructive for you! People there 
have those weird practical problems, it's crazy!



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

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

[Stephane Ducasse]

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

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

[Peter Uhnák]

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

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

[David T. Lewis]

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)

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

[Andrei Stebakov]

That would definitely help if Pharo shed some of its elitism with fancy
names.
Then it would have much more appeal for the masses (and definitely increase
popularity of Smalltalk) but it is the intent of the community, that's the
question.

On Fri, Apr 20, 2018 at 4:09 PM, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: pharo-users@lists.pharo.org
> Cc: "s...@clipperadams.com" <s...@clipperadams.com>
> Bcc:
> Date: Fri, 20 Apr 2018 20:09:43 +0000 (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> 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
> soo 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 availab

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
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 
soo 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 
 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?

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

[Sean P. DeNigris]

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

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

[Stephane Ducasse]

>
> 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-8f3c-42a0-a1ab-1374bbca9d5f
> [4]
> https://www.museodelprado.es/en/whats-on/exhibition/the-graphoscope/81bfb972-aade-4c24-93b2-dbd7e26e5e4a
> [5] https://duckduckgo.com/?q=grafoscopio=ffsb=v76-7=web
> [6] https://www.google.com/search?hl=en=grafoscopio
>
> Cheers,
>
> Offray
>
> On 13/04/18 09:01, Esteban A. Maringolo wrote:
>> On 13/04/2018 10:41, p...@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.
>>
>>
>>
>>
>>
>>
>>
>
>
>

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

[Offray Vladimir Luna Cárdenas]

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-8f3c-42a0-a1ab-1374bbca9d5f
[4]
https://www.museodelprado.es/en/whats-on/exhibition/the-graphoscope/81bfb972-aade-4c24-93b2-dbd7e26e5e4a
[5] https://duckduckgo.com/?q=grafoscopio=ffsb=v76-7=web
[6] https://www.google.com/search?hl=en=grafoscopio

Cheers,

Offray

On 13/04/18 09:01, Esteban A. Maringolo wrote:
> On 13/04/2018 10:41, p...@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.
>
>
>
>
>
>
>

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

[Jimmie Houchin]

On 04/13/2018 07:33 AM, Esteban Lorenzano wrote:



On 13 Apr 2018, at 14:23, Ben Coman > 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

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

[Todd Blanchard]

Or just expand the names to be descriptive.  

CalypsoClassBrowser would be cool




> On Apr 13, 2018, at 5:39 AM, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 14:33, Andrew Glynn > > 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 >> > 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,
   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
> 

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"I don't understand what you mean.  There is a setting that *gives* you the 
opportunity to decide."
I have no clue, I've never been able to actually have PharoLauncher start & 
work!!!

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

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

[Ben Coman]

On 16 April 2018 at 03:46, Benoit St-Jean  wrote:
>>
>> "As a work around, in the PharoLauncher settings can you set the
directories like
>> C:\PharoLauncher\images
>> C:\PharoLauncher\vms
>> and report if that helps.
>> "

> Or even better, let the user decide!

I don't understand what you mean.
There is a setting that *gives* you the opportunity to decide.


>> and report if that helps.

What was the result of my suggestion provided above?

Also, with the MSI I provided in the other link,
can you try installing under C:\PharoLauncher.

cheers -ben

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

[Cyril Ferlicot D.]

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



signature.asc
Description: OpenPGP digital signature

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"As a work around, in the PharoLauncher settings can you set the directories 
like C:\PharoLauncher\imagesC:\PharoLaucnher\vmsand report if that helps.  
"
Or even better, let the user decide!


- 
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 Sunday, April 15, 2018, 12:58:44 a.m. EDT, Ben Coman 
<b...@openinworld.com> wrote:  
 
 

On 13 April 2018 at 17:49, Benoit St-Jean via Pharo-users 
<pharo-users@lists.pharo.org> wrote:



-- Forwarded message --
From: Benoit St-Jean <bstj...@yahoo.com>
To: Esteban Lorenzano <esteba...@gmail.com>
Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Bcc: 
Date: Fri, 13 Apr 2018 09:49:15 +0000 (UTC)
Subject: Re: [Pharo-users] Where do we go now ?
For those interested.
Created the issues 21686, 21693, 21695, 21696.
And more to come...


Thanks for those.  I don't much time right to devote, but managed to knock one 
off.And I learn't something new. I'd not known there was a setting for screen 
background.
The other ones seem related to a problem dealing with user home folders 
containing non-ascii characters.Currently this seems only to affect a small 
number of people, but is a show stopper for them,and the numbers will grow with 
our hoped for growing popularity.
As a work around, in the PharoLauncher settings can you set the directories 
like C:\PharoLauncher\imagesC:\PharoLaucnher\vmsand report if that helps.  
Note, I bumped into an issue changing that setting myself recently where it 
tries to migrate the existing images from the old to the new folder, causing a 
catch-22 when your tryingto do that to work around other problems.  To work 
around that, I had to scroll down the debug stack to find where the migration 
was iterating through the image folders,and short circuit that with "Return 
entered value" from the context menu.  Any valuewill do when the return value 
is not used. good luck.
@PharoLauncher maintainers, can the change in this setting be made to succeed 
even if the migration fails.(I need to run right now)
cheers -ben
  --- End Message ---

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"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)--- End Message ---

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"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)--- End Message ---

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
OS/2 ?  What???  Is it free/openSource?  Man!  Where can I get that!!!  Good 
memories


- 
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 13, 2018, 6:57:16 a.m. EDT, <aglyn...@gmail.com> wrote:  
 
 
Btw, in my fascination with messing around, the 32 bit version of Pharo 7 for 
Windows runs better on OS/2 v.5 (yes, it still exists, it was released last 
June).  Probably because its Win32 subsystem is more compatible with Win32 apps 
than Windows 10.

  

Andrew

  

From: Benoit St-Jean <bstj...@yahoo.com> 
Sent: Friday, April 13, 2018 5:26 AM
To: Esteban Lorenzano <esteba...@gmail.com>
Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Where do we go now ?

  

BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

  

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?

  

  

- 
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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
<esteba...@gmail.com> wrote: 

  

  

  






On 13 Apr 2018, at 11:07, Benoit St-Jean <bstj...@yahoo.com> wrote:

  

I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

  


  

and btw… which part of ALPHA you do not get?

  

Esteban
  --- End Message ---

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

[Stephane Ducasse]

Ben

can you open a bug entry.
Now I can tell you that the launcher is one of the most complex
application built in Pharo because
it has to adapt to multiple OS, multiple version of OS, multiple
versions of the images and the VM.
For example we discover that we cannot open certain pharo 30 image
with the pharo 30 vm but
better with a pharo 40 vm.

Stef



On Sun, Apr 15, 2018 at 6:58 AM, Ben Coman <b...@openinworld.com> wrote:
>
>
> On 13 April 2018 at 17:49, Benoit St-Jean via Pharo-users
> <pharo-users@lists.pharo.org> wrote:
>>
>>
>>
>> -- Forwarded message --
>> From: Benoit St-Jean <bstj...@yahoo.com>
>> To: Esteban Lorenzano <esteba...@gmail.com>
>> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
>> Bcc:
>> Date: Fri, 13 Apr 2018 09:49:15 + (UTC)
>> Subject: Re: [Pharo-users] Where do we go now ?
>> For those interested.
>>
>> Created the issues 21686, 21693, 21695, 21696.
>>
>> And more to come...
>
>
> Thanks for those.  I don't much time right to devote, but managed to knock
> one off.
> And I learn't something new.  I'd not known there was a setting for screen
> background.
>
> The other ones seem related to a problem dealing with user home folders
> containing non-ascii characters.
> Currently this seems only to affect a small number of people, but is a show
> stopper for them,
> and the numbers will grow with our hoped for growing popularity.
>
> As a work around, in the PharoLauncher settings can you set the directories
> like
> C:\PharoLauncher\images
> C:\PharoLaucnher\vms
> and report if that helps.
>
> Note, I bumped into an issue changing that setting myself recently where it
> tries to migrate
> the existing images from the old to the new folder, causing a catch-22 when
> your trying
> to do that to work around other problems.  To work around that, I had to
> scroll
> down the debug stack to find where the migration was iterating through the
> image folders,
> and short circuit that with "Return entered value" from the context menu.
> Any value
> will do when the return value is not used.  good luck.
>
> @PharoLauncher maintainers, can the change in this setting be made to
> succeed even if the migration fails.
> (I need to run right now)
>
> cheers -ben
>

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

[Ben Coman]

On 13 April 2018 at 17:49, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: Esteban Lorenzano <esteba...@gmail.com>
> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Bcc:
> Date: Fri, 13 Apr 2018 09:49:15 +0000 (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> For those interested.
>
> Created the issues 21686, 21693, 21695, 21696.
>
> And more to come...
>

Thanks for those.  I don't much time right to devote, but managed to knock
one off.
And I learn't something new.  I'd not known there was a setting for screen
background.

The other ones seem related to a problem dealing with user home folders
containing non-ascii characters.
Currently this seems only to affect a small number of people, but is a show
stopper for them,
and the numbers will grow with our hoped for growing popularity.

As a work around, in the PharoLauncher settings can you set the directories
like
C:\PharoLauncher\images
C:\PharoLaucnher\vms
and report if that helps.

Note, I bumped into an issue changing that setting myself recently where it
tries to migrate
the existing images from the old to the new folder, causing a catch-22 when
your trying
to do that to work around other problems.  To work around that, I had to
scroll
down the debug stack to find where the migration was iterating through the
image folders,
and short circuit that with "Return entered value" from the context menu.
Any value
will do when the return value is not used.  good luck.

@PharoLauncher maintainers, can the change in this setting be made to
succeed even if the migration fails.
(I need to run right now)

cheers -ben

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

[Stephane Ducasse]

Hilaire

I will not start to argue. The bootstrap is in production since the
beginning of Pharo 70.
Now building multiple different images from it is another story.

Stef


On Sat, Apr 14, 2018 at 10:45 AM, Hilaire  wrote:
> 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
>
>
>

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

[Ben Coman]

On 14 April 2018 at 01:52, Richard Sargent  wrote:

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

You would expect this be a natural progression as more companies supporting
such priorities join the consortium.

The corollary is that its better the take greater leaps earlier when there
is a greater percentage of Innovators and Early Adopters
who are willing to ride some rough edges for the benefit they gain *now*.
When the Majority arrive, such changes would be more disruptive to
perception of Pharo i.e. more opinons, less care.

cheers -ben



>
> A second consideration is the size of the product teams (measured in
> full-time staffing). I think the commercial products had a much larger
> staffing in their early days than Pharo has even now. And I think the
> consequence of that is that the changes between v1 and v2 or between v2 and
> v3 of the commercial products *may* have been comparable to the
> differences between Pharo v(n) and v(n+3).
>
>
> Richard
>
>
>>
>> Hilaire
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
>

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

[Hilaire]

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

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

[Richard Sargent]

On Fri, Apr 13, 2018 at 1:11 PM, Hilaire  wrote:

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


Hi Hilaire,

Thanks for articulating this. I've been mostly watching Pharo rather than
using it, so I haven't been affected by the changes between versions. With
respect to commercial products versus Pharo *at the present time*, I think
we have different driving forces shaping things.

In my opinion, VA Smalltalk has been the one most strongly driven by the
importance of backward compatibility and ease of migration to a new
version. VisualWorks has been pretty good about providing a path forward
with minimal pain, although the more major version numbers difference, the
harder it is to transition. Likewise, GemStone/S has a strong emphasis on
keeping our customers' existing applications running with minimal changes.

That being said, I have no doubt that the earliest versions of all these
products had substantial incompatibilities between versions. I am also
pretty sure there is a threshold beyond which the adoption of Pharo in
business applications will compel Pharo development to facilitate migration
to newer versions and to better maintain API compatibility. [And that may
be simply because, as more businesses rely on Pharo, they will be
financially supporting its development.]


A second consideration is the size of the product teams (measured in
full-time staffing). I think the commercial products had a much larger
staffing in their early days than Pharo has even now. And I think the
consequence of that is that the changes between v1 and v2 or between v2 and
v3 of the commercial products *may* have been comparable to the differences
between Pharo v(n) and v(n+3).


Richard


>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

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

[Stephane Ducasse]

We know where we go (we have a roadmap) and this is always the same
and we are getting there. Tell me one smalltalk that is bootstrapped.
And only bad OOP programmers count number of classes
Now I will not reply to provocation. So I just trashed this thread
because it goes nowhere.
Sorry constructivism criticisms from people that already commited and
helped is something positive.
But in this thread I only read in inverse and I will let you with it
and keep my good energy for it .

Stef

On Fri, Apr 13, 2018 at 7:53 AM, Benoit St-Jean via Pharo-users
 wrote:
>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: pharo-users@lists.pharo.org
> Cc:
> Bcc:
> Date: Fri, 13 Apr 2018 05:53:46 + (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 
> looong 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 
> looong 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 

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

[Hilaire]

Sometime Pharo frustrate me a lot, I felt it too in the message from 
Benoit, in the other hand its community is very kind and always helpful. 
So it is not about blaming people.


In my opinion, there are too much things pushed at the same time in 
Pharo. You can't push too much things into the box, then when people 
complain about it to be overfull and bugged request them to fix it, I 
don't think it can work that way, at this scale of changes. In the 
other, this is not really what happen here, I very likely exaggerate 
this trait but you get the idea.


For example, I developed DrGeo for several years on P3. Why sticking to 
P3? It gave me the opportunity to fine craft DrGeo to be stable and 
predictable in the way it behaves to its end users, and a lot of 
releases occurred. When I started to look at porting to newer image last 
June, I realized  DrGeo will become unstable and oversized, so can of 
turning from A+ grade to a D- grade, just by the magic of porting it. My 
plan was to port it during the summer to get it ready end of August to 
deploy in local schools, it does not happen. And I can write it: it is 
s-u-p-e-r  f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I 
don't know, I am a casual developer, but it makes developing well 
crafted and reliable Pharo application a bit expensive to my taste. To 
such a scale that I started to evaluate alternative to Pharo as the 
underneath system, idea I finally gave up after several weeks of 
evaluations. All in all I still have this felling Pharo is not developer 
friendly, I fell DrGeo is not secure there. See when porting to newer 
image, I end up using P7-32bits alpha on Linux because it was the most 
comfortable situation comparing to P5/P6/P6.1, is it not strange?


In the other hand this struggle occurs at image change. Ok, may be it is 
a pattern specific to Smalltalk. Is it the case with commercial 
Smalltalk vendors?


Hilaire

--
Dr. Geo
http://drgeo.eu

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

[Herbert Vojčík]

Herbert Vojčík wrote:

Just a bit of a bikeshedding here:


But I prefer these names:
* Calypso System Browser


Calypso Browser Display


* Calypso Debugger


Calypso Debugger Display
Calypso Debugger Gear


* Iceberg Source Control Management\


Iceberg SCM Display
Iceberg SCM Gear


* Zinc HTTP Client


Zinc Web Client Gear


* Zinc HTTP Server


Zinc Web Server Gear


* Fuel Serialization


Fuel Serialization Gear


* Glamorous Spotter [*]


Spotter Search Display
Spotter Search Gear


* etc.

[*] I particularly dislike "Glamorous" adjective.

In the case of wrapper for libraries I'm hesitant to decide whether to
indicate pharo name in it or not.
I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of
calling "Salty".


NaCl Adapter
Maybe "Salty NaCl Adapter" here, to be consistent with the previous ones 
of "Fancy Merit Type".

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

[Herbert Vojčík]

Esteban A. Maringolo wrote:

On 13/04/2018 10:41, p...@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.

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

[Esteban A. Maringolo]

On 13/04/2018 11:12, Sean P. DeNigris wrote:
> EstebanLM wrote
>> I dream with even more classes: Selector, Protocol (we already have it,
>> but we need to use it), etc., etc., etc.
>> I will always prefer a class that defines a concept than a non-reified
>> usage of generic classes.

"Objects all the way down".

Most problems surge from the lack of proper abstractions.

-- 
Esteban A. Maringolo

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

[Sean P. DeNigris]

EstebanLM wrote
> I dream with even more classes: Selector, Protocol (we already have it,
> but we need to use it), etc., etc., etc.
> I will always prefer a class that defines a concept than a non-reified
> usage of generic classes.

Yes!!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Esteban A. Maringolo]

On 13/04/2018 10:41, p...@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

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

[Sean P. DeNigris]

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

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

[p...@highoctane.be]

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  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  wrote:
>
> On Fri, Apr 13, 2018 at 2:05 PM, 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,
>   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
>
>
>

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

[p...@highoctane.be]

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 
wrote:

> On 13 April 2018 at 11:04, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
> >>
> >> I consider Pharo 7 as a great piece of kit but unusable for my current
> work. There are many new things to learn in there. When is too much too
> much? Also, simplifications are breaking things in unexpected ways (like
> the #atEnd thing).
> >
> > Phil,
> >
> > Nothing fundamental will break with #atEnd.
> >
> > What you are reading in pharo-dev is a constructive discussion that (for
> me at least) started with the desire to support one very special kind of
> stream (stdin in C terms), something 99.99% of Pharo users have never seen,
> used or heard of.
>
>
> Completely agree (despite one of my later messages to Sven being
> overly grumpy).  I've learnt a lot from this exchange.
>
> Cheers,
> Alistair
>
>
> > Zn streams have worked well and as expected for Pharo versions going
> back to 3, that won't change.
>
>
>

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

[Esteban Lorenzano]

> On 13 Apr 2018, at 14:47, Esteban A. Maringolo  wrote:
> 
> 
> 
> On 13/04/2018 09:39, Esteban Lorenzano wrote:
>> 
>> 
>>> On 13 Apr 2018, at 14:33, Andrew Glynn >> > 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
> 

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

[Esteban A. Maringolo]

On 13/04/2018 09:39, Esteban Lorenzano wrote:
> 
> 
>> On 13 Apr 2018, at 14:33, Andrew Glynn > > 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

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

[Andrew Glynn]

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  wrote:
> > On Fri, Apr 13, 2018 at 2:05 PM, 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,
> > >   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
> > 

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

[Esteban Lorenzano]

> On 13 Apr 2018, at 14:33, Andrew Glynn  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 > > 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,
>>>   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

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

[Andrew Glynn]

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

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

[Esteban A. Maringolo]

On 13/04/2018 09:18, Peter Uhnák wrote:
> On Fri, Apr 13, 2018 at 2:05 PM, 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,
>   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

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

[Denis Kudriashov]

2018-04-13 13:01 GMT+02:00 Marcus Denker :

>
>
> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> >
> >
> >
> >> On 13 Apr 2018, at 12:19, Joe Shirk  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
>
>
>

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

[Esteban A. Maringolo]

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,
>   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.

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

[Ben Coman]

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  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,
>   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  wrote:
>
>>
>>
>> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
>> >
>> >
>> >
>> >> On 13 Apr 2018, at 12:19, Joe Shirk  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
>>
>>
>>
>

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

[Peter Uhnák]

On Fri, Apr 13, 2018 at 2:05 PM, 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,
>   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

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

[Denis Kudriashov]

With new Traits we have some issues which we are slowly fixing. Nice thing
that fixes are quite simple and clean and covered by tests. I guess it was
not like that before.
So Pablo did very good job here.

For this concrete case with implementors there is already issue 21652
<https://pharo.fogbugz.com/f/cases/21652/Smalltalk-allClassesAndTraits-duplicates-all-traits>:
the method allClassesAndTraits includes traits twice.

2018-04-13 11:30 GMT+02:00 Marcus Denker <marcus.den...@inria.fr>:

>
>
> On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>
> *From: *Benoit St-Jean <bstj...@yahoo.com>
> *Subject: **Re: [Pharo-users] Where do we go now ?*
> *Date: *13 April 2018 at 11:26:09 CEST
> *To: *Esteban Lorenzano <esteba...@gmail.com>
> *Cc: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Reply-To: *Benoit St-Jean <bstj...@yahoo.com>
>
>
> BTW, why put an .exe installer for Windows available when it crashes right
> from the start? It just doesn't work at all.  Period.  For everyone.
>
> And I thought looking for senders of a method was something we mastered a
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume
> that everything, even basic functionalities, are all broken because it's
> labeled "alpha” ?
>
>
> We have already a issue tracker entry with a description of a fix:
>
> https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-
> wrong-behaviour-to-tagsForMethods
>
> TODO: turn that description into code and make a Pull Request.
>
> Marcus
>
>

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

[Richard O'Keefe]

There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
  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  wrote:

>
>
> > On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> >
> >
> >
> >> On 13 Apr 2018, at 12:19, Joe Shirk  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
>
>
>

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

[Marcus Denker]

> On 13 Apr 2018, at 12:40, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 12:19, Joe Shirk  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

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

[aglynn42]

Btw, in my fascination with messing around, the 32 bit version of Pharo 7 for 
Windows runs better on OS/2 v.5 (yes, it still exists, it was released last 
June).  Probably because its Win32 subsystem is more compatible with Win32 apps 
than Windows 10.

 

Andrew

 

From: Benoit St-Jean <bstj...@yahoo.com> 
Sent: Friday, April 13, 2018 5:26 AM
To: Esteban Lorenzano <esteba...@gmail.com>
Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Where do we go now ?

 

BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

 

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?

 

 

- 
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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
<esteba...@gmail.com <mailto:esteba...@gmail.com> > wrote: 

 

 

 





On 13 Apr 2018, at 11:07, Benoit St-Jean <bstj...@yahoo.com 
<mailto:bstj...@yahoo.com> > wrote:

 

I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

 

 

and btw… which part of ALPHA you do not get?

 

Esteban

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

[aglynn42]

Maybe I’m missing something, or maybe I’m not ‘everyone’, but I’ve only had a 
few problems with 32 bit Pharo 7 and Windows.  Btw Windows 10 “64 bit” is about 
as 64 bit as Windows 95 was 32 bit.  i.e. not very.  Most of the issues center 
around Moose, not the core Pharo.  But I’m only playing with Pharo 7, mainly on 
Linux where the latest image seems pretty stable.  My actual development is 
still on 61 (and in one case, 5.0 since it requires the old FFI).

 

M$ is supposed to fix the remains of 32 bit Windows next year, but we all know 
what ‘next year’ means to Microsoft, it’s forever ‘next year’.

 

As far as I understood, most of the development of Pharo 7 is focused on the 64 
bit version in any case.  What’s missing from 61 that you absolutely have to 
have ATM?  

 

Andrew

 

 

 

From: Benoit St-Jean <bstj...@yahoo.com> 
Sent: Friday, April 13, 2018 5:26 AM
To: Esteban Lorenzano <esteba...@gmail.com>
Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Where do we go now ?

 

BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

 

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?

 

 

- 
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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
<esteba...@gmail.com <mailto:esteba...@gmail.com> > wrote: 

 

 

 





On 13 Apr 2018, at 11:07, Benoit St-Jean <bstj...@yahoo.com 
<mailto:bstj...@yahoo.com> > wrote:

 

I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

 

 

and btw… which part of ALPHA you do not get?

 

Esteban

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

[Sven Van Caekenberghe]

> On 13 Apr 2018, at 12:19, Joe Shirk  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" 
>  wrote:
> 
> 
> -- Forwarded message --
> From: Benoit St-Jean 
> To: pharo-users@lists.pharo.org
> Cc: 
> Bcc: 
> Date: Fri, 13 Apr 2018 05:53:46 + (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 
> looong 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 
> looong 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 

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

[Joe Shirk]

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 
To: pharo-users@lists.pharo.org
Cc:
Bcc:
Date: Fri, 13 Apr 2018 05:53:46 + (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 looong 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 looong 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 

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

[Ben Coman]

On 13 April 2018 at 17:07, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: Any question about pharo is welcome <pharo-users@lists.pharo.org>,
> Esteban Lorenzano <esteba...@gmail.com>
> Cc:
> Bcc:
> Date: Fri, 13 Apr 2018 09:07:16 +0000 (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> "You cannot take an alpha version and expect production quality."
>
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>
>
> Can I at least expect to be able to save code in my local Monticello
> repository ? It bombs. I just reported a bug!
>
> Can I expect the Windows installer for Pharo Launcher to work on Windows?
> It doesn't : it crashes.
>

It works fine for me on Windows 10.
There were some issues that depended on how PharoLauncher was installed.

The installer (NSIS) being used at that time doesn't handle non-Admin
installs very well.
Prior to PharoLauncher being promoted as the main download, I guess people
on Windows
using PharoLauncher either ran it as Admin, or worked around it like me -
on Windows I
would just roll my own from a fresh Pharo 6 and the Project Catalog.

To be clear, the problem was heavily influenced by the constraints of an
external tool.
Get PharoLauncher installed in the right location and it works like a dream.
Did you try the proof-of-concept installer I posted previously to the
list...
http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi



>
> Can I expect Pharo Launcher (not installed from the .exe installer) to
> work on Windows?  It just doesn't. I get all kinds of error related to
> WindowsStore, bad UTF-8 encoding and other things... (see
> https://twitter.com/smalltalkdev/status/978973863332798464)
>

Yes most people can expect it works perfectly on Windows.  But as always it
depends.
There is always the chance something in your environment triggers a bug.
like maybe non-ascii characters in you username/path?



>
> Can I expect that when looking for implementors of a method things still
> work?  I get duplicates (see attached file).
>

Do you mean only the duplicate "Traited class >> isTrait" in your
screenshot?
I just tried this in "Pharo-7.0+alpha.build.762.sha.0e0fe47c5ccef"
by typing "isTrait" into the Playground, selecting it and pressing Ctrl-M,
and I don't get the duplicate.

Which build of Pharo are you using?


>
> Can I expect reading input from the console to work on Windows?  It
> doesn't.
>

Bit hard to understand your problem from that one-liner.


>
> Can I expect to be able to test my stuff on Windows?  That's kinda hard
> when Windows is always 6 months to 1 year behind VM-wise.
>
I'm not whining about the effort people put into this project : I'm mostly
> whining about duplication of effort and code and *very poor* Windows
> support...
>

AFAIK, Pharo 6.1 32-bit VM is up to date with the other platforms.
Regarding 64-bit Windows.  Yes it is behind.  The specific companies
interested in 64-bit Linux support put money on the table to get it done.
No one has stepped up to do the same for Windows 64-bit, so realistically
it lags behind.

btw, lately it gets harder to run 32-bit apps on Linux and OSX, but there
is no reason to stop using 32-bits VM on Windows.



>
> Can I expect to be able to contribute ?  That is kinda sad but all the
> cool scripts out there are .sh files.
>

huh?



> Just spend 2 weeks working with Pharo on Windows.  You can start with
> version 5.1 if you want and let me know how it goes...  Brace yourself, I'm
> telling you, you're off for a wild & unpleasant ride.
>

Its been a while since I worked with Pharo on Windows, but I've been using
it the last few weeks with no problems. Pharo 6.1 and Pharo 7.

cheers -ben

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
For those interested.
Created the issues 21686, 21693, 21695, 21696.
And more to come...



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

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

[Clément Bera]

"Alpha software can be unstable and could cause crashes or data loss" [1]

Experiencing instability, crashes and data loss in the alpha version of a
software, including Pharo alpha, is to be expected and nothing to be
surprised about. The support of the Pharo stable version (currently 6.1)
has significantly improved in the past year. Many fixes and enhancements
were back-ported from Pharo 7 to Pharo 6.1. Based on your comments, it
seems that you have issues because you are not using the version of Pharo
that fits your needs (i.e. the stable version).

Checking the Pharo website [2], it seems there are *no* download links to
the alpha version so far because it's not considered stable enough. Where
did you get a link to download Pharo 7 alpha ?

[1] https://en.wikipedia.org/wiki/Software_release_life_cycle
[2] https://pharo.org/download


On Fri, Apr 13, 2018 at 11:26 AM, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean <bstj...@yahoo.com>
> To: Esteban Lorenzano <esteba...@gmail.com>
> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Bcc:
> Date: Fri, 13 Apr 2018 09:26:09 + (UTC)
> Subject: Re: [Pharo-users] Where do we go now ?
> BTW, why put an .exe installer for Windows available when it crashes right
> from the start? It just doesn't work at all.  Period.  For everyone.
>
> And I thought looking for senders of a method was something we mastered a
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume
> that everything, even basic functionalities, are all broken because it's
> labeled "alpha" ?
>
>
> -
> 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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano <
> esteba...@gmail.com> wrote:
>
>
>
>
> On 13 Apr 2018, at 11:07, Benoit St-Jean <bstj...@yahoo.com> wrote:
>
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>
>
> and btw… which part of ALPHA you do not get?
>

> Esteban
>
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/

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

[Alistair Grant]

On 13 April 2018 at 11:04, Sven Van Caekenberghe  wrote:
>
>
>> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
>>
>> I consider Pharo 7 as a great piece of kit but unusable for my current work. 
>> There are many new things to learn in there. When is too much too much? 
>> Also, simplifications are breaking things in unexpected ways (like the 
>> #atEnd thing).
>
> Phil,
>
> Nothing fundamental will break with #atEnd.
>
> What you are reading in pharo-dev is a constructive discussion that (for me 
> at least) started with the desire to support one very special kind of stream 
> (stdin in C terms), something 99.99% of Pharo users have never seen, used or 
> heard of.


Completely agree (despite one of my later messages to Sven being
overly grumpy).  I've learnt a lot from this exchange.

Cheers,
Alistair


> Zn streams have worked well and as expected for Pharo versions going back to 
> 3, that won't change.

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

[Cyril Ferlicot D.]

On 13/04/2018 11:26, Benoit St-Jean via Pharo-users wrote:

Do you expect a cleaning of the Kernel without any break during alpha
version?

This version introduce a new message browser, new Traits, more
modularization of the kernel and some cleaning of the Kernel. I see a
lot of reason why it might break during the alpha version.

-- 
Cyril Ferlicot
https://ferlicot.fr

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

[Marcus Denker]

> On 13 Apr 2018, at 11:26, Benoit St-Jean via Pharo-users 
> <pharo-users@lists.pharo.org> wrote:
> 
> 
> From: Benoit St-Jean <bstj...@yahoo.com>
> Subject: Re: [Pharo-users] Where do we go now ?
> Date: 13 April 2018 at 11:26:09 CEST
> To: Esteban Lorenzano <esteba...@gmail.com>
> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>
> Reply-To: Benoit St-Jean <bstj...@yahoo.com>
> 
> 
> BTW, why put an .exe installer for Windows available when it crashes right 
> from the start? It just doesn't work at all.  Period.  For everyone.
> 
> And I thought looking for senders of a method was something we mastered a 
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
> everything, even basic functionalities, are all broken because it's labeled 
> "alpha” ?

We have already a issue tracker entry with a description of a fix:


https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-to-tagsForMethods
 
<https://pharo.fogbugz.com/f/cases/21518/New-Traits-brings-wrong-behaviour-to-tagsForMethods>

TODO: turn that description into code and make a Pull Request.

Marcus

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

[Esteban Lorenzano]

ok, you want to have the last word.
Go ahead. 
You have it.

What you do not have is my attention anymore.

cheers!
Esteban

> On 13 Apr 2018, at 11:26, Benoit St-Jean  wrote:
> 
> BTW, why put an .exe installer for Windows available when it crashes right 
> from the start? It just doesn't work at all.  Period.  For everyone.
> 
> And I thought looking for senders of a method was something we mastered a 
> long time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
> everything, even basic functionalities, are all broken because it's labeled 
> "alpha" ?
> 
> 
> - 
> 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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
>  wrote:
> 
> 
> 
> 
>> On 13 Apr 2018, at 11:07, Benoit St-Jean > > wrote:
>> 
>> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
>> 
> 
> and btw… which part of ALPHA you do not get?
> 
> Esteban

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
BTW, why put an .exe installer for Windows available when it crashes right from 
the start? It just doesn't work at all.  Period.  For everyone.

And I thought looking for senders of a method was something we mastered a long 
time ago, like starting with Smalltalk-76.  Am I supposed to assume that 
everything, even basic functionalities, are all broken because it's labeled 
"alpha" ?


- 
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 13, 2018, 5:20:28 a.m. EDT, Esteban Lorenzano 
 wrote:  
 
 


On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
I'm on Windows 10, using Pharo 7.0 alpha 32 bit.


and btw… which part of ALPHA you do not get?
Esteban  --- End Message ---

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

[Esteban Lorenzano]

> On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
> 
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
> 

and btw… which part of ALPHA you do not get?

Esteban

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

[Esteban Lorenzano]

Can I expect a PR to help?

I tell you again: That tone does not helps your case, please calm down.

Esteban

> On 13 Apr 2018, at 11:07, Benoit St-Jean  wrote:
> 
> "You cannot take an alpha version and expect production quality."
> 
> I'm on Windows 10, using Pharo 7.0 alpha 32 bit.
> 
> 
> Can I at least expect to be able to save code in my local Monticello 
> repository ? It bombs. I just reported a bug!
> 
> Can I expect the Windows installer for Pharo Launcher to work on Windows?  It 
> doesn't : it crashes.  
> 
> Can I expect Pharo Launcher (not installed from the .exe installer) to work 
> on Windows?  It just doesn't. I get all kinds of error related to 
> WindowsStore, bad UTF-8 encoding and other things... (see 
> https://twitter.com/smalltalkdev/status/978973863332798464 
> )
> 
> Can I expect that when looking for implementors of a method things still 
> work?  I get duplicates (see attached file).
> 
> Can I expect reading input from the console to work on Windows?  It doesn't.
> 
> Can I expect to be able to test my stuff on Windows?  That's kinda hard when 
> Windows is always 6 months to 1 year behind VM-wise.
> 
> Can I expect to be able to contribute ?  That is kinda sad but all the cool 
> scripts out there are .sh files.
> 
> I'm not whining about the effort people put into this project : I'm mostly 
> whining about duplication of effort and code and *very poor* Windows 
> support...
> 
> Just spend 2 weeks working with Pharo on Windows.  You can start with version 
> 5.1 if you want and let me know how it goes...  Brace yourself, I'm telling 
> you, you're off for a wild & unpleasant ride.
> 
> 
> 
> 
> 
> 
> - 
> 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)
> 

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

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
"You cannot take an alpha version and expect production quality."
I'm on Windows 10, using Pharo 7.0 alpha 32 bit.

Can I at least expect to be able to save code in my local Monticello repository 
? It bombs. I just reported a bug!
Can I expect the Windows installer for Pharo Launcher to work on Windows?  It 
doesn't : it crashes.  

Can I expect Pharo Launcher (not installed from the .exe installer) to work on 
Windows?  It just doesn't. I get all kinds of error related to WindowsStore, 
bad UTF-8 encoding and other things... (see 
https://twitter.com/smalltalkdev/status/978973863332798464)
Can I expect that when looking for implementors of a method things still work?  
I get duplicates (see attached file).
Can I expect reading input from the console to work on Windows?  It doesn't.
Can I expect to be able to test my stuff on Windows?  That's kinda hard when 
Windows is always 6 months to 1 year behind VM-wise.
Can I expect to be able to contribute ?  That is kinda sad but all the cool 
scripts out there are .sh files.

I'm not whining about the effort people put into this project : I'm mostly 
whining about duplication of effort and code and *very poor* Windows support...
Just spend 2 weeks working with Pharo on Windows.  You can start with version 
5.1 if you want and let me know how it goes...  Brace yourself, I'm telling 
you, you're off for a wild & unpleasant ride.






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

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

[Sven Van Caekenberghe]

> On 13 Apr 2018, at 08:43, p...@highoctane.be wrote:
> 
> I consider Pharo 7 as a great piece of kit but unusable for my current work. 
> There are many new things to learn in there. When is too much too much? Also, 
> simplifications are breaking things in unexpected ways (like the #atEnd 
> thing).

Phil,

Nothing fundamental will break with #atEnd.

What you are reading in pharo-dev is a constructive discussion that (for me at 
least) started with the desire to support one very special kind of stream 
(stdin in C terms), something 99.99% of Pharo users have never seen, used or 
heard of.

Zn streams have worked well and as expected for Pharo versions going back to 3, 
that won't change.

Sven

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

[Pavel Krivanek]

Moreover, we are increasing the system modularity so more classes in the
IDE does not mean that you need to have them all loaded.

-- Pavel

2018-04-13 10:39 GMT+02:00 Esteban Lorenzano :

> As a general note, I have to say that I find amusing how people are often
> annoyed about the growing size of the image and the amount of classes.
> We have an image that contains a full IDE which incorpores more and more
> modern capabilities. And you want that to stay small and fewer classes? I’m
> sorry but you are missing the point. More tools (or same tools enhanced)
> means more size and classes.
>
> Then… why the fear about classes? This is OOP. Doing classes is what we
> do.
> I prefer a new class to, for example passing same information into a
> dictionary.
> I prefer a new class over a string.
> I prefer a new class over a tuple.
>
> We now have slots instead symbols to express variables. 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.
>
> We need better ways to organise that information? YES! (For example I was
> thinking browser by default should not show “tool packages”, to reduce the
> amount of information).
>
> But I welcome more classes and less esoteric usages of existing ones,
> always.
>
> cheers,
> Esteban
>
> On 13 Apr 2018, at 10:30, Esteban Lorenzano  wrote:
>
>
>
> On 13 Apr 2018, at 10:25, Ben Coman  wrote:
>
> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>> Just a quick word to get some things straight because, quite frankly, I
>> really don't know where we're heading.
>>
>
>
>> Do we really need 8 delay schedulers (DelayMicrosecondScheduler,
>> DelayMillisecondScheduler, DelayNullScheduler,
>> DelayExperimentalSpinScheduler, DelaySpinScheduler,
>> DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
>> DelayExperimentalSemaphoreScheduler) ?
>>
>
> This should have been cleaned up a while ago.  Thanks for the bump.  I'll
> get to it.
> However note, that half of those have not more than two methods, so are
> not contributing much to the size of the Image.
>
>
> I didn’t know. Thanks :)
>
>
>
>> 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.
>>
>
> I guess you are looking for...
> https://github.com/pharo-project/pharo-workingRoadmaps/
> blob/master/Pharo7/ROADMAP.md
>
>
> cheers -ben
>
>
>
>
>
>

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

[Esteban Lorenzano]

> On 13 Apr 2018, at 10:31, Cyril Ferlicot D.  wrote:
> 
> On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote:
> 
> Hi,
> 
> I don't have time to answer to everything but I can give some details:
> 
> - Nautilus will be removed when Calypso will be really stable (During
> the Calypso development if calypso breaks, you need an other browser to
> replace it)
> - The old compiler will be removed as an external project
> (https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md)
> - I think it's planned to remove the EyeInspector
> - Kommiter and Versionner will also be removed in next versions of Pharo
> 
> "Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha
> has 7612 classes."
> 
> In general I do not like metrics in term of number of classes because I
> prefer a system with 7500 classes of 50 lines of code than a system of
> 6000 classes of 300 lines of codes.

amen!

> 
> "Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
> settings. Pharo 7.0 alpha has 662 preference settings."
> 
> The number of settings is not a bad thing if it's well organized. The
> current problem is not the number of settings, it's more their
> organization.
> 
> Have a nice day. :)
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

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

[Esteban Lorenzano]

As a general note, I have to say that I find amusing how people are often 
annoyed about the growing size of the image and the amount of classes.
We have an image that contains a full IDE which incorpores more and more modern 
capabilities. And you want that to stay small and fewer classes? I’m sorry but 
you are missing the point. More tools (or same tools enhanced) means more size 
and classes.

Then… why the fear about classes? This is OOP. Doing classes is what we do. 
I prefer a new class to, for example passing same information into a dictionary.
I prefer a new class over a string.
I prefer a new class over a tuple.

We now have slots instead symbols to express variables. 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.

We need better ways to organise that information? YES! (For example I was 
thinking browser by default should not show “tool packages”, to reduce the 
amount of information).

But I welcome more classes and less esoteric usages of existing ones, always.

cheers,
Esteban

> On 13 Apr 2018, at 10:30, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 10:25, Ben Coman > > wrote:
>> 
>> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users 
>> > wrote:
>> Just a quick word to get some things straight because, quite frankly, I 
>> really don't know where we're heading.
>>  
>> Do we really need 8 delay schedulers (DelayMicrosecondScheduler, 
>> DelayMillisecondScheduler, DelayNullScheduler, 
>> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
>> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? 
>> 
>> This should have been cleaned up a while ago.  Thanks for the bump.  I'll 
>> get to it.
>> However note, that half of those have not more than two methods, so are not 
>> contributing much to the size of the Image.
> 
> I didn’t know. Thanks :)
> 
>>  
>> 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.
>> 
>> I guess you are looking for...
>> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>>  
>> 
>> 
>> 
>> cheers -ben
>> 
>> 
>> 
> 

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

[Cyril Ferlicot D.]

On 13/04/2018 07:53, Benoit St-Jean via Pharo-users wrote:

Hi,

I don't have time to answer to everything but I can give some details:

- Nautilus will be removed when Calypso will be really stable (During
the Calypso development if calypso breaks, you need an other browser to
replace it)
- The old compiler will be removed as an external project
(https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md)
- I think it's planned to remove the EyeInspector
- Kommiter and Versionner will also be removed in next versions of Pharo

"Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha
has 7612 classes."

In general I do not like metrics in term of number of classes because I
prefer a system with 7500 classes of 50 lines of code than a system of
6000 classes of 300 lines of codes.

"Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
settings. Pharo 7.0 alpha has 662 preference settings."

The number of settings is not a bad thing if it's well organized. The
current problem is not the number of settings, it's more their
organization.

Have a nice day. :)

-- 
Cyril Ferlicot
https://ferlicot.fr

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

[Esteban Lorenzano]

> On 13 Apr 2018, at 10:25, Ben Coman  wrote:
> 
> On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users 
> > wrote:
> Just a quick word to get some things straight because, quite frankly, I 
> really don't know where we're heading.
>  
> Do we really need 8 delay schedulers (DelayMicrosecondScheduler, 
> DelayMillisecondScheduler, DelayNullScheduler, 
> DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, 
> DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ? 
> 
> This should have been cleaned up a while ago.  Thanks for the bump.  I'll get 
> to it.
> However note, that half of those have not more than two methods, so are not 
> contributing much to the size of the Image.

I didn’t know. Thanks :)

>  
> 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.
> 
> I guess you are looking for...
> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>  
> 
> 
> 
> cheers -ben
> 
> 
> 

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

[Esteban Lorenzano]

Hi,

> On 13 Apr 2018, at 07:53, Benoit St-Jean via Pharo-users 
>  wrote:
> 
> 
> From: Benoit St-Jean 
> Subject: Where do we go now ?
> Date: 13 April 2018 at 07:53:46 CEST
> To: pharo-users@lists.pharo.org
> Reply-To: Benoit St-Jean 
> 
> 
> 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 7.0 is a development version.
Before is releases most duplicated things you mention here will be gone: 

- Nautilus 
- Compiler
- EyeInspector

Workspace could be gone but we need a fallback in case the other more potent 
tools fail.
Schedulers are still necessary.

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

Pharo 5.1 didn’t have : 

- GTTools
- Iceberg
- Epicea
- and many others.

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

If you do not want we to remove classes, how do you want we to go “smaller" and 
cleaner?

> 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 
> looong time ago anyway!

Zodiac relies on Sockets, there is not duplication there.

> You have code that deals with dependencies, should you use the old dependents 
> mechanism or convert everything to announcements?

you got me here. 
but removing takes time… you are free to contribute with fixes :)

> 
> UI speaking, what framework should anyone use ?  Athens?  Something else?

yes, I think Athens should not be part of the image but a loadable package.

> 
> 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 
> looong time ago anyway! 

again, you are mixing pearls and apples here.
(and btw, there was a HUGE refactor of streams on P7)

> 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!” ?

The plan is continue improving slowly but steady… things takes time.

> 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 

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

[Ben Coman]

On 13 April 2018 at 13:53, Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

> Just a quick word to get some things straight because, quite frankly, I
> really don't know where we're heading.
>


> Do we really need 8 delay schedulers (DelayMicrosecondScheduler,
> DelayMillisecondScheduler, DelayNullScheduler,
> DelayExperimentalSpinScheduler, DelaySpinScheduler,
> DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
> DelayExperimentalSemaphoreScheduler) ?
>

This should have been cleaned up a while ago.  Thanks for the bump.  I'll
get to it.
However note, that half of those have not more than two methods, so are not
contributing much to the size of the Image.


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

I guess you are looking for...
https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md


cheers -ben

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

[p...@highoctane.be]

It is true that there are many things in there.

New tools have to be finished before the old ones can be removed (there was
a time where refactorings were not in Calypso).

But for a real project, one is settling for a version and a toolset.

I am not really keen to migrate Pharo projects from one version to another
and some deprecations seems rather gratuitous sometimes.

The world also moves forward and it shows in the image.

I think that Iceberg has swallowed a lot of bandwidth and as a result other
elements are in need of more love.

Pharo7 is unreleased yet. Some say something is great by version 10. 3
versions to go.

I consider Pharo 7 as a great piece of kit but unusable for my current
work. There are many new things to learn in there. When is too much too
much? Also, simplifications are breaking things in unexpected ways (like
the #atEnd thing).

I am glad 6.1 gets backports and new releases for sure.

Phil





On Fri, Apr 13, 2018, 07:53 Benoit St-Jean via Pharo-users <
pharo-users@lists.pharo.org> wrote:

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

[Pharo-users] Where do we go now ?

[Benoit St-Jean via Pharo-users]

--- Begin Message ---
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 looong 
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 
looong 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)--- End Message ---