I have a couple simple ones off the top of my head:

- You write a recursive program the same way you write an inductive proof

- Abstract algebra and category theory are likely relevant, especially for metaprogramming. My math education hasn't included this, so I can't say much more.

- Linear algebra is just ridiculously important

- Statistics for machine learning. Also for figuring out how to combine data in a meaningful way. There are also a lot of people asking statistical questions directly, and writing programs is how you get those kinds of answers in a reasonable timeframe.

> Abstract algebra and category theory are likely relevant, especially for metaprogramming.

In general, the whole "oh yeah CS people should know some category theory and abstract algebra" is pretty hilarious.

First, it's a bit like saying "oh yeah CS people need to know the undegraduate basics and also the generalization that most mathematicians don't encounter until a couple years into grad school."

Second, most people who say this really mean "a conceptual grasp on different types of morphisms is useful". But that's like saying you need calculus in order to drive a car; or, in the case of categories, it's like saying you need two semesters of real analysis in order to drive a car.

Why not just say "knowing about different sorts of mappings is pretty useful in functional programming"? Knowing how this generalizes to more abstract mathematical objects is totally unnecessary.

Well, frankly you can get along not knowing the "Gang of Four" design patterns and write Java. By the same token, you don't need to know about iterables and comprehensions to write Python, smart pointers to write C++, Graph theory to use a Graph database, macros to write LISP, etc.

By analogy, you don't need to know abstract algebra and category theory to write Haskell. But as in the other cases, knowing helps.

I think you misunderstood my criticism.

"Different sorts of mappings" is NOT synonymous with "category theory". Not even close. Heck, Euclid knew about "different sorts of mappings".

Most everything in Gamma et al is arguably useful for everyday programming in Java. Maybe 5-10 pages of MacLane is useful for everyday programming in functional languages.

Unless by "Category Theory" you mean "5-10 pages of MacLane", Category Theory -- on the whole -- is a horrendously inefficient way of teaching about "different sorts of mappings useful in functional programming."

Unless you want to use functional programming as an environment for doing pure mathematics, there's no reason to actually study actual Category Theory.

Functional Programming is a vast subject.

I've really never needed an abstraction for semigroups, monoids, meet-semi-lattices, monads, comonads, arrows or catamorpisms in Clojure, Common Lisp, Scheme, or Hy.

These concepts become more relevant when I program Haskell, Agda, Isabelle/HOL, or Coq.

I'd say a stronger analogy can be made between reading MacLane's Catagories for the Working Mathematician and reading Hoyte's Let Over Lambda; you really only need to read a little bit of these books to get the core concepts. That being said, depending on what sort of functional programming you're doing, a strong background in category theory or meta-programming can enabling (or not).

> when I program Haskell, Agda, Isabelle/HOL, or Coq.

That's fair. Although Haskell is a bit of an odd man out in that list, both in terms of its nature and in terms of its typical use case.

> That being said, depending on what sort of functional programming you're doing, a strong background in category theory or meta-programming can enabling (or not).

This is where the analogy between the two books breaks down. When you're using a functional programming language as a proof assistant, category theory can be helpful. But this is far less common than meta-programming.

edit: 2nd paragraph.

More simply (but hard to appreciate without going through semesters of work): know that structure-preserving mappings are the important parts.

Yes. But my more important point is that you can tach about these mappings in isolation, in the context of functional programming. No Category Theory needed.

You can teach about "different sorts of mappings" in just about any setting. In fact, that's kind of the whole reason Category Theory exists. So why teach the general result when all you care about is its application to functional programming?

The importance of structure preserving mappings shows up in many other places besides functional programming. I do believe context is important, but having multiple contexts is even better.

> but having multiple contexts is even better.

Given the investment necessary to make this jump, I believe that the benefit outweighs the cost for most.

You don't need to teach category theory proper to get the idea. So I think we are in agreement :)

As someone currently teaching themselves linear algebra (via Strang), I'm curious as to why you believe linear algebra is ridiculously important. I see its applications to graph programming and obviously to cryptography, but I've done a lot of work in both of those subjects and never strictly needed a background in linear algebra to be effective.

Linear algebra is insanely important. I would consider the most important area of numerical mathematics to know. Any sort of mathematical modeling you do is going to involve linear algebra at some point.

I have argued that almost all numerical mathematics, in some form, can be modeled as a linear algebra problem. Google's original page rank algorithm is linear algebra. Remember that Netflix challenge? All linear algebra. Optimisation? Linear algebra. Want to do any engineering of a system? Behind the scenes it is all linear algebra as every single numerical technique for solving PDEs, that I am aware of, can be thought of in a linear algebra sense. Fluid modeling is all linear algebra. A lot of the machine learning I've seen is just linear algebra. I would also that almost every simulation running on the world's supercomputers involves linear algebra.

Do you absolutely need linear algebra to do this things? No. Just like I don't need to understand how my car works to drive it. But having an understanding how these systems operate can really help you use them in a more logical way.

`ridiculously` might be hyperbole, but the two biggest ones I can think of are computer graphics and machine learning; these of which you can't even sneeze at without getting in linear algebra.

I have some sense of the linear algebra implicated in machine learning (I lived for many years with a comp. neuroscience PhD), but I have no visibility into graphics. So with my ignorance pinned to my lapel: the linear algebra involved in computer graphics is pretty simple, right? Just knowing how to manipulate vectors and matrices? Not a lot of eigenvalues, or for that matter orthogonalization?

I'm asking not to rebut but because I hope to prompt the sort of "sell us on linear algebra" statement that will make me study harder. :)

Much of computer graphics operates in projective space (http://en.wikipedia.org/wiki/Projective_space), so it's a little bit more than cookie-cutter linear algebra. This is done so that translations in 3D space — which aren't linear transformations — can be represented as 4D linear transformations in projective space via homogeneous coordinates (http://en.wikipedia.org/wiki/Homogeneous_coordinates).

Still, many folks use the APIs without really grokking that, so in practice it can be a bit cookie-cutter. I think of it similarly to how people can use crypto APIs without, say, really understanding what's going on under the hood.

BTW, projective space is also intimately related to elliptic curves (as you may or may not know — not implying anything!). So that darn linear algebra is lurking all over the place.

Likewise, any time you're talking about fields (even finite fields), vector spaces and linear algebra are right around the corner.

I'm familiar with projective coordinates for elliptic curves, but the funny thing about curves is that, for high-speed software, the math is tricky enough that you don't "need" to grok it: there's an "explicit formulas database" that you can just copy from:

http://www.hyperelliptic.org/EFD/g1p/index.html

Curves are what made algebra 'click' for me, getting me from my high school understanding of "algebra is math about unknown variables" to "algebra is about sets of related objects with operators that have identities and inverses".

Disclaimer: I'm not very experienced with CG, but I think your intuition is correct on CG, for lots of 'boilerplate' game or photoshop programming.

However, I do think you can find plenty of examples in academia. For example, applying PCA

http://cmp.felk.cvut.cz/~hlavac/TeachPresEn/11ImageProc/15PC...

(Perhaps this is just the result of crossover between CG and ML/Statistics here).

Not a good sell, but perhaps someone with more experience can chime in.

- number theory underpinning almost all modern cryptography

- NFA/DFA underpinning regular expressions ( well practical regular exp are not in fact regular, but anyway)

Actually, although number theory touches a lot of "conventional" crypto (some of the design rationale for AES, polynomial MACs), most of workhorse cryptography in normal applications is not especially number-theoretic, and has more to do with information theory and statistics.

The belief that number theory is essential for cryptography is due to its role in public-key cryptography. But even if you're comfortable with number theory, new applications of public-key cryptography are tremendously difficult to get right, and require subject-matter specific expertise.

Another example:

- Linear algebra used in graphics and game programming

Well there is the Curry-Howard correspondence. Though I don't know if this correspondence is intuitive in the general case - I guess what this correspondence means is that programs can be translated to some computational model, which can then be translated to some formal logic, and then back again (but with these kinds of high-level facts, I'm bound to have misunderstood something, somewhere). Though this connection might be only intuitive for some kinds of languages - like statically typed functional languages.

I think it's amazing that programming can leverage and express so many mathematical facts - from implementing a binary tree that is enforced to always be balanced by the type system in Haskell, to using linear types to safely use and free OS resources in ATS.