[kens]

I'd much rather deal with the metal than with category theory.

(I'm not trying to be snarky here, but I've studied category theory and it seems like a whole lot of effort for very little benefit. On the other hand, it's fun to figure out the metal. (Although silicon's not exactly a metal...))

[wpietri]

Yes. To oversimplify, it seems like there are two schools of software: the car-mechanic school and the math-professor school. I happen to be of the car mechanic variety. That doesn't mean I'm not borrowing energetically from people pursuing the math-professor approach, but by now I'm pretty sure where my strengths lie. And given that computers (and cars) are mainly used for practical outcomes, I'm totally ok with that bias.

[dxbydt]

>the car-mechanic school and the math-professor school.

Heh heh. Having worked mostly with math professors, I would say the code they write almost exclusively belongs to the car-mechanic school. Math professors never deck up their code with CT. The majority of the time a math prof has to write code, its to do heavy-duty applied math, engg stuff ( solve pde's, fluid mechanics, EE math, fourier transforms, gradients etc. ) or to display some cool visualization to the students ( here's how a vector space looks! here is what happens when you apply linear transformation!! here are all the elements of a quotient group!!! ) - those tend to be done in Matlab/Mathematica/Maple/Gap...and these tools have zero CT. The applied stuff tends to use netlib, gams, gsl, colt, apache math...mostly a lot of gsl these days...again no CT there. Most of them are very happy to declare giant matrices & happily mutate away.

[wpietri]

Heh. Yeah, a lot of the actual PhD-types I know are amateur coders on a mission, and their code matches that.

I'm sure you get it, but just for the record, by math-professor I meant "very focused on things that to most people seem incredibly abstract", with a side of "passionate about solving intellectual challenges for their own sake".