James Britt <james.britt / gmail.com> writes:

> Christian Neukirchen wrote:
>> Once you *know* how a linked list/hash/sort/Delegate/Flyweight
>> works,
>> you can use the existing version.  It's always been like that, no?
>
> Yes.  One could use Ruby to show how various built-in features work,
> then use the Ruby version.  Students would know the essentials of
> linked lists, etc., and could then move on to using the built-in
> stuff.

Exactly.

> Arguing that this may involve too much hand-waving means moving
> further down the abstraction layers; the demarcation point, though,
> may be arbitrary.  At what point do you say, That's too much low-level
> detail?

Of course, that's a question of time.  If you only have a half or a
full year, you need to stop digging deeper pretty soon; depending on
what you really want them to learn.  Give foundations for figuring out
on their own.

> But to prepare people to make best use of current computational
> technology, how much geeky detail is right?   Do people *really* need
> to know the differences among various sorting algorithms?

People don't, but a reasonable programmer really ought to.  He at
least should know *where* to lookup sort algorithms, *how* to evaluate
them and make a good choice, and finally *implement* them, given a
description in English or pseudocode.

Your PHP codemonkey doesn't need to be able to do that, but if I hired
a serious programmer, I would expect that.

> I'm
> inclined to think that one cannot call oneself a programmer  without
> some reasonable knowledge of sorting, searching, various machine
> architectures, networking basics; well, basically the stuff one gets
> from a CS degree.

You don't need a CS degree (there are so many very good self-thought
people around), and you don't to know all the stuff by heart.  But you
need to be able to learn and pickup these things.

> Much like taking a driver's ed. course does not make you a mechanic,
> knowing how to assemble lines of code to run without errors and
> produce correct results does not make you a programmer (except in some
> loose populist sense).   It means you can get from one place to
> another without crashing.  Maybe that's enough.

That's a bad analogy.

Driver   : Car = User       : Application
Mechanic : Car = Programmer : Application

> Does the average coder need to know how to write a search algorithm or
> build a linked list?  Perhaps students should first be taught good
> taste; there seems to be less and less need to solve the low-level
> problems.  They're done. The issue now is how to best take available
> tools and make good, clean choices, both in the problems to solve and
> how the solutions are executed.

I'd like to add that it's wrong to think every problem can be solved
by another level of abstraction.

> Teach aesthetics, not engineering.

"Software aesthetics" sounds a lot better than "Software engineering",
too :-)

> James Britt
-- 
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org