Re: [9fans] nice quote

[Eris Discordia <eris.discordia@gmail.com>]

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" 
<blstuart@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.
>
>