Re: What's the best language to start with

Re: What's the best language to start with

[Alexander E. Kopilovitch]

In <dewar.839593445@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

>Over and over again I see cases of careful and well written implementations
>of completely absurd algorithms for standard problems, where quite
>obviously the programmer was simply unaware that there are much better
>solutions known.

It means that this "programmer" is not programmer indeed, but software
engineer. The combination of "careful and well written implementations" and
"completely absurd algorithms" is characteristic for substantional part of
the growing mass of these brave software engineers.

> For
>instance, if you want to compute eigenvalues of a large matrix, then
>you CERTAINLY do not try to invent your algorithm, and you probably don't
>even go and look up an algorithm, instead you use a standard library.

Not CERTAINLY. In most cases - yes, but not certainly, as you are programmer,
not software engineer. Definitely, you have no chance to invent general
algorithm for computing of eigenvalues better then already published ones,
but sometimes you have a chance to discover that computing of eigenvalues
aren't really needed to solve the problem, but much simpler task may be
performed instead.

>Reuse, of both code in standard libraries, and of ideas, in the form of
>published algorithms, is a key, perhaps *the* key, tool in a programmers
>arsenal.

All these are tools for local optimizations of the problem solution. They
can produce global optimum if you have guessed proper overall structure of
the program/problem.


---------------------------------------------------------------
Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

 

Re: What's the best language to start with

[Robert Dewar]

Alexander says

"It means that this "programmer" is not programmer indeed, but software
engineer. The combination of "careful and well written implementations" and
"completely absurd algorithms" is characteristic for substantional part of
the growing mass of these brave software engineers.
"


Well I can't easily tell if this is just a language problem (maybe the
terms in Russian have different implications), or out and out flame bait.
Probably the latter -- but in any case it is certain that there is no
distinction of this kind in the terms as normally used here. You can
find incompetent and competent people under all labels!

Re: What's the best language to start with

[Alexander E. Kopilovitch]

In  <dewar.839812305@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

>>I did not say that software engineers are incompetent and I did not say that
>>"programmers" are more competent than "software engineers". The difference
>>between these terms (or labels, if you want) doesn't directly relate to
>>some general competence. These "labels" can designate different _priorities_.
>>And you could not expect the same profile of competence from people with
>>substantionally different priorities.
>
>Well I can't reconcile these two paragraphs, perhaps it is a language
>problem, or perhaps there are two Alexanders :-)

Maybe language problem exists, which makes last 2.5 lines of my (cited) text
invisible.

>In the first paragraph you say that incompetence (of this kind) is
>characteristic of a "substanional" part of the growing mass of these
>brave software engineers, and then in the second paragraph you
>said that you were not commenting on relative competence associated
>with the two labels.

I repeat in hope that you can see these lines written in capital letters:

LABELS  "PROGRAMMER"  AND  "SOFTWARE  ENGINEER"  CAN  DESIGNATE  DIFFERENT
PRIORITIES.  THESE  DIFFERENT  PRIORITIES  OFTEN  LEAD  TO  DIFFERENT
PROFILES  OF  COMPETENCE.


>You seem to definitely have some derogatory reaction to the term SE,

No, I have no negative reaction to the term SE when it is used properly.
I have no negative reaction to the phrase "Windows 95 is an operating system",
but I become angry when I hear that "Operating systems are variations of
Windows 95".

> which you are certainly entitled to,
You guess is wrong until now. Thanks God. In my current conditions I cannot
be good SE, if I'm SE then I'm poor SE. But in the same time I can be
good programmer, and I hope I am. And I can emulate poor SE if it is needed.

> but
>for me a software engineer is merely a programmer who takes an organized
>engineering perspective to the job of producing code,

The point is "organized engineering perspective". Good thing. If you can
follow it without substantional hazards for final effect - very good. But
if there is an alternative... maybe you cannot imagine it ... or maybe you
think that such alternatives may appear only for very stupid people...
well, if there is such an alternative then the choice of SE and the choice of
programmer probably would be opposite.


>... one
>of the things we learn from the engineering disciplines is a respect for
>the body of knowledge associated with an engineering field.

Completely agree.


------------------------------------------------------------
Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia



 

Re: What's the best language to start with

[Alexander E. Kopilovitch]

In <dewar.839694958@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

>>It means that this "programmer" is not programmer indeed, but software
>>engineer. The combination of "careful and well written implementations" and
>>"completely absurd algorithms" is characteristic for substantional part of
>>the growing mass of these brave software engineers.

>... there is no
>distinction of this kind in the terms as normally used here. You can
>find incompetent and competent people under all labels!

I did not say that software engineers are incompetent and I did not say that
"programmers" are more competent than "software engineers". The difference
between these terms (or labels, if you want) doesn't directly relate to
some general competence. These "labels" can designate different _priorities_.
And you could not expect the same profile of competence from people with
substantionally different priorities.


-------------------------------------------------------------------------
Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

 

Re: What's the best language to start with

[Robert Dewar]

I did not say that software engineers are incompetent and I did not say that
"programmers" are more competent than "software engineers". The difference
between these terms (or labels, if you want) doesn't directly relate to
some general competence. These "labels" can designate different _priorities_.
And you could not expect the same profile of competence from people with
substantionally different priorities.

Well I can't reconcile these two paragraphs, perhaps it is a language
problem, or perhaps there are two Alexanders :-)

In the first paragraph you say that incompetence (of this kind) is
characteristic of a "substanional" part of the growing mass of these
brave software engineers, and then in the second paragraph you
said that you were not commenting on relative competence associated
with the two labels.

Anyway the bottom line is that I think the distinction that you are
trying to make is absurd. There is no connection between incompetence
of this kind and the choice of label by either the programmer/SE themselves
or the outside perception of the terms. You seem to definitely have some
derogatory reaction to the term SE, which you are certainly entitled to, but
for me a software engineer is merely a programmer who takes an organized
engineering perspective to the job of producing code, and using "completely
absurd algorithms" is NOT part of such a perspective. On the contrary one
of the things we learn from the engineering disciplines is a respect for
the body of knowledge associated with an engineering field.

Re: What's the best language to start with

[Tim Behrendsen]

On Sat, 10 Aug 1996, DAVID A MOLNAR wrote:

> In article <01bb8540$59ac8420$87ee6fce@timpent.airshields.com> you wrote:
> : 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.
> 	I'm not a CS grad, but I can't help wondering what is considered 
> a moderately simple algorithm at this level.  What sort of description 
> would you give to a person in that position? I would imagine that a fair 
> level of mathmatical literacy might be expected, not to mention some 
> acquaintance with the field you are hiring for...
> 	May I respectfully ask what kind of an algorithm it is/was? If 
> you're still using it as a test for job applicants, I understand if you 
> don't wish to disclose the particulars. I only ask because I am currently 
> finishing up a CS1/CS2 sequence and have been following this debate with 
> increasing interest. Although I can't help but wonder why no one has yet 
> mentioned Scheme (my own 'first'). :-) It's caused me to take a look at 
> what I have and have not learned in the year or so that I've been taking 
> classes...and what I need to learn in the future. Fortunately, I have 
> some years yet until graduating from college. :-)

I have been intentionally not giving my problems away, because it's hard
to think of good solid problems that can be solved in a reasonable amount
of time that doesn't get too much into specialized knowledge that
would make them unfair.  Basically, I have a problem that is arithmetic
oriented, to see if someone can think mathemetically; a logic problem
to see if they understand bits and logic; stuff like that.

I will tell you one "bonus" problem that I give to see if they
are paying attention; I don't really factor it in much when I decide to
hire someone or not because it's not really a fair question.  I love
the problem, though, because it's a pure "thinking" problem.

----
You are writing a preprocessor program that takes C source as
its input.  The preprocessor replaces all variables and symbols
in the program with unique names of the form VARxxxxxx, where
"xxxxxx" is an incrementing decimal number.  Describe what is
needed to handle the case where the input source file already
contains a variable of that form.
----

I would say about 95-98% of the applicants get this question
wrong.  I have had people I respect give the "obvious" wrong answer,
though, so it's mostly a matter of not really thinking about it
before answering.

You should see some of the answers I get that are WAY off,
though.  It's really scary.  At least 20% of the answers are
some form of "I've never done a C preprocessor before, so I
don't know." Yes, these are people with full-blown degrees.

-- Tim Behrendsen (tim@airshields.com)

Re: What's the best language to start with

[Frank Manning]

In article <Pine.A32.3.91.960811134122.76393A-100000@wc.airshields.com>
Tim Behrendsen <tim@airshields.com> writes:

  [ Bonus interview question ]

----
> You are writing a preprocessor program that takes C source as
> its input.  The preprocessor replaces all variables and symbols
> in the program with unique names of the form VARxxxxxx, where
> "xxxxxx" is an incrementing decimal number.  Describe what is
> needed to handle the case where the input source file already
> contains a variable of that form.
----

OK, I'll bite. I'd say that particular case is handled just like any
other case. The input variable/symbol is a completely separate entity
from output string "VARxxxxxx" you replace it with, except for the
1:1 mapping of input vs. output strings. Examples:

   INPUT          OUTPUT

   abc            VAR000001
   Color_Value    VAR000002
   VAR000001      VAR000003
   VAR000004      VAR000004
   X_Prime        VAR000005

Nah...that was too easy. I musta missed something...

-- Frank Manning

Re: What's the best language to start with

[Tim Behrendsen]

Frank Manning <frank@bigdog.engr.arizona.edu> wrote in article
<4up0ar$pim@news.ccit.arizona.edu>...
> In article <Pine.A32.3.91.960811134122.76393A-100000@wc.airshields.com>
> Tim Behrendsen <tim@airshields.com> writes:
> 
>   [ Bonus interview question ]
> 
> ----
> > You are writing a preprocessor program that takes C source as
> > its input.  The preprocessor replaces all variables and symbols
> > in the program with unique names of the form VARxxxxxx, where
> > "xxxxxx" is an incrementing decimal number.  Describe what is
> > needed to handle the case where the input source file already
> > contains a variable of that form.
> ----
> 
> OK, I'll bite. I'd say that particular case is handled just like any
> other case. The input variable/symbol is a completely separate entity
> from output string "VARxxxxxx" you replace it with, except for the
> 1:1 mapping of input vs. output strings. Examples:
> 
>    INPUT          OUTPUT
> 
>    abc            VAR000001
>    Color_Value    VAR000002
>    VAR000001      VAR000003
>    VAR000004      VAR000004
>    X_Prime        VAR000005
> 
> Nah...that was too easy. I musta missed something...

Nope, you got it. :)

The typical wrong answer (when they make an answer at
all) is to start describing a list they keep of the ones that
are already of the form, etc.  Occasionally I'll get someone
go off the deep end and describe incredibly elaborate data
structures.  Heh heh.

I don't count it too much, because it's so stacked to lead
the person down the wrong path.  "Trick" questions rarely
tell you anything significant, except where the "wrong"
answer is really confused.

-- Tim Behrendsen (tim@airshields.com)

Re: What's the best language to start with

[Bob Kitzberger]

Tim Behrendsen (tim@airshields.com) wrote:

> You are writing a preprocessor program that takes C source as
> its input.  The preprocessor replaces all variables and symbols
> in the program with unique names of the form VARxxxxxx, where
> "xxxxxx" is an incrementing decimal number.  Describe what is
> needed to handle the case where the input source file already
> contains a variable of that form.

Do they get extra credit if they hand-optimize to take into
account paging locality, compiler optimizations, etc.?

	:-)


--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: What's the best language to start with

[Robert Dewar]

Tim says

"I would say about 95-98% of the applicants get this question
wrong.  I have had people I respect give the "obvious" wrong answer,
though, so it's mostly a matter of not really thinking about it
before answering."

I can't see an obviously wrong answer, only a trivially right one, so
perhaps you should tell us the mysterious obviously wrong answer. I tried
this on a few people around here and they were all as puzzled as I was.

Re: What's the best language to start with

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.840032915@schonberg>...
> Tim says
> 
> "I would say about 95-98% of the applicants get this question
> wrong.  I have had people I respect give the "obvious" wrong answer,
> though, so it's mostly a matter of not really thinking about it
> before answering."
> 
> I can't see an obviously wrong answer, only a trivially right one, so
> perhaps you should tell us the mysterious obviously wrong answer. I tried
> this on a few people around here and they were all as puzzled as I was.

Well, it seemed obvious to me, too when I heard it the first time
(A friend of mine's father used it as an intelligence test to
programmers), but I guess that shows the general level of
competence in the world.

The typical wrong answer (if I get an answer at all) is to describe
some elaborate data structure to keep track of the "duplicates".
Here's a couple of examples [pulling off the "reject" stack]:

-----------
"The basic need for the program is to replace the input, given
from a C source, with a unique name of "VARXXXXX".

The main body of this program would simply read in data (in c)
and replace it with a variable name.  In order to make sure any
one input source did not have the same variable name (as what it
might be replaced with) we would simply have to add a condition
to our loop.  The program would be set up in the form of a _loop_
where a variable is read _AND_ check that the unique name it will
be replaced with is not the same as the input source file and
then proceed to replace the variables.  In the case where the
input file did have the same variable, a new variable name would
have to be used."  [Underlines were the applicant's]

-------------------
- or -

"I guess it depends on the requirements, performance, but you
could read the code first, save all the variables in a list,
then read the code a second time, then you replace the variable
to a new name, you can check to see if exists already."

Without mentioning the school, this last graduated with a 3.5
and a Dean's Honor List distinction.  Completely unable to
think.
---------------------
I wasn't intentionally picking the most lame ones, BTW; these
were pretty much the ones on the top of the (reject) stack.

Also to be fair, I make them hand-write the solutions, which
is why the grammar is often not perfect (although, still
pretty lame).

-- Tim Behrendsen (tim@airshields.com)

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

[Tim Behrendsen]

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4u7grn$eb0@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:
> : Maybe I'm weird, but I just don't see assembly as being harder
> : than a HLL, and in fact, it seems to me that it's much easier.
> : The number of fundamental things to learn is *very* small, and
> : I would think that being able to show a problem in terms of the
> : "array of memory" being manipulated would just make it infinitely
> : easier than having to wrestle with all the abstract nonsense.
> 
> I know what you're trying to say, but you neglect what the subject
> is trying to teach.  I don't need my students to learn how to print
> out a string calling interrupt this function that, or that the
> instruction *after* a branch is always executed (in some pipelined
> RISCs), or you cannot divide by the ZZX register.  These will all
> be useless in a few years, perhaps even a few months.  I need my
> students to learn when and why quicksort is more efficient than
> bubblesort, and telling them to use assembly sidetracks that effort.

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.

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.

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.

Whatever were doing now is *not working*, let me tell you.

-- Tim Behrendsen (tim@airshields.com)

Re: What's the best language to start with

[Ian Ward]

In article 87ee6fce@timpent.airshields.com, "Tim Behrendsen" <tim@airshields.com> () writes:
>Szu-Wen Huang <huang@mnsinc.com> wrote in article
><4u7grn$eb0@news1.mnsinc.com>...
>> Tim Behrendsen (tim@airshields.com) wrote:
>> : Maybe I'm weird, but I just don't see assembly as being harder
>> : than a HLL, and in fact, it seems to me that it's much easier.
>> : The number of fundamental things to learn is *very* small, and
>> : I would think that being able to show a problem in terms of the
>> : "array of memory" being manipulated would just make it infinitely
>> : easier than having to wrestle with all the abstract nonsense.

Assembler is easy to understand, it has very simple instructions,
this is what makes it so useless at expressing solutions. One needs
so much of it to do anything. Besides all the small solutions have
already been done.

Besides, the second best female software woman I know, who works
for Oracle (in support ???? duh.) got a first class honours degree
in computing/combined science without knowing what Hex was, and I'd
trust her code with my life (but not Oracle's.) Simply because, her
course did not require it. If she had the brains to be able to deal
with abstract concepts, then she could do the design work, and the
simple algorithms could be left to someone else. 

[That was not what I thought of this at the time mind, I thought
she was a stupid bitch, but then in that same year I remember
defending Basic _and_ assembler against Pascal, simply because
I had not come across a problem that I could not solve (and
remember the complete solution months afterward) in my head. 
I wish I go back then, playing around for four hours a day in 
college, and then drinking ten pints of lager (56p a pint.)
Wall to wall vomitting, best days of your life.]

>> 
>> I know what you're trying to say, but you neglect what the subject
>> is trying to teach.  I don't need my students to learn how to print
>> out a string calling interrupt this function that, or that the
>> instruction *after* a branch is always executed (in some pipelined
>> RISCs), or you cannot divide by the ZZX register.  These will all
>> be useless in a few years, perhaps even a few months.  I need my
>> students to learn when and why quicksort is more efficient than
>> bubblesort, and telling them to use assembly sidetracks that effort.
>
>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.
>

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.

2. Software engineering.
There are two things here, one is abstraction, and the other is
best fit solution from multiple points of reference. (The second,
I like because it works for me, I always used to call this 
abstraction, but the whole of the rest of the software engineering
community, in fact, do not seem to.)

I take no credit for this observation, it is blatantly plagiarised.

Abstraction, the software design technique of placing a model for
your design which is as wide as possible, (such as designing your
car control system to be actually a system which can handle all
vehicles up to say, 14 wheels, and then restraining your
implementation to a four wheeled vehicle, by parameters) is part
of the whole series of modern developments in software engineering,
which have been created or refined since early languages were 
created. It is in these fields that languages such as Ada95 and C++
have advantages over their earlier counterparts.

Plagiarism over.

We see modern languages providing the means to implement,
efficiently (or not), modern design techniques (such as, but not
limited to, abstraction) which are the solutions to the increasing
varying types of problems that software people now face. These
varying different approaches to problem solving are mirrored in
modern languages, and by learning (using in the way they were
intended.) languages of sufficiently different front end, the
methodology rubs off and affects the users thinking. (Of course
the methodology shall not rub off, if the programmer writes the
new language in the same way as he would have his old language.
This is why I always feel you must love the language. This accounts
for the experiences of people achieving better solutions in their
preferred language, even though it may not be the best language to
solve the problem. It also explains why people hate some languages,
which of course, they don't, they just resent having to use it.)

In contrast :

  Modern assembler does nothing more clever at the programmer
  interface than it did twenty years ago, even though they are
  miles more efficient than they ever were.

  In my opinion, the main improvements in processor technology
  have come in the internal way they get their speed. There are,
  I guess, two exceptions to this, that really affect the
  programmer, the ability to connect them together, that is
  multiprocessing... and the useful test and set instructions.

-------------------------- ~ ----------------------------

In an interesting post a couple of weeks ago, Robert Dewar,
in reply to a post about somebody who said that learning 
5 or 6 assemblers 'just for fun' that this kind of experience
was not valuable. This fits in with my pet theory on the
subject, because all assemblers are basically the same, and
they implement clever techniques below the programmer interface,
but nothing innovative at it.

Tim seems to be of the school that teaching CS should be done
in assembler because they don't have to put up with loads
of abstractions (read modern methods.) Peter on the other
hand basically is disagreeing with him, on the grounds that
with exception of new device drivers, all the easy stuff (the
stuff that is so easy it can be done in assembler just with
simple jumps, adds etc.) has been done. Modern methods have
evolved to cope with problems that could not be solved, or at
the very least old methods provided unreliable or slowly
developing solutions.
I do not think problems will converge in there similarity either,
by their very nature, the nature of new problems will diverge as
ways are found to solve existing ones.

I have to agree with Peter in this case. I do not think that
assembler is a very useful grounding for programmers, even 
though Z80 was basically my first language. I think I would
have been a better programmer had this not been the case.

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 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. 

Furthermore, if students were told that computers implemented,
at ground level, say, strings, and all these students'
interfaces provided strings, then they would think the bottom
level was their provided interface. There is no reason why they
need to even know assembler, these days, ten or twenty years
from now, there will be even less of a case.

>
>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.

>Whatever were doing now is *not working*, let me tell you.

Perhaps if you tested people differently, and employed the
people who could understand sound abstract concepts, then the
solutions your company provides would be designed better
originally, rather than having lots of clever bits of algorithmic
code to save the inexperienced design these hackers you have
employed have made. Then you may see more success, and not
feel the situation is so hopeless. :-) 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?"

In the rare cases where they do, they, (like ex boy racers
turned thirty, with children,) still retain their speed but
become the safest people on the road, because they have seen
the behaviour of the vehicle beyonds its limits, and they
know not only when it is safe to speed, but also when it
is not. 

>
>-- Tim Behrendsen (tim@airshields.com)


I think Peter is on the right track here.

Best regards,
Ian.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be

Re: What's the best language to start with

[Tim Behrendsen]

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)

Re: What's the best language to start with

[Robert Dewar]

Tim said

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

This seems like a pretty extreme case of NIH syndrome. Any competent
programmer MUST be an "algorithm memorizer" in the sense that if you
have a complex algorithmic problem, then you should at LEAST know where
to go and look up appropriate solutions. In other than trivial cases,
you are very unlikely to be able to cough up on the spot solutions
that compare to the combined knowledge represented by 30 years of
research by thousands of researchers. 

Over and over again I see cases of careful and well written implementations
of completely absurd algorithms for standard problems, where quite
obviously the programmer was simply unaware that there are much better
solutions known. 

Suppose for example you need a fast in place sort with bounded time
behavior (i.e. you are concerned with worst case performance). A good
programmer knows immediately that treesort3 or some variation of it (Knuth
likes to call this algorithm heapsort) is the natural choice. You are NOT
about to invent this on your own. You don't necessarily need to recall
the details, but you should certainly know where to look up this algorithm,
and then be able to code from that description, or in some environments
you can of course short circuit this by using standard libraries. For
instance, if you want to compute eigenvalues of a large matrix, then
you CERTAINLY do not try to invent your algorithm, and you probably don't
even go and look up an algorithm, instead you use a standard library.

Reuse, of both code in standard libraries, and of ideas, in the form of
published algorithms, is a key, perhaps *the* key, tool in a programmers
arsenal.