NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/misc/4031

Internet Message Format | 1992-12-14 | 5.5 KB

Path: sparky!uunet!think.com!barmar
From: [e-mail] (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Safety.  Was: Re: Pointers
Date: 15 Dec 1992 01:31:00 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 94
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: telecaster.think.com

In article <[e-mail]> [e-mail] (Herman Rubin) writes:
>In article <[e-mail]> [e-mail] (Wayne Throop) writes:
>>I have not seen any posting in which Herman explains *why* he does not
>>consider unions an adequate way to specify type punning
>ANYTHING which suggests to the compiler that something is to be stored when
>it does not have to be is not adequate.  Also, there are problems if one
>type of object is, say, 32 bits, and another 64 bits.

Unions don't suggest that additional information should be stored.  And for
your applications, I don't expect that you would ever have a union
containing objects of different sizes, so what's the problem?

>There was an attempt in the 1930's to introduce a language called
>"Basic English" which eliminated most of the verbs in English, as well
>as other features.  It never caught on.  Languages should be arbitrarily
>extensible.  If humans can conceive of an operation, it should be
>possible to add that operation to the language with little problem.

Humans are remarkably flexible in our use of language; we learn new words
and grammatical constructs with relative ease, and it seems that much of
our brain (as well as other parts of human physiology) is structured around
and optimized for language use.  We have not yet developed the techniques
that allow high-level computer languages to be so extensible; the best we
can do is allow the user to slip low-level constructs in, with constructs
like assem() or with separately-compiled assembly routines.

>The same holds for types; the C++ classes are really types, and the
>C typedef should have been called typealias.  Even prior to C, there
>were implementations of Fortran which allowed additional types.

And "static" should have been called "local" when it's used to specify that
a name should have file scope, but who really cares what it's called?
"Typedef" was presumably given that name because it defines a name that can
be used where the grammar specifies that a type name belongs.

>> Why should their FIRST course introduce them to situations
>> that are strikingly atypical of most software development?
>
>This is a chicken-and-egg phenomenon.  Most software development does
>not do certain things because the languages, compilers, and the training
>of the programmers does not mention them.

And most buildings are designed using "standard" architectural designs,
because that's what is taught in architecture classes.  A typical
architecture curriculum probably doesn't teach you how to design the
Guggenheim Museum.  Yes, there's a problem of in-breeding in such
educational systems, but I don't think the results are as serious as you
do.  Exceptional students will go beyond the syllabus, and those are the
people who should be dealing with the unusual projects.

If the language features you talk about were really that important, I think
that in the 35-year evolution of computer languages they would have managed
to creep in to some more languages.  Then again, you may be right about the
incest problem -- look at how difficult it is to convince people bred on C
and Pascal that the automatic memory management of languages like Lisp is
a good thing.

>                        Political correctness is bad
>even in political situations.  What proportion of current programmers,
>even those who have had "advanced" courses, are aware of the important
>mathematical types of fixed point (NOT integer) and rational?  How many
>of them would think of including them?  There are many situations in
>which floating point is a guaranteed way to have problems, and the
>person who starts out thinking that the type list of languages such
>as C are adequate will have a lot of unlearning to do to be able to
>do a good job in those numerous cases where C is inadequate.  Unlearning
>provides major obstacles for students in mathematics and statistics, and
>I see no good reason why CS and programming languages should be any
>different in this matter.

Well, there's a real bootstrapping problem here.  Supposing we wanted to
introduce students to all these issues that aren't addressed in the
available computer languages, how would we do so?  We could have them try
to program the missing routines, but in order to do that they have to know
the language.  So first we must teach them how to program in existing
languages!

Do you really think that someone should be learning the inherent problems
of floating point or how to implement fixed-point and rational arithmetic
before they learn about things like subroutines and if-then-else
constructs?  The latter will be useful for them no matter what types of
programs they write, while the former are useful only in a small
application domain.

By the way, none of the courses in the CS program at MIT teach you a
programming language.  They teach computer concepts and programming
techniques, and use programming languages in homework and lab work.  This
is analogous to the EE program -- there's no lecture on wiring up a
circuit.
--
Barry Margolin
System Manager, Thinking Machines Corp.

[e-mail]          {uunet,harvard}!think!barmar