This article is in response to another article by Sarah Mei. I think her article is actually more interesting (and less condescending) than this article.
I don’t agree with this guy that mathematics is less rigorous than programming. I think that people often get away with not-very-rigorous things in mathematics by accidentally glossing over something that seems rigorous, but you can do that just as easily with a program by just writing a bug into your program.
I think there are two kinds of “Programming is Math” arguments flying around these days. One of them is the one that Sarah Mei addressed, which I think she demonstrates pretty well is not persuasive. The more interesting “Programming is Math” argument comes from the Curry-Howard isomorphism.
I think I would agree that programming is literally math, but also that not being good at math in school is not an indicator that you won’t be a particularly good programmer. However, being really good at writing proofs might be an indicator that you won’t be terrible at writing programs.
It’s easy to argue in isolation that understanding algorithms and being able to reason about algorithmic complexity are important. Obviously having this knowledge is better than not having this knowledge, all other things being equal.
But learning this stuff often means not learning other things. I recently read a piece (can’t recall where) arguing that it’s more important that the interfaces to your code be clean and clear than the internal implementations, because it is so much easier to change a messy or buggy or poorly-performing algorithm inside of your system than it is to change its interfaces once there are any consumers of those interfaces. I couldn’t agree more, yet this is an inversion of the priorities of many CS curricula. People graduate with an impressive command of a whole bestiary of algorithms and data structures (many of which they will never again in their careers need to implement from scratch) but without having had to think much or at all about picking the right level of granularity when decomposing problems, designing for extensibility, naming things well, etc. These are the things that, if you mess them up, will make your life harder for years–but most of us have to learn them by being dropped in the deep end.
This article is in response to another article by Sarah Mei. I think her article is actually more interesting (and less condescending) than this article.
I don’t agree with this guy that mathematics is less rigorous than programming. I think that people often get away with not-very-rigorous things in mathematics by accidentally glossing over something that seems rigorous, but you can do that just as easily with a program by just writing a bug into your program.
I think there are two kinds of “Programming is Math” arguments flying around these days. One of them is the one that Sarah Mei addressed, which I think she demonstrates pretty well is not persuasive. The more interesting “Programming is Math” argument comes from the Curry-Howard isomorphism.
I think I would agree that programming is literally math, but also that not being good at math in school is not an indicator that you won’t be a particularly good programmer. However, being really good at writing proofs might be an indicator that you won’t be terrible at writing programs.
I think this is a case of Jeremy intentionally looking past the argument he knows she is making, seems a little belabored.
It’s easy to argue in isolation that understanding algorithms and being able to reason about algorithmic complexity are important. Obviously having this knowledge is better than not having this knowledge, all other things being equal.
But learning this stuff often means not learning other things. I recently read a piece (can’t recall where) arguing that it’s more important that the interfaces to your code be clean and clear than the internal implementations, because it is so much easier to change a messy or buggy or poorly-performing algorithm inside of your system than it is to change its interfaces once there are any consumers of those interfaces. I couldn’t agree more, yet this is an inversion of the priorities of many CS curricula. People graduate with an impressive command of a whole bestiary of algorithms and data structures (many of which they will never again in their careers need to implement from scratch) but without having had to think much or at all about picking the right level of granularity when decomposing problems, designing for extensibility, naming things well, etc. These are the things that, if you mess them up, will make your life harder for years–but most of us have to learn them by being dropped in the deep end.
Being able to craft the argument and arc of a great essay is a more powerful skill than exquisite grammar.