|
|
|
|
|
by thaumaturgy
5433 days ago
|
|
> ...and the HtDP authors definitely have a point about how much heavy math is involved. I get why people object to heavy math in programming -- it makes the entire field less accessible -- but programming is heavily based on mathematics, if not entirely a subset of mathematics. Saying, "it requires too much math to learn this" strikes me as a lot like saying "there's too much biology in learning to be a doctor". |
|
But simple imperative programming at the level of assembler, for example, I would argue is more closely related to cooking recipes than it is to mathematics. And the reverse mapping of mathematics to programming isn't terribly strong either; most general-purpose programming isn't abstract enough to get big gains from maths.
As a practical matter, I work professionally on compilers - i.e. far closer to the CS end than the glue code end of things - and outside of the usual bits of parsers and grammars and graph theory, I would still submit the only really important piece of CS maths a self-motivated student programmer needs is the analysis of algorithm complexity; big-O notation for space and time, in other words.
All that said, I'd prefer by far students being taught from SICP or CTM[1] than any book targeted at introducing people to a programming language, rather than using a programming language to introduce people to CS concepts. Using practical, industrial languages like Python or Java warps your perspective because in the interests of practicality, those languages are quite opinionated in how you should structure your programs. Things are different with Scheme or Oz.
[1] Concepts, Techniques, and Models of Computer Programming