On 2011/05/10 04:11, Florin Mateoc wrote:
> On 5/9/2011 6:32 PM, Casey Ransberger wrote:
>> On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com
>> <mailto:nicolas.cellier.aka.nice at gmail.com>> wrote:
>>
>>     If you have a wonderful simplification, you can also try selling it to
>>     Juan and have it adopted in Cuis.
>>
>>
>> Heh, you know we actually had a nice exchange about that. The
>> conclusion we landed on was "Cuis needs namespaces like a fish needs a
>> bicycle." :) Since Cuis is about starting with Smalltalk-80, a system
>> designed to be mastered by a single individual, and gradually deriving
>> its essence, it's unclear that the advantages namespaces offer either
>> justify the cognitive load involved in learning/using them, or the
>> work involved in implementing them, within the context of the goals
>> which drive Cuis.
>>
>> Really namespaces are a solution to a social problem in my world: a
>> feature many engineering managers will want to see in a technology
>> before they will be convinced to approve the use of it. Yes of course,
>> namespaces are also technically very nice, but you don't really get
>> much value out of them for anything but selling the manager unless
>> you're working on a large code base or with a large team (or both.)
>>
>> That said! As Cuis gets smaller, it gets easier to approach working
>> prototypes for things that require a lot of support throughout the
>> kernel, because there's just less code surface there to have to modify
>> in order to realize one's ideas, which makes Cuis is a fantastic
>> platform on which to explore and experiment with stuff like this, and
>> namespaces is something I'd definitely like to try there :) In fact, I
>> do mean to load Environments up as soon as I get OmniBrowser working
>> in Cuis.
>>
>> ...But back to Squeak. With the license clean, a fast VM,
>> active/visible development, and the core of Squeak looking better and
>> better all the time, this is really one of the last boxes that I have
>> to check before I can start winning the argument that says, "you
>> should think about using Squeak at _your_ company." This is exciting
>> to me!
>>
>>     Nicolas
>>
>>
>> --
>> Casey Ransberger
>>
>>
>>
>
> Just to be a bit contentious before this completely degenerates into a
> love-fest :)
>
> I want to say about your main topic, namespaces, that while neat as a
> check-box, they are a non-issue in practice. I have worked on several of
> the largest Smalltalk applications out there, and they all managed to
> grow to where they were (huge, over 10,000 classes), and still being
> relatively manageable, without namespaces. Javascript is considered
> ugly, but it is one of the most succesful languages out there, without
> namespaces. Java, on the other hand, has namespaces and, while the
> language is successful, Java projects groan under their own weight over
> a certain size (faster than Smalltalk). I am afraid Newspeak's obsession
> with modularity also misses the point.

I agree with most of your post: I think namespaces themselves - a means 
for avoiding class name clashes - are trivially solvable in practice by 
prefixing.

I'd be interested in hearing more about your Newspeak opinions. What 
point are they missing? What mistakes do you think they're making?

frank

> Commercial Smalltalk (VA, VW, ObjectStudio) manages complexity by
> splitting things in two orthogonal ways: class hierarchy and
> applications/packages/class extensions. This works quite well and
> namespaces do not add anything useful here. The fabled problem of trying
> to import different projects with clashing names is an urban myth.
> Useful packages already have solved this cheaply with prefixes: RB, GS,
> ... I don't see anything wrong in calling my classes FMSomething instead
> of org.fm.Something
> VW pushed their shiny new namespaces implementation down their
> customers' throats, which slowed the system significantly (this was
> offset by Eliot's efforts in the VM around the same release, but we
> would have obviously preferred to have a net performance gain, not a
> wash). They "demo-ed" the namespaces by gratuitously splitting the core
> of their system in namespaces, while admitting themselves that this was
> not the best example/usecase. But the most important thing is that
> namespaces did not help our huge project in any way. And they would not
> have helped it grow faster/better, had they been there from the
> beginning. On the contrary, in a system that already has
> packages/application, namespaces are just a distraction.
>
> And, since you are after opinion polls, I will take the opportunity to
> give you my opinion of what is missing from Smalltalk: multiple
> inheritance and multimethods.
>
> Cheers,
> Florin
>
>
>
>