Complexity and starting over on the JVM

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Tue Feb 5 00:39:46 UTC 2008


Klaus D. Witzel wrote:
>> To me, that example just shows again everything wrong with the Squeak
>> development process and why it is so frustrating to deal with it -- an
>> undocumented decompiled hack stands in for "free"-ly-licensed modular
>> robust software
> 
> Interesting. To what do you compare, what's the "free"-ly-licensed
> modular robust software?

Take, for example, Python or MzScheme. Both of these have a much cleaner
separation of what is in the core and what is in libraries. Python
especially has endless libraries, MzScheme not so much.
  http://planet.plt-scheme.org/

For beginners (or experts) they don't confront you with a ball of sticks and
mud, requiring you to be an expert's expert to disentangle the whole thing
and keep the complexity under control (if such was even possible -- Spoon
goes a long way in that direction though).

Both have their own issues of course. The underlying Python C implementation
(and also Jython's Java implementation) have messy parts (Jython
especially). But you generally never have to think about them much. You
don't like the CPython GUI library, use another -- without much fuss.

MzScheme and relations like DrScheme rely (last I looked, several years ago)
on a hacked up version of wxWindows for cross-platform graphics that was
getting harder to maintain.

Nonetheless, above those layers, both strive for modularity.

The JVM (in earlier non-Sun free versions, and now Sun's) supports
modularity in terms of libraries. It has its bugs, and Java is a cumbersome
language, but modular JAR files save the day and people do robust enterprise
work with it with many people on projects (of course, you need many people
since Java itself is a fairly unproductive language, unless you can find the
right prebuilt library, which you often can)..

The whole related set of C modules that support many applications tends to
be modular -- it has to be otherwise your C application would crash like a
pile of sticks since C code can be so brittle. Objective-C is an improvement
in that regard.

Nonetheless, each also has weaknesses. Who wants to program in C (or even
Objective-C) if there are more productive alternatives, especially with
integrated development environments? CPython wasn't designed with "edit and
continue" in mind and has trouble restarting exceptions. MzScheme is, well,
Scheme, which has both great points and bad points about it.

Smalltalk strikes a nice balance -- a loss of language complexity and
terseness (no macros) at a big win of more understandable code and great
tools in a super environment as a creativity amplifier. But I have never
felt as at-home or as confident writing with Squeak as when I wrote stuff
with, say VisualWorks+ENVY (though that is not free, so I stopped using it
seriously ten years ago, and ENVY has since gone to the bitbucket).

As another example, Scala for the JVM was designed with modularity and
scalability in mind. Personally, I prefer more dynamic languages like
Smalltalk for making most (or all) of an application, but for writing a VM
Scala is probably more fun than C or Java, and maybe even in some ways a
better choice than writing restricted type-implicit code in Smalltalk.

Then there is also Ruby, of course. Still getting there though, as a
Smalltalk with C-ish syntax. :-)

In short, most of Squeak's competitors for developer time have better
support for modularity. They have to be since in general they are weaker
systems or less productive systems or less introspective systems. A
Smalltalk environment by default allows handling more complexity than, say,
Java code under Eclipse,. But does that productivity boost mean we should
blow all the extra benefits by maintaining overly complex unmodular code and
still arguing (ten years later!) about how to properly strip mainstream
release images full of stuff (with or without Traits, and so on) and how to
reconcile all the different lines of development out there which differ on
mostly trivial things?

Squeak also deviates from other Smalltalks sometimes for no good reason. A
dozen years later you still can't use underscore as easily as in most other
Smalltalks because underscore is still overloaded as the assignment symbol.
I wrote something to convert my image to use underscores about ten years
ago, but it got lost in the relentless upgrade to new images (I use
underscores in simulations to let me tag methods and variables with units,
as in "rainfall_mmPerDay"). What does this weird use of underscore really
get anyone? And that's just one of multiple idiosyncrasies (which maybe were
pioneering once upon a time but now just confusing for no value).

Anyway being on the JVM is just one aspect of starting over as a
possibility. One would move step-by-step and add modules to bootstrap up
something like Spoon, move beyond it, and then hope the community finds it
worthwhile to expand it. Perhaps support ANSI Smalltalk as a minimum (with a
regular underscore), with other things possible on top of it in different
namespaces. Maybe write some code conversion tools to import old-style
Squeak-ish code down the road.

Alan Kay has several times talked (even at its release) of Squeak being just
as a stepping stone to something better. It is the Squeak community and
Squeak ideals that are the biggest assets -- not the code.

--Paul Fernhout



More information about the Squeak-dev mailing list