<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
On 5/9/2011 6:32 PM, Casey Ransberger wrote:
<blockquote
cite="mid:BANLkTimZvBtiN9GmWMjeSnWe3fW+0w88wQ@mail.gmail.com"
type="cite">On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
If you have a wonderful simplification, you can also try
selling it to<br>
Juan and have it adopted in Cuis.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>...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!</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Nicolas<br>
</blockquote>
<div><br>
</div>
</div>
-- <br>
Casey Ransberger<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
</pre>
</blockquote>
<br>
Just to be a bit contentious before this completely degenerates into
a love-fest :)<br>
<br>
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.<br>
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<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Florin<br>
</body>
</html>