>maybe if you paid attention in class...
This is kinda harsh. I wasn't trying to antagonize you.
>you would have learned that memoization and conversion to an iterative
>solution should always be done in practice unless you're working in a
>language like LISP or Haskell.
In the course I took, this "conversion to an iterative solution" was most
likely glossed over, or mentioned in passing.
I remember having to write a program that that found chess positions so that
no queen could capture any other queen, using recursion, in Pascal.
That assignment pointlessly emphasized the importance of recursion, to the
point of teaching us that it should be used more often that it actually
should be. A MUCH better assignment would have been this:
An evil computer programmer has used recursion in order to make his code so
hard to read and understand, that only he can understand it, thus preventing
him from ever getting fired. However, the company decided to fire him when
another programmer discovered his evil plan. As a newly hired programmer,
it is your job to CONVERT his recursive mess into an iterative solution that
is easy for other programmers to understand and maintain.
This would teach students how recursion works, AND how to convert it to an
iterative solution, AND teach good coding style, AND teach a lesson about
how trying to engineer your own job security makes life harder for the
person who will eventually replace you.
LISP is a great language for Artificial Intelligence, and recursion would be
better taught in a class that focuses on LISP
>> Do you have some specific examples of CS theory that you see
>> ignored, but shouldn't be ignored, and actually WORKS in practice?
>How about: use the right algorithm and data structure for the job.
Again...do you have a specific example? This is still pretty vague.
>I see a lot of people write inefficient (often non-deterministic)
>solutions to problems they don't really understand.
Still kind of vague. Anything specific?
>They often also don't understand how to estimate the efficiency of
>their code.
A little more specific?
>How about people using random numbers instead of permutations?
Like how?
>How about incredibly inefficient or broken representations of numbers?
Example please?
>For example, not understanding how positional number systems work is a
>big one
More detail please?
>I've seen a lot of problems which a quick glance at Knuth's TAOCP
>could solve.
Like what?
>Have you ever read Programming Pearls, by Jon Bentley? It's full of
>excellent anecdotes which illustrate my point.
This is a book I should probably own, and I will look for it the next time I
go to Barnes & Noble. But if they don't carry it, I would have to
special-order it just to be able to browse through it. Rather than wait 2
weeks, could you be more specific to the above examples so that we can ALL
improve our coding styles today?
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
