[squeak-dev] Re: talk on Newspeak online
Florin Mateoc
fmateoc at gmail.com
Sat May 10 05:31:45 UTC 2008
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
More information about the Squeak-dev
mailing list
|