Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[wheeler@aphrodite.csed.ida.org (David Wheeler)]

Tim Behrendsen (tim@airshields.com) wrote:
: Robert Dewar <dewar@cs.nyu.edu> wrote in article
: <dewar.838609515@schonberg>...
: > Tim recommends
: > 
: > "Assembly -> C [non-GUI] -> C-GUI -> C++
: > 
: > Assembly:   Learn what's *really* going on.  The most important."
: > 
: > I strongly disagree. A student treading this path will have a hard time
: > learning what abstraction is all about.


: I arrived at this conclusion based on the students that were coming
: to me to be hired.  I give a standard test to all my applicants that
: tests two primary attributes,

: 1) How well they understand what's *really* going on; the best
: programmers have a solid foundation.
: 2) How well the can take a problem they've (probably) never seen
: before and generate a solution.

I strongly agree with points 1 and 2. The best programmers understand
how things really work, and are able to generate a solution from a
problem.  Makes sense to me.  We just disagree on how to get there.

: I was shocked at the results.  I had people with Masters and
: Doctorates who were completely incapable of creating new solutions
: that they had never seen before.

I also agree that many people are coming out of schools and are
incapable of creating new solutions.  I've met them myself.

The biggest problem I encounter is not that they don't understand the
first principles.  The problem is that they don't understand how to
break a problem into parts, and then solve the problem.  It's a problem
in _abstraction_, not in understanding how the pieces work.

: It's like graduating someone with a writing degree who is
: illiterate.

Continuing your analogy, what they really need is experience in writing
seriously-size software -- and a CRITIQUE of their work by good writers.
I haven't seen much in the way of critique in universities, and students
tend to work with tiny problems (because nobody wants to evaluate big
ones).  This is an area where things really break down; it's possible
to get a Master's or PhD and not write anything longer than a thousand
lines, and with no feedback from experienced people.

: I had people, with *degrees* now,
: tell me "convert argument to binary" as one of the steps on a
: logical operation problem!  The latter are people who are ground
: in the "abstraction" of an integer, but are completely clueless
: that the computer works in binary. How can a student get a
: full-blown degree, and not understand a computer works in binary?

That's pretty clueless.  However, depending on how well they
understood their programming language, they might still produce
a reasonable result.  Why?  Because, although they may not realize
that some of these "conversion" operations have no run time impact,
they may know how to combine the features of their language to
produce solutions.

And it's the solutions, not the knowledge, that you're paying for.

I agree with you, though, you don't want such clueless people working
for you. The clueless ones won't know how to write high-performance
software where it's needed.  You want people who understand the
underlying technology _AND_ how to apply it.  But don't assume that the
former implies the latter.  In fact, given someone who knows how to
apply the technology, I can quickly get them up to speed on how it works.


: Bottom line, a student cannot fundamentally understand an
: abstraction until they understand the abstraction
: in terms of the fundamental components of programming; again:
: Move, Arithmetic, Test, Branch, and Logicals.

Any professional developer must understand several assembly languages,
and how they work in general.  I think that goes without saying.  That
doesn't mean it should be their first language.  There are various
pedagogical approaches, and I haven't seen any strong evidence for this
approach.  I think assembly language is excessively difficult as a
first step, and it obfuscates other necessary skills (like learning how
to abstract things).  A short course in how they work might be okay,
but serious work starting with assembly would IMHO be a disservice.

The language you use also determines the amount of detail
you need to know about the underlying machine abstraction.
When you're using C or C++, you really need to know how the
underlying assembly language works. Why? Because pointer arithmetic
makes little sense if you don't, and tracking down rogue pointers
overwriting your local stack values and other nasties is impossible if
you don't understand how underlying machines work.  Most of the
basic C/C++ operations are defined as "whatever your local machine does",
so it's really part of the C/C++ definition.

A professional developer using other languages should still know this
level of detail, but it's frankly less important in Java, Ada 95, Eiffel,
and Smalltalk (among others).  Who cares that "if" becomes a branch
instruction? Unless you call outside the language, you won't even get
to see how some capabilities are implemented in some languages. The
result: the detail you need to know to solve a problem shrinks.  Thus,
you can concentrate on learning how to abstract - the real problem.

In the immortal words of managers everywhere: Who cares how the
underlying system works? When will the code be ready?


: CS is currently taught the way you describe.  Why do you think
: it's so hard to teach abstractions at the elementary level?

It's not clear it's REALLY taught that way.  Lots of schools just give
a quick intro to a programming languages or two, and then show other
people's abstractions (instead of teaching how to abstract).  Besides,
many students just "get by" instead of learning, and many people
find abstraction really hard to grasp.


: This is what convinced me that our CS education is being done
: completely wrong.  I've said this before [excuse my repetition];
: it would be as if EE students were taught IC design in the first
: course, and were only given resisters, capacitors, ohm's law,
: etc. in their senior year, almost as an afterthought!

But even you are suggesting that there be an abstraction for
software developers.  Computers use resistors and
capacitors, too. Why not require a full EE degree?
The answer: because you don't REALLY need to know that level of detail;
an abstraction of a computer is good enough.

I've got a EE and CS degree; given sand and enough time I could build
a computer, and then build an operating system and compiler on top of it.
But in most of my work I don't need that level of low-level
understanding.  What I do need to know is how to abstract a problem
into parts so I can solve it.  I agree with Mr. Dewar - abstraction
is most important, worry about that first.

Thus: If solving problems is the key skill, start with a high-level
language that lets you concentrate on learning how to solve problems.


--- David A. Wheeler
Net address: wheeler@ida.org