If, by arguing that math skills are important to programming, you mean "skills in post-Calculus math" than say so. If you say "math," people will continue to believe that you mean math in the way that they experienced it, i.e. math ending at or shortly after calculus.
Lots of mathematicians freely admit that they're terrible at computation. Which is precisely my point - the two represent different skills. Being good at symbol manipulation (i.e. "math" as represented by your high school transcript, SAT, ACT, and college transcript if not a math major) is not a determinant of your aptitude as a programmer.
Is it useful to study math beyond calculus? Of course! I know (abstractly) that things like the typed lambda calculus and set theory exist and are the foundation for much of what we do. However, it is ignorant to talk about these things like they're related to your aptitude for pre-Analysis math.
But what it isn't is rational to to use performance in lower math classes to screen (computer science undergrad applicants|interns|programmers), or to encourage people to choose or not choose programming as a career path based on their performance in mathematics classes.
Your comment made it very unclear whether you believed what you were saying about mathematics or not. Rereading, it still seems like you think conjecture and proof is more like physics than math. And you claim that math is irrelevant to compiler design. It's not "abstractly" relevant, it's directly relevant. Parsing is formal language recognition. Register allocation is literally graph coloring. These things are not third-generation applications of mathematics. You seem to think that mathematics makes you good at computing, when in truth most mathematicians are bad at computing things by hand.
The root misunderstanding might be that most people wouldn't know math if it hit them in the head, but changing my definition of math to fit their misconceptions is certainly not going to fix the problem. I would even prefer it if people thought, "math? yeah I have no idea what goes on in that subject" to what you describe. Because distinguishing between "math" and "post-Calculus math" (the latter of which is almost all of math) won't help anyone.
You are basically claiming that everything is math, which is true, but useless. Programming is more like chemistry or biology in the purity access...not "like them" but at a similar level.
Writing parsers, which I do a lot, requires very little parsing theory...ya, they make for good academic papers, but nothing beats good ole simple recursive descent in flexibility for error handling. And for register allocation, you might use - gasp - an algorithm, but that doesn't dominate your work - writing a compiler involves some math (among other tasks), but is not mathematical activity.
Mathematicians can be bad or good at programming, just like musicians can be...there is no strong correlation to their aptitude based on their previous training.
> The root misunderstanding might be that most people wouldn't know math if it hit them in the head, but changing my definition of math to fit their misconceptions is certainly not going to fix the problem.
Math can be defined so broadly as to basically be a useless word. Is sociology math? Is chemistry math? Is physics math? Is engineering math? Is implementing an algorithm math? Meh, if so, then whatever, we haven't made any progress.
> Writing parsers, which I do a lot, requires very little parsing theory...
I am currently writing an Earley parser. When I'm done, you will indeed need little math to use it. However, I had to grasp several non-trivial mathematical insights to write this damn tool (most notably graph search). And I'm not even done: currently, my parser only handle grammars like this:
A -> B C D
A -> B 'x' E
B ->
etc.
I want to handle the full Backus Naur Form, however, so I will need to compile BNF grammars down to a set of production rules. This will involve things very close to lambda lifting, which is rooted in lambda calculus.
Math is the main activity in writing this parser. The code is merely a formalization of such math.
I believe the result will be worthwhile: the error handling should be just as good as manual recursive descent parsing (RDP). Parsing code using my framework should be about 10 times as short as RDP. It will not be limited to LL grammars, unlike RDP. And you will still need very little math to write a parser —just like RDP. But that's because I will have abstracted it under the rug.
---
I don't know what kind of compilers you write, but I'm surprised to hear you say math is not the main activity. We're talking about semantic-preserving transformations here, how could it not be math?
Or, you already know all the math, and applying it doesn't feel like "math" any more.
I do Bret Victor style interactive programming environments. I've developed a set of tricks over the years and they are all quite simple. It really is programming in the classic sense and not so much Greek symbols on the whiteboard.
also, what I do is not very well understood, so there is no good theory for it yet and a lot of open questions to investigate. So its more experiment and measure vs. find a proof that will tell you for sure the right thing to do.
> I've developed a set of tricks over the years and they are all quite simple.
Actually, so is Earley parsing. The more I study this little piece of CS, the more I see how simple this really is. This is why it feels so much like math to me: hard at the beginning, then something "clicks" and everything becomes simpler.
Your "set of tricks" are probably similar. Knowing nothing about them, I'd bet their simplicity is rooted in some deep, abstract, yet simple math, just waiting to be formalized:
> what I do is not very well understood, so there is no good theory for it yet and a lot of open questions to investigate.
And how do you plan to further your understanding, or finding good theories? It can't be just psychology and cognitive science. I'm sure there will be some math involved, including proofs.
My set of tricks is more like: trace dependencies for work as it is done, put work on dirty list when dependency changes, redo work, + some tricks to optimize previous steps. It is really hard to interpret that as math, especially if the word "math" is to remain meaningful and useful. It is all math at some level, but so is everything.
Thank you. This is what I was trying to say, but better articulated.
I would say that math done by mathematicians would be more indicative of skill, but most people who are/are trying to be programmers haven't really tried that, so it's impossible to assess them based on it.
If you still write parsers as recursive descent parser by hand, then this is because NOT ENOUGH MATH IS APPLIED IN PRACTICE (by programmers who think they don't need it).
No, its because incremental performance and error recovery are more important than raw performance and expressiveness. If you think Dr. Odersky doesn't know enough math...not to mention most production compilers out there written by the best professionals in the field. Reality is a harsh mistress.
My parsers, by the way, do things only your parsers could dream of:
Yep. Well, see my managed time paper; basically we use no fancy algorithmic tricks and it all works out fine. There are 2 ways to do incremental parsing: the hard way based on some fancy delta algorithm, and an easy way based on simple memoization and conservative recomputation.
Academics especially often over think these problems when the simple solution often works fine, and performance wise you'd have to mess up pretty bad before parsing becomes a noticeable bottleneck.
> I would even prefer it if people thought, "math? yeah I have no idea what goes on in that subject" to what you describe. Because distinguishing between "math" and "post-Calculus math" (the latter of which is almost all of math) won't help anyone.
Why not?
Most educated Americans did "math" for a minimum of 13 years of their lives. It would be immensely useful if people who control gates like employment and admission understood that the math relevant to computer science and they math they did/can measure about candidates are different things.
The fact that most mathematicians are bad at computing things by hand is the key takeaway. Hand computation skill doesn't mean you should be a mathematician or programmer. Lack of hand computation skill doesn't mean you shouldn't.
If, by arguing that math skills are important to programming, you mean "skills in post-Calculus math" than say so. If you say "math," people will continue to believe that you mean math in the way that they experienced it, i.e. math ending at or shortly after calculus.
Lots of mathematicians freely admit that they're terrible at computation. Which is precisely my point - the two represent different skills. Being good at symbol manipulation (i.e. "math" as represented by your high school transcript, SAT, ACT, and college transcript if not a math major) is not a determinant of your aptitude as a programmer.
Is it useful to study math beyond calculus? Of course! I know (abstractly) that things like the typed lambda calculus and set theory exist and are the foundation for much of what we do. However, it is ignorant to talk about these things like they're related to your aptitude for pre-Analysis math.
But what it isn't is rational to to use performance in lower math classes to screen (computer science undergrad applicants|interns|programmers), or to encourage people to choose or not choose programming as a career path based on their performance in mathematics classes.
Basically, I side with Lockhart's Lament. https://www.maa.org/external_archive/devlin/LockhartsLament....