Complexity and starting over on the JVM

Sean Heber sean at fifthace.com
Wed Feb 6 03:06:58 UTC 2008


I feel a little out of place commenting, as I am even less than a  
newbie when it comes to Squeak/Smalltalk.  In fact, I've only started  
Squeak a few times, poked around, and closed it in disgust and/or  
utter-confusion after a time due to the overwhelming complexity (and,  
IMO, ugliness) of the UI that hits like a brick to the face when  
first starting an image.

So why am I here and why do I care?  I love the core principals of  
Smallktalk (and Seaside!) so much that I've been subscribed to the  
list for awhile just reading and watching and waiting for some sign  
of... I dunno... social growth?

As an outsider looking in, what I see is a relatively closed  
community of uber-experts who enjoy their exclusive membership in an  
exclusive club.  Looking past the UI and other complexities and  
shunning the (much larger) outside world of file-based development  
feels like an unspoken hazing ritual that newbies are asked to just  
accept blindly in order to join.

I have a hard time playing with Squeak because it feels so isolated  
by design.  I want to make apps that fit in with my other apps.  Can  
I use Squeak to make an OSX app that looks and acts like an OSX app,  
for example?  I honestly don't know because from what I've seen,  
Squeak seems to want to be only about Squeak.  And, IMO, the core  
community reflects that same insular attitude.  (Or vice-versa?)

Just what *is* Squeak for, in the end?

l8r
Sean


On Feb 5, 2008, at 8:23 PM, Paul D. Fernhout wrote:

> 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