Great post! Thanks for writing. You made some points well that I was struggling to express, so thank you. I really need to take some time to look at Newspeak soon. 

On May 10, 2011, at 1:12 PM, Florin Mateoc <fmateoc at gmail.com> wrote:

> 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
>