In P7 scrpt variable to tmp when in debugger

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
110 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Richard O'Keefe
I was not talking about additional subsystems *for* Pharo,
but subsystems already *in* Pharo.  For example, when I
hover the mouse over "Epicea" in the leftmost browser
panel, there is a pop-up that explains what is otherwise
a rather opaque word.  But when I hover the mouse over
"Fuel", nothing happens.  "Grease" => pop-up, "Growl", no.
Actually there are three possibilities.  The third is that
there's no pop-up but if you click, there is a package
comment.


On 14 April 2018 at 00:18, Peter Uhnák <[hidden email]> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?

Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

EstebanLM
In reply to this post by Ben Coman


On 13 Apr 2018, at 14:23, Ben Coman <[hidden email]> 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.
where newcomers can add items for others to fill in.

this is part a debate Stef and I have since years. 
I think we need to put generic names to our tools: 

- System browser
- Source Version Control
- etc.

while Stef supports fantasy names: 

- Calypso
- Iceberg
- etc.

you know who won this debate ;)

but at least I would like to add an option for special menu to show what is suck tool.

cheers,
Esteban



cheers -ben

On 13 April 2018 at 20:05, Richard O'Keefe <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


On 13 April 2018 at 23:01, Marcus Denker <[hidden email]> wrote:


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





Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

aglynn42
In reply to this post by Peter Uhnak
I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do?  

Electron is as obscure as Phobos (although a phobia with web pages turned into desktop apps may be appropriate).

Andrew

On Fri, 2018-04-13 at 14:18 +0200, Peter Uhnák wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

EstebanLM


On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email]> wrote:

I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do?  

yes… but we actually have a problem there.
I would like to be able to add “tags" to tools, to be able to say: 

Calypso -> a class browser -> some more info
etc.

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 <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

aglynn42
In reply to this post by Richard O'Keefe
How many subsystems that do pretty much the same thing exist in Java?  Or Programmable Hyperlinked Pasta?  

Try this:  do a set of Moose queries on a largish Pharo subsystem, say GLORP, then do the same on EclipseLink, Toplink or Hibernate, either with or without the JPA interfaces.  

Even with the tools in Moose the Java frameworks make little to no sense compared to GLORP.  Neither do the names mean much other than Hibernate, which itself could be taken n different ways.  

And JavaScript, well, what can you say about a language with prototypes but no types to proto?

Most enterprise software is proof positive the Pastafarians are right - I've seen plenty of flying spaghetti monsters.

Andrew

On Sat, 2018-04-14 at 00:31 +1200, Richard O'Keefe wrote:
I was not talking about additional subsystems *for* Pharo,
but subsystems already *in* Pharo.  For example, when I
hover the mouse over "Epicea" in the leftmost browser
panel, there is a pop-up that explains what is otherwise
a rather opaque word.  But when I hover the mouse over
"Fuel", nothing happens.  "Grease" => pop-up, "Growl", no.
Actually there are three possibilities.  The third is that
there's no pop-up but if you click, there is a package
comment.


On 14 April 2018 at 00:18, Peter Uhnák <[hidden email]> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter


Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Esteban A. Maringolo
In reply to this post by EstebanLM


On 13/04/2018 09:39, Esteban Lorenzano wrote:

>
>
>> On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse
>> (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names
>> relate to what they do?  
>
> yes… but we actually have a problem there.
> I would like to be able to add “tags" to tools, to be able to say: 
>
> Calypso -> a class browser -> some more info
> etc.


But isn't that what the Catalog currently does?

Of course the catalog is not for a "package" (as in npm, apt, yum, etc).

Regards,

--
Esteban, the other one. :P

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

aglynn42
In reply to this post by EstebanLM
Agreed, just pointing out that other systems have similar issues, and do because it's not easy to do originally or to fix later on.  But I'm just a Pharo user, not a Pharo developer.  I'm leaning on the shoulders of much better developers.

It takes time to learn any system. I've spent 21 years programming Java and there's still plenty I don't know.  I've spent 16 years with Eclipse and the current version bears little resemblance to the original.  Rebasing all of Eclipse on OSGi was done in an incremental update,  between 3.3 and 3.4 if I remember correctly.

From the user perspective, at least the changes in Pharo provide more caveats, given they've taken place in full version changes with alpha versions preceding beta and stable versions.

Andrew

On Fri, 2018-04-13 at 14:39 +0200, Esteban Lorenzano wrote:


On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email]> wrote:

I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names relate to what they do?  

yes… but we actually have a problem there.
I would like to be able to add “tags" to tools, to be able to say: 

Calypso -> a class browser -> some more info
etc.

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 <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

EstebanLM
In reply to this post by Esteban A. Maringolo


> On 13 Apr 2018, at 14:47, Esteban A. Maringolo <[hidden email]> wrote:
>
>
>
> On 13/04/2018 09:39, Esteban Lorenzano wrote:
>>
>>
>>> On 13 Apr 2018, at 14:33, Andrew Glynn <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>> I find NPM as obscure as Pharo, honestly, and VA Smalltalk is worse
>>> (wth does abt or sst stand for?).  Grunt, Gulp, etc., how do the names
>>> relate to what they do?  
>>
>> yes… but we actually have a problem there.
>> I would like to be able to add “tags" to tools, to be able to say:
>>
>> Calypso -> a class browser -> some more info
>> etc.
>
>
> But isn't that what the Catalog currently does?

I’m talking about what is *inside* the image.

Esteban

>
> Of course the catalog is not for a "package" (as in npm, apt, yum, etc).
>
> Regards,
>
> --
> Esteban, the other one. :P
>


Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

philippeback
In reply to this post by alistairgrant
I am not complaining about these exchanges, which were interesting indeed.

Just that P7 is still in flux and not something I can use in some way for my projects.

No problem with that, just that I cannot afford using it in projects for clients, it is too much of a risk. So, I am not testing it as much as I'd like.
I have found that the real issues show up with cases I face in such projects.

Phil

On Fri, Apr 13, 2018 at 11:39 AM, Alistair Grant <[hidden email]> wrote:
On 13 April 2018 at 11:04, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 13 Apr 2018, at 08:43, [hidden email] 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.



Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

philippeback
In reply to this post by aglynn42
A somewhat unique name makes it easier to google for it (like Roassal Pharo, or DeepTraverser Pharo, or Zinc Pharo). 
These will give us hits that are relevant.

Try System Browser, Inspector...

And Apple has worked with NSObject and stuff like that without too much trouble (at a much larger scale for whatever XyzKit they released).
Ah, yes, they used the "Kit" suffix. Maybe can we have something like that with Pharo. Like SystemBrowserKit ( nah, too Appleish.

Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too bland), or SystemBrowserGear (why not), SystemBrowserRig (this one sounds cool actually)).

Now, I am back to liking the current naming.

Phil

On Fri, Apr 13, 2018 at 2:43 PM, Andrew Glynn <[hidden email]> wrote:
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 <[hidden email]> wrote:
On Fri, Apr 13, 2018 at 2:05 PM, Richard O'Keefe <[hidden email]> wrote:
There are a lot of subsystems in Pharo, and being a bear of
very little brain, I have a hard time relating Zinc, Calypso,
&c &c to, well, whatever they are.  I presume there is
somewhere a list of topic/name/PFX triples for guidance.
Can some kind soul tell me where it is?


Until we have mature package manager (similar to Cargo or npm), you have to use google.
On the bright side, with the move to git(hub), people are much more likely to actually describe what their project does, and maybe even a bit of documentation. This was almost non-existent with SmalltalkHub.

Peter



Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Sean P. DeNigris
Administrator
In reply to this post by EstebanLM
EstebanLM wrote
> I would like to be able to add “tags" to tools, to be able to say:
> Calypso -> a class browser -> some more info

Yes! That is what I was trying to get at in the other thread [1], but not
explaining very well. The thing is that this should be *the default view* of
the system for new users.

The left browser pane could have at least three views of the system:
- Packages
  - What we have now
  - Least generally important (really only matters for modularity when
you're adding code)
- Projects
  - What's been proposed because many packages could be collected under one
project node
  - Better than the above, but still falls prey to the problems being
mentioned (i.e. WTH is a Seashell/Coral/SandCastle/FishingPole - what are
they *for*)
- Purpose/Category/Tag
  - This was the function of the original System categories and what I think
Esteban is proposing. Of course in the browser and other tools the arrows
would flow differently: 'Browser' -> #(Calypso Nautilus) -> some more info

1.
http://forum.world.st/Why-can-t-we-use-in-protocol-for-package-extension-tp5073597p5073663.html



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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Esteban A. Maringolo
In reply to this post by philippeback
On 13/04/2018 10:41, [hidden email] wrote:

> A somewhat unique name makes it easier to google for it (like Roassal
> Pharo, or DeepTraverser Pharo, or Zinc Pharo). 
> These will give us hits that are relevant.
>
> Try System Browser, Inspector...
>
> And Apple has worked with NSObject and stuff like that without too much
> trouble (at a much larger scale for whatever XyzKit they released).
> Ah, yes, they used the "Kit" suffix. Maybe can we have something like
> that with Pharo. Like SystemBrowserKit ( nah, too Appleish.


But I prefer these names:
* Calypso System Browser
* Calypso Debugger
* Iceberg Source Control Management
* Zinc HTTP Client
* Zinc HTTP Server
* Fuel Serialization
* Glamorous Spotter [*]
* etc.

[*] I particularly dislike "Glamorous" adjective.

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


> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too
> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one
> sounds cool actually)).

Fortunately in the past the lack of namespaces caused the use of
prefixes instead of suffixes.

With time prefixes become invisible.

A suffix, instead, will get into all your names, bothering with other
existing suffixes like `Component`, `Model`, `Collection`, and so on.







--
Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

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

Yes!!!



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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Herby Vojčík
In reply to this post by Esteban A. Maringolo


Esteban A. Maringolo wrote:
> On 13/04/2018 10:41, [hidden email] wrote:
>> A somewhat unique name makes it easier to google for it (like Roassal
>> Pharo, or DeepTraverser Pharo, or Zinc Pharo).
>> These will give us hits that are relevant.
>>
>> Try System Browser, Inspector...

Just a bit of a bikeshedding here:

> But I prefer these names:
> * Calypso System Browser

Calypso Browser Display

> * Calypso Debugger

Calypso Debugger Display
Calypso Debugger Gear

> * Iceberg Source Control Management\

Iceberg SCM Display
Iceberg SCM Gear

> * Zinc HTTP Client

Zinc Web Client Gear

> * Zinc HTTP Server

Zinc Web Server Gear

> * Fuel Serialization

Fuel Serialization Gear

> * Glamorous Spotter [*]

Spotter Search Display
Spotter Search Gear

> * etc.
>
> [*] I particularly dislike "Glamorous" adjective.
>
> In the case of wrapper for libraries I'm hesitant to decide whether to
> indicate pharo name in it or not.
> I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of
> calling "Salty".

NaCl Adapter

Ending with "... Display", "... Gear" and "... Adapter" high-level
categorization. Question, is separation of UI and underlying machinery
always possible.

>> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too
>> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one
>> sounds cool actually)).
>
> Fortunately in the past the lack of namespaces caused the use of
> prefixes instead of suffixes.
>
> With time prefixes become invisible.
>
> A suffix, instead, will get into all your names, bothering with other
> existing suffixes like `Component`, `Model`, `Collection`, and so on.

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

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


Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

HilaireFernandes
In reply to this post by Pharo Smalltalk Users mailing list
Sometime Pharo frustrate me a lot, I felt it too in the message from
Benoit, in the other hand its community is very kind and always helpful.
So it is not about blaming people.

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

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

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

Hilaire

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



Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

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

Stef

On Fri, Apr 13, 2018 at 7:53 AM, Benoit St-Jean via Pharo-users
<[hidden email]> wrote:

>
>
> ---------- Forwarded message ----------
> From: Benoit St-Jean <[hidden email]>
> To: [hidden email]
> Cc:
> Bcc:
> Date: Fri, 13 Apr 2018 05:53:46 +0000 (UTC)
> Subject: Where do we go now ?
> Hello guys,
>
> Just a quick word to get some things straight because, quite frankly, I really don't know where we're heading.
>
> When Pharo started, the goal was to depart from Squeak and do a *major clean up* of all the code, especially Morphic.  The promise of a new, clean & lean Smalltalk attracted a lot of people.  And then...
>
> I'm looking at the Pharo 7.0 image right now and I just don't get where we're heading.  Every Pharo release gets bigger, and bigger, and bigger.  I don't mind the environment getting bigger if it adds functionalities or new tools but that's not quite the case here. LOTS of stuff is just duplicated.
>
> Do we really need 2 code completion classes (NECController, NOCController) ?  Do we really need 2 system browsers (Nautilus, Calypso)? Do we really need 2 compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler, DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler, DelayTicklessScheduler, DelayExperimentalCourageousScheduler, DelayExperimentalSemaphoreScheduler) ?  Do we really need 2 inspectors (GTInspector, EyeInspector) ?  Do we really need 2 workspaces (GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.  I could go on, and on, and on...
>
> Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has 7612 classes.  Can you see a trend?
>
> Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference settings. Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?
>
> Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0 alpha has a 47.97 MB image.  Can you see a trend?
>
> Add to that the fact that Pharo is a nightmare when you want to port code.  Just with the 7.0 release, 61 classes will be deprecated (and lots more to come if you search for the string "deprecated" into the code, most of the time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess classes).
>
> You have code that deals with sockets, should you use the old Socket classes or convert everything to Zodiac? And why do we keep both "frameworks" in the image ?  Pharo hasn't been backward compatible with "old socket classes" a looooooong time ago anyway!
>
> You have code that deals with dependencies, should you use the old dependents mechanism or convert everything to announcements?
>
> UI speaking, what framework should anyone use ?  Athens?  Something else?
>
> You have code that deals with streams, should you use the old stream classes or convert everything to Zinc ? And why do we keep both "frameworks" in the image ?  Pharo hasn't been backward compatible with the old stream classes a looooooong time ago anyway!
>
> So what's the plan?  For instance, should I keep using the Nautilus Browser or I should switch to the Calypso browser and get used to it because Nautilus will be deprecated?  Or should I just don't care because a third system browser will be added in Pharo 8 just because "it's cool, let's add this one too!" ?
>
> Couldn't we just decide on what's "official" and what's a goodie or an external optional tool/package/framework the same way all other Smalltalks do?  If you say Calypso is the official & supported browser, fine!  Then just get Nautilus out of the image, create a nice loadable package for it and if someone prefers Nautilus, they'll just have to load it into the image, the same way VW has a gazillion optional tools/packages/frameworks you can load from a parcel!
>
> Whenever I get asked a simple question by a newbie like "Oh, which system browser should I use?", quite frankly, I don't know what to answer.  Did we include Calypso to deprecate Nautilus later?  Is Calypso just a proof of concept?  Is it just an optional tool?  What about all those delay schedulers?
>
> "I loaded this code from SqueakSource and it just doesn't work".  Should I help the guy to fix it or just tell him to convert all the code to the corresponding framework in Pharo?
>
> Perhaps a little bit of clarity and details about what's coming and what's the plan would be beneficial to a lot of us.
>
>
> -----------------
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>

Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

Richard Sargent
Administrator
In reply to this post by HilaireFernandes
On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <[hidden email]> wrote:
Sometime Pharo frustrate me a lot, I felt it too in the message from Benoit, in the other hand its community is very kind and always helpful. So it is not about blaming people.

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




Reply | Threaded
Open this post in threaded view
|

Re: Where do we go now ?

HilaireFernandes
In reply to this post by Stephane Ducasse-3
Le 13/04/2018 à 19:49, Stephane Ducasse a écrit :
> We know where we go (we have a roadmap) and this is always the same
> and we are getting there. Tell me one smalltalk that is bootstrapped.
I don't see we are there yet. At least from my humble point of view the
bootstrap still looks like WIP.


Hilaire

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



123456