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

["Tim Behrendsen" <tim@airshields.com>]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4u89c4$p7p@solutions.solon.com>...
> In article <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Let me bring it back full-circle where we started.  The reason
> >I mention assembly in the first place was the number of graduates
> >coming to me for a job that were failing the test I give
> >*abysmally*, particularly in the areas of creating an algorithm
> >for a problem they've never seen before, and doing logical
> >operations.
> 
> These are fundementally abstract operations.  Generalization is the core
of
> algorithm design; you must abstract what the problem is, what a solution
looks
> like, and what their relationship is.  Logic is entirely an abstract
beast.
> 
> >I chalked this up to the lack of the fundamentals being taught,
> >and the students having their brains filled up so much with
> >abstractions that they don't understand how to solve problems
> >anymore.
> 
> The entire concept of a solution to a problem, rather than the answer to
a
> question, is a matter of abstraction.

I agree; my point is that I think the student learns more if they
are thinking purely in terms of fundamental operations (which are
still abstractions above the raw hardware components), rather
than layers and layers of syntax that hide the essential essence
of what the computer is doing.

The people I saw could quote me book definitions of C syntax.  But
they had very little knowledge of what it really meant, and how
to use it.

If programming is reduced to fundamentals of move, arithmetic,
test, branch, etc it prevents the student from leaning on the
abstraction rather than truly understanding the solution to the
problem.  In other words, if they can express it in the above
terms, you *know* they understand the solution.
 
> >This is why I think assembly is the better way to teach
> >algorithms; it's just you and the algorithm.  It forces them
> >to really think about the problem, because they don't have any
> >"training wheels" to protect them from the problem.
> 
> But the training wheels protect them, not from the problem, but from the
> implementation.
> 
> Consider string searching.
> 
> An *algorithm* for searching strings has nothing to do with whether you
can
> use a postdecrement or postincrement addressing mode.
> 
> An assembly program for doing so may well *have to* consider these
issues.

True; there is assembly syntax that could be considered irrelevent
to the central issues.  I really don't see that as a big problem
compared to the much larger problem of the brain-damaged students
that are asking me for jobs.

Perhaps the solution is a middle ground one; rather than "real"
assembly for students, maybe what they need is a "MIX" kind of
thing where it is reduced to fundamental elements, an assembly
abstraction if you will.  That way, "dangerous" concepts such
as post-increment, etc. can be safely hidden away, but we can
still give allow them to think in pure data manipulation terms.
 
> >Whatever were doing now is *not working*, let me tell you.
> 
> What we're doing now is exactly what we do in every other field; we give
them
> lists of desired answers.  Most math programs would be just as bad if
math
> were as high paying and easy to get a job in as CS.
> 
> I've seen *very* few good teachers in any field, especially ones which
require
> abstraction.
> 
> The problem I've seen is that students think too much about how to
implement,
> and not enough about the abstract design.  I have this problem, even.  I
spend
> way too much time, during designs, thinking about what the data type will
need
> to look like, rather than what it will need to be able to do.  This
frequently
> turns into extra time about halfway through the implementation, because I
> didn't think enough about the *abstract* part of the problem.
> 
> I haven't even thought about memory layouts, and I'm *still* too specific
and
> not abstract enough.

The problem is that we *can't* think purely abstractly,
otherwise we end up with slow crap code.  It is simply not
possible to ignore the way code is structured, and completely
depend on the compiler to save us.  That is just not the
real world.

At least not my world, where I have to pack as many users
as possible onto one CPU.

-- Tim Behrendsen (tim@airshields.com)