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
|