Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

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

Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Ben Coman
On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*,

The default position would be leveraging someone else's experience, so this begs the question, what is wrong in namespace implementations in VW, Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, SmalltalkX, other languages)
Are there been any research papers around comparing these?  

I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's commercial future.  So a naive approach would be to do namespaces just like Gemstone.  Maybe its not the best, but would it be "good enough" -- perfection being the enemy of done and all that jazz.   

cheers -ben
 
and 2) where they fall on the endless prioritized todo list
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
Personally I dont get it, we find the path to bootstrap the pharo image clear and we cannot see the path to namespaces ? 

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the introduction of modules(in future version) in replacement (not removal) of his awful header file format.... I think we got the excuse to be confident we can come up with something decent. 

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next version, and no it cannot be an individual our outside effort. But we have the community super qualified to do it. 

On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <[hidden email]> wrote:
On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*,

The default position would be leveraging someone else's experience, so this begs the question, what is wrong in namespace implementations in VW, Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, SmalltalkX, other languages)
Are there been any research papers around comparing these?  

I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's commercial future.  So a naive approach would be to do namespaces just like Gemstone.  Maybe its not the best, but would it be "good enough" -- perfection being the enemy of done and all that jazz.   

cheers -ben
 
and 2) where they fall on the endless prioritized todo list
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Thierry Goubier
Hi Kilon,

disclaimer: I've used Parcplace Smalltlk without namespaces, then VisualWorks with namespaces.

2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Personally I dont get it, we find the path to bootstrap the pharo image clear and we cannot see the path to namespaces ?

Because namespaces, by essence, come with serious issues. I won't take someone seriously on namespaces until he can cite those faithfully.
 

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the introduction of modules(in future version) in replacement (not removal) of his awful header file format.... I think we got the excuse to be confident we can come up with something decent. 

C++ is about adding incidental complexity to the development process, i.e. how to make something complex where it could be done in a simpler way.

So I'd be very wary of any innovation coming from that direction.
 

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next version, and no it cannot be an individual our outside effort. But we have the community super qualified to do it. 

And qualified enough maybe to also see it doesn't make that much of sense.

Please remember that the design of a programming language consists not just in a laundry list of features, but also in making judicious choices of what to *omit* and, more importantly, in establishing design principles that are easy to understand [Steele, 2003]
 
Thierry


On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <[hidden email]> wrote:
On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*,

The default position would be leveraging someone else's experience, so this begs the question, what is wrong in namespace implementations in VW, Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, SmalltalkX, other languages)
Are there been any research papers around comparing these?  

I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's commercial future.  So a naive approach would be to do namespaces just like Gemstone.  Maybe its not the best, but would it be "good enough" -- perfection being the enemy of done and all that jazz.   

cheers -ben
 
and 2) where they fall on the endless prioritized todo list

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

As much I hate C++ , no I will have to disagree with your there, bad language design sure, but many of the "bad design" choices they make are based on the fact that this is a pure performance orientated language. Oh and we still wait for the real C++ alternative. Rust people claim they are close, D people claim they are close, everyone claims its very close, but still no alternative. Well I dont count C becaue its not OO, even if you claim C++ an abomination of OOP. I can guarantee that the dude that will come up with a language as fast as C++ and much better design he is going to make a fortune. In the mean time , those that have to use C++ will continue to use C++ and wait for the extemely remote competition to catch up. In the mean time C++ is the undisputed king in its speciality. 

Unfortunately coming up with a top performance language is a lot more than language design, live coding and OOP. Took ages for C and C++ to get to the level of optimisation they are nowdays. That's no easy feat even if you or I dont find interesting. 

So yes the modules that C++ will come up with, will be as ugly as hell, templates that suppose to be there as an alternative to dynamic typing etc are ugly as hell, but I dont see much protest in getting them removed. And there cases you cannot even use these "improvements" because ... well performance issues. While other languages worry how many times slower they are compared to C++, C++ worries about how much percentage of performance it loses with each added feature. C++ exits in a diffirent universe than the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one. 

On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <[hidden email]> wrote:
Hi Kilon,

disclaimer: I've used Parcplace Smalltlk without namespaces, then VisualWorks with namespaces.

2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Personally I dont get it, we find the path to bootstrap the pharo image clear and we cannot see the path to namespaces ?

Because namespaces, by essence, come with serious issues. I won't take someone seriously on namespaces until he can cite those faithfully.
 

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the introduction of modules(in future version) in replacement (not removal) of his awful header file format.... I think we got the excuse to be confident we can come up with something decent. 

C++ is about adding incidental complexity to the development process, i.e. how to make something complex where it could be done in a simpler way.

So I'd be very wary of any innovation coming from that direction.
 

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next version, and no it cannot be an individual our outside effort. But we have the community super qualified to do it. 

And qualified enough maybe to also see it doesn't make that much of sense.

Please remember that the design of a programming language consists not just in a laundry list of features, but also in making judicious choices of what to *omit* and, more importantly, in establishing design principles that are easy to understand [Steele, 2003]
 
Thierry


On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <[hidden email]> wrote:
On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*,

The default position would be leveraging someone else's experience, so this begs the question, what is wrong in namespace implementations in VW, Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, SmalltalkX, other languages)
Are there been any research papers around comparing these?  

I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's commercial future.  So a naive approach would be to do namespaces just like Gemstone.  Maybe its not the best, but would it be "good enough" -- perfection being the enemy of done and all that jazz.   

cheers -ben
 
and 2) where they fall on the endless prioritized todo list
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Stephan Eggermont-3
In reply to this post by Thierry Goubier
On 13-10-17 09:55, Thierry Goubier wrote:
> Because namespaces, by essence, come with serious issues. I won't take
> someone seriously on namespaces until he can cite those faithfully.

Let's start with the misconception that namespaces are about modularisation

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Thierry Goubier
In reply to this post by kilon.alios


2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <[hidden email]>:
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

I told you. Namespaces are a solution, but they come with issues.
 

As much I hate C++ , no I will have to disagree with your there, bad language design sure, but many of the "bad design" choices they make are based on the fact that this is a pure performance orientated language. Oh and we still wait for the real C++ alternative. Rust people claim they are close, D people claim they are close, everyone claims its very close, but still no alternative. Well I dont count C becaue its not OO, even if you claim C++ an abomination of OOP. I can guarantee that the dude that will come up with a language as fast as C++ and much better design he is going to make a fortune. In the mean time , those that have to use C++ will continue to use C++ and wait for the extemely remote competition to catch up. In the mean time C++ is the undisputed king in its speciality. 

No. In the HPC world, a common held position is that Fortran code is 30% faster than C++.

Remember that part of my job is to write compilers.

I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages.
 

Unfortunately coming up with a top performance language is a lot more than language design, live coding and OOP. Took ages for C and C++ to get to the level of optimisation they are nowdays. That's no easy feat even if you or I dont find interesting. 

I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place.
 

So yes the modules that C++ will come up with, will be as ugly as hell, templates that suppose to be there as an alternative to dynamic typing etc are ugly as hell, but I dont see much protest in getting them removed. And there cases you cannot even use these "improvements" because ... well performance issues. While other languages worry how many times slower they are compared to C++, C++ worries about how much percentage of performance it loses with each added feature. C++ exits in a diffirent universe than the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one. 

As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say).

Thierry
 

On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <[hidden email]> wrote:
Hi Kilon,

disclaimer: I've used Parcplace Smalltlk without namespaces, then VisualWorks with namespaces.

2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <[hidden email]>:
Personally I dont get it, we find the path to bootstrap the pharo image clear and we cannot see the path to namespaces ?

Because namespaces, by essence, come with serious issues. I won't take someone seriously on namespaces until he can cite those faithfully.
 

it makes zero sense to me

Plus what you say, countless and countless of implementation of namespaces out there. And again what you say about perfection.

If C++ can improve, If C++ can dream of namespaces planning the introduction of modules(in future version) in replacement (not removal) of his awful header file format.... I think we got the excuse to be confident we can come up with something decent. 

C++ is about adding incidental complexity to the development process, i.e. how to make something complex where it could be done in a simpler way.

So I'd be very wary of any innovation coming from that direction.
 

We develop a freaking IDE for crying out loud.

No it wont be a walk in the park, no it wont get done in one or next version, and no it cannot be an individual our outside effort. But we have the community super qualified to do it. 

And qualified enough maybe to also see it doesn't make that much of sense.

Please remember that the design of a programming language consists not just in a laundry list of features, but also in making judicious choices of what to *omit* and, more importantly, in establishing design principles that are easy to understand [Steele, 2003]
 
Thierry


On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <[hidden email]> wrote:
On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*,

The default position would be leveraging someone else's experience, so this begs the question, what is wrong in namespace implementations in VW, Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, SmalltalkX, other languages)
Are there been any research papers around comparing these?  

I found the "Pharo on Gemstone VM" talk impressive.  The "develop on Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's commercial future.  So a naive approach would be to do namespaces just like Gemstone.  Maybe its not the best, but would it be "good enough" -- perfection being the enemy of done and all that jazz.   

cheers -ben
 
and 2) where they fall on the endless prioritized todo list

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

NorbertHartl
In reply to this post by Stephan Eggermont-3

> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>
> On 13-10-17 09:55, Thierry Goubier wrote:
>> Because namespaces, by essence, come with serious issues. I won't take
>> someone seriously on namespaces until he can cite those faithfully.
>
> Let's start with the misconception that namespaces are about modularisation
>
+1

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
In reply to this post by Stephan Eggermont-3
"Let's start with the misconception that namespaces are about modularisation

Stephan "

  Well I can only for speak for Python because is where I used  namespaces the most and the language I am most experienced with. Namespaces in python are merely objects that come with a collection of method speciallised in the handling of source code files , individuals and in collection with all the objects contained in them , cause everything in python apart from the core synstax are object.

Last time I checked, objects even in Pharo are abour modularistation so it stands to reason that at least in Python namespaces are too.

Maybe your refer to something else ?
Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
In reply to this post by Thierry Goubier


On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <[hidden email]> wrote:
2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <[hidden email]>:
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

I told you. Namespaces are a solution, but they come with issues.
 

Then I misunderstood you but I am geniouly interested in what those problems are and I think the infromation is something others will find interesting as well. 

No. In the HPC world, a common held position is that Fortran code is 30% faster than C++.

Cannot even rememeber the last time a 3d graphics developers mentioned Fortran.I occasional frequent forums and mailing lists plus keeping in contact with Blender developers. 

I have heard that Fortran can outperform C++ in numeric computation around the percentage you mentioned but first time I heard that its generally faster.   

Language Benchmark seems to strongly disagree


of its widely criticized but then what benchmark is not
 
Remember that part of my job is to write compilers.


I knew that you write compilers (SmaCC) I did not realise you are a pro and especially on ones that generate highly optimised machine code
 
I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages.

On other hand I have close to zero experience on compilers 
 . 
 
I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place.

I lost you there, you mean compilers for other languages than C++ ? 

As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say).

Thierry
 

And I "work" in a world that C++ is the undisputed king , that's 3d graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design language , should be possible in Pharo and easier. Not ease, just easier. 

Of course that's just a wild assumption but I hope this thread do not only disaprove my assumption but said a light in the real challanges of namespace implementation

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
to be more specific what I mean because apparently I may know nothing about namespaces , I was talking in terms of Python's module and package system

even though python uses special syntax "import" to import a module, a source file, the real functionality is actually a method but of an object dealing with the handling of modules and packages , packages are basically file directories containing mutliple modules

as soon as you do the import the syntax is the usual object syntax

so 

Dog.bark() 

can be anything
1) A class method call, Dog being the class
2) A instance method call, Dog being the instance
3) or a function call, Dog being the function , which is also an object (methods in python are basically function object taking the reference to an instance as first argument, hence why the weird syntax of adding self as first argument when we define instance method) and Dog is the module imported. 

of course in case (3) you can collapse the module "name" so you can do only bark() if you import via "from Dog import *" which means from module Dog import every object. 
But from import is frown upon in the python world because obviously it makes it easier to have name collision which is what the module system try to avoid in the first place.

So the equivelant of pharo would be

MyModule MyInstance myMessage: 

or if you include packages as well

MyPackage MyModule MyInstance myMessage:

which follows pharo syntax and OO design. That's my general idea at least.

Please enlighten me :)

On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <[hidden email]> wrote:
On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <[hidden email]> wrote:
2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <[hidden email]>:
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

I told you. Namespaces are a solution, but they come with issues.
 

Then I misunderstood you but I am geniouly interested in what those problems are and I think the infromation is something others will find interesting as well. 

No. In the HPC world, a common held position is that Fortran code is 30% faster than C++.

Cannot even rememeber the last time a 3d graphics developers mentioned Fortran.I occasional frequent forums and mailing lists plus keeping in contact with Blender developers. 

I have heard that Fortran can outperform C++ in numeric computation around the percentage you mentioned but first time I heard that its generally faster.   

Language Benchmark seems to strongly disagree


of its widely criticized but then what benchmark is not
 
Remember that part of my job is to write compilers.


I knew that you write compilers (SmaCC) I did not realise you are a pro and especially on ones that generate highly optimised machine code
 
I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages.

On other hand I have close to zero experience on compilers 
 . 
 
I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place.

I lost you there, you mean compilers for other languages than C++ ? 

As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say).

Thierry
 

And I "work" in a world that C++ is the undisputed king , that's 3d graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design language , should be possible in Pharo and easier. Not ease, just easier. 

Of course that's just a wild assumption but I hope this thread do not only disaprove my assumption but said a light in the real challanges of namespace implementation

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Thierry Goubier
Hi Kilon,

then the discussion is a bit different. As your example points out, the syntax is already there, but the notion of a module is still open and ties into the package management.

I've played a bit with Metacello to have a working "project" concept synchronized with Metacello, and I could imagine providing module like objects (the baseline itself?) giving access to more generic names instead of the internal, prefixed ones.

One suggestion maybe: what about trying it for yourself with one of your projects? With a kind of overall class which has the name of the module, and automatically adding methods to it (or a #doesNotUnderstand: that handles those) for all the classes in the module, removing from the class name the prefix? It would allow an experiment, to see how the code looks like and if it is understandable, or if a special syntax is necessary.

Thierry


2017-10-13 11:51 GMT+02:00 Dimitris Chloupis <[hidden email]>:
to be more specific what I mean because apparently I may know nothing about namespaces , I was talking in terms of Python's module and package system

even though python uses special syntax "import" to import a module, a source file, the real functionality is actually a method but of an object dealing with the handling of modules and packages , packages are basically file directories containing mutliple modules

as soon as you do the import the syntax is the usual object syntax

so 

Dog.bark() 

can be anything
1) A class method call, Dog being the class
2) A instance method call, Dog being the instance
3) or a function call, Dog being the function , which is also an object (methods in python are basically function object taking the reference to an instance as first argument, hence why the weird syntax of adding self as first argument when we define instance method) and Dog is the module imported. 

of course in case (3) you can collapse the module "name" so you can do only bark() if you import via "from Dog import *" which means from module Dog import every object. 
But from import is frown upon in the python world because obviously it makes it easier to have name collision which is what the module system try to avoid in the first place.

So the equivelant of pharo would be

MyModule MyInstance myMessage: 

or if you include packages as well

MyPackage MyModule MyInstance myMessage:

which follows pharo syntax and OO design. That's my general idea at least.

Please enlighten me :)

On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <[hidden email]> wrote:
On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <[hidden email]> wrote:
2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <[hidden email]>:
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

I told you. Namespaces are a solution, but they come with issues.
 

Then I misunderstood you but I am geniouly interested in what those problems are and I think the infromation is something others will find interesting as well. 

No. In the HPC world, a common held position is that Fortran code is 30% faster than C++.

Cannot even rememeber the last time a 3d graphics developers mentioned Fortran.I occasional frequent forums and mailing lists plus keeping in contact with Blender developers. 

I have heard that Fortran can outperform C++ in numeric computation around the percentage you mentioned but first time I heard that its generally faster.   

Language Benchmark seems to strongly disagree


of its widely criticized but then what benchmark is not
 
Remember that part of my job is to write compilers.


I knew that you write compilers (SmaCC) I did not realise you are a pro and especially on ones that generate highly optimised machine code
 
I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages.

On other hand I have close to zero experience on compilers 
 . 
 
I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place.

I lost you there, you mean compilers for other languages than C++ ? 

As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say).

Thierry
 

And I "work" in a world that C++ is the undisputed king , that's 3d graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design language , should be possible in Pharo and easier. Not ease, just easier. 

Of course that's just a wild assumption but I hope this thread do not only disaprove my assumption but said a light in the real challanges of namespace implementation


Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
I am against the very idea of special syntax. Even python uses special syntax as nothing more than syntactic sugar to make the code more readable from the point of view of not everything looking the same. I agree with the concept of everything being an Object. 

I also dont like the idea that we tend to not have a clear cut border between the IDE and the language/library. Of course I think IDE functionality as much as namespaces is concerned (within the borders of my understanding) is essential. But should be seperate and the IDE act mostly as a visualisation tool and automation tool. 

My problem , is that the Pharo operates on a global space , so lets say i do what I said above I still dont avoid name collisions. Because MyInstance outside MyModule should diffirent from MyInstance inside MyModule. 

It could become possible by masking the names from the user. 

So that there is no conflict between 

MyModule MyInstance 
and
MyModule2 MyInstance

unless you introduce of couse similar to python the optional feature of collapsing the scope. 

We already have Packages which tie in with Metacello, so I was think about Modules or however we want to call them as a layer between. I am fine with metacello personally. Its the name collisions that only concerns me and not forcing me to use unique names. Of course a module can contain other modules. 

I know how to do this for my projects , I would manipulate the IDE into displaying Modules as a seperate row in System Browswer , Packages will continue being the the up most container. And for name of a class I would add the name of the Module to the class , if I wanted to keep supporting the existing enviroment , but hack it so it appears to the user as 2 seperate things

so for user will see

MyModule MyInsance myMessage:

 but it  Would be for the system
MyModuleMyInstance myMessage:

which would make sense from naming persepctive even to an outsider not using the module system and would not require for him to install the modue library
and essentially 

MyModule MyInstance 
act as you said via Message not understood as a reference to MyModuleMyInstance . A unary message returning a reference to an instance or class or other object.

of course you will have a class like ModuleGenerator to handle the technical details for you

Version control , dependencies and other technicallities would be handled normally as usually by Metacello with MyModule pointing also to the correct configuration , baseline, whatever. 

At least thats my general idea of it.  

On Fri, Oct 13, 2017 at 2:16 PM Thierry Goubier <[hidden email]> wrote:
Hi Kilon,

then the discussion is a bit different. As your example points out, the syntax is already there, but the notion of a module is still open and ties into the package management.

I've played a bit with Metacello to have a working "project" concept synchronized with Metacello, and I could imagine providing module like objects (the baseline itself?) giving access to more generic names instead of the internal, prefixed ones.

One suggestion maybe: what about trying it for yourself with one of your projects? With a kind of overall class which has the name of the module, and automatically adding methods to it (or a #doesNotUnderstand: that handles those) for all the classes in the module, removing from the class name the prefix? It would allow an experiment, to see how the code looks like and if it is understandable, or if a special syntax is necessary.

Thierry


2017-10-13 11:51 GMT+02:00 Dimitris Chloupis <[hidden email]>:
to be more specific what I mean because apparently I may know nothing about namespaces , I was talking in terms of Python's module and package system

even though python uses special syntax "import" to import a module, a source file, the real functionality is actually a method but of an object dealing with the handling of modules and packages , packages are basically file directories containing mutliple modules

as soon as you do the import the syntax is the usual object syntax

so 

Dog.bark() 

can be anything
1) A class method call, Dog being the class
2) A instance method call, Dog being the instance
3) or a function call, Dog being the function , which is also an object (methods in python are basically function object taking the reference to an instance as first argument, hence why the weird syntax of adding self as first argument when we define instance method) and Dog is the module imported. 

of course in case (3) you can collapse the module "name" so you can do only bark() if you import via "from Dog import *" which means from module Dog import every object. 
But from import is frown upon in the python world because obviously it makes it easier to have name collision which is what the module system try to avoid in the first place.

So the equivelant of pharo would be

MyModule MyInstance myMessage: 

or if you include packages as well

MyPackage MyModule MyInstance myMessage:

which follows pharo syntax and OO design. That's my general idea at least.

Please enlighten me :)

On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <[hidden email]> wrote:
On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier <[hidden email]> wrote:
2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <[hidden email]>:
fair enough you think namespaces are not the right solution, what you think is the right solution then ? 

I told you. Namespaces are a solution, but they come with issues.
 

Then I misunderstood you but I am geniouly interested in what those problems are and I think the infromation is something others will find interesting as well. 

No. In the HPC world, a common held position is that Fortran code is 30% faster than C++.

Cannot even rememeber the last time a 3d graphics developers mentioned Fortran.I occasional frequent forums and mailing lists plus keeping in contact with Blender developers. 

I have heard that Fortran can outperform C++ in numeric computation around the percentage you mentioned but first time I heard that its generally faster.   

Language Benchmark seems to strongly disagree


of its widely criticized but then what benchmark is not
 
Remember that part of my job is to write compilers.


I knew that you write compilers (SmaCC) I did not realise you are a pro and especially on ones that generate highly optimised machine code
 
I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages.

On other hand I have close to zero experience on compilers 
 . 
 
I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place.

I lost you there, you mean compilers for other languages than C++ ? 

As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say).

Thierry
 

And I "work" in a world that C++ is the undisputed king , that's 3d graphics , though I must admit I try to stick with Python as much as I can.

In any case my point was that if namespaces can be done in a badly design language , should be possible in Pharo and easier. Not ease, just easier. 

Of course that's just a wild assumption but I hope this thread do not only disaprove my assumption but said a light in the real challanges of namespace implementation


Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Esteban A. Maringolo
In reply to this post by NorbertHartl
2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:

>
>> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>>
>> On 13-10-17 09:55, Thierry Goubier wrote:
>>> Because namespaces, by essence, come with serious issues. I won't take
>>> someone seriously on namespaces until he can cite those faithfully.
>>
>> Let's start with the misconception that namespaces are about modularisation
>>
> +1

+1 to this as well.

Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.

I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.

If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)

Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.

Regards,

Esteban.

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

kilon.alios
Modularisation is coming whether you like it or not
its called 

Bootstrap 

And the more modular the image will get the more will get closer to namespaces anyway. So frankly all I have to do is wait and if I can of course contribute ;) 

You can call it Bootstrap or the Pink Elephant for all I care, in the end for me its about having multi layer system. That's all I care. 

But you wont get an argument from me the more about the fact that the more we wait the harder will get but again, I am not a Bootstrap contributor so I have no right to complain. I really admire those people :D  

Modularisation for personal project is super easy to do,if you do it from the start that is,  its the existing code that is a pain in the hat to modularise when until fairly recently even colors were hard coded into the IDE. 

On Fri, Oct 13, 2017 at 3:55 PM Esteban A. Maringolo <[hidden email]> wrote:
2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
>
>> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>>
>> On 13-10-17 09:55, Thierry Goubier wrote:
>>> Because namespaces, by essence, come with serious issues. I won't take
>>> someone seriously on namespaces until he can cite those faithfully.
>>
>> Let's start with the misconception that namespaces are about modularisation
>>
> +1

+1 to this as well.

Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.

I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.

If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)

Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.

Regards,

Esteban.

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Esteban A. Maringolo
You're mixing modularization, namespacing, packaging and parametrization.

If we're speaking about modules/namespaces I rather call them as such,
not Pink Elephant.
Having an agreement on the terms semantic is important for any communication.

To me a module is not a factorization for the bootstrap process nor
the proper packaging to enable partial loading, a module must be
reified as such.

The only Smalltalks I remember had something closer to a module were
VisualSmalltalk and maybe VisualWorks binary parcels can be thought as
modules, but strictly speaking none of them implement modules as such.
Only Modtalk tried to do that, but the project seems defunct now.

Regards,

Esteban A. Maringolo


2017-10-13 12:00 GMT-03:00 Dimitris Chloupis <[hidden email]>:

> Modularisation is coming whether you like it or not
> its called
>
> Bootstrap
>
> And the more modular the image will get the more will get closer to
> namespaces anyway. So frankly all I have to do is wait and if I can of
> course contribute ;)
>
> You can call it Bootstrap or the Pink Elephant for all I care, in the end
> for me its about having multi layer system. That's all I care.
>
> But you wont get an argument from me the more about the fact that the more
> we wait the harder will get but again, I am not a Bootstrap contributor so I
> have no right to complain. I really admire those people :D
>
> Modularisation for personal project is super easy to do,if you do it from
> the start that is,  its the existing code that is a pain in the hat to
> modularise when until fairly recently even colors were hard coded into the
> IDE.
>
> On Fri, Oct 13, 2017 at 3:55 PM Esteban A. Maringolo <[hidden email]>
> wrote:
>>
>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
>> >
>> >> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>> >>
>> >> On 13-10-17 09:55, Thierry Goubier wrote:
>> >>> Because namespaces, by essence, come with serious issues. I won't take
>> >>> someone seriously on namespaces until he can cite those faithfully.
>> >>
>> >> Let's start with the misconception that namespaces are about
>> >> modularisation
>> >>
>> > +1
>>
>> +1 to this as well.
>>
>> Having modularization is like having security, very hard to add them
>> later if you didn't include it in the original design.
>>
>> I'm using VisualWorks these days, and I find its namespaces something
>> more of a hassle than a real use.
>>
>> If we could name Classes with a dot, that could solve most of what
>> namespaces are used for in practice: avoiding name colissions.
>> That's why most of the popular frameworks have prefixes like Zn, WA,
>> RB, and so on and so forth. But now I'm used to prefixes, I don't need
>> them. :)
>>
>> Modularity is a different beast, if you look at how some modules work
>> in JS, like AMD, you see that in practice they avoid collisions by
>> importin what they need from a module, and assign it to a "namespace"
>> (it is not, but works as such), so they get modules first, and
>> namespacing later.
>>
>> Regards,
>>
>> Esteban.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Jimmie Houchin-5
In reply to this post by Esteban A. Maringolo
I watched this video a year ago and was intrigued. I have not thought
about it deeply and do not know consequences of this model. However,
Gilad is a smart man who has thought deeply about these things and has
experienced consequences as a language designer. But it does sound
interesting and I wonder if it would potentially be a solution to the
namespace or modularity problems.

https://youtu.be/pM0Hz4pFDZM

He is talking about Newspeak in 2016 and what I refer to is its use of
Nested Classes.

No Global Namespace
     No Global Variables
     No Pool Variables
     No Class Variables
     No Class Instance Variables

I have no idea if it would work for Pharo or what would be involved in
implementing such. Or even if the community or leaders would even care
to explore that direction. I have not seen it discussed here.

Just wanted to toss his discussion of these ideas into the arena of
ideas for Pharo.

Jimmie


On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:

> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
>>> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>>>
>>> On 13-10-17 09:55, Thierry Goubier wrote:
>>>> Because namespaces, by essence, come with serious issues. I won't take
>>>> someone seriously on namespaces until he can cite those faithfully.
>>> Let's start with the misconception that namespaces are about modularisation
>>>
>> +1
> +1 to this as well.
>
> Having modularization is like having security, very hard to add them
> later if you didn't include it in the original design.
>
> I'm using VisualWorks these days, and I find its namespaces something
> more of a hassle than a real use.
>
> If we could name Classes with a dot, that could solve most of what
> namespaces are used for in practice: avoiding name colissions.
> That's why most of the popular frameworks have prefixes like Zn, WA,
> RB, and so on and so forth. But now I'm used to prefixes, I don't need
> them. :)
>
> Modularity is a different beast, if you look at how some modules work
> in JS, like AMD, you see that in practice they avoid collisions by
> importin what they need from a module, and assign it to a "namespace"
> (it is not, but works as such), so they get modules first, and
> namespacing later.
>
> Regards,
>
> Esteban.
>


Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Ben Coman
btw, are you aware that Newspeak is developed on top of the CogVM that Pharo, Squeak, Cuis all share?
cheers -ben

On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <[hidden email]> wrote:
I watched this video a year ago and was intrigued. I have not thought about it deeply and do not know consequences of this model. However, Gilad is a smart man who has thought deeply about these things and has experienced consequences as a language designer. But it does sound interesting and I wonder if it would potentially be a solution to the namespace or modularity problems.

https://youtu.be/pM0Hz4pFDZM

He is talking about Newspeak in 2016 and what I refer to is its use of Nested Classes.

No Global Namespace
    No Global Variables
    No Pool Variables
    No Class Variables
    No Class Instance Variables

I have no idea if it would work for Pharo or what would be involved in implementing such. Or even if the community or leaders would even care to explore that direction. I have not seen it discussed here.

Just wanted to toss his discussion of these ideas into the arena of ideas for Pharo.

Jimmie



On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:
2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:

On 13-10-17 09:55, Thierry Goubier wrote:
Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.
Let's start with the misconception that namespaces are about modularisation

+1
+1 to this as well.

Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.

I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.

If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)

Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.

Regards,

Esteban.




Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Jimmie Houchin-5

Absolutely. I have contemplated giving it a try. But when I go look at the mailing list, it looks like such a lonely place. I still might give it a go. It looks interesting.

Jimmie


On 10/19/2017 05:20 PM, Ben Coman wrote:
btw, are you aware that Newspeak is developed on top of the CogVM that Pharo, Squeak, Cuis all share?
cheers -ben

On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <[hidden email]> wrote:
I watched this video a year ago and was intrigued. I have not thought about it deeply and do not know consequences of this model. However, Gilad is a smart man who has thought deeply about these things and has experienced consequences as a language designer. But it does sound interesting and I wonder if it would potentially be a solution to the namespace or modularity problems.

https://youtu.be/pM0Hz4pFDZM

He is talking about Newspeak in 2016 and what I refer to is its use of Nested Classes.

No Global Namespace
    No Global Variables
    No Pool Variables
    No Class Variables
    No Class Instance Variables

I have no idea if it would work for Pharo or what would be involved in implementing such. Or even if the community or leaders would even care to explore that direction. I have not seen it discussed here.

Just wanted to toss his discussion of these ideas into the arena of ideas for Pharo.

Jimmie



On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:
2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:

On 13-10-17 09:55, Thierry Goubier wrote:
Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.
Let's start with the misconception that namespaces are about modularisation

+1
+1 to this as well.

Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.

I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.

If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)

Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.

Regards,

Esteban.





Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Stephane Ducasse-3
For the record at ESUG at Prague there was a really interesting
discussion about namespace and some people working with newspeak
mentioned that the namesapce there was a hell. And I trust these
people. So good luck.

For the record we are working and we are making progress on module
system for Pharo but as I explained at ESUG this year. We do not want
just to have a namespace. We want a system that does not kill the live
programming experience.
Imagine you have two browsers opened:

   - in N3 one one you inherit from a class A import from N1
   - then in N1 you decide to move that class A to N2

   Should the system discard all the subclasses from A n N3 because it
cannot find anymore the class A?

This is why we are working on
 - during year we remove harcoded reference to Smalltalk
 - Undefined classes (read the IWST 2017 paper)
 - new class definition
 - model for class definition
 - real life programming supporting module system.

So each time I hear about namespace, I think that the best way to get
a namespace system for Pharo is to help doing something else.
This way we can concentrate on building a real working solution for
Pharo. But since we have many other things to do then it takes time.

Stef





On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <[hidden email]> wrote:

> Absolutely. I have contemplated giving it a try. But when I go look at the
> mailing list, it looks like such a lonely place. I still might give it a go.
> It looks interesting.
>
> Jimmie
>
>
> On 10/19/2017 05:20 PM, Ben Coman wrote:
>
> btw, are you aware that Newspeak is developed on top of the CogVM that
> Pharo, Squeak, Cuis all share?
> cheers -ben
>
> On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <[hidden email]>
> wrote:
>>
>> I watched this video a year ago and was intrigued. I have not thought
>> about it deeply and do not know consequences of this model. However, Gilad
>> is a smart man who has thought deeply about these things and has experienced
>> consequences as a language designer. But it does sound interesting and I
>> wonder if it would potentially be a solution to the namespace or modularity
>> problems.
>>
>> https://youtu.be/pM0Hz4pFDZM
>>
>> He is talking about Newspeak in 2016 and what I refer to is its use of
>> Nested Classes.
>>
>> No Global Namespace
>>     No Global Variables
>>     No Pool Variables
>>     No Class Variables
>>     No Class Instance Variables
>>
>> I have no idea if it would work for Pharo or what would be involved in
>> implementing such. Or even if the community or leaders would even care to
>> explore that direction. I have not seen it discussed here.
>>
>> Just wanted to toss his discussion of these ideas into the arena of ideas
>> for Pharo.
>>
>> Jimmie
>>
>>
>>
>> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:
>>>
>>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
>>>>>
>>>>> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>>>>>
>>>>> On 13-10-17 09:55, Thierry Goubier wrote:
>>>>>>
>>>>>> Because namespaces, by essence, come with serious issues. I won't take
>>>>>> someone seriously on namespaces until he can cite those faithfully.
>>>>>
>>>>> Let's start with the misconception that namespaces are about
>>>>> modularisation
>>>>>
>>>> +1
>>>
>>> +1 to this as well.
>>>
>>> Having modularization is like having security, very hard to add them
>>> later if you didn't include it in the original design.
>>>
>>> I'm using VisualWorks these days, and I find its namespaces something
>>> more of a hassle than a real use.
>>>
>>> If we could name Classes with a dot, that could solve most of what
>>> namespaces are used for in practice: avoiding name colissions.
>>> That's why most of the popular frameworks have prefixes like Zn, WA,
>>> RB, and so on and so forth. But now I'm used to prefixes, I don't need
>>> them. :)
>>>
>>> Modularity is a different beast, if you look at how some modules work
>>> in JS, like AMD, you see that in practice they avoid collisions by
>>> importin what they need from a module, and assign it to a "namespace"
>>> (it is not, but works as such), so they get modules first, and
>>> namespacing later.
>>>
>>> Regards,
>>>
>>> Esteban.
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

Jimmie Houchin-5
Thanks for the reply and for your explanation and Pharo's position on
this idea and on the subject of namespaces and modules. I was simply
offering a solution that was presented at Smalltalks conference.

My use of Pharo is in the small. I do not in general see or know the
problems associated with namespaces. I may see consequences in other
people's software I use in Pharo because of the naming of classes. But
it is them that dealt with the problem. I am very unqualified to comment
or address either of these issues. I just didn't know who had seen the
video and if it offered a solution or not. Thank you for engaging the
conversation so that we have a position on record regarding a publicly
available video which offers their view on a solution. You addressed one
of the things I do love about Pharo and its expressed goals is that it
seeks to offer real working solutions. I am okay that the hard things
take time, and am happy that they are being addressed even if it takes
some time. Pharo is shaping up very nicely.

Thanks.

Jimmie


On 10/20/2017 04:07 AM, Stephane Ducasse wrote:

> For the record at ESUG at Prague there was a really interesting
> discussion about namespace and some people working with newspeak
> mentioned that the namesapce there was a hell. And I trust these
> people. So good luck.
>
> For the record we are working and we are making progress on module
> system for Pharo but as I explained at ESUG this year. We do not want
> just to have a namespace. We want a system that does not kill the live
> programming experience.
> Imagine you have two browsers opened:
>
>     - in N3 one one you inherit from a class A import from N1
>     - then in N1 you decide to move that class A to N2
>
>     Should the system discard all the subclasses from A n N3 because it
> cannot find anymore the class A?
>
> This is why we are working on
>   - during year we remove harcoded reference to Smalltalk
>   - Undefined classes (read the IWST 2017 paper)
>   - new class definition
>   - model for class definition
>   - real life programming supporting module system.
>
> So each time I hear about namespace, I think that the best way to get
> a namespace system for Pharo is to help doing something else.
> This way we can concentrate on building a real working solution for
> Pharo. But since we have many other things to do then it takes time.
>
> Stef
>
>
>
>
>
> On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <[hidden email]> wrote:
>> Absolutely. I have contemplated giving it a try. But when I go look at the
>> mailing list, it looks like such a lonely place. I still might give it a go.
>> It looks interesting.
>>
>> Jimmie
>>
>>
>> On 10/19/2017 05:20 PM, Ben Coman wrote:
>>
>> btw, are you aware that Newspeak is developed on top of the CogVM that
>> Pharo, Squeak, Cuis all share?
>> cheers -ben
>>
>> On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <[hidden email]>
>> wrote:
>>> I watched this video a year ago and was intrigued. I have not thought
>>> about it deeply and do not know consequences of this model. However, Gilad
>>> is a smart man who has thought deeply about these things and has experienced
>>> consequences as a language designer. But it does sound interesting and I
>>> wonder if it would potentially be a solution to the namespace or modularity
>>> problems.
>>>
>>> https://youtu.be/pM0Hz4pFDZM
>>>
>>> He is talking about Newspeak in 2016 and what I refer to is its use of
>>> Nested Classes.
>>>
>>> No Global Namespace
>>>      No Global Variables
>>>      No Pool Variables
>>>      No Class Variables
>>>      No Class Instance Variables
>>>
>>> I have no idea if it would work for Pharo or what would be involved in
>>> implementing such. Or even if the community or leaders would even care to
>>> explore that direction. I have not seen it discussed here.
>>>
>>> Just wanted to toss his discussion of these ideas into the arena of ideas
>>> for Pharo.
>>>
>>> Jimmie
>>>
>>>
>>>
>>> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:
>>>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <[hidden email]>:
>>>>>> Am 13.10.2017 um 10:24 schrieb stephan <[hidden email]>:
>>>>>>
>>>>>> On 13-10-17 09:55, Thierry Goubier wrote:
>>>>>>> Because namespaces, by essence, come with serious issues. I won't take
>>>>>>> someone seriously on namespaces until he can cite those faithfully.
>>>>>> Let's start with the misconception that namespaces are about
>>>>>> modularisation
>>>>>>
>>>>> +1
>>>> +1 to this as well.
>>>>
>>>> Having modularization is like having security, very hard to add them
>>>> later if you didn't include it in the original design.
>>>>
>>>> I'm using VisualWorks these days, and I find its namespaces something
>>>> more of a hassle than a real use.
>>>>
>>>> If we could name Classes with a dot, that could solve most of what
>>>> namespaces are used for in practice: avoiding name colissions.
>>>> That's why most of the popular frameworks have prefixes like Zn, WA,
>>>> RB, and so on and so forth. But now I'm used to prefixes, I don't need
>>>> them. :)
>>>>
>>>> Modularity is a different beast, if you look at how some modules work
>>>> in JS, like AMD, you see that in practice they avoid collisions by
>>>> importin what they need from a module, and assign it to a "namespace"
>>>> (it is not, but works as such), so they get modules first, and
>>>> namespacing later.
>>>>
>>>> Regards,
>>>>
>>>> Esteban.
>>>>
>>>
>>


12