Re: Where to use SELF - your opinion

[jmaloney@Eng.Sun.COM]

Here's where I think we agree:
  1. memory-unsafe languages are bad
  2. different levels of bug-finding effort are
     useful in different situtations
  3. typechecking is a useful because it finds many bugs
  4. typechecking doesn't necessarily find all bugs,
     so testing will always be necessary
  5. predictable performance is good
  6. all things being equal, good performance is is better,
     and is sometimes worth sacrificing other things for

Here's where we partially disagree:
  1. languages without static typing necessarily require
     more runtime overhead (space, time, or both)
	[My position: you're right but how low can we push
	 the overhead? At some point, it may be worth paying
	 the extra overhead in exchange for program reliability,
	 ease-of-evolution, or speed-of-development. We usually
	 don't need efficiency badly enough to write in assembler,
	 after all. Perhaps some day we won't need efficiency
	 badly enough to write in C++ or C.]
  2. the value of typechecking
	[We both agree it is valuable, but I think you value it
	 more highly than I do. I used to program in Mesa, which
	 had a much stronger type system than C. When I first started
	 working in Smalltalk it made me very nervous to try my
	 programs because I knew they had bugs. They did, but the
	 cost of encountering a bug was so low, I soon got over my
	 psychological addiction to the security of typechecking. I've
	 been doing most of my programming in Smalltalk and Self for
	 four or five years now and whenever I use C I'm shocked at
	 how difficult it is to find bugs, even using the Think C
	 symbolic debugger. I suspect that you use C and C++ much
	 more than I do and are thus more viscerally aware of how
	 much tedious debugging the type system is saving you from.
	 On the other hand, I've been doing exploratory programming
	 and am keenly aware of how much restructuring I do as my
	 program evolves. I don't want to have to push a lot of type
	 information around every time I make a design change, as I
	 did in Mesa.]

I'd like to see a single memory-safe language with a flexible,
discretionary type system. During exploratory development, type
errors could be discovered at only at run time. As parts of the
system become mature and stable, the programmer could add type
annoations to help the system find errors and to make the program
more understandable to the reader. Type errors would be reported
but could be ignored if the programmer chose to run a partially
correct program. Ralph Johnson's typed-Smalltalk was supposed to
do some of these things but I'm not sure how far he got with it.

Re: garbage collection at low levels

I've had good luck writing high-perfmance and real-time code
in Self and Smalltalk. The time-critical low-level code is carefully
written to pre-allocate all the storage it needs. Since it never
allocates anything, this code never triggers garbage collection.
I think it's better to do things this way than to open the door
to the possibility of dangling references by having the programmer
explicitely allocate and free storage.

It would really be interesting to get some data on the reliability of
"production" Smalltalk programs (i.e., programs that are pretty carefully
tested before being given the the customer).

	-- John