Re: out-of-control GC

[David Kastrup]

Linas Vepstas <address@hidden> writes:

> Perhaps.  Back in the day, when young programmers were learning C++
> for the first time, they felt obligated to use each of the nifty new
> tricks they just learned: multiple inheritance, overloaded operators,
> virtual methods, virtual base classes, templates: not just use, but
> abuse these, even when something simpler was available.  It was like
> working with quick-set concrete: after the code was written, it seemed
> like it was impossible to make any significant changes to it that
> would even compile, much less do the right thing.  This kind of code
> was hard to read cause it was badly written.

The language C++ has had a long-running inferiority complex towards
FORTRAN, basically with the motto "we can do the same, but user-defined,
and still get native performance of a statically typed system".  This
gave it a monstrous, and actually unpredictably contorted type
conversion lattice in order to simulate Fortran's builtin complex types.
It also gave birth to a legion of attempts to do efficient
runtime-dimensioned multidimensional arrays, with the result that there
are no numeric libraries equivalent in usability and efficiency to
half-century old FORTRAN libraries like BLAS and LINPACK since there
still is no agreed-upon efficient multidimensional array type, let alone
one where the compiler can do good strength reduction.

This "we can do the same, but user-defined, and still get native
performance of a statically typed system" mantra pervades all language
standardization processes and basically leads to a Turing-complete
template, type and ambiguity resolution system that is a wholly
independent layer akin to the C preprocessor but syntactically
structure-preserving.

Scheme (and its overall LISP family) has no language syntax to speak of
and its input _is_ already a data structure, so "structure-preserving"
has always been a given for its preprocessing.  It also never really was
into static typing, but "JIT compilation" allows to reduce the impact of
that decision considerably.

> Sometimes, with scheme, I get the sense that if you haven't read SICP
> you can't understand what the code does: that you can't understand the
> code cause it's well-written.

Well, that does not sound like a good language design goal either.

-- 
David Kastrup