Linas Vepstas <linasveps...@gmail.com> 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
