[arghbleargh]

As someone who has done a fair bit of both math and programming, I will agree that having some math knowledge has definitely helped at various times when programming, but I don't think these specific instances (e.g. the 10 examples given in the article) constitute the primary reason it's a good idea to learn math. For the purposes of handling those specific situations, I think you would do fine to just learn the math as you encounter the need for it (and 95+% of the time you don't need anything beyond high school).

To me, the primary value of math for programming is that it is a pure form of exercising many of the skills that help you write good code. For example:

- fluency in logical reasoning

- turning vague intuitions into precise statements (translating business requirements into code)

- formalizing proofs (covering all cases, establishing invariants)

- developing abstractions to succinctly describe relationships

- solving a problem systematically

You can also learn these skills by programming, of course, but probably not as quickly, because you will be distracted with other tasks such as debugging, setting up your dev environment, waiting for your program to run, etc. So in my opinion, what's important is not so much the immutability of the math itself, but rather the process of doing the math. I would be interested to know if others have had similar experiences.

[kaeluka]

I agree with what you say, but it seems obvious to me.

On the other hand, what gets overlooked, IMO, is the "other stuff". Humanities, law, business, biology, take your pick!

When faced with a problem, a programmer is always looking at at least two issues:

1. to implement, 2. to understand the problem domain.

I see math being exceptionally helpful in 1), but at most somewhat helpful in 2) -- because at the end of the day, programs that we write tend not to be about math, or logic. Category theory does not help you understand the contract your company signed with some other company 12 years ago, and the amendments they made 7 years ago. It does help you implement these things concisely and correctly. What'd would help you understand would be for a programmer to know something about contracts.

Most programmers that I know have a certain talent for and knowledge about math. Most programmers that I know, also don't know a lot about the world outside of computers. That includes me, fwiw.

I think that their careers would profit from considering learning some non-mathematical domains more than from learning more math.

I'm not arguing against math, but I'm arguing for a good balance. To know at least the basics of some other domains, before you set out to learn a lot about one.

[pigged]

I disagree, I would say most programmers know too little math and even too little computer science. As a field we are way behind most other fields in how well we know our own field. Yet most programmers are somewhat familiar with many other fields because they spend a lot of time reading about stuff on the internet.

I think the reality is the opposite of what you suggest, programmers are in no way an example of a profession where most practitioners have a deep and extensive knowledge. For most programmers, the learning method is finding out how to DO things (as in, find an example on the internet, try it, it works, I'm done) without actually understanding anything.

You must be very lucky in where you work if you think programmers know a lot of math and even know what "category theory" is.

[kaeluka]

I don't think that reading about stuff online leads to knowledge, just like repeating writing the same boring CRUD app over and over again won't make you a much better programmer.

> As a field we are way behind most other fields in how well we know our own field.

I'd be surprised if that was so. I think we have a tendency to idealise other fields' achievements :) Additionally, I think you're using a scientist as a role model for a programmer. I don't think that's a good role model. Most programmers are technicians, not scientists. They produce products, not knowledge.

> You must be very lucky in where you work

Hm. It is the case that I'm lucky! I work at a University, in a PL group. So the people around me daily have better math foundations than most. I'll admit that there is bias in what I say.

[pigged]

I am not using a scientist role model. I am using a role model like Linus Torvalds, John Carmack or Eric Lippert. Would you disagree that these are good programmer role models? They have DEEP knowledge, not just "hey man have you seen the latest javascript framework".

And I don't see why you think the average programmer knows less about the law than someone in another non-legal profession. In my experience this is simply not the case, and yes, reading about it on the internet is better than not reading about it at all. It's not like dentists spend their time reading actual law books. Honestly, I have no idea where you get this from, it sounds absolutely wrong, but I guess we'll have to agree to disagree on this.

[kaeluka]

These are role models that I personally very much agree with. At the same time, the industry has need for relatively few people like them. Of course, if every programmer would magically turn into them, that'd be great. But no one turns into them over night. And I think it's obvious that it makes no sense honing yourself into a perfect logical machine of deadly precision, if tomorrow you're still writing the same boring crap. Most programmers have boring jobs. Not because they're bad, but because most software being written is solving boring problems.

I don't think that the average programmer knows less about the law (or any other field) than someone in another non-legal profession, I think that they know about the same amount. But they should know MORE about the other professions, because most programming jobs have to do with commerce, law, design, what have you. Software products almost always have to do with a domain that is not software. A dentist has little use for law in his working life, but a programmer is more likely to profit from a basic understanding.

One thing that is special about the programming profession is that it is very diverse in levels of skill. And that's not only ok, I think that's a good thing.

I think this diversity is connected to a few things, one of them:

Our work product is very cheap to copy, and in the resulting economy, a small difference in utility will lead to huge differences in market share. Given a large market, this makes it reasonable to hone your skills further, where in other professions you'd be facing diminishing returns much earlier. This applies more to software that is widely used -- it has a larger market. Given a small market, this applies much less. In other, oversimplified, words: if you're writing software that is used (directly, or indirectly) by thousands, it pays off to train yourself for an extra year, even if it increases the utility of your product by only a small percentage. On the other hand, if you're a freelancer building web pages for a local business (a market size of 1), you're not going to profit much from the increase in utility.

Becoming Carmack makes sense in a large market. In a small market, it doesn't make sense to try to dominate it, but to acquire new markets.

[pigged]

I think the average programmer makes many more mistakes due to not knowing computer science and math / lacking a deep understanding of programming than due to any other deficiency like not knowing laws. It is at least true for the programmers I've worked with and have not been satisfied with.

So in the real world, this is what causes me problems - actual problems with a large application that cause friction with clients - people being bad at programming and not knowing even the most basic computer science and math, mostly manifesting itself in the application becoming littered with inefficient code over time (the second most common problem being lack of or superficial technical knowledge, such as using a framework or even language without understanding how it works under the hood, this usually manifests itself in the same way).

Note that the "I don't need to know math/cs" people will often not realize they needed something because they will just solve the problem incorrectly, inefficiently, or decide it is not possible to solve efficiently and compromise on requirements. What's worse, even if they are shown the error of their ways multiple times, they almost never truly change their mind, regardless of evidence. It is a mindset people seem to commit to early in their career, or even to a more general version of the same mindset in childhood, and never change it. That's why there's so many of them.

Sure, there might be situations where it is not useful to be a better programmer than you are. But I would say that is not the norm. I don't work on some algorithmically-super-complex application, it is just a typical large application used by professionals for their work; it doesn't involve any truly difficult problems but has a huge number of relatively small and easy problems all over the place. I'd say it's somewhere in the middle of the software development spectrum.

[adrianratnapala]

This comment sums up my own thinking better than I could have. Though if the pure functional approach gains more ground, the link between maths will become more direct -- writing a Haskell program feels a lot like writing a formal proof of an algorithm. And all proofs are maths.

That said: this might be a reason to teach less maths in schools. If someone can invent a good informatics curriculum for children, then it's OK if it eats into class time for maths, because the (hypothetical good) IT subject will teach them some of the most skills underpinning maths.

[noelwelsh]

Agree 100%. The strong connections between FP and maths make the programming in an FP language very much like doing maths. Usually very simple maths, but that's a good thing.

You might like the Bootstrap curriculum: http://www.bootstrapworld.org/ It's developed by the PLT research group behind Racket and How to Design Programs. Very good stuff.

[henrik_w]

Exactly! Keith Devlin also made this point in an article (from 2003) in Communications of the ACM called "Why universities require computer science students to take math" (pdf) ftp://ftp.gunadarma.ac.id/.upload/Communication-ACM/September-2003/p36-devlin.pdf

Sample quote: "Once you realize that computing is all about constructing, manipulating, and reasoning about abstractions, it becomes clear that an important prerequisite for writing (good) computer programs is the ability to handle abstractions in a precise manner."

[sklogic]

Exactly. Programming is mathematics, all of it. It is not just overlaping with mathematics in few peculiar areas but it is nothing but mathematics and must be treated as such.

[InclinedPlane]

For me I found that having an education in math made me a better scientist, and being a better scientist made me a better developer. Having a background in mathematics makes you very sensitive to when and where assumptions get made, as well as very exacting about the line of reasoning between evidence and conclusions. It's surprising how common unchallenged assumptions can be in science, but in development work it's practically a disease. Troubleshooting and root cause analysis are extremely important parts of dev work, and it's amazing how bad the average dev is at it. Prone to jumping to conclusions and ready to blame the usual suspects even when the evidence doesn't match.