Squeak UI and toolkit commentary: (was: Re: Who has no job? (was Re: O'Reilly Squeak book?))

Jim Benson jb at speed.net
Fri Apr 19 06:30:19 UTC 2002


Charles,

I have the exact opposite answer as to what Cees de Groot gave as comments
to your commentary.

Modern personal computers are usually owned by people or businesses who have
spent their hard earned money to acquire them. They have a vested interest
in being able to use them. Most people that I have met want to be able
perform some specific set of tasks with their computers, whether de Groot
deems those tasks to be necessary or not.

As an example, most people that I know want to be able to sit down and type
in a letter, then print it out using their machines. They want to check
their spelling, they like to use different fonts and maybe even include some
simple illustrations if need be. Whether this is mandated by this Taylor
character is irrelevent, that's what people like to do, and have voted so
with their wallets. I would guess that for 95% of  these tasks, simple
applications provided with todays modern Windows and Mac OS (such as Wordpad
and SimpleText) provide a pretty compelling solution. Squeak doesn't do that
very well currently. Same with other mainstream applications such as
spreadsheets, paint programs and such.

As for printing things out on paper, just rearrange what Enzo Ferrari said
about fuel injection for car engines when it was first introduced: "If
someone invented carburetors after they invented fuel injection, do you
think fuel injection would remain a dominant force?" Paper has a great many
advantages in comparison to a computer, plus it's dirt cheap and requires
little power. Do we need paper? Uh, yeah, thank you for asking. For a lot of
people, computers are a great way to process paper.

So we know that most people have an investment in their machines. The
machine manufacturers include operating systems which are supposed to
provide a unified way to interact with your computer. You have windows, a
blinking caret, scrollbars, buttons, etc, all with a common "look and feel".
Most people on this list agree that this is not an ideal interface.
Personally, it seems to me that these interfaces are a pretty good impedance
match for the hardware that has been available for the last ten years, but I
probably don't know any better.

So what's the deal with Squeak? Conceptually, you could just dismiss these
arguments with a simple wave of the hand, "Yeah, it *could* look (or act)
this way if you wanted it to; it's pretty close as it is", and just move on.
You can also scream and shout that "Squeak is the best" as loud as you want.
You can also say that current WIMPs suck, and that Squeak is "the way". So
the few hundred of us (who can't really even agree between ourselves) "know"
better than the 100 million on the outside with their own machines. You
might find this surprising, but the outsiders aren't buying in.

Look at it another way, they've already made their investment. They've
learned the various intricacies of operating their machines OS. When they
first use Squeak, they want to know what the screw is going on here? And not
from the perspective of "Now that's some really nice programming". What's
the benefit of learning another environment? Sure there are a couple "killer
apps" in the Squeak world, but overall the learning curve is very high for
people who are task oriented, and the reward relatively low. Maybe this
Taylor is responsible for this behaviour, but I don't think so.

I've had quite a few laughs the last few days reading the list with all of
the different suggestions to make Squeak more mainstream. These suggestions
have ranged from let's write another book, let's have more documentation,
let's have a better website (including my favorite comment of the entire
last year, something along the lines of "Let's make sure the HTML on the web
site is good (well formed) so that people will take us seriously").

I'm not against any of those things, most all are obviously good ideas. I
think there are different issues here. My first question would be, "Why do
you care what others think about Squeak?". I think this time would be better
off spent making Squeak better for the people who use Squeak. What does
"mainstream" mean -- and why in the world would you devote any energy to
getting it?

 I can tell you why *I* use Squeak, and I've got to tell you upfront that I
disagree about some of the projects that go on here in Squeakland. However,
since they don't really effect my work (other than those modules) I say "go
nuts, have some fun".

As noted, there is a difference between Squeak the programming language, and
Squeak the environment. On the list here, I've seen people state that Squeak
has a difficult syntax. What in the world are they comparing it to??? From
the programming side, I have faith that people who can understand the syntax
of C++ or Java have a chance at understanding Squeak. I also think that most
non-programming types stand very little chance of understanding C++ or Java.
The syntax and the language Squeak is fine for what it does.

 We talk a lot on the list about people "getting it", but we rarely outline
what "it" is. We also dismiss other peoples work rather quickly (unfairly I
think), like Java, Pearl, C++, etc, but rarely for the right reasons. To me
"it" is pretty simple. Lisp and a few other languages also have "it". "It"
is life. Squeak has this completely different view of the world from most
other programming languages, and it even brings its own house to live in.
The world Squeak lives in is alive. Squeak builds live objects. Squeak
consists of live objects. Squeak is live objects.

By contrast, most all other computer languages (and certainly all the
mainstream ones) build dead programs. The code base for these dead programs
are totally static, they cannot grow, cannot mutate, cannot become more
interesting as time progresses. Most, if not all, of the data structures are
dead. The tools that the cult of dead use for propogation of their kind are
usually centered around things like files and file editors and post mortem
debugging tools, and recently have been swaddled in graphical interfaces
giving the illusion of being living dead. [As an aside, I recently showed a
friend of mine the "versions" of a method that I had coded, using the built
in Squeak tools. This minor part of Squeak brought a wide eye stare of
astonishment from a high priest of the cult of dead].

The cult of dead has borrowed some of the ideas of Smalltalk and used them,
such as "object oriented programming", garbage collection, and virtual
machines. However, this approach totally fails. It is the use of these ideas
used in unison with each other (the sum is mightier than its parts) that
brings life to the party. Each part alone is inanimate, and helps to
obfusticate the true underlying principals of a living system. In some
sense, it's like taking a nucleus or a mitochondria from a cell, and placing
it on a table without any of the cell machinery surrounding it. From
experience, I can tell you that they don't tend to flourish under those
circumstances. A cell without a nucleus isn't a very happy camper either.

This is not to say that the cult of dead are not useful. Eventually when you
get down to it, the bits are the bits, and the dead are very good in dealing
with the bits. They are useful for writing a VM, or some type of device
interface if need be. Also, for many of the same reasons, to think that
Squeak is some modern day cure all for every computer problem that comes
along is rather misguided.

So when I hear talk about killing most parts of a Smalltalk environment to
produce a 20K FreeCell executable, it is very sad. You've basically banished
the FreeCell away from his family, and sent him to die in a lonely corner of
the world. The FreeCell should be among his friends, where he can laugh and
play and have a good time. Note that this is different than having a slimmed
down version of the image (which in my mind should be built by some type of
cross compilation process, rather than amputating objects out of a living
image) for specific tasks. I also understand the need of task oriented
solutions, where the end user is locked out of the development environment.

With that said, it's not contradictory to want a clickable file to launch
Squeak. One of the things that I like about Squeak is that I only need four
files, and I don't have to worry about the Windows registry this, shared
libraries that, execution paths and all of those other nasty things. If it
was one file, even better. I'll remind you that a .EXE file is rather
Windows centric, but conceptually that's probably what you want to do.

With that information in mind, the reason I use Squeak is that I can write
even complex computer programs in a reasonable amount of time. Using cult of
dead tools, you are extremely limited to how much "dead program" you can
write or manage by yourself. In the living world, I can take objects that
are already alive and have them do my bidding. For example, to start writing
virtually any dead program from scratch you have to figure out all the
libraries and such that you will need to perform even the simplest tasks. In
Squeak, all I have to do is call my minions by name and they are at my side,
ready to roll. All of this means that I can go through several itertations
of implementation in the same amount of time it takes a dead counterpart to
go through one iteration. I view Squeak as a personal multiplier of force,
that is, it projects my will over a broader path than I could by myself in a
dead program. You can take almost any one of the problems that you
mentioned, for example a database report writer, and actually have a chance
of building one yourself. I would estimate that it would take forever and a
day with cult of dead tools.

I agree with many of your points. Many of the UI paradigms that are
implemented on the host should be respected by Squeak. Simple things like
dialog windows should act like dialog windows, buttons should be buttons,
etc. At the same time, I think a lot of the core concepts of Morphic are a
great addition to the environment, and should be available too. By providing
a little bit of the interface sugar of the native UI, we can inject the more
important underlying concepts of the morph world, which gives us leverage to
build on. In other words, it's a trap. It mostly looks and feels right, but
we're not in Kansas anymore ;-) I think one thing Alan Kay said was that
Squeak should have a thousand looks. I don't think one look in a certain
context would be out of the question.

I'll add that I think that the real way to make Squeak popular is to produce
'killer apps' that play to Squeaks strengths. These apps give the user a
reason to invest the time, energy, and effort to learn Squeak. Etoys is one
such app, a "Super Hypercard" app, the Swiki is another. I'm sure you can
think of several by yourself. In general, people want to solve some specific
problem, or complete a task. Or be introduced to an entirely new, powerful
concept. Virtually all of the  different "killer" apps that you can think
of, (text editor, word processor, desktop publishing, photo editing, email,
etc.) are the compelling draws to use a computer. Indeed, machines have been
sold specifically just to run certain apps. That's why people buy machines,
to run apps. And they want to run the apps they want to run, regardless of
how off putting it may seem to people on this list. If you make compelling
content or apps, people will buy in.

I think you make a lot of good points, and appreciate your comments.

Jim

PS: Sorry, this got a little out of hand; I guess I felt more strongly about
this subject than I thought ;-)


> I'm really too new here to be speaking, but being a quite new user, I
> perhaps have a perspective on how Squeak looks to a new commer (i.e., a
> potential convert)...
> Sorry, but this is basic.  Dialogs need to look reasonable.  There needs
> to be a decent way to make them.  There needs to be a decent way to
> align the parts.  There needs to be a good way to secure them against
> right-clicks.  (I have been told that such a way exists, but the
> environment doesn't give evidence of it.)
>
> Squeak is a great environment for programmers.  It seems to be a lousy
> environment to turn end-users loose in.
>
> This could all be answered if there were a good way to create a "stand
> alone executable".  I notice that Dolphin sells that as their high end
> product.  But this is so basic that no professional application can be
> created without it.  (Well, maybe some, but none that I could use at my
> job.)
>
> The power of Squeak really amazes me.  It's so easy to create an
> animation.  Etc.  But the appearant weaknesses are equally amazing.
>
> The basic parts of most jobs are:
> Text Work, Database work, (a tiny bit of misc.)
> The users interact via interfaces, which must be predictable.
>  Customization should be restricted to "power users", and even for them
> there needs to be an easy way to reset the interface to it's default
> state.  So when they've confused themselves, they can recover.
>
> Where Text and Databases interface there need to be reports.  Printed
> reports.  With headers and footers, page numbers, dates, etc..
>  Sometimes tables of contents are important, though usually that's only
> for Word Processing documents.  But indicies are often imporant, and
> they need to index by page number.
>
> Squeak should be an excellent environment for this, but it's missing
> features.  There isn't any obvious way to build these things (I told you
> I was a newbie!).  I built a part of the Rolodex example, and now I'm
> looking at it and saying to myself:  What's the best way to align these
> boxes?  A grid mode would help this tremendously, but if it's available
> I can't figure it out.
>
> Then I say:  If I were to want to print this out, what would the
> printout look like?  It wouldn't look like the data entry screen, so
> having a basic association between the text field and the data is the
> wrong organization.  There needs to be a database (even a flat file
> would be better!) underneath this, and the entry form needs to be just
> one view of the data.  A report would be another.  Different views could
> have different sorts, so perhaps an indexing system needs to be a part
> of the view ...  etc. (This sounds like it might be MVC, but the
> tutorials seem to ignore that option.)  Now how do I print it out
> scrolling down the page 2 columns wide?
>
> Perhaps one of the other Smalltalks can handle this.  But the last time
> I checked into this (a couple of years ago) none of the ones that I
> could afford to evaluate could.  And most of them were tied to Windows.
>  (The actual reason that I'm looking at Squeak is in hopes that it could
> be an acceptable cross-platform development environment.  I've also been
> looking at Ruby and Python, but they don't have very good GUI
> environments.  [Fox works ok on Windows, but the Linux version of
> FxRuby, e.g., never seems to work with the version of Fox that got
> installed.].  And it's also difficult to create a packaged program with
> them, though Python has some tools that make it possible if not easy.)
>
> These don't seem to be intrinsic weaknesses.  In fact, they all look
> pretty elementary (if complicated).  But new users can't do anything to
> fix them.  And can't even produce a toy application that's good enough
> to show to the boss.  (The right-click halo alone is enough to prevent
> that.)  So I may use Squeak at home, but until these are repaired (or
> until I know how to work around them) I'll never be able to use it in my
> job.
>
>
>
>
>




More information about the Squeak-dev mailing list