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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110509/d6c98b7f/attachment.htm