Article View: comp.lang.misc
Article #6484Re: Xerox PARC's Cedar
From: Jef Poskanzer
Date: Thu, 18 May 1989 22:13
Date: Thu, 18 May 1989 22:13
52 lines
3014 bytes
3014 bytes
In the referenced message, sritacco@hpbsla.HP.COM (Steve_Ritacco) wrote:
}Cedar started out as Mesa, the implementation language of ViewPoint
}and the Star software (among other things).
Are you trying to attract people or frighten them away? Anyone who
knows anything about the internals of ViewPoint is now running for the
hills! But then you can write bad software in any language (Flon's
Law). Mesa was actually a damn good language. Unfortunately, the
Cedar folks basically ruined it.
Still, I'll be very happy if Xerox does release Cedar, so long as they
include sources. Then the first thing I'll do is rip out all the Cedar
junk and re-release it as Mesa (or Cedar--?).
}When Mesa
}became Cedar, certain features were added. A data type called "ropes",
}a generic pointer type (ref. any), and a run time garbage collection
}system.
Ropes (Cedar's "industrial strength" strings) are grotesque, just like
all the other interfaces the Cedar folks added to Mesa. There's an
artistry to good interface design, and the Cedar folks lacked it.
Generic pointers were in Mesa all along, and as for garbage
collection...
Adding garbage collection to a language that doesn't need it is an
admission of failure. Consider, there are two main kinds of errors
involving dynamic memory: forgetting to free an object, and referencing
an object after it has been freed. The first type is commonly called a
memory leak, and it is often easy to see (but not to find) by simply
watching the size of your program and noting that it grows over time.
The second type, often called a heap smash, is more pernicious; you
will typically only find it by accident, when you re-allocate the same
chunk of memory somewhere else in your program, and things start
failing randomly.
So what does garbage collection do? It gets rid of some memory leaks
(the kind where you put a pointer into a local variable and forget to
free it). It also converts heap smashes into memory leaks. True, your
program is now less likely to fail randomly and catastrophically; this
is a win. But it is now impossible to find any remaining memory
leaks. In the long run, your programs are *less* reliable.
It is much better to use proper programming discipline and modern
debugging tools than to punt the issue with the short term (and
expensive) fix of garbage collection.
---
Jef
Jef Poskanzer jef@helios.ee.lbl.gov ...well!pokey
"Don't worry about the world coming to an end today. It's already tomorrow in
Australia." -- Charles Schultz
Technical Details
Message-ID:
<11735@well.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!pokeyReferences:
<460002@hpbsla.HP.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!pokey From: pokey@well.UUCP (Jef Poskanzer) Newsgroups: comp.lang.misc Subject: Re: Xerox PARC's Cedar Message-ID: <11735@well.UUCP> Date: 18 May 89 22:13:13 GMT References: <460002@hpbsla.HP.COM> Reply-To: Jef Poskanzer <jef@helios.ee.lbl.gov> Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Lines: 52