From: "Paul D. Fernhout" <pdfernhout kurtz-fernhout com>
To: Open source advocacy in education and government <open-source-now-list redhat com>
Subject: Re: [OS:N:] Developing for developers and users
Date: Wed, 25 Aug 2004 21:32:26 -0400
Bill Kendrick wrote:
I mean, shit... anyone remember Macintosh? ...
and yeah, even that was just a ripoff of the earlier PARC stuff)
Actually there was some licensing deal between Apple and Xerox PARC so
it wasn't exactly a ripoff in the financial sense, but clearly many of
the ideas for the Macintosh were taken from Alan Kay's (and other's)
innovative Smalltalk system. There is a quote somewhere by Steven Jobs
(see for example) http://www.smalltalk.org/alankay.html http://americanhistory.si.edu/csr/comphist/sj1.html
saying he was so bowled over by the GUI during his visit to PARC he
immediately wanted to get back to Apple and start working on that that,
but he wished in retrospect he had stayed longer to get the idea of
Smalltalk and object-oriented programming (as well as networked
computers). If you look at Steve Jobs' subsequent effort, NeXT, you
will see many more of the Smalltalk ideas and network ideas (in
Objective-C and NeXTStep type ideas).
A proprietary Smalltalk system called "The Analyst" built for the
intelligence community then leveraged Smalltalk to an incredible degree
to form an integrated information handling suite far beyond Office. http://wiki.cs.uiuc.edu/VisualWorks/The+Analyst http://www.mojowire.com/TravelsWithSmalltalk/DaveThomas-TravelsWithSmalltalk.htm
"Why would Xerox develop an incredible spreadsheet that could display
images, conjugate Russian verbs and why did that happen in a strange
group called XSIS located in Los Angeles and Washington? Apparently they
had an important customer with a lot of complex information to analyze.
How did Angela Coppola know that 1000 people would show up for OOPSLA'86
when the PC committee predicted 100-200? What sort of technology could
the National Security Administration use to print Chinese leaflets circa
1978? The Xerox Analyst served the CIA as a analytic tool for many
years. Even 13 years later it still offers tools more powerful than
MSOffice. The Analyst is still alive and well and forms a key component
in TI ControlWorks Wafer Fab Automation System."
So anyway, even more than a decade ago, there were much better things
than Microsoft Office.
And Engelbart's (and other's) work on Augment (predating Smalltalk in a
sense) was also a move in that direction of integrated information
management tools (embodying coding tools together with text and
hypertext and collaboration tools), eventually moving to being on top of
Smalltalk at some point. [I have my own issues with the Engelbart
approach -- including particularly a need to rethink what is meant by
"document" in an age of tiny modules, but in general I like what
Engelbart attempts.]
It's been said any sufficiently complex C program reimplements half-of
Common Lisp badly, and I think once could also say any sufficiently
complex GUI application in C/C++ reimplements half of Smalltalk badly
(garbage collection, dependencies, MVC, bitblt, dynamic binding of
plugins, inspectors, browsers, modifying running code, developing while
debugging, etc.).
As a software developer, the problem I have contributing to most any
mainstream project like Mozilla or OpenOffice (except maybe ones in
certain Smalltalks, or perhaps Python) is this notion that so much of
the code base is going to be a specific implementation of things that a
good Smalltalk (or Common Lisp, etc.) generalizes. [BTW, Java fails at
some of this too, so it isn't the answer.]
Take for example garbage collection; almost all C (or C++) GUI type
programs generates lots of temporary objects, and they carefully manage
allocation and deallocation with lots of code (or now some link in
conservative garbage collectors for freeing malloced blocks). Compare
this with, say, the advanced garbage collection schemes in something
like VisualWorks Smalltalk
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks+7+White+Paper
(a modern Smalltalk architecture, though a proprietary implementation,
which tenures objects as they age, has separate spaces for objects of
different characteristics, supports weak references, and some other
aspects, some user-tailorable) http://wiki.cs.uiuc.edu/VisualWorks/ObjectMemory+Size+Tuning
you end up finding out often enough that a complex GUI type C program
spends more time on garbage collection in that sense and does a worse
job of it than Smalltalk, which has a highly optimized general system.
Python is currently struggling with some of this as it has a
simple-minded reference counting approach that bogs it down in speed and
circularity problems and programming burden for extension writers.
While I have adopted GNU/Linux for my main system, it was only after
many years of avoidance because of the legacy UNIX architecture
(including the C focus) and hoping for something better to emerge as a
standard. Even now, I face an installed GNU/Linux system of literally
gigabytes of software where most of that code is simply reimplementing
Smalltalk VM like ideas and duplicating code etc (poorly). By
comparison, a Forth system could do timesharing, compiling, scheduling,
and editing in about 16K (not MB!) bytes of RAM. http://www.colorforth.com/HOPL.html
And Squeak Smalltalk can run on bare metal and provide a complete GUI
development system in about a megabyte or so. Granted, we want full
featured applications, but overall, do we really need gigabytes of
compiled code to do not much more in core functionality than these systems?
Now this bloat and redundancy isn't specific to GNU/Linux; for a long
time now, to save on storage space and memory use, Microsoft has many
proprietary hidden interpreters embedded into Windows applications,
including one which uses bytecode like instructions unpacked into real
code at the heart of Microsoft Office applications. For what it is
worth, even Bill Gates was big on Smalltalk a long time ago: http://www.danielsen.com/jokes/BillGatesquotes.txt
From the back of an old Digitalk Smalltalk/V PM manual, 1990:
"This is the right way to develop applications for OS/2 PM. OS/2 PM
is a tremendously rich environment, which makes it inherently complex.
Smalltalk/V PM removes that complexity and lets you concentrate on
writing great programs. Smalltalk/V PM is the kind of tool that will
make OS/2 the successor to MS/DOS".
Just one more example of the power of such thinking -- Dan Ingalls, a
key original Smalltalk developer who later worked on Squeak Smalltalk,
wrote the following: http://minnow.cc.gatech.edu/squeak/3084
"Mini.image, on the servers, is not much over 500k and includes a full
development environment. Since it can reconstruct and browse over 800k
of source code by decompilation, we used to boast that it was like
source code compression with a full-featured development environment
thrown in for free."
Now when you are used to that kind of system, it's hard to look at
systems that take 30MB just to do some simple dedicated application.
Anyway, this isn't an argument everything should be written in Smalltalk
or GNU/Linux should be ditched in factor of saw Squeak Smalltalk on the
bare metal. But it is to say something similar to one of Kim's points,
only in the field of core software (not hypertext functionality), that
many wheels are getting reinvented badly in the community -- I might add
perhaps as part of a learning process. Now that may just be the nature
of open source / free software, but one can hope that as this culture
grows and becomes somewhat more introspective and educated (through the
power of the internet) these issues will slowly resolve themselves, and
we will see much more powerful cores of VMs and libraries on which to
build special purpose applications. Python is one step in that direction
(having some advantages over typical Smalltalks, plus some
disadvantages). But it does lead to a problem for more experienced
developers, when they look at something like the C/C++ (or Java etc.)
codebase for Mozilla or OpenOffice and say, gee, why maintain all that
poorly done Smalltalk reimplementations rather than start over (and no
offense intended, I use Mozilla every day and I like it, and OpenOffice
rocks too). And anyone starting over would be foolish not to look at how
those systems worked and all the application specific problems they have
solved. And there remains the tension of how much of legacy support to
build into a new system, as it is in that legacy support (especially if
done broadly) that much complexity and bloat lies.
I think there is a general feeling we are not there yet for a good
underlying system architecture; the Gnome convolutions, the continued
work on language and library design, and so on all points to a hope for
something better underlying this all. I feel one reason end-user
experience is so poor is that the tools the end-user applications are
built on under GNU/Linux are so poor (C/C++, files, etc.; as good as
they are in many ways at what they think is important). I feel that
situation is improving with various desktops and an increase in library
functionality in a small way, but it nowhere near approaches the promise
of something like, say, Squeak Smalltalk (this is not to say Squeak
delivers on such promises either, it just shows them in the hands of
someone like Alan Kay if you watch his live demo).
So in any case, I would not agree withthe spirit of the point that
office type applications are taking from each other (even if that is
true); I think it more like they are all harking back to the 1960s and
1970s, and we have not yet reached the potential of Engelbart's Augment
or Kay's Smalltalk in a free and open way. We can still do OK with what
we have, but if we could realize the promise of Augment and Smalltalk,
we could finally move beyond that (although I would add the web is
something different and wonderful in its own right in terms of sheer
volume of content accessible via a search engine like Google).
Yes, I know Ocaml/Haskell/etc. are cool, and a lot of hard work goes
into tracking standards and deviations like with HTML versions, reverse
engineering .Doc version formats, etc. etc.; this isn't meant to put
down future great ideas in the making or lots of hard work needed to
make today's approaches go, just to say something about the unrealized
potential of free computing even with 1960s/1970s ideals...