On 5/10/2011 2:08 AM, Frank Shearar wrote:
> On 2011/05/10 04:11, Florin Mateoc wrote:
>> 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
>


Well, first you ask for my Newspeak opinions, then you follow up with another message warning that this thread is
turning into something else :)

In short, and related to what I already mentioned, I think there is great value in having the possibility to modify
somebody else's code to suit your needs (this is also what open source is all about), but if you can, instead of
directly changing the code in place, it is very helpful to keep your changes separate, mainly by extending their
classes, or even better, in combination with overrides (and of course, in combination with inheritance) - overrides is
one thing that VW did better than Envy, at least conceptually (the implementation had its hickups), and I think it is
the natural successor to class extensions.
I think that one cannot really future-proof their designs (not over what you can achieve already by writing clean/clear
code, well organized in hierarchies and extensions), so it is the wrong choice to hamper useful activities (other people
conveniently extending/modifying your implementation) for at best marginal improvements in manageability (or whatever
else modularity brings). If I have nice concepts and tool support for extending/modifying imported packages, I can
actually write less code and keep those modifications/extensions cleanly separated and better managed.
Smalltalk is permissive, it does not forbid you to use modules (e.g. by using conventions). It also does not force you
to use extensions if you dislike them.

Furthermore, from reading what Gilad wrote about class extensions, I assume he has never worked with Envy or Store.
Those are clearly not about monkey patching, or applying patches dynamically, or patching in general. In addition to
being source control systems, class extensions in their contexts are a way to organize your code, which is orthogonal to
the class hierarchy, and as such, it helps enormously to deal with complexity. One puts methods which are dealing with,
say, XML representation, in an application called XML. These include extensions to Object, String, etc, and they help
keeping class Object clean (at least as it is in its original package/application), not pollute it - of course, this
assumes tool support, but the browsers are essentially the only place where we can talk bout pollution, nobody cares
that at runtime the class has all those methods in its method dictionary. But extensions to base classes are by far the
exception, not the rule. A large application, and its classes, deal with many different aspects, for which extensions
are more appropriate than new classes. This is one of the reasons aspect oriented programming made sense in Java, which
does not have extensions, but does not make a lot of sense in Smalltalk. And the thing is, you can add aspects to
somebody else's projects as well, they could not have thought of everything possible or needed in advance.

Just like with the image (I am not talking about Newspeak right now), so many people complain about image based
development, but nobody stops them from loading everything fresh in some minimal core image every time they start
working, yet nobody does it. Java is oh, so clean, it starts fresh from files - so why do people complain about startup
times, when you have a huge application and you need to load and initialize thousands of classes every time you start
it? The image model is not (really) forced upon us, we use it because we like it and it is convenient. It can probably
be improved upon, here I am pretty much in agreement with what Gilad said, my point is that one should not take that
useful capability away just because it allows you to do bad things.

Florin