Design Principles Behind Smalltalk, Revisited

When I was looking at GST vs. Ruby benchmarks today,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gst&lang2=ruby
I came across a link at the bottom to the original "Design Principles
Behind Smalltalk" paper by Dan Ingalls, see:
http://users.ipa.net/~dwighth/smalltalk/byte_augc81/design_principles_behind_smalltalk.html

This essay attempts to look at Dan's 1981 essay and move beyond it,
especially by considering supporting creativity by a group instead of
creativity by an isolated individual, and also by calling into question
"objects" as a sole major metaphor for a system supporting creativity.
Some of this thinking about "objects" is informed by the late William
Kent's work, especiallyKent's book "Data & Reality":
   http://www.bkent.net/
   http://www.bkent.net/Doc/darxrp.htm
Presumably the original paper reflects not just Dan's work and thinking,
but that of Alan Kay and the larger Learning Research Group at Xerox Parc
at the time, but I will refer to it as Dan's writing, because his is the
only name on it.

Mainly I will consider the first half of the paper. This essay is perhaps
a little in the spirit of 'The Rise of "Worse is Better"',
   http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
and is intended to help in understanding why, say, Python has been so
successful in capturing the hearts and minds of the last decade of
development, running core systems from Google to NASA, whereas Squeak
Smalltalk has remained a niche project during that time. And this is true
even though we all know that Squeak is better than Python in oh so many
ways (with a more expandable and more self-documenting syntax using
key:words: instead of functions, better transparency from top to bottom of
the system, better core graphics engine, better community in terms of very
bright people capable of handling a high level of abstraction, better core
tools, more consistent language model, better streams and number classes,
more portable VM, better dynamic development where you can code in the
debugger and restart a method instead of an application, and so on).
Still, for all those Squeak advantages, I think, the same applies for
Squeak Smalltalk as Richard Gabriel of 'The Rise of "Worse is Better"'
says of Lisp, "... one can conclude only that the Lisp community needs to
seriously rethink its position on Lisp design."

That "Worse is Better" paper probably has had little effect on changing
Lisp the language, and I doubt this note will have much effect on Squeak
the system. :-) Ultimately languages (and the mailing lists that support
them) are somewhat self-selecting -- if you have major problems with the
language or paradigm, you probably are not using Squeak or on the Squeak
development list. Still, I found it of value to me to write up these
issues, in terms of thinking of the next generation of tools and users,
and I hope some Squeakers out there find it of value to read.

First off, I agree with Dan's stated goal of a quarter century back: "The
purpose of the Smalltalk project is to provide computer support for the
creative spirit in everyone." So, overall, there is no difference in goal
when broadly construed.

This essay will outline some points of disagreement with how to best
support that goal. Some of this disagreement will be from a coming at the
notion of how to support creativity different perspective, especially
given how the computing landscape has changed due to the very success of
the object-oriented and networked GUI paradigms which Smalltalk (and the
Alto it was developed on) pioneered. As Steve Jobs said:
   http://americanhistory.si.edu/collections/comphist/sj1.html
"SJ: ... I saw their early computer called the Alto which was a phenomenal
computer and they actually showed me three things there that they had
working in 1976. I saw them in 1979. Things that took really until a few
years ago for us to fully recreate, for the industry to fully recreate in
this case with NeXTStep. However, I didn't see all three of those things.
I only saw the first one which was so incredible to me that it saturated
me. It blinded me to see the other two. It took me years to recreate them
and rediscover them and incorporate them back into the model but they were
very far ahead in their thinking. They didn't have it totally right, but
they had the germ of the idea of all three things. And the three things
were graphical user interfaces, object oriented computing and networking."

=== creativity by an individual versus creativity by a group ===

Dan wrote in the paper: "If a system is to serve the creative spirit, it
must be entirely comprehensible to a single individual."

I strongly disagree with this, as much as I still agree with his later
statement of: "Any barrier that exists between the user and some part of
the system will eventually be a barrier to creative expression."

The disagreement comes from considering the idea of creativity of a
community involving building on the work of others (where such work you
use may be beyond your ability to either fully comprehend or modify). Or,
is what is best for the individual in conflict with what is best for the
group? And if so, which should win? While ideally, any system should have
no barriers to the individual user, in practice, it may, and yet may still
support a large amount of creativity by the group, sometimes directly
because of those barriers. Another way to think of a barrier is an
"interface" or a "firewall", and those have some positive connotations.
Even Smalltalk's very success is due in part to creating a strong barrier
at run-time  between the user image of objects and the VM which supports
it; this is a barrier which people have complained about, with the phrase
"if you can't crash it, you're not doing the driving. " :-)

Consider, for example, the success of Python, which is a mostly
object-oriented language core written in C, where lots of other libraries
have been bolted on to it by the community. It is this widespread
availability of useful libraries which drives Python adoption more than
any other thing. (Same with Perl adoption.) Python has other ideas which
proves popular, like its use of significant white space like Occam used,
having dictionaries built in and easy to use, and looking a lot like C,
but it is the libraries and the related modularity which is one of the
biggest wins for Python. Well, and that you can write a program in a few
lines in a text editor that use those great libraries, making it easy to
build small things with little learning. I think this sentiment of
focusing on empowering the individual primarily, indirectly at the expense
of empowering the community, was why Squeak Smalltalk has suffered from
poor modularity so often and why, for example, it took so long to get
namespaces and such into the mainstream, and also why it has struggled to
have as many libraries as Python offers.

So while I think Dan's original goal is a nice ideal, in practice it is
not needed in the extreme, since the creativity of a group sharing, say, a
community mailing list, will still move beyond the creativity of any
individual in the group. So, it is *more* important in the internet age to
have techniques for supporting group creativity, including modularity,
than it is for the system to not have any barriers. That is probably one
reason a system like Python is actually used in practice by more people to
do creative things than Smalltalk. Python makes it easy for many
individuals to do small things. While Python as a language and as an
environment in practice does not scale as well as Smalltalk, the aggregate
amount of all  those individuals doing small things overwhelms what any
one Smalltalker can do (or even a small group of them stepping on each
others' toes and watching their contributions suffer from "bit rot").

Another issue here is that Dan was writing 25 years ago in the context of
a *proprietary* system. So, availability of all the code within that
system to the user was essential for creativity, even if the code was
controlled by someone else, since otherwise the individual had no access
to the code ever. But, when working with open systems based on free
software, the code and tools to work with it are accessible to anyone,
even if they are in other languages or supported by other communities,
say, GCC community, than the community one is currently working in (say,
GNU Smalltalk).

Again, to contrast with Python, Squeak wants to run the show, but Python
plays nice with all the other free tools of the GNU/Linux ecosystem. When
you use Python, your environment is not just Python; it is really more
like GNU/Linux. So, free (as in "freedom") software -- with accompanying
free licenses like the GPL that work as de-facto constitutions for
collaborative communities -- has shifted the landscape, and the
development ideals may need to shift with it. This is another reason why
Python, which has always been free and had a core community with those
values, has been able to succeed so quickly over the past decade, whereas
Smalltalk, which was originally proprietary, has struggled, even though a
free-ish Smalltalk like Squeak is much more accessible to easier
modification in many ways than Python.

=== technical versus conceptual barriers ====

Another issue here is that Dan is talking about "technical" barriers,
which are not the only, or even the biggest, barriers to creativity. There
often exist "conceptual" barriers. It is in the "failure of the
imagination" that we face our biggest hurdles. Imagination is indeed "the
ultimate resource".

For example, the code to generate the VM in Squeak needs a certain mindset
to understand; one has to think about the domain of bit manipulations.
Even though the syntax looks like Smalltalk, the domain is very different
from your run-of-the-mill GUI application or eToy. While it is indeed an
innovation to use Smalltalk syntax in an uncommon domain, and indeed
Smalltalk's syntax is a marvel which can make unnecessary many "domain
specific languages", one can not get around the conceptual barrier of a
programmer understanding a new domain, as much as a familiar syntax might
help with the task.

Thus, barriers will always exist in any programming system, since all
interesting programs probably address new domains (or old domains in new
ways). So, again, while the goal Dan defined twenty five years ago is
"ideal", it is an ideal that can never be reached because of conceptual
barriers encountered when working in multiple domains, even in a pure
Smalltalk system which minimizes arbitrary technical barriers like
differing syntax. Forcing everyone to work in Smalltalk using Smalltalk
tools, as good as they are, means that other innovations developed in
other languages with other tools, for example, Java, are lost to the
Squeak community. Yes, in theory, anything is possible, especially with
Squeaks interface to loadable modules; I am speaking more of tone and
emphasis and culture here.

And, if it is so often the conceptual barrier that is the ultimate hurdle,
then are technical barriers of different syntax and different tools really
so big? Many humans become fluent in multiple human languages and their
accompanying cultures, which is typically a harder thing than learning new
computer languages. If one needs to switch mental gears conceptually to
work on the VM, then is it *really* so bad if the VM is written directly
in C like GNU Smalltalk does? Now, I know a lot of positive arguments can
be made for the utility and convenience of the Squeak VM written in
Smalltalk (especially given C's quirks as a not-quite-cross-platform
language), but in the end, my point is, keeping everything in one syntax
may not really save that much time for the community, all things
considered. Even when the syntax is the same, the underlying domain
semantics may be very different, and those semantics, or meaning of all
the objects, are what take the time to learn. To build a new VM, one still
needs to spend a long time understanding what a VM is and how it could
work, and no choice of familiar tools or use of one single syntax will
make that extremely easier (a little easier, yes). A better choice of
abstraction perhaps might make maintain a VM easier for those who get the
abstraction, but not a choice of language by itself all other things being
equal. Were the Squeak VM coded in some other portable language (like Java
or Free Pascal or OCaml) then it might not take very much more trouble to
maintain -- and such a VM might even be easier to develop, as one could
use the complete tool set of that other system to debug the VM in the
language it was maintained in, rather than facing a technical barrier :-)
of seeing C code for the VM in the debugger instead of the original
Smalltalk source which was translated from. Granted, if the Squeak VM was
coded in, say, OCaml, one would have a barrier to an VM maintainer of
learning that language and its paradigms, but I would argue that the
barrier would remain more conceptual than technical, and the syntax
problem would be the lesser issue.

Right now, I think Squeak on the JVM, like Talks2 is a step towards, could
be a really big win for the Squeak community, and translating the VM from
an abstract representation (in Smalltalk) to a specific language is a big
win there. Still, the VM could have been in any translatable abstraction
(XML, Lisp, ANTLR parse tree from a VM-specific language, Parrot, etc.)
and generating Java would still be easily doable (though of course
Smalltalk encoding is preferable for Smalltalkers). Also it is not clear
even if this is a big win, if it is a big enough win to justify other
aspects making VMs harder to debug and maintain by having an intermediate
translation step, compared to just working in a language that is more
cross-platform by design than C, where somebody else does the hard work of
maintaining that other platform. Again, here is the issue of community
support versus individual support, and related assumptions.

=== Language versus "group computation" =====

I really like the "Figure 1" diagram in the original paper. And it remains
a useful illumination of the problem area. Still, the bold statement
"Purpose of Language: To provide a framework for communication" may not be
the entire picture. What if one drops the big idea of "Language" entirely
and focuses instead on "computation"? Consider if two or more people are
not so much engaging in "language" as they talk, but instead are engaging
in a "group computation", where utterances between group members plays a
facilitating role. So, from this point of view, the major goal has to be
allowing the group to compute effectively, whatever that takes. Language
is one aspect of this. But the, so are licenses. So are communications
channels. So are formal and informal community processes. And so on to all
of sociology and politics. In a way, by elevating "language" as a
paradigm, many of these other aspects could be missed.  Squeak the
community has certainly suffered on some of these issues at various times
(though recent efforts, especially on relicensing even it just had PR
value, are hopeful sign).

Also, consider, the latest thinking on cognitive psychology and AI
includes that the human brain simultaneously thinks about problems in
multiple representations, and chooses second-by-second the representation
that pays off the most in making progress towards goals. So for example,
we may look out the window at a rainy day with a goal of going to the
store by car, and we may simultaneously imagine becoming wet as a sort of
3D world simulation of rain falling on our heads as we venture to the car
in our imagination, engage in formal logic based on linguistic experience
("if rain, then take umbrella"), use neural net pattern matching to get
the most common behavior in the gestalt of the situation (it just feels
right to reach for the umbrella based on the gestalt of the situation),
plus we be mentally making a two-D map of a route an areas with obstacles
(rain between self and car) and considering ways to make progress through
the 2D representation of a rain obstacle. So here we might have four
different representations we might be using simultaneously, which each
have parsed the world differently, perhaps into "objects" of various sorts
or perhaps not. One or more of them may prove most useful and drive our
behavior for that moment.

Language is only playing a direct role in one of those representations in
this case, the formal symbolic-logical process. Language may play a role
in the others representations as well as we internally reflect with
language (generating internal questions like "why do I feel like reaching
for the umbrella?" Or, "How can I overcome the rain barrier?" etc.).
However the other representational schemes may also be applied to the
formal linguistic-symbolic representation or to each other.

In short, we now know that viewing the mind as solely about "language" is
an overly simplistic way of thinking about it. And if the paradigm has
grown, then so too should our computer support systems, in order to honor
the insight in the original paper of: "The mechanisms of human thought and
communication have been engineered for millions of years, and we should
respect them as being of sound design. Moreover, since we must work with
this design for the next million years, it will save time if we make our
computer models compatible with the mind, rather that the other way around."

One of those forces shaping the mechanisms of human thought has been how
it is the *group* which survives in the wilderness; the lone *individual*
is rapidly picked off by accidents (say, a broken leg) or runs into
trouble (say, a pack of coyotes) beyond his or her individual ability to
cope. (That's one reason it's foolish to think you can survive an
apocalyptic disaster long term by running away to the wilderness on your
own.) When a village defends itself against a large pack of coyotes, even
with verbal shouts and grunts to the coyotes or between villagers, what is
going on is in some ways is primarily a coyote defense "computation"
involving all the villagers and all their thinking (which may be operating
lots of simultaneous decision making models), not just a "discussion"
among villagers about coyotes, as useful as language may be in helping
that larger group computation to come to a successful conclusion. So in a
tool to enhance group creativity, we must consider all the ways to enhance
these creative group computations, and those go beyond just supporting a
common language.

== objects are an illusions, but useful ones ===

In my undergraduate work in psychology I wrote a senior paper in 1985
entitled: "Why intelligence: Object, Evolution, Stability, and Model"
where I argued the impression of a world of well-defined objects is an
illusion, but a useful one. Considered in the context of the section
above, we can also see that how you parse the world into objects may
depend on the particular goal you have (reaching your car without being
wet) or the particular approach you are taking to reaching the goal
(either the strategy, walking outside, or any helping tool used, like a
neural net or 2D map). Yet, the world is the same, even as what we
consider to be an "object" may vary from time to time; in one situation
"rain" might be an object, in another a "rain drop" might be an object, in
another the weather might be of little interest. So objects are a
*convenience* to reaching goals (in terms of internal states), not reality
(which our best physics says is more continuous than anything else in
terms of quantum probabilities, or at best, more conventionally a
particle-wave duality). So objects, as tools of thought, then have no
meaning apart from the context in which we create them -- and the contexts
include our viewpoints, our goals, our tools, or history, or relations to
the community, and so on.

Consider Dan's statement of "A computer language should support the
concept of "object" and provide a uniform means for referring to the
objects in its universe." That appears to me to have made a classical
mistake of thinking the universe has only one parsing into one object
hierarchy and that the objects exist in some sort of Platonic ideal. See
Plato's "Allegory of the Cave" for the best example of the mistaken notion
of only one true parsing, even though as the social commentary it may
still be accurate: :-).
   http://faculty.washington.edu/smcohen/320/cave.htm
   http://www.ship.edu/~cgboeree/platoscave.html
As discussed above, the world does not have just one unique parsing into
objects. Or, to bend Plato's allegory, that we sometimes find apparently
discrete "shadows" useful to perceive and think about as "objects" does
not mean there really are discrete ideal things out there casting those
shadows, with any sort of one-to-one correspondence. Again, this is not to
say objects are not useful, just that they are a tool.

To use an example from the paper, when Dan wrote: "Every time you want to
talk about "that chair over there", you must repeat the entire processes
of distinguishing that chair. This is where the act of reference comes in:
we can associate a unique identifier with an object, and, from that time
on, only the mention of that identifier is necessary to refer to the
original object." That sounds really nice on the surface. But consider,
what if the "chair" is glued to the floor? You think it is an "object" but
there is no clear real boundary between it and the floor. And when you
attempt to move it, what if the floor boards come up with it? You now have
an entity you are manipulating which is not quite a "chair" and not quite
a "floor" -- what is it? There is no neat "class" to put it in. Clearly
you, the reader, can think about this entity so the human brain supports
this fluidity in changing our definitions of objects and not requiring a
one-to-one mapping to ideal classes to think about them, but a computer
language like Smalltalk would have many problems representing this.
William Kent, in the book _Data & Reality_ discusses these sorts of
problems at length.

Sure, you could make a new object for the combined entity, but what if
then you decided to take apart the chair into cushions, legs (with floor
boards still glued on), a back, and lots of bolts? Now you have lots of
new objects? Sure, but then how do you reference about all the objects and
all their relations in all possible permutations consistently? Your mind
can do it easily; a Smalltalk class hierarchy and related application
would struggle to do it, at best.

Sure there are design patterns for some of these things (like "Facade")
but they are not completely reflected in a system which has an overly
static notion of "object". Smalltalk has some ways to deal with these
things, like "becomes:", but that is not dealing with this problem in all
its generality. You can simultaneously think about an original chair, a
chair with floor boards stuck on it, and a chair taken apart -- so your
mind is capable of much more imaginative representational power than a
simple notion of "objects".

Again, discrete objects are a useful tool to think with, but they are not
the only tool, and they are not as stable a tool as one might think at
first glance. Objects are useful within contexts. Yet, Smalltalk lacks a
formal notion of an object having a context (or imaginative world) which
defines its meaning. When people (including Alan Kay) talk about Smalltalk
they often say to the effect that objects are self-contained. But clearly
they are not. Their meaning emerges out of their interactions with a world
of other objects. Yet modern Smalltalk have not formalized the notion of a
world of objects beyond a very coarse-grained kitchen-sink "image". It
would seem one needs finer-grained contexts, be they "worlds", "modules",
or some other thing.

==== talking to an object vs. manipulating it ====

Consider this statement from the paper: "Computing should be viewed as an
intrinsic capability of objects that can be uniformly invoked by sending
messages." It sounds uniform (from an implementation point of view), yet
it violates the human notion of how most of our time is spent actually
interacting with "objects". When we use language, we are generally talking
to ourself or other people; most items in the world don't respond directly
to language. We use our hands or feet or whatever to manipulate them -- to
move them or change their internal configuration. Not every object in the
real world has a name or knows what the best inspector is for it; in fact,
very few of them do, except perhaps people. When we pick up a rock, we try
different tools on it if we want to observe it. We classify it ourselves;
we don't ask it its class. We may stick a label on it and put it in a
museum, but that is an active effort of categorization. And we may later
change our minds about how to label it. Or we may break it into two parts
(plus some rock fragments), and grind one of the parts up into rock dust
and put some of the dust through various chemical processes over a period
of years (say, if it was originally a "moon rock"). A moon rock does not
know how to perform chemical analysis on itself or even split itself in
two, yet Smalltalk philosophy encourages making models of reality as if a
moon rock did.

I think the issue shows why languages like Lisp or Python (a Lisp
derivative in some ways) or even C++ have hung on so well, both as
philosophies and communities. In those languages you often have data
structures which are operated on externally by large subroutines. And
people who like these languages claim they like to sometimes do OO when
they want it (OO meaning behavior emerges from a lot of interacting
objects), or at other times to do these sorts of external manipulations on
sets of inert objects using complex routines. Manipulating otherwise
inert-seeming objects according to our fancy of the moment is something
that people are comfortable with, and likely a big part of our mind is
structured to do that well. Yes, we do talk to people or certain animals
(or now certain devices). But we also do a lot of manipulation by hand (or
foot etc.) and classification by eye (or ear or touch).

So, this suggests perhaps it is a mistake to have an object hierarchy
where at the top everything knows its name or how to put data into its own
slots. What's wrong with, say, asking the VM to put data into an objects
slots? Or asking the VM for the ID of an object? Why should objects be
expected to be so smart when we programmers are surrounded in the real
world with objects which are usually quite dumb? This a violation of the
good principles that Dan starts out the paper with -- to make a system
which maps well onto how humans think. Humans both talk and manipulate, so
it would seem a system should support both styles of interaction. Granted,
it is almost trivial in Smalltalk to reach into other objects and
manipulate them, but my point is that Smalltalk is not presented that way,
and such interactions are generally discouraged as bad practice. Somehow I
  feel this issue needs to be revisited. Among newer GUI interfaces, like
Morphic, there is an emphasis on direct manipulation. Yet, somehow, this
notion is discouraged in programming. There is a paradigm conflict here
which needs to be addressed.

== summing up==

I don't have time or energy right now to go into the rest of this
excellent paper in detail; much is either on the value of modularity,
which I agree with (even as Squeak Smalltalk may not have enough of it in
practice), or implementation strategy or GUI (which is a whole other can
of worms).

But let me say these criticisms are made with (perhaps) 20/20 hindsight a
quarter century later. Dan himself may have come to these insights or
better ones by now; no doubt like many people when contemplating their
earlier work of decades gone by, they can be both proud of it and
embarrassed by it at the same time (I know I am). As Dan said insightfully
in the conclusion: "There are clearly other aspects to human thought that
have not been addressed in this paper. These must be identified as
metaphors that can complement the existing models of the language."
This essay is intended along those very lines Dan mapped out so long ago.

For its time, the original paper is a remarkable achievement, as is
Smalltalk-80. It is only because of such great work that we can think
about moving forward onto even greater projects.

But what I find most illuminating stumbling across this paper again (I
probably read it in Byte way back when) is that now, in retrospect, it
seems to explain both the ways Smalltalk would *succeed* spectacularly in
the goal of making (*some*) individuals more creative (though, contrast
with Howard Gardener's theory of *multiple intelligences* including
non-language ones, see the list here:)
   http://www.infed.org/thinkers/gardner.htm
and also the ways Smalltalk would *fail* (somewhat) in making groups more
creative (which it was not designed to do), compared to, say, Python
(which is not as scalable for individual user's creative projects, but has
other advantages in a group context).

Subconsciously it may be these sorts of issues that motivate would-be
Squeakers to have an interest in, say, Python. And these sorts of issues
may be implicitly behind some of the specific issues Squeak has wrestled
with both as an implementation and as a community. Obviously, the Squeak
community, especially with, say, Monticello or Croquet, is trying to
bridge this gap to support group creativity. OpenAugment, based on Squeak,
is indirectly another such project.
   http://www.openaugment.org/
So it is not like there are no attempts to recognize some of these issues
and move forward. But perhaps the original "Design Principles Behind
Smalltalk" paper (as it unconsciously resonates about in the Smalltalk
community, and even in the minds of core Squeakers) now holds Smalltalk
(and Squeak) back, as much as that paper propelled Smalltalk forward for a
quarter century.

--Paul Fernhout
(I hearby place this essay under the GPL, version 2 or later; and also the
GFDL with no invariant sections).

One doesn't have to look far for this.  C became popular for no other reason
then it was "close enough" and we could use it "right now" to build systems.
  The more advanced languages used resources when there were no resources to
use.

"The rise of worse is better" largely misses the point here.  The point is:
getting 80% today is infinitely better then 100% "some day".  And all the
rest is just the incredible weight of "backward compatibility".

And the concept of backward compatibility isn't just software and hardware.  
It extends to workers as well.  The average programmer is just not very good
(and I don't speak about the worth of the people as human beings.  There are
just so many in the field with no interest in it other then money, which is
totally ok.  It just doesn't make for good programmers).  The cost of moving
people who are barely keeping up from C++ to Java isn't so bad.  It actually
makes things simpler:  just the same syntax again with much of what they
didn't understand taken out.  But moving these folks away from a C based
syntax is out of the question.  And getting rid of them in favor of more
talented programmers would be just as out of the question.

>Again, to contrast with Python, Squeak wants to run the show, but Python
>plays nice with all the other free tools of the GNU/Linux ecosystem.

I keep on seeing this, but it appears largely overstated.  Java has it's own
VM, threads etc. as well.  And it is easier to connect to the outside world
in Squeak then Java, because in java you are in "your on your own!" land.  
In Squeak you always were so there is no need to be afraid of this step if
you need it.  In at least Squeak and Dolphin smalltalk you can call "extern
C" style functions directly from smalltalk (thought in squeak you need to
load FFI first).  That is at least as good as any of the other languages.

And if you mean more to address the tools, well yes you *can* edit Java code
in vi if you really want to.  But no one really wants to.  And if your
interface to the language is through some program anyway, then the "barrier"
of the code not being on the file system disappears.

>Forcing everyone to work in Smalltalk using Smalltalk tools, as good as
>they are, means that other innovations developed in other languages with
>other tools, for example, Java, are lost to the Squeak community.

Um... What innovations in Java?

>Many humans become fluent in multiple human languages and their
>accompanying cultures, which is typically a harder thing than learning new
>computer languages. If one needs to switch mental gears conceptually to
>work on the VM, then is it *really* so bad if the VM is written directly in
>C like GNU Smalltalk does?

Typically?  It is harder in every case, no matter how badly designed the
programming language.

And what do you want to gain here?  If the squeak community came out today
and said "Ok!  You can write the squeak VM in anything you want, we don't
care", they wouldn't suddenly get volunteers knocking the doors down to work
on squeak.  They would only lose people who can work on the VM today (not
because these people *can't* do it, but because they wouldn't want to
anymore).

While I agree that squeak is not required to be written in a subset of
smalltalk, it *is* and changing it wont gain anything.  Getting squeak to
run on strong talk might, but I haven't seen anyone forbidding that.

>Right now, I think Squeak on the JVM, like Talks2 is a step towards, could
>be a really big win for the Squeak community, and translating the VM from
>an abstract representation (in Smalltalk) to a specific language is a big
>win there. Still, the VM could have been in any translatable abstraction
>(XML, Lisp, ANTLR parse tree from a VM-specific language, Parrot, etc.) and
>generating Java would still be easily doable (though of course Smalltalk
>encoding is preferable for Smalltalkers).

Java isn't the end-all/be-all here.  Microsoft is moving to a more dynamic
VM already, and because of this Java will be forced to as well.  Java has
always been behind pre-existing technologies and this area is no different.  
If you want to move into the future it is best not to follow a group that is
always behind.

To me this was the most insightful point in the whole essay.  Though,
honestly I thought this was pretty well understood.  Object Orientation is
simply a way of organizing code in a way that makes sense from the
perspective of the problem domain it is related to.  But since programming
is a task of managing complexity, correct organization is a critical piece
of the puzzle.

But this observation is the reason OO databases haven't really taken off:  
An OO database will tend to model things how *your* application wants to see
them.  A traditional relational DBA will model things in the most generic
way he can so that *all* the applications can build the view they need
easily.  Relational DBA's tend to be of the view point: The data will exist
for the life of the company, while the applications that access it come and
go like the tide.  And one only needs to look at the huge Java rewrites
going on to know they are right.

>Consider Dan's statement of "A computer language should support the concept
>of "object" and provide a uniform means for referring to the objects in its
>universe." That appears to me to have made a classical mistake of thinking
>the universe has only one parsing into one object hierarchy and that the
>objects exist in some sort of Platonic ideal.

Actually I think this applies more to C++ derived OO languages (e.g. Java).  
It is those languages that have huge hierarchies of things that are not that
related due to the brain-dead typing systems.  In smalltalk the only
hierarchy that has to be is inheriting from Object.  And you don't even have
to do that.

But I think this works just fine:  We are choosing to code something, so we
have to model it in the point of view appropriate to how we are going to
solve the problem.  And this implies some organization technique.  And among
organization techniques, (correct) OO has had the most success in my
opinion.

><chair part snipped> There is no neat "class" to put it in.

I wouldn't expect it to be in a class.  I would expect classes to know how
to stick to each other. :)

>Clearly you, the reader, can think about this entity so the human brain
>supports this fluidity in changing our definitions of objects and not
>requiring a one-to-one mapping to ideal classes to think about them, but a
>computer language like Smalltalk would have many problems representing
>this. William Kent, in the book _Data & Reality_ discusses these sorts of
>problems at length.
>

I disagree with where the focus is placed here.  An entity typically does
have just one name and would make sense to be called one thing in the
system.  What you are describing sounds more like interface protocols.  This
might be an area that could use more research, but honestly I would want to
know what is bought by formalizing this existing practice more (e.g. making
protocols first class objects themselves or something).

For an example of what I mean, in case it isn't that clear, we could think
about Lists.  They have a collection protocol: a series of messages that
conform to what other collections can do.  But they could also have a
"stack" protocol: a series of messages for treating the list as though it
were a stack.

This could be seen as what we do in real life.  Due to necessity I may find
myself driving a nail into a piece of wood with a screw driver.  But I would
never call what is in my hand a hammer.  I would simply be using it's "blunt
object" interface momentarily.

Thanks,
JJ

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001

J J wrote:
> One doesn't have to look far for this.  C became popular for no other
> reason then it was "close enough" and we could use it "right now" to
> build systems.  The more advanced languages used resources when there
> were no resources to use.

Paul Graham has an essay on why languages become popular:
   http://www.paulgraham.com/popular.html
In the case of both C and C++, one should not discount the wight of AT&T,
one of the largest and most widespread and visible companies of the time
(as it ran a telephone monopoly). Similarly, without the backing of both
Sun and IBM, Java might well never have taken off. Clearly Smalltalk was
much better than Java in many ways when it was released:
   http://www.oreillynet.com/ruby/blog/2006/01/bambi_meets_godzilla.html
And, before Java,. people were actively converting too it as a "COBOL for
the 1990s"; and either C++ or Smalltalk were both so different from COBOL,
that there was no huge difference in ease of understanding either syntax
for COBOL programmers; in fact, Smalltalk was closer to COBOL's use of
complete words without arbitrary abbreviations if anything.

Well, it is also true one big issue is that an Algol-like syntax with
operator precedence (times over plus) is taught in K-12 school. That is a
big advantage for a computer language to build on that, even as that
precedence is arbitrary and Smalltalk is more consistent. And you are
right on how Java seemed an easy move for C++ programmers. Of course, now
Ruby seems an easy move for Java programmers (and much of Ruby is based on
Smalltalk ideas), so in a matter of time, we may see Ruby developers
making the leap to a more self-documenting and flexible syntax. :-)

Still, Smalltalk syntax was supposedly designed to be easy for kids to
learn. It is not that hard to learn the syntax. I've helped people in
business learn it. It takes at most  week to become proficient in it (and
often just a day). What is hard is to learn all the libraries. But, with
more and more programmers learning things like Java or Python or Ruby, all
systems with rich libraries, Ruby's being almost exactly Smalltalk's in
many ways, making the leap to a new syntax would be a minor investment
(and one worth taking because Smalltalk syntax is more extensible and
self-documenting than any of those other languages').

People are changing languages all the time. People have moved to Python;
people are moving to Ruby; people have even moved to languages like Perl,
which have much more tortured syntaxes or PHP which have much more limited
libraries. People learned HTML out of the blue because they wanted to do
web sites, and HTML is a much harder syntax to work in than Smalltalk's in
many ways (though you can edit in vi and then see immediate results in
your local web browser). So, why not people moving to Smalltalk (Squeak
especially)?  People in Python or Perl or PHP or Ruby camps are not
bemoaning "backward compatibility" as the reason for limited success and
adoption. While everything you say it true, it is not true enough IMHO to
be the main reason. What are the others and how can they be addressed to
produce a popular free Smalltalk?

True. Though there can still be a difference in "culture" of the
communities surrounding a language. Clearly Smalltalk's (or Squeak's)
culture is very different than Python's. I wrote something on that here,
in terms of how the cultures of the communities relate to their histories:
   http://mail.python.org/pipermail/edu-sig/2006-December/007476.html

> And if you mean more to address the tools, well yes you *can* edit Java
> code in vi if you really want to.  But no one really wants to.  And if
> your interface to the language is through some program anyway, then the
> "barrier" of the code not being on the file system disappears.

Well, there is a bigger difference here between Python (which I mentioned)
and Java (which you mentioned). Python plays nicer with UNIX-y systems
than Java in many ways, mostly because Python is smaller, historically had
a faster startup time, and earlier had more comprehensive libraries for
interfacing with UNIX-y libraries. My point was more for Python, which is
being billed as a "glue" languages -- something to glue together your C
libraries.

Java is different, as you point out. However, Java is so different, and
received so much attention, and incorporated so many Smalltalk-pioneered
ideas in the JVM design and class libraries (Swing) that ten years after
it has been introduced, it finally mostly works right as a self-contained
environment. Not quite VisualWorks, but darn close in many ways by now,
and it is free as in beer and is becoming free as in freedom (GPL). :-)

But for both Java and Python, being able to be easily edited in vi (or
emacs) or being able to use a conventional text oriented version control
system were indeed big wins, as they reduced the learning curve and
initial commitment to new ideas. Being able to use the familiar file
manager to look at code was also of value. And going beyond vi, the fact
that Java IDEs started to look like C++ IDEs was another big win on
familiarity. And seeing each class in a separate file in the good old
reliable file system was also comforting -- at least you knew where your
source is, and could use grep or other tools to search and manipulate it
and back it up in a familiar fashion. Talks2 shows this is possible --
having a directory of Smalltalk class files. It is possible to generate
text files from an image -- any Smalltalk can typically export such
classes. And it isn't that hard to export instances as text either (I made
something in Python that does it for instances in that language; any
Smalltalk could do much the same) which gives you an image defined by
textual program code to rebuild a world of objects.

>> Forcing everyone to work in Smalltalk using Smalltalk tools, as good
>> as they are, means that other innovations developed in other languages
>> with other tools, for example, Java, are lost to the Squeak community.
>
>
> Um... What innovations in Java?

Extensive tested and debugged libraries on a variety of topics.

>> Many humans become fluent in multiple human languages and their
>> accompanying cultures, which is typically a harder thing than learning
>> new computer languages. If one needs to switch mental gears
>> conceptually to work on the VM, then is it *really* so bad if the VM
>> is written directly in C like GNU Smalltalk does?
>
> Typically?  It is harder in every case, no matter how badly designed the
> programming language.

Well, Spanish to Portuguese might be easier than COBOL to OCaml? But COBOL
to OCaml is hard for different reasons than syntax. :-)

> And what do you want to gain here?  If the squeak community came out
> today and said "Ok!  You can write the squeak VM in anything you want,
> we don't care", they wouldn't suddenly get volunteers knocking the doors
> down to work on squeak.  They would only lose people who can work on the
> VM today (not because these people *can't* do it, but because they
> wouldn't want to anymore).
>
 > While I agree that squeak is not required to be written in a subset of
 > smalltalk, it *is* and changing it wont gain anything.  Getting squeak
 > to run on strong talk might, but I haven't seen anyone forbidding that.

My point here wasn't that Squeak should change; it was just an example of
how being different and staying entirely in Smalltalk might not have been
a big win, compared to just having a VM written in, say, C. There remains
the "conceptual" barrier of the VM domain, even as the "technical" one of
syntax is removed.

I am not against translating a VM from an abstract representation, in, say
Smalltalk. I think it is a clever idea, especially since it already has
been done. And with some more work, it might even gain the elegance of say
ANTLR's plugin for Eclipse, or ANTLRWorks, where you can step through the
abstraction in an IDE without seeing the underlying code (Java in ANTLR's
case). (Maybe Squeak can already do this by now?)

Still, having said that, a Smalltalk VM is so simple, consider this 47K
Public Domain one that does most of the work (from the Java version of A
Little Smalltalk, now called SmallWorld):
  http://budd.eecs.oregonstate.edu/~budd/SmallWorld/Source/SmallObject.java
so how hard is that to maintain a Smalltalk VM the original Java?

Translating primitives into C or Java, like for sound manipulation, seems
like a bigger win. But even then, you have to be writing that code (or
rewriting that code) in such a non-Smalltalk way semantically that it is
still not clear to me if there is a lot of value in it. Especially when
the alternative might be to just call an existing sound synthesis library
written in Java or C. We now have Java for a good cross-platform language
with equivalent to C++ performance, so it would have been a harder choice
ten years previously  as to what cross-platform language to use if not C
with all its quirks (Free Pascal?).

The value of Squeak on Java is a separate issue. The value is mostly to be
able to reduce deployment overhead, especially for systems that mix
Smalltalk and faster native-y code written in Java or another JVM
language; Talks2 already did a lot of this work.

But here again is an issue of culture. Who cares if Sun is "behind"; or if
Squeak runs 30% slower without some extra dynamic dispatch opcode in the
JVM? Speed is not Squeak's main problem. Being able to leverage Sun's JVM
and the fact that you can call AWT classes in the same way for any
platform Java runs on is a big win for Squeak IMHO, as it would reduce the
maintenance burden of it in terms of complexity of the common code base,
and would also make it easy to install one common package for any platform
Java runs on. Ten years ago, or even five, I myself would have laughed at
the value of this idea (as Java was so buggy and unstable and slow). But
most of the bugs have been fixed, the 1.5 JVM shares memory across JVMs
and does dynamic translation for speed, so Java finally, now that it is
going free under the GPL, has the potential to be a great cross-platform
tool where you get both a common base GUI window system as well as the
ability to deliver fast primitives written in Java, as well as access to a
lot of libraries someone else has already written and debugged for you.

The Squeak community could admit that it would be a big win to leverage
that "pink plane" success, even if it is "behind" and decide to move
forward on top of it, but in other "blue plane" directions. Or it can
continue to spend a lot of time dealing with time consuming basic issues
relating to packaging and testing C code for lots of platforms (which
essentially just duplicates the work the Java community is doing, but not
as well because of more limited people power).

dot net is a non-starter because it is proprietary (and may be covered by
patents). And I would not make this suggestion without basing it on Sun's
move to the GPL for Java. There are several JVM Smalltalk already of course.
   http://www.robert-tolksdorf.de/vmlanguages.html
But none have the power of Squeak. And, building on Squeak's strengths, it
could be an opportune time to also shake off licensing problems, say by
carefully comparing with and using GNU Smalltalk code when possible, or by
using an approach like Bistro to leverage Java libraries temporarily until
replacement versions in Smalltalk could be written in a true "clean room"
fashion.

But the bigger point, along the lines of this main "revisited" thread, is
that building on others work in a comprehensive way, like having a Squeak
on top of Java, even though it has been done somewhat with the excellent
Talks2, is something that goes against the grain of the community (and
quite possibly to its disadvantage).

Python, by contrast, runs on the JVM, using Jython, and has great
integration with Java. It has issues, and lags the main release, but
overall it is production quality (at least in earlier releases); and since
Java is such a difficult language to develop in because it is so verbose
with braces and passing through exceptions and types and such, Jython may
well be the big thing that makes Java continue to succeed. :-)
From:
   http://www.jython.org/Project/index.html
" Jython, lest you do not know of it, is the most compelling weapon the
Java platform has for its survival into the 21st century:-)  —Sean
McGrath, CTO, Propylon"

Why not have Squeak in that role too? But the deeper question is, why is
it not there already, and why has, say, Talks2 not gotten more effort
behind it? And I think that issue has to do with community issues and also
licensing issues than technology issues. (I myself would build on Talks2,
right now except it is stuck in the same licensing ambiguity Squeak is;
I'm hoping when Squeak gets that cleared up for itself, that Talks2 might
follow).

>> == objects are an illusions, but useful ones ===
 > [snip]
>
> To me this was the most insightful point in the whole essay.  Though,
> honestly I thought this was pretty well understood.  Object Orientation
> is simply a way of organizing code in a way that makes sense from the
> perspective of the problem domain it is related to.  But since
> programming is a task of managing complexity, correct organization is a
> critical piece of the puzzle.

When one thinks deeply about this, perhaps your point about organization
is the big missing piece of the puzzle. Yes, you are right, people build
models of systems with objects, and should admit those models are
imperfect. But there is no formal support for this process in the
environment, or between people, other than using basic Smalltalk tools
(Browser, Debugger, maybe Refactoring tools). Well, I guess you could use
one of the formal OO modelling approaches, like CRC cards, but even that
is oriented to getting one model -- not to managing a variety of possible
representations to be used simultaneously as appropriate. Perhaps a next
generation of OO systems needs to explicitly support this process somehow.
How, I do not know. I just have the question here, not the solution. I do
think having objects point to a context or world is perhaps a start, and I
did that in a couple frameworks I have made in either Python or Smalltalk.

> But this observation is the reason OO databases haven't really taken
> off:  An OO database will tend to model things how *your* application
> wants to see them.  A traditional relational DBA will model things in
> the most generic way he can so that *all* the applications can build the
> view they need easily.  Relational DBA's tend to be of the view point:
> The data will exist for the life of the company, while the applications
> that access it come and go like the tide.  And one only needs to look at
> the huge Java rewrites going on to know they are right.

Good point.

All true, but if you look at how people teach OO, and how people talk
about it, especially n  Smalltalk circles, I think the community and its
culture is somehow at odds with a greater flexibility. It's hard for me to
detail this precisely; it more has to do with tone. Certainly I like the
Smalltalk approach; it is just not enough.

That is one of the reasons I have been attracted to Prototypes, which
attempt to address issues like:
   http://en.wikipedia.org/wiki/Self_programming_language
"Experience with early OO languages like Smalltalk showed that this sort
of issue came up again and again. Systems would tend to grow to a point
and then become very rigid, as the basic classes deep below the
programmer's code grew to be simply "wrong". Without some way to easily
change the original class, serious problems could arise"

But prototypes have other problems, the biggest being difficulty being
self-documenting the way classes are. As someone put it to me, "if you
want to share something, you probably have to name it".

Formalizing protocols is one possible idea. Dan mentions it in his paper.

I thin the solutions to this issue lie in deeper directions. Classes or
instances or prototypes could be building blocks, perhaps, but we could
use other abstractions and better tools somehow. What these are, I do not
know for sure. Still, like Bill Kent, I think these may lie in the
direction of being able to model "relations" somehow.

--Paul Fernhout

Paul,

if you haven't seen it already, you might find the description of the Us
variation of Self (which makes it a kind of Smalltalk in my view)
interesting:

http://citeseer.ist.psu.edu/5049.html

You might also want to see Dan's Squeak-on-JVM (I don't have Java here,
so I can't test whether this URL still works):

http://Weather-Dimensions.com/Dan/ForwardToThePast.jnlp

Note that some people were interested in getting Squeak to run on top of
Strongtalk's VM and that would match your request for a non Smalltalk
syntax (it is written in C++).

While I can see how Python might seem like a success to be emulated from
a Squeaker's viewpoint, I am sure the notion would seem very funny to a
VisualBasic programmer.

I think there is still an important role for systems which can be
understood by a single person (an entirely separate issue from making it
easy or not to collaborate). There are huge advatanges of being able to
just pick up black boxes created by other people but there are also
costs - such systems tend to grow exponentially in size for linear gains
in functionality.

-- Jecel

Jecel Assumpcao Jr wrote:
> if you haven't seen it already, you might find the description of the Us
> variation of Self (which makes it a kind of Smalltalk in my view)
> interesting:
>
> http://citeseer.ist.psu.edu/5049.html

Thanks for the link. I'm not sure how this differs from regular Self? And
the paper is not online that I could find.

I spent a few months working on adding prototypes to Python inspired by
Squeak, Self, and Morphic (most of the effort was GUI related, as the
internal mechanism was fairly easy to add to Python); I succeeded, to some
extent, see:
   http://patapata.sourceforge.net/
but I did not like the results, see my postmortem critique here:
   http://patapata.sourceforge.net/critique.html

I would be curious about your opinion, as someone also very interested in
prototype based systems. :-) Essentially, the part of the critique of most
interest (or disinterest :-) to you would be this section: """The biggest
issue is that I learned that the seductive idea of prototypes may not be
as powerful as its execution (especially as an add-on to an existing
language). Consider what I wrote to someone else: "I've been repeatedly
confronted with the fact that prototype languages are powerful and elegant
but ultimately, like Forth, end up losing something related to documenting
programmer intent. Documenting intent is one of the most important part of
programming, and that is something that Smalltalk's formal class structure
enforces for most code over Self, just like C's named variables document
intent which gets lost manipulating Forth's data stack. Plus, it is hard
for any great language feature to offset issues like lack of community or
lack of comprehensive libraries." And after at person suggested you
usually need to name things before you can share them, I replied: "And I
agree on the issue of "naming" something in order to share it. Which gets
back to the issue I mentioned of "documenting intent". With the PataPata
system I made for Python, there was a choice point where I decided that
prototypes used by other prototypes as parents needed to be named (a
difference from Self). And I liked that choice. But then, what am I really
gaining over Smalltalk (except not having a class side, which is nice, but
is it worth the extra trouble and confusion?)" So, this leaves me
questioning the whole move to prototypes. That person also pointed out
previous work on "Exemplar based Smalltalk", so that is something I should
look into further, perhaps as a compromise with Prototypes when I
understand such previous work better."""

Anyway, while I still like prototypes in the same way I like Forth (or now
its functional cousin, "Joy");
   http://www.latrobe.edu.au/philosophy/phimvt/joy/forth-joy.html
it's just not clear to me that the cost (of being different from plain
Smalltalk) is worth it to not have a class side (which just gets
reinvented in other ways anyway, as one distinguished between the exemplar
an instance inherits from versus the code used to actually build an
appropriately configured prototype/instance on demand).

> You might also want to see Dan's Squeak-on-JVM (I don't have Java here,
> so I can't test whether this URL still works):
>
> http://Weather-Dimensions.com/Dan/ForwardToThePast.jnlp

Thanks for the link; yet it works. It hangs on me when I try to do certain
things with it (like resize the window) and some other things are broken
(like when I try to save the image) but I can evaluate "1 + 1" and get 2
in a Workspace! Launching via Web Start works exactly the way I hoped; one
click (and a security question) later and I am in Squeak. Terrific! Great
proof of concept. Redrawing is slower than it seems to me it has to be,
but just stuff to start improving.

I'd imagine one could take a similar approach and get a similar thing
working under an Apache license (the same idea perhaps but with an even
earlier version (1.1? 1.13?) of Squeak?). Although even then it is GPL
incompatible, and being GPL compatible is very important to me. Especially
for Java, given Sun is going GPL instead of Apache. Frustrating, once
again. So close, but so far.

Still, people run GPL applications on top of Apache web servers, so maybe
an Apache Squeak core would be good enough?  Musing out loud, in order to
make something like this meet the FSF definition of "free" or OSI "open
source", I would need to know the details of what Squeak version was in
the end put under Apache? And what an Apache license implied about
applications written on top of it?

> Note that some people were interested in getting Squeak to run on top of
> Strongtalk's VM and that would match your request for a non Smalltalk
> syntax (it is written in C++).

Again, I don't care if the VM is written in Smalltalk. I think it is
clever to make a VM in an abstract way, especially as it is already done
(even though there are some disadvantages). I'd much rather work in
Smalltalk syntax than other syntaxes (even Python). I was using it more as
an example of Squeak applying a design principle which may be obsolete in
the internet and free software age.

Good point.

--Paul Fernhout

On Dec 26, 2006, at 10:35 AM, Paul D. Fernhout wrote:

> Jecel Assumpcao Jr wrote:
>> if you haven't seen it already, you might find the description of  
>> the Us
>> variation of Self (which makes it a kind of Smalltalk in my view)
>> interesting:
>> http://citeseer.ist.psu.edu/5049.html
>
> Thanks for the link. I'm not sure how this differs from regular  
> Self? And the paper is not online that I could find.

The paper is available at the linked page.  Look at the top-right  
corner; I downloaded it by clicking on the 'PDF' link.

Josh

Paul D. Fernhout wrote:
> Jecel Assumpcao Jr wrote:
> > [Us paper]
> > http://citeseer.ist.psu.edu/5049.html
>
> Thanks for the link. I'm not sure how this differs from regular Self? And
> the paper is not online that I could find.

Clicking on the "PDF" link in the upper right corner of that page worked
for me just now. Self is an objective language, which means that the
code to be executed depends on the type of the receiver and on the
message selector. Us is a subjective language where the code to be
executed also depends on the context from which the message was sent.
This is an extension of the work on "layers" done in Smalltalk in the
PIE project.

An idea closely related to the "viewpoints" introduced in Us is "roles"
where the code also depends on the context. The difference is that when
you change viewpoints all objects change at the same time (like moving
your head in a 3D environment) while when you change a role only a
single object is affected (like rotating an object in a 3D environment).
Both of these features address some of your complaints about using
objects exclusively for everything.
 
> [patapata and documenting intent]

I think the issue is unrelated to class vs prototypes and is actually
about having a global catalog vs allowing loose objects. Even in
Smalltalk-80 you have loose objects (like "Set class"), of course, by
they are so closely coupled with cataloged objects that they don't
matter. As always, there are tradeoffs. Doing things one way will make
some stuff easier and others worse (without loose objects there is a
strong temptation to use block where you should really be defining new
objects, for example). We have a lot to learn about how to best organize
systems, specially when they are modular.

> [Squeak-on-JVM and licenses]

I think the extra step of getting Squeak 1.1 relicensed as Apache after
Apple had already agreed to relicense it as APSL 2 was more than we
could have hoped for. All code written after that is in the process of
being relicensed using the old X11 (often called "MIT") license. The
latter is GPL compatible, so as long as you are willing to do your own
replacement for Squeak 1.1 your legal needs would be met.

The whole point of the Slang trick was to be able to debug using all the
nice Squeak tools instead of gdb. Some people don't want that while for
others it makes all the difference in the world.

-- Jecel

Josh-

Thanks, I got it; missed that somehow.

--Paul Fernhout

Joshua Gargus wrote:

Hello Paul,

Interesting article. I am still looking at the linked material.

Have you looked at Lua?

http://www.lua.org

A very interesting language that I like a lot. It is very small has some
Smalltalk like characteristics, but is a Prototype language. Actually it
seems to handle various paradigms quite well. It has objects,
prototypes, modules, closures, coroutines, tail-recursive, etc. and a
very clean and small implementation in C. Very, very portable,
embeddable, and very fast. Compare it to Ruby, Python and GST on Alioth.
It integrates easily and well with libraries written in C, etc.  It is
the scripting language built into SciTE.

Its biggest weakness for me and many, is that it does not currently have
a rich set of libraries. But I believe that is very doable. I would love
to see Lua with a rich set of libraries like Python's. But it is not
without libraries. One would just need to see if it has what one needs.

I much prefer it as a language to both Python and Ruby. Its syntax is
clean and nice. I find it easier to think in Lua than either Python or
Ruby. And as one who is not a computer professional, the fact that I can
read the book over and over is a big plus. I finally understand
closures. :)  (at least as presented in PIL2)

I am hoping that someday soon that libraries could be written for Lua
and it have an equally rich system as Python or Ruby. A rich Lua system
arriving around or before Python 3, Ruby 2, etc. would provide for an
interesting alternative. And I don't believe it would have to equal
Python's or Ruby's to be an excellent alternative to Python or Ruby.

It isn't perfect. But I think its problems are definitely fixable.

Lua is MIT licensed. So it is compatible with anything you want to do.

Just wanted to toss that out there. Didn't quite mean to get so
evangelistic on the Squeak-list. But oh well. I love Squeak. But I've
learned to love Lua also. I just tolerate Python, no love. :)

Again thanks for the essay.

Jimmie Houchin
Homeschooling father of 9 ;)
   Yes I read your writings on edu-sig.

On Tue, 26 Dec 2006 05:52:26 -0800, Paul D. Fernhout  
<[hidden email]> wrote:

> In the case of both C and C++, one should not discount the wight of AT&T,

http://en.wikipedia.org/wiki/Wight

Indeed. :-)

> Well, it is also true one big issue is that an Algol-like syntax with  
> operator precedence (times over plus) is taught in K-12 school. That is  
> a big advantage for a computer language to build on that, even as that  
> precedence is arbitrary and Smalltalk is more consistent.

I learned operator precedence in programming, not in math. I'm sitting  
among college graduates--in the IT department--right now who give me a  
blank stare when I say "operator precedence". One guy knows it has to do  
with parentheses. My favorite (tongue-in-cheek) response was "That means  
the user comes first." (And as a professional programmer, my rule has  
always been: Don't count on your ability to remember operator precedence.  
C++ has, what, 17 levels of precedence?)

I guess my point is, I don't consider "operator precedence" to be a  
significant advantage. Smalltalk works the way I think; I have to actively  
(admittedly easily at this point) allow for operator precedence. And I  
don't bury my Smalltalk code in parentheses, yeah!

> And you are right on how Java seemed an easy move for C++ programmers.

The prevalence of "C-like" syntax has convinced me over the years that C  
programmers are wusses. They apparently won't try anything that doesn't  
look like something they already know.

        ===Blake===

Jecel Assumpcao Jr wrote:
Thanks for the link and the explanation (Joshua also pointed me to the
right link).

I just read the paper (well, my mind glazed over about half way through
but I kept at it, skipping a few implementation details). I definitely
liked the history review bit, including where is mentions "the notion of
an object being a 'figment of its viewer's beliefs' is a feature in Alan
Kay’s sketch of a language he called Rainbow" -- detailed apparently an
unpublished Xerox Parc report of the 1980s (I would love to learn more
about that). I repeatedly see why Alan Kay is surprised Squeakers are so
satisfied with Smalltalk-80 and how he wants to go further. Clearly there
are a lot of good ideas to explore, even if we limit ourselves to the
1980s. :-)

I kind of lost faith in their proposal when their model had a common
object ID across all layers; since part of my suggestion would be that
what are the relevant objects would differ by perspective. Also, I am not
sure they built a compelling case for adding complexity by not having
enough worked out examples of how perspectives as they outlined them were
a really big win. But in any case it is a clever set of ideas and shows
that a lot of thinking can go point this which is moving *beyond* the
original "Design Principles Behind Smalltalk", which was the main point I
was making. And they make clear in their literature review how the notion
of adding "context" is one many people have explored.

There are also solutions to some of the issues they raised in other
directions, for example the classical one of the debugger not working when
you mess up how any window in the system opens. In the PataPata
(prototypes for Python) case, every prototype has a "world" it belongs to,
and I have the debugger in a different "world", which has its own copies
of core classes, so you can break the Window class in one world, but the
debugger can still debug it. Prior to the ParcPlace-Digital merger they
were working on something similar at PP using a "firewall" or something
(just heard of it in passing). I did not bring PataPata to the point where
worlds were in completely separate processes though, so you can still hang
the system in other ways; ideally I wanted worlds to each be in their own
VM process and to communicate using sockets or other means of sharing
state across images.

Good points. I'll need to think about them. One of the PataPata decisions
was to reference parents by *name* rather than *pointer*. In self, key
objects can have names, but they are still referenced by pointer. The
PataPata choice gave me a little more flexibility in some ways I think --
by adding yet another layer of "late binding" to the system. (And
accompanying overhead, of course).

That's one strategy I guess. I would expect it probably fairly difficult
to extract useful parts from a combined system built on 1.1 without
running into various problems though. I'll be more curious how the Apache
license is interpreted in a Squeak context -- whether it is considered to
flows through to applications built on it as "derived works" (and so they
cannot be GPL) or whether the license just applies to Squeak itself and
not things you put on it.

In thinking more deeply about Dan's accomplishment (Squeak on the JVM,
which I had not been aware of) and looking at discussions on it from April
and comparing it in my mind to other Smalltalk on the JVM Bistro, A Little
Smalltalk, Talks2 (another Squeak derivative), etc.) a big issue is
whether you use Java objects as the base Object (like Jython) or if you
try to build your own objects from bits (as I imagine Dan's port does?).
It would seem more efficient to use Java objects -- because then you could
just use the Java garbage collection system and so on -- maybe even the
byte codes, or maybe not. However, that would not be Squeak-as-it-is
obviously, but it could potentially be a good Smalltalk (or Self or Us)
anyway. :-) In the past, I have looked at the thoughts of porting GNU
Smalltalk on the JVM (total VM rewrite plus other core changes), improving
A little Smalltalk (much work), or using Sharp Smalltalk (the best match
in some ways, as it was written for a similar system, dot net, but also
missing a GUI and so on). Squeak would be my first choice of what to work
from based on completeness and community, except for licensing issues.

Perhaps the biggest single issue is, how do we have a community around new
things inspired by Squeak? I brought this issue up many years ago, but was
basically shot down in flames of people pushing "Squeak the artifact" not
"Squeak the community". Still, it seems like it is community which makes
the value in the free and open source world. Yet the Squeak community
seems closely tied to Smalltalk-80 and Squeak-as-it-is, in part as a
self-selecting process -- yet ironically as Alan Kay himself keeps saying
he wants something better.

True, you can use all the nice tools when developing the VM under Squeak,
but you can't use them when you actually test your code after it has been
translated. So, an unexpected "barrier". Which was my point again -- there
are always barriers (even just conceptual ones) -- at best we can pick
where they will be (which is similar to what you said above on
prototypes). "Design Principles Behind Smalltalk" implicitly says some
barriers are more worthy of lowering then others; it's perhaps worthwhile
25 years later to revisit which those should be.

Increasing complexity is easy; moving it around in tradeoffs is harder;
reducing it is hardest and generally require a leap of the imagination.
Sorry to say it, but Squeak still seems pretty complex to me, and moreso
than ten years ago. :-)

--Paul Fernhout

I've looked at lua a little, but I really like Smalltalk syntax. :-)
It seems there are several prototype based systems (including IO the
language) but they all seem to start out thinking Smalltalk (or Self)
keyword syntax is a problem, whereas for me I see it as a solution.

All the best. You might find our free software, especially the PlantStudio
program, of interest for homeschooling for your kids. :-) That's the
biggest thing I want to port to a dynamic language like Squeak or Python
(from Delphi).

--Paul Fernhout

Jimmie Houchin wrote:

Paul D. Fernhout wrote:
> I've looked at lua a little, but I really like Smalltalk syntax. :-)
> It seems there are several prototype based systems (including IO the
> language) but they all seem to start out thinking Smalltalk (or Self)
> keyword syntax is a problem, whereas for me I see it as a solution.
>
> All the best. You might find our free software, especially the
> PlantStudio program, of interest for homeschooling for your kids. :-)
> That's the biggest thing I want to port to a dynamic language like
> Squeak or Python (from Delphi).

I too love the Smalltalk syntax. It enabled me to learn Smalltalk
rapidly. The environment kept me comfortable as I learned the libraries
and provided me tremendous availability to learn.  But the syntax is
attached to Smalltalk. Now that isn't a bad thing necessarily. But if
you are looking at options which are not Smalltalk including Python and
Ruby which were mentioned in your essay. And I know you have worked
extensively with Python even tho' seemingly with angst. :)

In the options category I offered Lua. Lua is as much like Smalltalk and
more than some. 1 based indexing. Yeah! Blocks. do ... end.  No it isn't
Smalltalk, but if non-Smalltalks are an option then consider Lua. :)
I think it is much closer to the philosophy of Smalltalk, Self and also
the syntax than either Python or Ruby. Now, I know you have a
significant investment in Python. But if alternatives are an option
consider improving Lua. :)

If not, then please tell us what lacketh an Apache licensed Squeak
requires for you to use? What compels you to look beyond Squeak? And if
you look beyond Squeak then the Smalltalk syntax isn't an option. As an
option Lua is nice. But it does desire libraries.

Unfortunately, can't try anything that's not Mac OS X or Linux. I don't
do Windows. So until your software is ported, can't try it.

Portability is one of the beautiful things about Squeak. Lua also is
incredibly portable. But graphics depend on the specific library. But of
course your accustomed to that. ;)

Squeak and/or Lua are very nice options.

Options are good.

Jimmie

Jimmie-

I'll agree options are good; on the other hand, there is only so much time
for exploring them (especially when you have kids, though older ones can
do some of the exploring for you, I guess. :-)

You're not the first person to recommend Lua to me, so I've installed a
later version, and will look some more at it. In the past I have evaluated
Lua mainly from the documentation from the point of view of being a VM to
put other Squeak-like work on back when I was also looking at Parrot (and
the JVM comes out higher for me as a value proposition, now that Sun has
announced its move to GPL for Java code).

Just out of musing, lets us consider this issue of picking what system to
build on abstractly out of all the known options.

There is a such a thing as a language or programming system  being
"entrenched" in a company (or even in a programmer's toolbox in some
sense). (Entrenched literally meaning "dug in" or "in a trench").
   http://wordnet.princeton.edu/perl/webwn?s=entrenched

New things rarely start out "entrenched" -- unless, in a few special cases
they have, say, lots of sales and marketing money behind them (Britney
Spears? :-) or Java marketed by Sun and IBM). Or they somehow spin off
from another already entrenched group (say, Microsoft taking the torch
from IBM when IBM carelessly picked an OS for its internally unimportant
IBM PC, or Java gaining ground being linked with Netscape browsers, or
Java syntax looking a lot like C++). So, as an unusual case, Java started
out "entrenched" in several ways, and only got more so, as it was actually
used over the past decade (very painfully at first). That's one reason
Smalltalk did not have much of a chance against Java in 1996 -- Java was
one of those rare systems that was entrenched multiple ways from the
start, and Smalltalk had missed tis chance to stop Java (and the major
Smalltalk player, ParcPlace etc., actually embraced Java for a time and
tried to reposition itself as a Java tools company!)

Now, most systems do not go from nonexistent to entrenched overnight. Even
Java internally had various steps internally from VisualWorks/ST-80
(runtime fees too high! :-) to Green to Oak Java. Yes, I say Smalltalk,
because from what rumors I hear, Sun did want to use Smalltalk for the set
top box first, but was rebuffed out of greed. You see there that a
somewhat-entrenched Smalltalk had a chance to nip Java in the bud but a
failure of management vision coupled with short-term commercial greed got
in the way IMHO. And all Smalltalkers have paid the price -- both for that
failure of vision but also for our own personal decisions to couple our
fortunes (money wise and aesthetics wise) to a commercial vendor. That is
the main reason why the personal copy I purchased of VisualWorks + ENVY
Client + ENVY Server (at almost $10000 all together) sits gathering dust
on a shelf and instead I use Python and explore Squeak or other free
Smalltalks; I just don't want to be on that path anymore -- entrusting my
fate mainly to someone else's greed; it has brought me and many other
Smalltalkers years of pain of having to work in other languages and
related environments like Java (or, even, to a lesser extent, Python, when
you know what an programming environment could be like). Maintaining large
complex business apps in Smalltalk was often fun; maintaining them in Java
is mostly work. (Python is somewhere in the middle.)

The usual progression to becoming "entrenched" is probably somewhat like this:
* ignored.
* experimental (you downloaded it and are playing with it)
* first useful task (you actually did something with it, probably where
you don't need to maintain the code, like reformatting a text file).
* multiple minor useful tasks.
* first major task (you did something very important or profitable with it).
* multiple major tasks that need to be supported.
By the last phase, the tool has become "entrenched".

I think an important "design principle" should be that a system should
easily move from one stage here to the next. :-) Because, all other things
being equal, ultimately, entrenched systems are easier to use. :-)

Things can also become "un-entrenched" when the applications they support
get replaced or diminish in importance. VisualWorks was entrenched in many
large companies in the early 1990s; it is less so now, even as it remains
a niche.

While people often talk about "the industry", in reality the programming
industry is a lot like a big city, with lots of niches and variety. Sure
there is a big Java convenience store on every corner, but that does not
mean there is not a nice Smalltalk boutique on 5th Avenue doing a brisk
business in dynamic objects. So, being entrenched is often relative to the
person or company under consideration (if you live on "5th Avenue" in this
hypothetical programming city, Smalltalk is then a lot more convenient
than Java).

For Lua or Squeak to make it all the way to entrenched for me personally,
it needs to make it through all those phases. Python has already done that
for me, and so is "entrenched" for me. However, in the past, VisualWorks
was entrenched, just like Delphi, C, and some other programming systems,
which have all fallen out of daily use with me for one reason or another.
Squeak itself was even almost entrenched for me about six years ago (but
then lost out to Python as I found I could convince people in industry to
try Python, whereas most people would not even look at Squeak, both for
licensing reasons and also for syntax issues).

To progress from ignored to experimental, through useful, and then to
entrenched, is not an easy thing. Tools either need to be so easy to
install and use (Python, the programming language?) in terms of low
hurdles at each stage that you can make it over one hurdle to the next
easily, or they need to be so powerful or fun to use (Squeak, the idea
processor to boost creativity?) that people are motivated to jump higher
hurdles. Ideally, things are both powerful and easy to install, use,
deploy, and support; unfortunately Squeak doesn't fall into this category
for the masses (being powerful but quirky and unstable and incomplete and
still problematically licensed).

For me, while I'll still consider learning other systems, Python (mostly
Jython these days) is the entrenched tool with an Algol syntax. Lua just
has no hope I can see of displacing Python for me anytime soon (barring
external forces or some new need I come up with). Sure, I just downloaded
the latest version and will experiment with it (so, it has made it to the
first phase beyond "ignored"), but it has a long road to go. And it is not
clear to me that it offers a big enough value proposition to move forward
for me. Granted, if say "COBOL" or "C++" was what was entrenched for me,
then Lua might have a level playing field with Python and Ruby and
Smalltalk (ignoring user community size).

This is not a slur on the value of Lua. This is just to say that to
compete head-to-head against an entrenched alternative (say like
Python/Jython vs. Java in many businesses today) a programming language
has to offer not just 10% more value (1.1X), but more like 300% more value
(3X). Python (as Jython) does offer that 300% over Java for most Java
developers who will use it. Lua does not offer 300% more value to me than
Python (at least as far as I can see right now; time will tell). No
language is perfect; but some meet current needs better than others; as
needs change, so does the landscape of sensible possibilities.

Squeak's big value proposition is that it is four things:
* an effective self-documenting programming language,
* a set of cross-platform libraries and runtimes,
* a complete IDE, including a fantastic debugger and source code control,
* an idea processor for enhancing creativity (its ultimate purpose).

And that is why I find Python or for that matter, probably Lua,
unsatisfying in contrast. Python has the first being a language that has
been called "executable pseudo code", for sure, but the other three ares
are where it starts to falter and then fall short. For example, it's
difficult to alter a running Python program, and almost impossible to
restart a function, which is easy to do in Squeak and a big part of
Smalltalk productivity -- especially in large programs. I had no problem
maintaining huge things in VisualWorlks+ENVY or participating in a
development process involving lots of people (many of them relatively
inexperienced), but even a mid-sized Python program developed by one or
two experienced people begins to get a big of a bear to maintain and
refactor and incrementally improve (not impossible, just harder than I
know a similar application in Smalltalk would be).

However, issues like familiarity, stability, completeness, modularity, and
licensing have trumped those other Squeak advantages (for me) which is why
I usually turn to Python. Most projects I do are not that huge anyway, or
can be refactored into smaller parts. So, to be a better value
proposition, Squeak (or Lua :-) either has to become an even more
compelling "idea processor" (e.g. even beyond OpenAugment), or gain those
other advantages Python has, or really *now* needs to do both, since for
me Python is already "entrenched" and Squeak needs to now be 300% better
to compete against it. Ten years ago, Squeak could have been as good as
Python; now it needs to be vastly superior. "Just as good" is not "good
enough" when the alternative is already "entrenched". Granted, however,
some specific issues about Squeak (licensing, GUI feel, internal
complexity) have kept me from giving it a lot of chance to grown on me as
an idea processor.

Now, I'm only bothering to write this not to point out Squeak-ish
competitive disadvantages by themselves, but because I'm willing to put a
little work into those directions -- since I still believe in a lot of the
Smalltalk ideals (and remember its accomplishments when I used it) and
still prefer keyword syntax (though I still have to trade that off against
getting other stuff done now with Python). Perhaps a Squeak 1.1 under the
Apache license on the JVM the same way Dan did a Squeak 2.2.
   http://weather-dimensions.com/Dan/ForwardToThePast.jnlp
might be a start. Then I could leverage Java's ability to provide some of
those other things (stability -- after ten years of Sun working on it,
ease of installability -- one click web start, and so on). Essentially, an
"idea processor" for the JVM? Unfortunately, Squeak 1.1. reaches so far
back (and I remember the early problems with 1.13) that there is a lot of
work to bring 1.1 back up to something really usable. And even then that
system might be in the same position Lua is in now, great, but not
"entrenched". :-)

And, as for your question on license, what matters to me in that regard is
being able to put GPL'd applications on top of the platform.  (I don't
care that much about the licensing of the platform otherwise, as long as
it is "free"). If that is possible with an Apache version of Squeak,
that's fine. If it is not, then that is a big difficulty. I like the GPL
as a constitution for defining cooperation on an application and have used
it before with success to that end. About half the free software out there
is under the GPL, another big chunk is under a GPL compatible license
(X/MIT or BSD), and then a smaller part is GPL-incompatible (Apache, etc.).
   http://www.fsf.org/licensing/licenses/
And it's a sad situation, as the FSF themselves writes about the Apache
2.0 license: "This is a free software license but it is incompatible with
the GPL. The Apache Software License is incompatible with the GPL because
it has a specific requirement that is not in the GPL: it has certain
patent termination cases that the GPL does not require. (We don't think
those patent termination cases are inherently a bad idea, but nonetheless
they are incompatible with the GNU GPL.)"
Here is Apache's take on this:
   http://www.apache.org/licenses/GPL-compatibility.html
Anyway, it's still not clear to me what the licensing issues are for an
Apache-licensed Squeak in terms of derived works built on top of it, and
then how that interacts with added GPL code. But, after having been burned
before on this, I prefer to know exactly what the most likely licensing
implications are up front before committing a major effort to something
(so I don't find out afterwards I can't release it).

--Paul Fernhout
(By the way, our garden simulator and other free software runs under Wine
under GNU/Linux, last I tried it).

Jimmie Houchin wrote:

Hello Paul,

Paul D. Fernhout wrote:
[snip]
> Just out of musing, lets us consider this issue of picking what system
> to build on abstractly out of all the known options.
>
> There is a such a thing as a language or programming system  being
> "entrenched" in a company (or even in a programmer's toolbox in some
> sense). (Entrenched literally meaning "dug in" or "in a trench").
>   http://wordnet.princeton.edu/perl/webwn?s=entrenched

Ok. Didn't see that as a requirement or variable in the previous
discussion. As one who currently does no professional programming and
gets to pick what language he wants to do a project in, it is a non-issue.

[snip]

Sad story. And I understand completely. My first programming experience
was with Prograph CPX on the Mac. $1500 (not quite your investment) was
very significant to me, and the company did not honor its obligations
and went out of business. My next one was Optima++. It too (as a
product) went into oblivion. Ugh. Two of my compelling reasons for my
desire of Open Source software.

> I think an important "design principle" should be that a system should
> easily move from one stage here to the next. :-) Because, all other
> things being equal, ultimately, entrenched systems are easier to use. :-)

True, very true. But for things done on a personal level, I am a big
believer in "build it and they will come". That is provided there is a
compelling product being offered. So started Python. Being entrenched
wasn't its goal. But entrenched it is. Having something compelling and
worth being entrenched is the important part unless you can provide
dollars or politics in which to cause entrenching.  ie: Java

[snip]
> For me, while I'll still consider learning other systems, Python (mostly
> Jython these days) is the entrenched tool with an Algol syntax. Lua just
> has no hope I can see of displacing Python for me anytime soon (barring
> external forces or some new need I come up with).

That's fine. As the one picking the language I use or play with I place
a higher value on pleasure or beauty of the language than on its being
entrenched anywhere than with me. Squeak is the only thing entrenched
with me. I can use Python but don't really enjoy so.

I enjoy functional programming and Lua offers that nicely.
I love that Lua uses 1 based indexing, has blocks, closures, coroutines.
I love that it is small so it can be learned to a reasonably high level
quickly.

I've tended to use Python more functionally than OO. So Lua fits me
better in that regard.

For some strange reason, when in Squeak I jump right in creating classes
and methods. ...

In Python I've never created a class. I just create methods and data
structures. Strange. And I have never like Pythons OO. It just doesn't
feel right to do length('string') instead of 'string'.length .

For that reason I've often considered Ruby. But I've stumbled and never
acquired the taste for @$@@LineNoise.

Oh well, so much for the vagaries of personal whims. :)

[snip]
> This is not a slur on the value of Lua.

Never thought so.

 > This is just to say that to
> compete head-to-head against an entrenched alternative (say like
> Python/Jython vs. Java in many businesses today) a programming language
> has to offer not just 10% more value (1.1X), but more like 300% more
> value (3X). Python (as Jython) does offer that 300% over Java for most
> Java developers who will use it. Lua does not offer 300% more value to
> me than Python (at least as far as I can see right now; time will tell).
> No language is perfect; but some meet current needs better than others;
> as needs change, so does the landscape of sensible possibilities.

Will not argue or dispute that.

> Squeak's big value proposition is that it is four things:
> * an effective self-documenting programming language,
> * a set of cross-platform libraries and runtimes,
> * a complete IDE, including a fantastic debugger and source code control,
> * an idea processor for enhancing creativity (its ultimate purpose).

Agreed.

Understood.

I don't believe you need to start with Squeak 1.1. If I am not mistaken
Viewpoints is attempting to relicense the whole of Squeak having gotten
Apple to relicense its part. It is trying to move the whole of core
Squeak into an Apache(Apple)+MIT(the rest) license situation.

The nice thing is that Squeak is compelling enough that I think most
issues will be addressed. Despite that Python has owned you for awhile
it doesn't seem to have owned your heart. You keep looking back to
Squeak hoping and longing.

I would just say that if given the opportunity on a project if
compelling (Squeak) vs. entrenched (Python) that compelling is anywhere
in the running give it a chance.

Personally, due to my quirk above. I've even considered prototyping in
Squeak and porting to Python on some things. Squeak is just such a
comfortable place to work, even if for entrenched or other reasons you
can not deploy. It is a great place to work out the ideas and thoughts
until you have a fruitful conclusion. Then if necessary, deploy to
entrenched. If not enjoy the compelling and its good enough. Might
reduce the head banging. At least while in the thinking it through
process. (not sure if I'm preaching to you or me. ;)

I would think GPL on top of Squeak is doable if your GPL code is
separate from Squeak and the GPL only applies to your code. But I'm not
expert and prefer MIT to GPL.

> --Paul Fernhout
> (By the way, our garden simulator and other free software runs under
> Wine under GNU/Linux, last I tried it).

Alas, I am the only Linux user. My wife and children use Mac with OS X
on PowerPC machines.

Jimmie

Sorry about editing out most of what you wrote, but it is the only way I
can get a reply out this year...

Paul D. Fernhout wrote:
> >>>[Us paper]
> [new ideas from the 1980s]

Exactly - people are so impressed that the stuff from the 1970s is
finally reaching most programmers that they forget that there was some
neat stuff done after that.
 
> [problems: common object ID across all layers]

If you want collaboration you need to share object IDs. This will get
you some of the good stuff that people now get by using databases.

> [debugging - the patapata solution]

Self had already done this:

> http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Kansas.html

So the suggestion to do it differently in Us was an attempt to see if
viewpoints would make it cleaner. The paper shows a shiny new hammer and
then looks around for nails it could be used with :-)

> >>[patapata and documenting intent]
> > [loose objects vs catalogs]
>
> Good points. I'll need to think about them. One of the PataPata decisions
> was to reference parents by *name* rather than *pointer*. In self, key
> objects can have names, but they are still referenced by pointer. The
> PataPata choice gave me a little more flexibility in some ways I think --
> by adding yet another layer of "late binding" to the system. (And
> accompanying overhead, of course).

A reasonable system has several different ways to bind objects. As Brad
Cox liked to say, you need soldered parts, parts that are screwed
together, parts that snap together and so on. Pointers are like solder,
while names are a more loose coupling.

> [Squeak on Java alternatives]

You might want to talk with Klaus Witzel to see if you two aren't doing
the same thing.
 
> [community around a new Squeak?]

That is something I thought a lot about back in 1998. And I watch
closely the community's reaction to stuff like Coke or Slate. What I
concluded was that there are several rather different groups. The
largest group is the eToys users and they are extremely under
represented here. There is a tiny "use Squeak to build something better"
group but most people here are in the "we need a great open source
Smalltalk-80" (there is a lot of overlap, of course). So I don't see how
you can change things and not lose a significant part of this
(squeak-dev) community.

> Increasing complexity is easy; moving it around in tradeoffs is harder;
> reducing it is hardest and generally require a leap of the imagination.
> Sorry to say it, but Squeak still seems pretty complex to me, and moreso
> than ten years ago. :-)

Which is why it is a good thing that the version of Neo Smalltalk I am
working on right now is 16 bits. When you only have 32K objects total
simplicity is not optional.

In another message in this thread you mentioned the story that Java was
started only because Sun couldn't get a reasonable license from
Parcplace. I have heard this a few times before but don't believe it -
Sun had a good Smalltalk for free in the form of Self and it would have
been easier for them to reshape that to their needs if they had
seriously considered going in that direction.

-- Jecel

On 28-Dec-06, at 10:51 AM, Jecel Assumpcao Jr wrote:


>
> In another message in this thread you mentioned the story that Java  
> was
> started only because Sun couldn't get a reasonable license from
> Parcplace. I have heard this a few times before but don't believe it -

I was there. It seems to be true, at least so far as the  
'negotiations happened and SUN didn't want to pay that much'. There  
were also talks about using VW as the standard tool-building tool for  
admin type tools.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
.signature not found!  reformat hard drive? [Yn]

Jecel Assumpcao Jr wrote:
> In another message in this thread you mentioned the story that Java was
> started only because Sun couldn't get a reasonable license from
> Parcplace. I have heard this a few times before but don't believe it -
> Sun had a good Smalltalk for free in the form of Self and it would have
> been easier for them to reshape that to their needs if they had
> seriously considered going in that direction.

Sun has definitely made some sad decisions.

Strongtalk, Self, Tcl/Tk, ...

I would have rather had a better performing, bytecode compiled, vm
based, standardized OO Tcl with a modernized Tk  than what Java is. And
it would have cost them less, IMO.

I would have thought improving Strongtalk would have been a whole lot
less expensive that all the Java machinations.

Self, hmm. Don't really know enough about Self. But I bet Sun could have
done something better for less.

What a legacy.

Oh well. :(

Jimmie

Tim Rowledge wrote:
Interesting - thanks for the information! My observation was based on
the fact that January 1991 was not only when the Self team moved from
Stanford to Sun but also when the first real meeting of the
Stealth/Green/Oak/Java group took place (in Aspen).

Do you remember when these negotiations took place? Perhaps this was for
some other Sun project?

-- Jecel

When I became V.P. of Development at ParcPlace-Digitalk in 1996, Bill
Lyons (then CEO) told me the same story about Sun and VW. According
to Bill, at some point in the early '90's when Adele was still CEO,
Sun approached ParcPlace for a license to use VW (probably
ObjectWorks at the time) in some set top box project they were
working on. Sun wanted to use a commercially viable OO language with
a proven track record. At the time ParcPlace was licensing Smalltalk
for >$100 a copy. Given the volume that Sun was quoting, PP gave Sun
a firm quote on the order of $100/copy. Sun was willing to pay at
most $9-10/copy for the Smalltalk licenses. Sun was not willing to go
higher and PP was unwilling to go lower, so nothing ever happened and
Sun went its own way with its own internally developed language
(Oak...Java). The initial development of Oak might well have predated
the discussions between Sun and PP, but it was PP's unwillingness to
go lower on the price of Smalltalk that gave Oak its green light
within Sun (according to Bill anyway). Bill went on to lament that
had PP played its cards right, Smalltalk would have been the language
used by Sun and the language that would have ruled the Internet.
Obviously, you can take that with a grain of salt. I don't know if
Bill's story to me was true (he certainly seemed to think it was),
but it might be confirmable by Adele. If it is true, it is merely
another sad story of what might have been and how close Smalltalk
might have come to universal acceptance.

-Eric Clayberg
  Sr. Vice President of Product Development
  Instantiations, Inc.
  mailto:[hidden email]
  http://www.instantiations.com