Where to use SELF - your opinion

[deutsch@Eng.Sun.COM (L. Peter Deutsch)]

> If we stick to these assumptions, then you can't criticize the
> Self language on the basis of its current implementation.

I was trying (in my mind) to separate implementation and language
characteristics.  I do believe that it is intrinsic that a language without
static typing will require substantially more runtime overhead -- whether
space or time -- than one with static typing, to deliver the same average
level of performance.

> In languages like C and C++, typechecking can't find all the bugs and the
> ones it misses are often exactly those of the difficult-to-find variety.

For the Nth time: just because typechecking doesn't find ALL bugs doesn't
mean that it isn't useful, and just because some people associate it with
memory-unsafe languages doesn't mean it can't be useful in memory-safe
languages.

The idea that "most run-time bugs are trivial to find and fix" does not
match my experience.  A significant fraction of the bugs in my Smalltalk
programs are the result of incomplete comprehension of a design.  Type
declarations are, in my experience, an extremely useful way to satisfy
myself of a certain level of design consistency without having to resort to
trial and error.

I disagree with the statement that this is "especially [true of] those bugs
that would have been caught by compile-time type checking."  Run-time
errors can only show the presence of bugs, not their absence.  Type
checking finds ALL the bugs of a certain type in a program, not just the
ones triggered by particular data values on particular control paths.  And
I think the idea that it is OK to have run-time bugs in a delivered product
shows some lack of appreciation of the requirements of commercial software.

> I don't mind typechecking, as long as it isn't too difficult
> to manage all the type declarations as the program evolves.
> But I'd rather live without typechecking than use an unsafe
> language like C or C++.

It depends on what you want to do.  At higher levels of a system you can
afford to throw away the time and space costs of the untyped language, and
the consequences of a runtime bug may not be as serious.  At the lower
levels, you need the performance, and it's worth the trouble to apply all
known validation techniques to remove as many bugs as possible.

By the way, I have an open mind as to how low in a system one should push
garbage collection.  Given my belief that we need more performance
predictability in software, not less, I'm inclined to think that it should
be reserved for the application level.

Also, in case it isn't obvious, I don't like type-unsafe and memory-unsafe
languages.  I want a language that is type-checkable, memory-safe, and with
enough leeway that I don't feel hemmed in by the type system.  Since I
can't get one right now, I'll take memory-unsafe when I need high
performance, and type-uncheckable when I want to explore ideas.