21–30 of 76 posts
This isn't unique to mathematics; it's the reason it's hard to scale the number of programmers working together on a Lisp codebase. Each programmer writes their own notation (macros), and ends up down their own rabbit-hole of a sub-language that nobody else can immediately understand.
> Perhaps one of the most prominent objections to devoting a lot of time to mathematics is that it can be years before you ever apply mathematics to writing programs. On one hand, this is an extremely valid concern. If you love writing programs and designing software, then mathematics is a nothing more than a tool to help you write better programs. Calling it an "extremely valid concern" is understating it. The dilem…
Everything else is specific to the domain you're programming in; these "meta" fields (I need a better name for them) have programming or reasoning itself as the domain.
I don't know about the OP's point on the value of proof to programmers. I do optimization and machine learning, and I use all kinds of math on a regular basis. But I don't prove things, and rarely need to follow someone else's proof either. You can get a lot out of applied math without touching a proof. And if it isn't applied, then you really don't need it ;-). I agree there is value in learning how to read math not…
I can't believe how many times a great advancement in theory in different field comes from pure math advancement (or applying pure mathematical results). Say in economics, if Nash didn't apply topology, how would one ever know Nash equilibrium exists. Stable matching, compressed sensing and others also comes to mind.
I have a hypothesis that any field would benefit if we introduce some pure mathematicians to them.
I think the biggest stumbling block for me was all of the stupid tricks involved in the proofs I had to do for school. "If I add sin(x) to both sides of the equation, then I can use such-and-such identity which makes this equal foo." If you don't make the correct mental leap, then you get completely stuck and it's really easy to give up.
* enough memory to remember the identities * fast enough recall of identities from memory @ * fast enough exploration of possible solutions @
@ Fast enough is when you can do it all within the amount of time it takes for solving the problem to give enjoyment rather then ending a frustration.
Without the above I have to use different, usually more intentional, strategies.
tl;dr: i'm a snobby research student who is trying to trash developers who didn't need college. (yeah. that was an ad hominem. come at me.)
That's not at all what the author is trying to say. He's pointing out the shortcomings of mathematics notation and why that can be off-putting to otherwise motivated programmers.
If this is intended as a defense of Math culture, I think it falls short. He does a good job of pointing out the corresponding problems in the state of programming: Indeed, the opposite problems are familiar to a beginning programmer when they aren’t in a group of active programmers. Why is it that people give up or don’t enjoy programming? Is it because they have a hard time getting honest help from rudely abrupt mo…
This isn't entirely true. Numerous mathematicians have publicly bemoaned the difficulty of communication between mathematicians in different specialties. So it's definitely not something that is ignored. The question is what to do about it. We're not just talking about confusion arising from different notation between mathematical specialties (resolving that would be as easy as defining your notation in an appendix),…
In programming languages, different paradigms differs as much as how different field in math. So a more concrete analogy would be one jumping from different paradigms of programming languages. Like someone using a imperative language like Java for their entire life and must learn to read a Haskell program.
First of all, let's acknowledge that many (the great majority of?) programmers have little or no use for math, and know it, and are correct. That's totally fine. I think danso's comment captures this well, with references to UI design, domain knowledge, engineering practices, etc, and dxbydt similarly mentions "git rebase and jira tickets". So let's assume we're restricting ourselves to programmers who do have a use for math (and hopefully know it).
FIRST PROBLEM
TFA's introductory claim is apparently that there are programmers who say "math is useful, I want to use it, I don't want to read or write proofs", and that this is ludicrous. It's absolutely not ludicrous.
Yes, a working mathematician's job is to explore and understand the space of mathematics, and yes, that is inextricably bound up in proof. And I would suggest that learning more about math proof is a soul-enriching use of anyone's time (in the same broad vein as learning Latin). But techniques of calculation are one of the valuable outputs of mathematicians, and it is reasonable and effective for a person with a task to say "I would like to have more powerful techniques of calculation, and I don't want to learn proofs".
For example. Certainly it is possible to learn how to do Gaussian elimination, and use it to solve systems of linear equations, to good effect, without being able to prove that elementary row operations preserve the system. Maybe it helps? Maybe it doesn't? If you want to invent a new technique, I imagine that in that case being able to prove the correctness of the existing technique probably helps a great deal. But what's unreasonable about the person who says "I have these equations, I need to find the values (if any) of these variables here that make all the equations true, and I'm too busy to learn any proofs today (and too busy to write any proofs ever)"?
For a simpler example, we used arithmetic just fine before ZFC.
SECOND PROBLEM
Maybe this is actually two problems, intertwined. And maybe both of these problems are quibbling.
Primus, he says "Mathematics is cousin to programming in terms of the learning curve, obscure culture, and the amount of time one spends confused". I think this is highly questionable. Mathematics is far harder and more baroque than programming, not least because as a discipline it's nearly one hundred times older.
Secundus, after acknowledging the insanely annoying tendency of math papers to make up their own notation without ever defining it, he claims that the non-mathematician's confusion is comparable to the non-programmer's confusion at for(;;);. No, it's not comparable. The math case is hard because someone failed to tell you what you need to know, and no one wrote it down anywhere. The for-loop is only hard if you did the opposite: failed to read what was actually written down (e.g. in K&R) and took someone's word for it that the standard and general form of the for-loop is for(int i=0;ido stuff with i/ }
My claim here is that the learning math - even just the calculation techniques - is genuinely inherently hard. Partly that's because it's so overwhelmingly useful that if it wasn't, we'd already know it; clever students know more calculation technique by age 15 than most professional programmers know about programming. But on the other hand it's also contingently hard, because mathematicians aren't generally very interested (nor incented) to export their product so that outsiders can make use of it. Which I guess isn't so terrible; once someone else labours mightily to learn all that very-hard math, you can hire her at an exorbitant rate to make use of the calculating techniques she has learned. Or if you want to get that benefit without paying the exorbitant rates to outsource the math, you can roll up your own sleeves. Good luck!
I don't know about the OP's point on the value of proof to programmers. I do optimization and machine learning, and I use all kinds of math on a regular basis. But I don't prove things, and rarely need to follow someone else's proof either. You can get a lot out of applied math without touching a proof. And if it isn't applied, then you really don't need it ;-). I agree there is value in learning how to read math not…
I think that theorems are just like libraries you can pull in for your purposes, and the proofs are the unit tests that you can dive into if needed ;) !
> “The proof is trivial.” This is the mathematician’s version of piping output to /dev/null. Heh heh. Never thought about it like that. Amazing write-up, btw. As somebody who dabbled in both CS & Math, I'd say the cultures are vastly different. You can spend years, decades even, just teaching undergrad calc courses while having barely 1-2 papers to your name, and yet you'd be considered a legitimate mathematician & g…
However, many CS papers aren't an easy lecture either, even if they talk about something really practical. I remember reading the paper on String B-trees, which is a data-structure for string search optimized for external storage (so you don't have to fit the whole index in RAM) and even if I understood all the concepts, the language was rather obtuse for no reason.