Re: What's the best language to start with

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

Ian Ward <ian@rsd.bel.alcatel.be> wrote in article
<4uaf5h$mid@btmpjg.god.bel.alcatel.be>...
> There are two fundamental points here which until recently I had
> not sussed, and which seem to be fighting each other in this thread.
> 
> 1. Algorithmic problem solving. 
> Tim here suggests that assembler should be used to teach students
> how to become software engineers, because the simple structure 
> of the assembly language is easy to understand. Students will 
> be able to follow it, etc. Additionally, people studying this, if
> (and only if) they become good programmers using this method, then
> they are the type of people who can work things out for themselves.

What I'm really saying is I want students to get the feel
for algorithmic analysis, and it seems to me that it's better
to "mix the fundamental ingredients" to learn to cook than it
is to reheat a frozen dinner.  Yes, both are technically
cooking, but I married the former. :)
 
> [interesting stuff snipped]
> Just how much speed do we need anyway? Even if hand written
> assembler was faster than compiled code, which it is not, these
> things need to be put into perspective. A modern high end
> desktop PC will be faster than an old Cray One (400Mhz. I think)
> in _less_ than two years.

I don't think there's much of anything that really needs to
be done in assembler, but I think there is no beating it
when it comes to getting the "feel" of how computers really
work.

> >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.
> 
> It was probably just lack of what you consider to be fundamental,
> however, with the very few exceptions, straight assembler will 
> almost totally unused, anywhere, twenty years from now. 

I should say that my test had them render solutions in C.  I
gave them a moderately easy but not trivial algorithm to
implement, and they just plain couldn't do it.

> >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.
> >
> 
> Very few people have good problem solving abilities, I agree
> but a lot of this minority have developed this ability themselves,
> or inherited it from their parents (or a bit of both.)
> 
> Out of these, almost nobody has derived sound software engineering
> methods from first principles. They have to be taught.

Electronic Engineering seems to do pretty well from "first
principles".  I would say the average competency level of
an EE grad is *much* higher than the average CS grad.

> [more interesting stuff snipped]
> >Whatever were doing now is *not working*, let me tell you.
>[snip] 
> Inexperienced (or 
> people with narrow experience) but talented
> problem solvers, in my experience, often cause more damage
> than they should, because they are more likely to just say,
> "I can see how to do it!" and start coding. Yet all these 
> problems, where it is possible to humanly achieve a viable 
> solution using this technique are drying up. Unfortunately,
> these problem solvers, having relied on their wits since the
> day they first started to think, are the last people to step
> back and think, "Is there another way of doing this?"

I completely disagree!  Someone who is an "algorithm memorizer"
is *much* less likely to go back and think "Is there another
way to do this," because they by definition do not think
about their solutions.  They simply look them up in the book,
and if the book says that's the best, well, no need to go
further.

Take John Carmack, the 3D game engine programmer of Doom and
Quake.  An astoundingly talented guy, and definitely of
the "talented problem solver" class.  According to a mag
article, he has written over 20 gaming engines in search of
the most optimal implementation.

-- Tim Behrendsen (tim@airshields.com)