You might check out Slate:) It's all about the multiple dispatch.

On Mon, May 9, 2011 at 8:11 PM, Florin Mateoc <fmateoc at gmail.com> 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> 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
>
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110509/16a84c61/attachment.htm