NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/tcl/1210

Internet Message Format | 1992-08-17 | 9.7 KB

Path: sparky!uunet!olivea!decwrl!sdd.hp.com!usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: [e-mail]
Newsgroups: comp.lang.tcl
Subject: Class-free object systems and other religious beliefs
Message-ID: <[e-mail]>
Date: 18 Aug 92 01:26:55 GMT
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 148

A few random notes that might make my eariler post more comprehensible:

1) Self 2.0 has just been released by the Self group, which is now at
both Stanford AND Sun. The license, so far as my poor faculties can
determine, makes it essentially unencumbered (thanks, Sun -- I thought
you had hired them all to make a product out of it!). Unfortunately,
they appear to be phasing out support for the sun3 (yeah, I know, big
deal), which means that the only platform it works on is the sparc. As a
major part of Self (and, in fact, one of the major foci if not THE major
focus of their research) is their very heavy-duty compilers (which are
not, I fear, easily retargettable), I can't use it for my work -- but,
with 2.0 you DO get full source code. This platform limitation is the
major reason why I wrote BOS. Although the two languages differ greatly
syntactically (tcl is basically BOS' syntax, whereas Self is based on
Smalltalk) and in internal details (I didn't implement method caching,
namespace separation, and don't have terribly good support in the System
class for multiple inheritance (you can do it easily by hand, but the
basic primitive to create a "subclass" doesn't grok it)), all of my
inspiration came from the Self folks. In particular, I must reiterate my
plea for anyone at all interested in object-oriented systems (I use OOS
as shorthand for OOPL, OOPE, OODBMS, and all the other OOisms) to ftp to
self.stanford.edu and pick up a copy of The Self Papers, as well as Self
2.0. The Self papers describe in great detail the design, implementation
and philosophy of Self, and show how class-free object systems can be
used to build any other kind of object system you want
(single-inheritance ala Smalltalk, MI like CLOS or, etc. etc.). They are
really the occam's razor of object-oriented systems. They are also very
easy to implement (the source code for libbos is a measly 7781 lines,
though I admit it could have more bells and whistles and still be as
simple on the outside).

Now that I have BOS, I'm not so sure I would switch to Self even if it
ran on everything; the incredible ease I bought myself for free in
mixing C and interpreted code, the ability to have C call bos/tcl as
easily as bos/tcl call call C, the lack of any problems in transfering
arguments between the two (this is a bit of a headache in Self 2.0, just
like in *-lisp and Smalltalk), and the ease with which I've integrated
other programmers into working with BOS has convinced me that I'm on to
something, even if I'm the only one that ever uses it.

I do plan on doing at least things like method caches and private slots
to BOS before the compiler. Actually, I would like to have all of the
machinery the Self folks have in place in my environment for figuring
out when methods should be compiled and how they should be compiled
(Self automatically compiles your methods for you when they have been
invoked so many times (a user-settable param), and can be smart about
inlining them, caching them, etc., and can undo the whole bit without
your knowing it). At the very least, I can use it for profiling.

2) I am not at all an opponent of lisp. In fact, until I met tcl, I was
a dyed-in-the wool, HARD-CORE lisp hacker. Any kind of lisp, you name
it: WOOL, elk, SIOD, scheme, {allegro,lucid,kibuki,*} common lisp, zeta
lisp, NIL, franz lisp, xlisp, elisp, PSL, Mocklisp; If I could've made a
lisp interpreter my login shell, I would've. I even took the elisp
interpreter out of emacs and turned it into a C-callable library WAY
back when (had too many problems with elisp's idea of GC and other
problems (mostly lack of time to hack on it)). I've said it before, and
I'll say it again, IMHO tcl embodies the BEST (not all!) features of
things like lisp (and, with bos, smalltalk) while at the same time
buying you substantial gains in the crucial, CRUCIAL area of
integration. Its not like I haven't done scads of work in lisp; I've
tied together solid modelers written in lisp (Alpha_1, written in PSL)
with expert systems written in ops and analytical programs written in C
and fortran. I've written GUIs in lisp. I've built distributed systems
in lisp. Etc. Etc. In my experience, when you start wanting to build
systems that work the same way across platforms, mix lisp and C and
fortran, have to talk with other programs and packages, start to get
really big, need to work in a distributed environment, need to meet hard
performance criteria, etc. etc. you start to bump your head against the
limitations of all current implementations of lisp I've used; the
development environment you have to work in for the lisp portions of the
system IS (usually) really neat-o, but then there are all those other
bits you have to work on, which aren't usually so neat-o, and then
there's the bit of tying them together, which DEFINITELY isn't so
neat-o.  This is not to say that lisps don't have features that tcl
lacks, that things like this cannot be done with lisp (I've bloody DONE
them, ok?), that tcl is better than lisp in some pure, platonic way, or
anything like that. It is a purely pragmatic observation, and I believe
owes its validity as much to market issues, perception issues, legacy
issues and all sorts of other things IN ADDITION to technical issues.
Yes, tcl doesn't have circular data (BOS does, but nevermind that). Yes,
tcl doesn't have closures (although you could implement them). Yes, tcl
doesn't have a debugger. Or bignums. Or documentation strings. Or
packages. I know all of that. Never the less, I've managed to (a) build
substantial amounts of software using it as a BASIS (not as the total
environment, as I've pointed out so tediously already), and (b) live
without all of the things I listed above (and others). I even, get this,
live without a garbage collector (gasp!). How I do this is beyond the
scope of this already-too-long missive, but I'd be happy to get into it

In short, I don't use lisp for the same reason I don't use heroin. Yes,
it is REALLY nice (well, so I've heard), but then there's that god-awful
wakeup call if you stop using it. Tcl is sort of like methodone (ok, now
I've opened the door for all sorts of ridiculous posts and cross-posts
to alt.drugs, hurrah for the net).

3) I believe it is the mission of academic hackers like John Ousterhout
(hope you don't mind the characterization ;-), rms, the epoch folks, the
postgres folks, the self folks, the mach folks, even little guys like me
(not to put myself in such illustrious company), to raise the level of
the Lowest Common Denominator. By this I mean: if you go buy some random
workstation running foo-ix, what can you expect to find on it without
putting out for "extra" software? Right now, you can expect to find X11
(in some, usually belated form (AIXwindows, DECwindows, etc. etc. Yuck.
I hate it all and generally, if possible, go build myself a vanilla X
installation from scratch and use that instead on whatever machines I
hack on). You can expect to find a C compiler (although this is changing
thanks to the unenlightened policies of Sun, HP and probably others).
You can expect to find some sort of source-level debugger for C
programs. You can expect to find the (2) calls documented in the V7 PM
plus some TCP/IP stuff and other BSD kernel facilities (but this last
bit is not universal). You can expect to find some sub- or super-set of
the (3) calls documented in same. You can expect some sort of csh. You
can expect ed and vi. And baby, that's pretty much it. You cannot expect
a lisp. You cannot expect an RDBMS. You cannot expect emacs/epoch. You
cannot expect any interpreted languages, let alone an object-oriented
one (Xt+C does NOT count and, anyway, you don't always get Xt with your
X, nor a real C compiler). You cannot expect some facility to ease the
building of distributed systems (can you tell this is a big deal for me?
:-). There's NO BLOODY WAY IN HELL you can expect the full source code
to ANYTHING (I was recently reminiscing with a fellow hacker at CMU
about the old lisp hardware environments like the explorer and the
symbolics where you had the source code (in lisp! yay!) to EVERYTHING --
the editor, the OS, the compiler, EVERYTHING. Sigh.). You MIGHT have
some or all of these, but then, you might not. I think that efforts like
tcl/tk, postgres, mach, gcc, the free version of ISIS,  and, yes, BOS
and Self are slowly raising the PERCEPTION of what the LCD *should* be,
if not its actual state. To make it into the widest possible perception
of what the LCD is, something basically has to be so portable,
unencumbered, useful and easy to use that vendors of all colors can't
afford NOT to absorb it somehow. Witness X windows. Witness (god, I
hope) TCP/IP.  Recently, witness GCC, GNU Emacs and other FSF output.
I'm sorry, but I don't see any current implementation of (common) lisp
making a difference this way -- maybe I'm wrong. Again, it is surely
beyond the scope of a note like this to argue the point, but I'd be
happy to if anyone else is interested. There is an excellent tech report
from SEI by PeterFelier that talks about the LCD issue in the context of
CASE tools and vendors, which I highly recomend. I can post the
reference if anyone cares.

If I were an FM DJ, I'd be fired for too much talk. So, now back to your
regularly scheduled programming.

Cheers,
                -- Sean
--
Sean Levy, n-dim Group, EDRC, CMU, 5000 Forbes Ave, PGH, PA 15213
Email: [e-mail], Phone: [phone], Fax: [phone]