Caveat: please add IMH(UI)O in front of any assertion that comes below.
Since education was brought up: I remember I found it seriously twisted
when I was told mathematics freshmen in a top-notch university not
(geographically) far from me are taught not one but two courses in computer
programming... in Java.
Being the hobbyist (as contrasted to the professional) here, and the one
who's got the smaller cut out of the intelligence cake, I think I am sure C
was a lot easier to learn and comprehend than either Pascal--all the kids
were into "Pascal or C? That's the problem" back then--or C++ or even the
mess of a language called GW-BASIC (which I learnt as a kid and before I
knew C, too, could be learnt by kids). Even if Pascal got all the buzz
about being a "teaching language."
What seems to distinguish--pedagogically, at least--C is, as I noted on
that other thread, its closeness to how the small computer, not the actual
small computer but the mental model of a small computer, works. Pointers?
They're just references to "pigeonholes" in a row of such holes. Scope?
It's just how long your variables are remembered. Invocation? Just a way to
regurgitate your own cooking. If one has to solve a problem, implement an
algorithm, on a small computer one needs to be able to explain it in terms
of the primitives available on that computer. That's where C shines.
There's a close connection between language primitives and the primitives
of the underlying computer. I'm not saying this is something magically
featuring in C--it's a property that _had_ to feature in some language some
time, C became that. In a different time and place, on different machines,
another language would/will be that (and it shall be called C ;-))
I whined about LISP on yet another thread. Above says precisely why I did.
LISP is twofold hurtful for me as a naive, below average hobbyist. For one
thing the language constructs do not reflect the small computer primitives
I was taught somewhere around the beginning of my education. For another,
most (simple) problems I have had to deal with are far better expressible
in terms of those very primitives. In other words, for a person of my (low)
caliber, LISP is neither suited to the family of problems I encounter nor
suited to the machines I solve them on. Its claim to fame as the language
for "wizards" remains. Although, mind you, the AI paradigm LISP used to
represent is long deprecated (Rodney Brooks gives a good overview of this
deprecation, although not specifically targeting LISP, in "Cambrian
Intelligence: The Early History of the New AI"). One serious question today
would be: what's LISP _really_ good for? That it represents a specific
programming paradigm is not enough justification. Ideally, a language
should represent a specific application area, as does C, i.e.
general-purpose system and (low-level) application programming.
A favorite quote out of my favorite physics textbook:
Further progress lies in the direction of making our equations invariant
under wider and still wider transformations. This state of affairs is
very satisfactory from a philosophical point of view, as implying an
increasing recognition of the part played by the observer in himself
introducing the regularities that appear in his observations, and a lack
of arbitrariness in the ways of nature, but it makes things less easy for
the learner of physics.
-- P. A. M. Dirac, The Principles of Quantum Mechanics
Unlike physical phenomena languages (natural or artificial) are subject to
constraints that act (in comparison) very slowly and very leniently.
There's a great deal of arbitrariness in how a computer language might
look. It is epistemologically, aesthetically, and pragmatically
advantageous to "remove arbitrariness" by fitting a language to either its
target platform or its target problem, preferably both. C did and continues
to do so, LISP doesn't (not anymore, to say the least).
P.S. UI stands for "uninformed."
--On Friday, September 04, 2009 10:47 -0700 "Brian L. Stuart"
<blstu...@bellsouth.net> wrote:
>> > K&R is beautiful in this respect. In
contrast, I
>> never managed to
>> > bite in Stroustrup's description.
>>
>> Ok, now I'll get provocative:
>> Then why do so many people have a problem
understanding C?
>
> Are you saying that there is a significant number of
> people who understand C++ but not C? The reason
I wasn't saying anything, I was asking a question. :)
Ah, I misunderstood. The question about why people don't
understand C on the heels of a reference to Stroustrup
led me to think that was a suggestion C++ was easier to
understand than C. Of course, I may be a little too
sensitive to such a claim, because of what I've been
hearing in the academic community for a while. Some
keep saying that we should use more complex languages
in the introductory course because they're in some way
easier. But I've yet to understand their definition
of easier.*
BLS
*Well, actually I do kind of realize they are suggesting
that a tinkertoy approach makes it easier for a beginner
to see something happen. The problem I have is that's
not the point of teaching that material. Just getting
something to happen might be training, but it sure isn't
education.
