Complexity and starting over on the JVM

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Wed Feb 6 02:23:58 UTC 2008


Keith-

As I pointed out, I wrote such code for Squeak ten or so years ago. The
problem isn't making the change. The problem isn't people being too "busy"
to put a few lines of code in the mainstream image changing a few classes
and then running a script while having lunch. If it was, in sometime over
the course of *ten years* someone would have found a few minutes to remove a
needless incompatibility Squeak has with just about every other dialect of
Smalltalk in the universe -- this strange us of underscore perhaps the
single biggest syntactic reason you can't easily exchange code with other
Smalltalks.

IMHO the issue includes the process and community norms whereby such changes
get adopted and mainstreamed to remove a *pointless* incompatibility with
the rest of the world (while still leaving it open to experts to do things
differently). And I use the underscore issue as an *example*; it's just one
of many. Namespaces was another big one. Stuff like a left click brings up a
menu lots of times is another (just plain bad GUI design by any modern
standard of expectations for 99% of people, with there being practically
zero benefit to doing things the current way, if anyone can easily even
*explain* how it works consistently).

I'm all for diversity. The problem is, to have a vibrant free software
community, you want diversity more at the edges than the core. That's what
Python has. Or what C has. And if you have diversity at the core, you want
some way to manage it well (like Igor suggests).

It is my hope a redesign on a common platform, leveraging that standard,
might push Squeak in positive new directions. I've already spent
person-months coding that from another direction, trying to make Python more
Squeak-like (which it its own limits).

While I've long been interested in this issue (new versions of Squeak) I
started this topic in response to a major maintainer and Squeak contributor
and booster and Squeak foundation board member saying some really tough
things to hear.

Again, he said: "I can tell you that I will ***never** maintain Squeak
anymore and I'm really thinking about what I will do. Because I think that I
did a lot for smalltalk in general the last 10 years and may be this is the
time to do something else to get a large breath of fresh air."

I am putting on the table what I think is a big set of issues (complexity
management) and one possible solution (a rebuild from scratch), thought of
course there are others (what Igor proposes with loading multiple versions
of code will likely be the future, and to an extent Les Tyrrell's OASIS
worked in that direction).

Over the last dozen or so years, I've seen lots of changes fall by the
wayside with Squeak. Lots of questionable stuff get frozen. Although I'll
freely admit I am not longer a current Squeak user for pretty much five
years or so (beyond fooling with it now and then every few new releases,
usually giving up after a couple of crashes when I stress test it and it
falls over).

In general, I don't think it is productive on open source / free software
mailing lists to say "if you want X, do it yourself". The reason for that is
that feedback from users who do testing and even potential users is often
very useful in thinking about the evolution of a system -- and not all users
or potential users have the same level of skill or available time or
commitment to do something. This is where that line of response can lead IMHO:
  "Mitch Kapor's Weekend at Bernie's [How Chandler wnet wrong]"
http://whydoeseverythingsuck.com/2008/01/mitch-kapors-weekend-at-bernies.html
"The Chandler interface design lead responded. Because I don't want this to
be personal I will refer to her as DL. DL responded to that statement with
the following: "Thank you Hank for articulating this. I think this may be at
the core of issues you are running into. [Note: *its my* issue] ... Think of
it this way. If you have a tool and you can't predict what the behavior of
that tool will be, it will *never* be useful. ... And so I issued a
challenge to the entire OSAF team. I challenged anyone to explain to me what
the "View" menu did. No takers. It's so complicated even the designers
couldn't explain it. ... If you let the fact that no one could explain a
core menu bar function sink in, you might get a clue as to why, despite what
had to be 10 to 20 million dollars of Mitch's money invested, Chandler
still, well, sucked."

Now Squeak isn't in that position overall, but *areas* of it are, IMHO. And
these are often the first areas a Squeak newbie encounters. And a big part
of that is in relation to not focusing on taming complexity IMHO. And that's
the reason someone like that board member is so frustrated IMHO. And I'm not
convinced those problems can be fixed by submitting a few patches. For a few
reasons, including, one key person who is/was taking in such patches is
talking about throwing in the towel over how that process isn't working out.

Anyway, I did post some code (but in Java). :-) And it was written months
ago towards such an effort.

All the best.

And by the way, how would you feel if when you posted "I just discovered on
Mac OS X 10.5 Leopard that the unix vm (3.9-8/3.9-10) uses leopards  X11
support rather than the quartz interface." or "When using the latest
XML-Support/YAXO with universes it is sending the image into an
un-interruptible state when it tries to parse the xml returned form the
server." someone replies that you were ranting and just fix it yourself?

Frankly, I wish I *was* ranting, and I could fix it just by myself. :-)

--Paul Fernhout

Keith Hodges wrote:
>> And yes, in a new Squeak, backarrow assign should be the first thing to be
>> removed from the default image IMHO. :-)
>>
>> --Paul Fernhout
>>
>>   
> Dear Paul,
> 
> you are ranting.
> 
> The reason this has not happened is that people are busy.  I have been
> wanting to do this for two years and just havent had time.
> Since squeak is open source, if you want something doing... you are as
> much invited to improve things as anyone else is.
> 
> In the time you have spent writing your long emails you could have
> tweaked the parser to enable underscores in methods and variables, AND
> still have it available for assignment. Some packages like
> Poststress/Gloop already make similar tweaks.
> 
> Since you care about it so much, I look forward to seeing what you come
> up with
> 
> cheers
> 
> Keith



More information about the Squeak-dev mailing list