Re: OT: Type safety (was: Language War (Re: "C" Manual))
Lo, on Monday, December 31, Jeffrey W. Baker did write:
(First, a quick note about my credentials. For the last 3.5 years, I've
been working as a software developer at a telecommunications company. I
do most of my work in C++. However, as an undergraduate, I concentrated
on programming language theory and implementation techniques, so I bring
both practical experience and theoretical understanding to this issue.)
<SNIP>
> I submit -- and this has been my only point all along -- that the
> different attributes and qualities of programming languages exist
> entirely in our heads.
In general, you're correct: type safety, garbage collection, and
multiple inheritance are all abstractions that are layered on top of the
standard computer hardware. One could approach computing purely from
the perspective of the CPU, which performs only a limited set of very
simple instructions. In my experience, though, this doesn't get you
very far. (I wouldn't want to read an assembly language program that's
longer than about 250 lines, and even that's pushing it.)
Some of my co-workers seem to be stuck at the level of abstraction that
you describe. Their code tends to execute extremely rapidly. However,
it is also extremely difficult for other people to read and understand,
and it is very sensitive to changes in other (theoretically separate)
parts of the system, so it's extremely fragile. As a result,
maintenance costs are much higher.
In short: extremely low-level views of computing don't scale well. I
think Knuth said it best: good programmers must be prepared to function
at a whole range of abstraction levels, and they must be prepared to
shift between these levels very rapidly.
In addition, there have been computers from time to time that provide,
in hardware, much more support for advanced languages than is typical
among general-purpose computers today. Take a look at the Lisp Machines
produced by a number of firms, notably Symbolics. (They were still
stored-program computers operating on the von Neumann model, but there
are some important differences between these and your standard
run-of-the-mill modern RISC machine.)
<SNIP>
> ...but these are all different ways to arrive at the EXACT same
> program.
Well, the programs are the same from the point of view that they have
the same functionality, yes. However, as I alluded to above, programs
are not written in a vacuum. People have to maintain them, and the
costs (especially time) associated with this process are not trivial.
Given that, it may make some sense to choose a language or development
methodology that results in programs that are easier to maintain.
> So, this is the only thing I initially meant to say: many programming
> techniques can be used by many programmers in many different ways to
> arrive at a given result. It is a fallacy to dismiss any of them, even
> though they may be out-of-fashion. And it is certainly a fallacy to write
> a 500-page screed on the subject.
There I disagree. Dismissing a language simply and only because it is
out of fashion is certainly pointless. (I must admit, though, I'm a
little confused as to why you're applying this to a criticism of C++.)
However, there are significant differences between languages, and as my
earlier arguments explain, these differences do matter. It *is*
possible to express a preference for language X over language Y *and* to
support this preference with solid technical reasons. However, for
social and political reasons, people prefer to assume that all
`high-level languages' are basically equivalent.
I highly recommend that you check out Paul Graham's article, _Beating
the Averages_: <http://www.paulgraham.com/avg.html>. It explains the
logic behind this in a very clear fashion.
Richard
Reply to: