Things We Must Have (Re: [squeak-dev] Resolution of Contentious Issues)

Frank Shearar frank.shearar at angband.za.org
Tue May 10 08:05:30 UTC 2011


On 2011/05/10 04:26, Casey Ransberger wrote:
> You might check out Slate:) It's all about the multiple dispatch.

Don't forget to read Foote/Johnson/Noble's take at 
http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html. 
I'd _love_ to read the implementation, but I can't find it.

This touches on another issue though. The thread's turning into a bit of 
"X is useless/unnecessary but I really want Y".

Before we turn things into a kitchen sink it might be worthwhile teasing 
apart what we want, and include helping APIs instead of the things.

For instance, multimethods. Foote/Johnson/Noble fiddle a bit with the 
Compiler (and tools) to implement multimethods/multiple dispatch as a 
sort've currying process. I'm just using this as an example, mind, with 
the hope that other people's "vital feature I simply must have" may be 
amenable to similar analysis.

So FJN fiddle with the compiler. You can imagine that other people might 
also need to fiddle with the compiler, to add pattern matching, for 
instance. So perhaps instead of adding multimethods or pattern matching 
to trunk, we should add ways of modifying Compiler to trunk such that we 
can reasonably safely extend the system without stepping on each other's 
toes (through overrides, or whatever).

frank

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




More information about the Squeak-dev mailing list