sure but namespaces do not solve that problem either. They actually make it much worse. You can have a library named Door by X author and then another library named Door by author Y , hello name clash. Even worse those libraries may contain objects than name class, normally that would not be a problem under the expected usage of name space but lazy coders being .... well lazy... they love to collapse the namespace to reduce typing. So House.Door.Handle will become just Handle which may clash with with the name of another collapsed namespace.

Pharo is immune to such issues and the enviroment guarantees that you wont have name clashes inside the image. Namespaces , dont.

Add to that that we are very much centralised community around STHub and GitHub which makes it dead easy to find any potential name clash, compared to other languages that are spread all over the internet.

So I would say its more a luxury solution than a poor man's. What pharo lacks is something that helps us organise our classes even more and even tag them to form relationships between them. But thats easy to implement the questions is who is going to port the thousands of classes to a new system.

On Thu, Jan 14, 2016 at 4:50 AM Ben Coman <btc@openinworld.com> wrote:
On Thu, Jan 14, 2016 at 2:12 AM, Dimitris Chloupis
<kilon.alios@gmail.com> wrote:
> "I have seen someone in another thread expressing the desire for namespaces.
> As a newcomer, I also feel that is something important and missing. But
> since one of the goals of Pharo is to produce an environment that can be
> understood by a single person, the lack of namespace might actually be a
> feature. Namespace are essential for languages like C++, designed for large
> projects, produced by large teams, where nobody understands the whole
> system. They embody an industrial approach to programming. In contrast, I
> have the impression that Smalltalk emphasises regularity to minimise system
> size, rather than modularity to manage system size, and that it embodies a
> craftsmanship approach."
>
> Pharo contains over 800000 methods spread around several thousands classes
> and the system has not imploded yet even though we have no namespaces. The
> reasoning is simple, Pharo does not need namespaces because its not a
> programming language. Namespaces primary role is not organization so much as
> prevention of name clashes , this is not a problem for Pharo since it does
> not allow name clashes in the first place.

Name clashes can still happen between different external libraries.
Effectively we have a poor-mans namespaces with prefixes.�� But its
harder to port libraries from other Smalltalks that support
namespaces, limiting our ecosystem.�� Not necessarily the main driver,
but worthy of consideration.�� Squeak has recently done some namespace
stuff so will be interesting to see their experience.

cheers -ben


> Thats is happening in the
> enviroment and not language level, if you want to organise your classes you
> use packages . Packages also are not part of the language and are also
> implemented on enviroment level, though one could argue that language is
> also part of the enviroment.
>
> So yes it feelt strange even for not having namespace coming from python but
> after coding in pharo for over a year its clear to me that pharo does not
> need it and would probably benefit by more sophisticated and specific
> implementation when it comes to organisations. But generally speaking we
> already have plenty of tools that help you locate classes and methods with
> ease, so that is not much of a problem.
>
> Pharo enviroment is far from simple, quite the contrary Smalltalk
> implementations were always far more complex than you average language like
> C++, the big diffirence is that the enviroment is constructed in such way to
> help you deal with complexity. Where modern languages ephasize simplicity
> pharo and smalltalk in general invest on better dealing with complexity ,
> hence why Smalltalk has been very popular in specific very complex fields
> like Banking Sector, Shipping etc. C++ is no where as suitable for complex
> applications , its popularity merely stems from the fact that is OS language
> with immediate access to OS libraries and massive support.
>
> On Wed, Jan 13, 2016 at 7:30 PM David Allouche <david@allouche.net> wrote:
>>
>> Thank you everyone for the kind responses. I will answer some of the
>> questions and suggestions here.
>>
>> To get faster to the intellectual stimulation, pick a task / project and
>> start asking questions. And have fun :).
>>
>>
>> That is good advice, but right now I think I will just explore the system,
>> review changes, and wait for the tasks to find me. There are already more
>> things I want to do than I will probably every be able to accomplish :-)
>>
>> I think when people referring to Smalltalk refer to Smalltalk as the
>> language or OOP itself, but thats only the tip of the iceberg, Pharo tries
>> to stay true to vision of smalltalk creating the virtual enviroment where
>> the user can easily create his or her own tools or modifying the existing
>> ones, something that I feel no other language out there can emulate because
>> they follow a non monolithic approach where there is a deep dichotomy
>> between language, libraries and the environment itself. You could say that
>> Smalltalk is the anti-Unix architecture , a great example of monolithic
>> design that works great in practice yet its easy to modify and extend.
>>
>>
>> The�� fact Smalltalk the language cannot be taken in isolation from
>> Smalltalk the environment became clear rather early on: reading the UPBE and
>> other materials shows that the language itself does almost nothing: it
>> cannot even define classes or packages. It is all part of the environment.
>>
>> I have seen someone in another thread expressing the desire for
>> namespaces. As a newcomer, I also feel that is something important and
>> missing. But since one of the goals of Pharo is to produce an environment
>> that can be understood by a single person, the lack of namespace might
>> actually be a feature. Namespace are essential for languages like C++,
>> designed for large projects, produced by large teams, where nobody
>> understands the whole system. They embody an industrial approach to
>> programming. In contrast, I have the impression that Smalltalk emphasises
>> regularity to minimise system size, rather than modularity to manage system
>> size, and that it embodies a craftsmanship approach.
>>
>> Since I am just old enough to remember a time where computer systems could
>> be understood by a single person, I find it an attractive idea to try and
>> produce a modern system with that property.
>>
>> I can't remember who famous said something like "The only languages
>> worth learning are the ones that changes the way you think about
>> programming..."�� and I found that with Smalltalk & Pharo.
>>
>>
>> I am familiar with that idea too. And most good languages provide that.
>>
>>�� One day I will have learn some language from the ML family. I choose
>> Smalltalk because it clearly had such a strong influence on the thinking of
>> people who have used it, I thought I could learn
>>
>> A good way to get your hands dirty is to review fixes submitted by
>> others...
>> https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=45
>> There are never enough hands there :)�� (my own action here fluctuates
>> from time to time)
>>
>>
>> I will try to spend some time reviewing code. That is a good way to get
>> exposed to things one does not even know they exist.
>>
>> Did you look at Seaside?
>> Since you should be able to read french there is�� a nice tutorial:
>> tinyBlog. In two days you can build a small web app
>> with a mongo back end.
>>
>>
>> I have no looked at Seaside yet, I have not even read the corresponding
>> chapter in UPBE. But I certainly will, eventually. The web is an essential
>> part of society today.
>>
>> Where are you located ?
>>
>>
>> Paris, France.
>>
>> It did occur to me that the Pharo community does have a unusually large
>> fraction of french people. But that is not a factor for me.
>>
>> Thanks again for all the kind words. I am sure this journey is going to be
>> a lot of fun. :-)
>>
>>
>