Re: [stella] OT: Programming, CS theory

Subject: Re: [stella] OT: Programming, CS theory
From: Julian Squires <tek@xxxxxxx>
Date: Thu, 25 Oct 2001 22:31:13 -0230
On Thu, Oct 25, 2001 at 05:11:08PM -0500, Kennehan, Richard wrote:
> >I'm also constantly amazed at how many people, especially those with
> >CS degrees, know nothing about data structures, algorithms, or their
> >effective application. (lots of hobbyist programmers tend to ignore
> >the importance of CS theory, too...)
> I have a CS degree, and I have found a great deal of difference between what
> works "in theory", and what works in practice:

Note that I specifically pointed out people with CS degrees as often
lacking these things.

Since when is any of this stuff theory? This sounds more like the crap
that half-assed profs who haven't written code in 20 years pass off as
``practical programming'', or the often-repeated but rarely understood
quotations of famous people like Dijkstra. Perhaps the only one I might
have issue with is:

> THEORY: Recursion is great!
> PRACTICE: Recursion wastes memory and assumes that the compiler's garbage
> collector is 100% flawless, which is rarely the case

Recursion is an excellent way to approach a problem. Many solutions
are easy to find when you use recursion, and, maybe if you paid attention
in class, 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.

> 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.
I see a lot of people write inefficient (often non-deterministic)
solutions to problems they don't really understand. They often also
don't understand how to estimate the efficiency of their code.

Have you ever read Programming Pearls, by Jon Bentley? It's full of
excellent anecdotes which illustrate my point. There are also many
examples in specific fields. In terms of game programming, the whole
gamut exists because it spans so many fields. How about people using
random numbers instead of permutations? How about incredibly inefficient
or broken representations of numbers? [for example, not understanding
how positional number systems work is a big one]

I've seen a lot of problems which a quick glance at Knuth's TAOCP would

 |/|  Julian Squires <tek@xxxxxxx>

Archives (includes files) at
Unsub & more at

Current Thread