Vassili Bykov wrote:
> On Thu, May 8, 2008 at 11:04 PM, Florin Mateoc <fmateoc at gmail.com> wrote:
>   
>> One thing that I particularly like about Smalltalk is precisely the small
>> number of features/concepts.
>> I don't think that more is always better, and all those "crappy" languages
>> prove it again and again.
>>     
>
> Hi Florin, it's good to see you. Here are lists of core concepts of a
> couple of modern Smalltaks, and of Newspeak. I'm skipping secondary
> and transient artifacts such as categories, method arguments, temps
> and contexts.
>
> Squeak:
>
> Instances
> Classes
> Traits
> Methods
> Messages
> Assignment
> Instance variables
> Class variables
> Class instance variables
> Pool dictionaries
> SystemDictionary (global scope)
>
> VisualWorks:
>
> Instances
> Classes
> Methods
> Messages
> Assignment
> Instance variables
> Class shared variables
> Class instance variables
> Class imports
> Namespaces
> Namespace shared variables
> Namespace imports
> Name visibility
> Import visibility
> SystemDictionary (global scope)
>
>   
Hi Vassily, it's good to hear from you too.
I think you forgot the new kinds of literals introduced to support 
namespaces, plus I suspect that you bear some responsibility for the 
increase in complexity in VW as well :)

> Newspeak:
>
> Instances
> Mixins (classes are only applications of mixins)
> Methods
> Messages
> Slots
> Access modifiers
> Initializers
>
>   
Come on, you had just mentioned nested classes, isn't that a new concept?
And doesn't the label "Access modifiers" hide a collection of 
concepts/features ?
And mixins, are they themselves classes or are they separate concepts 
from classes?

And talking about global scope, e.g. Java doesn't have (an objectified) 
global scope. So what do people do when they need it? They stick 
whatever they need in a class, which is globally visible (I assume this 
is true even in Newspeak), and access it indirectly. The only thing you 
"gained" is an extra indirection.
Sure, global scope should not be abused. But it is damned convenient. 
Very useful as a quick debugging aid. Once again you seem to want to 
save us from ourselves, but there are a lot of languages out there that 
are already doing just that, thank you very much (they are called crappy 
languages). Give us more power, not more guard rails!
>> Not all developers are the same, not even if we only consider the brilliant
>> ones. Some are more paranoid than others, some are more over-engineerish
>> than others, some are more frugal, some are more hackish. If you happen to
>> find yourself downstream from a paranoid one, and the language supports his
>> or her paranoia, you are out of luck
>>     
>
> Right. This is an old argument, and my sympathy has always been (and
> still is) with the side arguing for less control and paranoia. It
> feels funny to seem to argue the opposite. But it often helps to
> analyze your own weaknesses. One of the big weaknesses of Smalltalk is
> the inability of untangling your application from the rest of the ball
> of wax. The proof of this are the niches where it is successful. One
> of the characteristics of those is that deployment is very
> controllable. You are either on a server or in a position of not
> scaring users away by a multi-megabyte monolithic install. "20M for an
> RSS reader? You've got to be kidding!" The second important factor,
> Dolphin being a pleasant exception, is that the users shouldn't be
> scared by ugly and clunky GUIs. Marketing megadollars and
> institutional stupidity are big problems, but there are the technical
> issues that exacerbate them. Show me how my Smalltalk app can be
> separated from image version 3.10.1234 with custom patches to
> WorldState and initialization of ClassBuilder circumvented by my very
> special subclass, and shipped over the wire to run elsewhere. Funny
> that I should be among the least unhappy with the status quo--I've
> been paid for working in Smalltalk for 15 years straight. Perhaps if
> us Smalltalkers are happy to mediate on the perfection of our navel
> with no regard to what happens outside the image, we shouldn't be
> concerned with vulgar issues such as relevancy and paid jobs.
>
>   
Ah, you mentioned the "dirty image" curse word! Time for another rant:

Let's take Java, which does not have the concept of snapshotting a fully 
loaded and initialized memory dump of their application. Because of 
that, they are now scrambling to find ways to "pre-load" stuff in order 
to cut those awful startup times that have to be paid again and again by 
everybody, every time they use a (large) Java application. Oh, what joy 
to spend time loading and compiling and initializing those exact same 
classes again and again instead of doing it only once!
I find it mind-boggling that even Smalltalkers are complaining about 
this "bad" image idea, when it's one of the major factors in their 
superior productivity. Let's not even mention the benefit for 
development of living in the same space as both the target application 
and the development environment. Even for deployment it is a great 
debugging aid to just leave all the tools in the image (just hide them), 
so when the inevitable occurs, you are not stranded (like in the crappy 
languages) with an unwound stack that you cannot debug.
Of course, one can do stupid things with an image: one can save it with 
all kinds of external resources open etc. But, you know, if it hurts, 
don't do it. Does this mean we should all give up all the amazing 
benefits that we enjoy, simply because somebody could be stupid and use 
it poorly? This is like saying that merely because one could take a copy 
of a hibernated OS image from a laptop and move it in a different, 
inappropriate place where it could break when started, we should all 
give up the capability of doing hibernation on our laptops.
And why do you conflate the image "problem" with modifying base classes? 
If somebody really wants to, now that we have the full sources to the 
Java class libraries, nothing stops anybody from modifying them, putting 
them in a jar and the jar in the classpath. Yes, many will shoot 
themselves in the foot in the process, but if somebody can make a useful 
bugfix/feature that Sun has not thought of, why not?

Of course a Smalltalk app can be separated. It may be painful. I went 
through that pain just for kicks with the VW base image when I had too 
much time on my hands during the post-internet bubble downturn. I did it 
by talking to my target image through tcp-ip, and slowly peeling away. 
Craig demonstrated another, more productive way in Squeak. The thing is, 
it is possible, and to my mind, the main reason it is not in wide use is 
because that dreadful image problem is not as dreadful as it is made out 
to be (by some).


>> And here I have to disagree again. I have worked on a large and successful
>> Smalltalk project, where some such internal machinery was developed to add
>> all kinds of semantics to the slots: default values/initializers,
>> constraints (types/values), persistence, object-graph ownership relations,
>> ... Yes, if you looked, you could see the wiring.
>>     
>
> I'd be interested to see an example. I really mean it. Especially
> default values/initializers.
>
>   
Well, I cannot offer you or Stef code, it is a proprietary application.
But I can talk about it, and there is nothing special about the code. It 
is not deeply hackish/mop-ish from an implementation point of view. Of 
course, it is so from a conceptual point of view.

I think the main insight was that these do not have to be universal 
features in the image, they do not need to include the base classes, 
anyway the base image code would not know what to do with them. So if we 
only need them for application-specific code, we can simply make all our 
classes be subclasses of a certain class, let's call it Special, and 
restrict our modifications to these subclasses. Well, I lied, there was 
a need for a few special base classes (collections), and as a result 
there was a little bit of hierarchy duplication because collection-like 
classes were created as subclasses of Special.
The rest was achieved by modifying the browsers, to make them aware of 
(and to display and make editable) the extra features. This was all the 
meta-layer separation that we needed, the wiring was almost never 
touched, and all the development happened through normal (but enhanced) 
browsers. This had a very natural feeling to it, it almost looked like 
Smalltalk itself had those extra properties.

Cheers,

Florin