I've never understood the idea that math is not necessary for software development... It bothers me, math is not just useful but just taken for granted... pointer offsets require addition, looping requires counting - doing useful things in software almost always requires math... it might be super simple math, but it's math... Also typically the hard problems the ones that people will benefit from in software does require advanced math, e.g. machine learning.
If you're chugging out html or css maybe you have used math to calculate an offset?
If you're working in a database maybe you've thought about the intersection of a set of two related collections of data?
Math is used and pretty darn necessary for programming. You are probably just taking it for granted.
It seems obvious that the discussion here is about college level (or late highschool level) math, not elementary school arithmetic.
Your response is a little bit like an article saying "studying literature isn't necessary to be a good software engineer" and someone replying "reading and writing names and 1-sentence comments is still reading and writing".
The extent that math is directly involved in html and css is a pretty weak; I don't see it as justification for the "math being necessary" idea for programming. At least not anymore than "math is necessary" to be a cashier or truck driver. It certainly isn't "construction worker" level math.
However I do think math is beneficial, verging on required, but that is because studying math (beyond just arithmetic) exercises a sort of problem solving skill that I find very similar to what is often encountered in programming.
> pointer offsets require addition, looping requires counting - doing useful things in software almost always requires math... it might be super simple math, but it's math
Thats grade school arithmetic nothing to do with what is usually considered math ( cliche about mathematicians struggling to calculate tip ).
Math is about creating abstractions and using those abstraction to build even bigger abstractions much like software development.
While arithmetic is almost undeniably necessary for programming (and even some more advanced topics like basic linear algebra), I think the core argument here is more about "higher" math. Stuff like how to reason about abstraction and prove statements or more technical details like how to confront round off error.
I'd say these are essential skills for me, but I can see why some might see them as unnecessary.
Exactly. I think people get hung up over what level of math and what type of programming.
Sure, you use general math in almost all programming. Up to basic algebra and maybe a little more. I've done well enough for myself, but never received more than a basic junior high algebra class. Of course, I'm not writing cryptographic systems, graphic engines, or some sort of predictive engine, either.
Others, say John Carmack, need an obscene amount of match knowledge (among other things).
But math beyond that is what we're talking about. I an am accomplished programmer but I never 'got' math in my later years of high school - whether it was the teacher or me I don't know, but trigonometry and the like are still somewhat of a mystery to me.
But it hasn't really impacted me as a developer. I think there's a separation between specific mathematical concepts and logic - I get the latter, but not the former.
You can't possibly know whether it has impacted you as a developer, because you don't know what "you with more math" would be like as a developer. You can say that you're doing fine in spite of no math background, but I don't think you can reasonably claim anything about where you would be if things were otherwise.
For myself, I have experience programming with no math at all, with high school math, and with self-taught axiomatic math (I've been programming since I was quite young). I can say with certainty that every time I've learned more math, I've been able to improve as a programmer as a direct result. This even applies to relatively esoteric parts of mathematics, like category theory.
I don't think anyone's claiming that you can't work as a software developer without a heavy math background. We're just saying that you can go a hell of a lot further if you take the time to learn the math.
I never said that I am the best developer that I can ever be without it. After all, the title is "Math is Not Necessary for Software Development", not "Math will increase your skills at Software Development".
If I had better math skills I don't doubt that it would benefit me. As it is, I've got some design skills and some product knowledge, so my broader skills just skew a little differently.
Your claim was: "it hasn't really impacted me as a developer." That's the claim I responded to. Also, if you read the actual article, you will see that the majority of the content is regarding whether or not math is useful for software development, not just whether or not it is necessary.
"[T]rigonometry and the like are still somewhat of a mystery to me."
That's a shame. Trigonometry was the most fun I had in a math class before college. I'd recommend you give it another try, ever - the trick is to relate everything back to the unit circle.
For web, front-end, or mobile apps (excluding games), I agree math is not necessary. These type of apps rarely uses math, they simply streamline data and present it on the screen. It can't hurt, but it isn't a criteria when I interview developer.
Of course, once you get into back-end systems, data analytics, and algorithms, math becomes much more useful, if not a necessity.
I've done quite a bit of front-end work and one of the teams I was on built a large graphing application. It required algebra for some of the plotting routines, but nothing too major.
It wasn't until I got into relational databases that I saw you really needed more applied mathematics to be a good database designer. Then you start to read about Dijkstra and Codd and suddenly realize your HTML, CSS, JS world seemed rather small by comparison.
Yeah, and it's REALLY important for graphical programming. Vectors, Matrices, and Quaternions nearly killed me when I started doing work that required it.
Have always wondered. Is there any evidence that learning to solve math problems - even in the spirit of this Author's post - makes you a better thinker / problem solver? That is - compared to similarly rigorous problems in other fields - does math come out ahead?
The only other field that I have deep knowledge of is Electrical Engineering and I'm hard pressed to find rigorous problems in EE that aren't based on math at some level. The same could probably be said for any other branch of Engineering or science.
What kind of problem from another field were you thinking of that doesn't devolve to a mathematical problem in the end?
(Sorry if I'm reading into an implication that isn't there)
To clarify, everything is based on Math at some level, just like everything is based on Physics at some level. My question is does it follow that solving difficult math problems make you better at solving difficult Foreign Policy problems, for instance? That is, if one student studies 10 hard math problems, and another studies 10 hard Foreign Policy problems, which will be better at solving the next Foreign Policy problem? The next Literary Analysis problem?
I don't think it follows that math being a required part of a solution for difficult problems makes it the best tool for the task of solving the problem at hand. But its common to argue that rigorous mathematical education will make you better at solving problems in general; I just wonder if there's any actual evidence to it, or if its all based on belief (however logical and well argued).
That's actually what I wanted answered. While I do believe that study of math improves the ability to analyze problems that have an underlying logical framework, I also think it can be a hindrance in some cases.
Something like Foreign Policy involves so much nuance and understanding of History, human and organizational behavior that I think attempting to take a purely analytical approach to solving those problems will fail.
You reminded me of something an English professor said to my class decades ago when one of us complained about the amount of Liberal Arts classes we were required to take. As best I can remember it was, "as engineers, your job will be to solve problems, but you need to understand that not all problems can be solved logically. There probably is no better way to learn that than by studying Literature."
It depends what type of software developer you are. If you're the type who scours the web for open source tools to solve your problems, generalizing your challenges as coding problems, then maybe math isn't useful. Having a logical, structured approach to solving your problems, the way you would with theoretical problems (like in algorithms or discrete math), definitely requires some mathematical maturity. Not to mention, you can't study CS in college without a strong math background. Even outside of math requirements, you would absolutely struggle in core CS classes like algorithms or automata. Then again, a CS degree may not be necessary for software development either. But even from a practical point of view, it's harder to get a job in software development without a CS degree.
WRT the "only one right answer" argument -- even with math there are often multiple approaches to a solution. See "Pythagorean Theorem" for one example.
Yah I don't get the "math is not necessary" argument either. Perhaps in some very narrow and limiting definitions of either "math" or "software development" this is true. Logic, functions, data structures, all have sturdy foundations in mathematics.
Maybe you can get started in software without good mathematics fundamentals, but you won't get far without them.
Sarcasm whooooosh (and edited to add that a lot of people disagree with you, as near as I can tell the vast majority of database designers ... I like that, I make a huge sum of money coming in later to fix their screw ups)
I actually do agree that math isn't necessary for many types of software development. This is one of the reasons I'm angling to get more into data science - I was a math major, and I'd actually like to be doing more math. I would also tend to agree that studying math can sharpen your mind in a way that would help for programming, but you could say that about a lot of mentally challenging fields.
It is, of course, possible to agree with a conclusion while disagreeing with the reasoning behind it. I completely disagree with a couple of statements here. Again, this is probably because as a math major (and as a short-lived doctoral student in an engineering department that was heavy on proof based math theory around optimization and stochastic processes), I've experienced "math" very differently from most people, including engineering or science students who have done a substantial amount of math (say, the calculus sequence through differential equations).
Math (I'm talking about the US based university approach) changes dramatically once you get to "upper division" coursework. Real Analysis is very, very different from the differential equations course that is about one-fifth math majors and four fifths engineering or hard science majors. There's very little "applying an equation" going on. And the notion that there is "one answer" is remarkably incorrect (I suppose it's correct if you define "TRUE" as the one correct answer to fermat's last theorem, but there are often so many different correct ways to go about a proof).
I remember a story about Graham Nash (the Nash equilibrium guy - this is all from memory based on his biography, so I may have some of the details wrong). Nash proved a very difficult and elusive theorem early in his career. It was later discovered that a different mathematician had completed a proof for the same theorem a short time earlier (I think it was a few months). Nash was apparently very depressed by this. However, he shouldn't have been - the other proof was by contradiction, whereas Nash's proof was more direct and contained the structure for an algorithm, and would probably be more influential.
This isn't at all unusual in math. There are a huge number of different angles on a problem.
Part of the problem here is what is meant by "math"... it is a shame that someone could get as far as second year university math in the US and still see it as a field where you simplify things to the point where you can apply a formula to arrive at the one right answer. In Ross Hunter's defense, he didn't say that's all that math is, he said "People who are good at math are good at breaking problems down into parts, recognizing patterns, and applying known formulae to those parts to arrive at the one right answer."
But you know, people who are good at math do far, far more than that. I know, because oh my god math got harder after the standard "calc through diff eq" sequence.
King Graham was the guy in the King's Quest games. I think we now need a PC adventure game where the main character is a musician king who discovers new mathematical ideas and then goes horribly insane.
> Part of the problem here is what is meant by "math"... it is a shame that someone could get as far as second year university math in the US and still see it as a field where you simplify things to the point where you can apply a formula to arrive at the one right answer. In Ross Hunter's defense, he didn't say that's all that math is, he said "People who are good at math are good at breaking problems down into parts, recognizing patterns, and applying known formulae to those parts to arrive at the one right answer."
I think it's reasonable to assume, given what he stated, that Ross does in fact conceive of math that way. It blows my mind that one can get through a discrete math class and still think of math as basically computational in nature, since as far as I know most curricula treat the course as an opportunity to introduce the sort of concepts that typically figure into an introduction-to-higher-mathematics-type course, such as proof techniques, basic number theory, and so on.
> Part of the problem here is what is meant by "math" ...
this
Math education is mainly suffering from a PR problem right now. Most people associate the word 'math' with memorization of facts and rote learning of arithmetic steps. These are boring and unpleasant activities: if this is what math is like, then I don't like math either!
It's end time we re-associated math with abstract thinking and modelling of the real world. It will make it much harder to be a math hater... Anyone interested in rekindling their relationship with math and physics can check out my book http://minireference.com/
(Disclosure: I taught college mathematics courses (almost entirely from the calculus sequence on up) for one semester as an undergrad, 4.5 years in grad school, and 4 more years as an assistant professor.)
> Math (I'm talking about the US based university approach) changes dramatically once you get to "upper division" coursework.
It's not just a dramatic change; for most, it's a cliff thrown in the middle of the learning curve. There are many reasons for it: some high schools passing students along when they shouldn't, some professors doing the same thing when students get to college, and the ever-so-fetishized focus on applications over concepts. In short, it's a cultural problem. And at this point, I have no idea how--or if--it can be resolved.
> It's not just a dramatic change; for most, it's a cliff thrown in the middle of the learning curve.
When I transferred to a new university I was placed in their first year calculus program over my own protests. I had already done AP Calculus in high school, and completed the first year calculus course at my previous college, which was admittedly of much lower quality than the university I was transferring to. I thought this new one would be a complete waste of my time.
The first thing we covered in this new course were limits. I rolled my eyes; everyone knows how to find a limit. Was this really the kind of thing we were going to cover in this class? Then the professor said these words I had never heard in relation to limits before, "epsilon" and "delta." And here my troubles began.
That turned out to be one of the hardest courses I've ever taken, I had to relearn almost everything I thought I knew about math.
[nod] Yep, sadly, there are too many "calculus" courses that don't mention epsilon and delta at all (I'm looking at you, Business Calc). Without thinking about epsilon and delta, it's prettymuch impossible to have anything but a vague, fuzzy notion of what a limit is.
In Calc I, I kept my eyes out for two groups of students: those who did really poorly on the first exam, and those who did really well. The first I watched for obvious reasons, but some of the folks in the latter group--especially those who took some calculus in high school--would start to think "Oh, I know all of this now! Cool. Easy A." and then coast. And they'd be mincemeat somewhere in between implicit differentiation and related rates.
For me, this cliff came with discrete mathematics, where the appearance of proofs, induction, set theory, and so on left me completely foundering for some time. They were all topics that I had literally never touched before except in the most brief, informal ways, and none of them seemed to have any relation to material I'd previously learned.
None of it really made any sense to me, and in retrospect, the only reason I even managed a passing grade in the course was because I'd been taking a statistics course at the same time that covered many overlapping topics (sets and relations, discrete probability, etc) in a "use these things to calculate this other thing" way that actually meshed with my previous education.
Proofs were the real killer out of all of it. I still today have barely any idea how to manage a formal proof or what elements are involved in one, because at the time trying to figure out what the hell was going on with this notation and formatting and abbreviations everywhere that I'd never seen before and trying to make any sense of the weird self-referencing logic of it was unpleasant enough that I just fumbled through the bare minimum to get a passing grade whenever they were involved.
I think a better way to phrase the point that the original post was trying to make is "If you're bad at math as it is taught in elementary/secondary school in the US, that doesn't necessarily mean you'll be bad at software development." It also never claims that math isn't useful, which is what this author is spending a lot of time trying to refute. It just says that you don't necessarily need to know/understand a lot of advanced math in order to write a CRUD app, which should be obvious.
If you're bad at math as it is taught in elementary/secondary school in the US, that doesn't necessarily mean you'll be bad at software development
Yes! Or from my perspective. "The love of methodical problem solving that you can discover in software development can help you overcome your math anxiety"
And just for fun, I'll reassure everyone here that, "If you're bad at math as it is taught in elementary/secondary school in the US, that doesn't necessarily mean you'll be bad at real math."
If you're bad at math as it is taught in elementary/secondary school in the US, that doesn't necessarily mean you'll be bad at actual math either. And if you're bad at actual math, you're almost definitely going to suck at writing good software I'm afraid.
You are all missing the point. Who cares if it is not necessary? It will enrich you as will a wide variety of other things that can enhance a skill set. Ok?
The "math isn't needed for software dev" sentiment is really anti-intellectual. How can you ever have a hope of improving the software stack if you refuse to understand some of the fundamental ideas that inspired/powered it?
I've said it before: the job of college is to give you a solid understanding of fundamental concepts that you can apply to various situations, which [should] confer entry-level employment in various domains. College is not the place to go to learn yesterday's cool framework. Anybody can do that.
> College is not the place to go to learn yesterday's cool framework. Anybody can do that.
Slightly pedantic : you can do that anywhere. Just about anybody (who can teach themselves a development framework) can probably handle going to college as well.
I agree that college & Uni is a good place to focus on core fundamentals, and less on instant gratification or application.
It seems the definition of math, as defined by programmers, is a moving target. I cannot imagine programming even the most basic of systems without basic algebra and arithmetic, but since everyone knows how to do that, it isn't considered math. Math is what is always beyond what you currently understand.
I used pythagorean theorem, and cos/sin for my project to calculate speed and trajectory of UI speed. Happiest day of my life :) I think we (I) tend to find out-of the-box solution too often, sometime if you sit down, and use some math - you get some pretty elegant solution.
There are much more clear-cut examples of math in programming than this.
3D graphics requires matrices, and more. You'll find blog posts all over the Net of game programmers teaching themselves quaternions. You don't have to be writing a physics engine to need them, just using one. Even 2D graphics often requires pretty fancy high school math, like testing whether a point is in a polygon.
Proofs. Especially when defining new data types, you often want to prove that certain properties hold in a pretty rigorous manner. If you've never had to prove anything before, even at high school geometry level, it seems unlikely you'd sit down and do this. Or maybe that's completely wrong, and proving things about code is just a programming skill like debugging. It seems worth mentioning, however, because proofs come from the domain of mathematics and require a huge amount of creativity sometimes.
Easing functions for animation; being able to reason about binary and modular arithmetic; having enough foundational knowledge to say sensible things about compression and cryptography. If you do anything in robotics, control systems, or simulation -- differential equations.
If you're not doing anything with numbers, graphics, or data structures, you might be safe.
> all over the Net of game programmers teaching themselves quaternions
That's what I did too, but I didn't think of it as math. It seemed like a cool trick for working with arrays of floats — not math.
"Math" I knew from school was always boring and useless. I was told to memorize formulas that did some abstract operations on on other things I had to memorize — nobody told me I could be rotating spaceships in 3D!
You can do software development without math, but you can also do aerospace engineering without (advanced) math. Doesn't take much math to draw an airplane part in SolidEdge. But is it a good idea?
I've never been "good at math" (at least not in the Math Olympiad sense of "good at.") I really dislike math classes. But every class I've taken has given me new insights into programming. And I didn't even work in one of those obviously math-y areas like 3D. But so much of programming can be described by graphs, state machines, analyzed statistically or with proof methods, etc. You don't even realize it until you have the mathematical language to describe it.
They say that when all you have is a hammer, everything looks like a nail and with my narrow math education, I definitely feel that way (wait can we model this as a DAG?) But what about someone who doesn't even have a hammer?
It's certainly possible to do a kind of software development without much math, but having a strong basis in math definitely gives you tools to solve hard problems better. Even fairly trivial apps often need to solve problems (like recommending content, auto-generating playlists, etc.) that are much easier if you're familiar with fairly advanced math topics (like k-means clustering and Markov chains in those examples).
To disprove that math isn't useful for programming, I don't think anyone has to look further than the source code for Doom [1]. Math tricks were integral to making that game even work back then.
I don't think this particular bit was in Doom, but there was the fast inverse square root trick[1] that is only a couple lines of code, yet has a very lengthy explanation that requires both knowledge of math and floating point representation.
I think this may also a good example of why they say programmers don't need math. Very few people have the opportunity to even be in a position of inventing new algorithms like this. They are just going to read the relevant academic papers or use a library that implements it for them to make use of something like this in their own code. Even if you fully understand why the algorithm works, there is still a certain impostor syndrome at play for not being the one to invent it, leading people to believe they do not know math.
The same way you can write an if statement without understanding of math. i.e. You can't, but we don't label it math, because it is not the invention of new mathematical concepts. Only people sitting in ivory towers doing things with math that the world has never seen before are considered to know math in the eyes of most programmers, it seems.
Not only that, but that bit of Q3 code was at one point in time a mystery to even John Carmack. Which is why it has the "what the fuck?" comment next to the magic number. Eventually they did track down the guy that authored that bit of code. Not only did the guy that wrote that have a good understanding of the math behind it, but he also understood the low-level mechanics of floating point. Which is something your average math major wouldn't know much about. Even most software engineers don't know floating point, sad as that may be.
But Doom and early Quake are bad examples of why math is needed. Those were ground-breaking games. Their math has been encapsulated and turned into libraries and things like DirectX and OpenGL. Today, you generally just take a physics engine and 3d engine off the shelf and tweak it a little here and there.
I started a Math degree after 16 years of programming without any Math beyond high school (the highest being high school calculus). Most of my work as a software developer didn't require any "higher" Maths.
Once I began studying math, including Modern Algebra, Analysis, Graph Theory, Category Theory, etc., I realized I understood many topics on an informal level, in a non-rigorous sort of way, through programming. I had a good sense of major algorithms and data structures as well as their running times. Once I did have more math under my belt, things did become easier, and I started to see connections and commonality between problems across different domains, i.e. more than one way to skin a cat.
Part of the reason I began studying math, is that I felt it was my limiting factor. The range of problems I could tackle as a programmer was limited by math. It turns out this was partly true.
The biggest misconception is that in Math there is one "correct" answer. This is almost never the case. Some of the most interesting solutions in Computer Science come directly from Math topics that were once considered "abstract". Likewise, some of the most interesting problems are solved through approximation algorithms of seemingly intractable problems, often requiring a bit of "hacking" and real world experience beyond what you'd get from a formal education in Math or Computer Science.
I think every developer should be an engineer. Engineers should be able to take any problem and with time break it into smaller and more manageable problems. I think math is important for developing that kind of toolbox, but it is not always necessary.
Math is not necessary, but not knowing enough of it puts a hard ceiling on your skills as a software writer.
I once had to write software that had to determine if two ellipses projected onto the surface of a common ellipsoid intersected in any points. That was a real bitch. In order to get acceptable performance, I had to break it down into a six-step approximation that could calculate the obvious trues and falses very quickly and still calculate the edge cases accurately. You are not doing something like that without knowledge of math.
So no, you're not going to need it, but without it, you are almost guaranteed to be less capable and competent. It's like saying that a carpenter doesn't absolutely need to have a framing hammer when nail guns are available--but if you want to be a master carpenter, you still need to know how to use your hammers.
Math is totally unnecessary for everyday software development.
It is necessary for interesting software development though. Someone has to build the core that all the other applications rely on, and these engineers actually need to know all that nerd stuff.
>Math is totally unnecessary for everyday software development.
You are writing the simplest possible CRUD app for storing / retrieving some client records. You have a database of these records on the back-end, and users can add/edit/remove these records.
Now, your boss asks you to add a feature of bulk insertion of new client records from some other legacy data source, with proper de-duplication. There are no unique ids across the legacy and new data stores.
I hope this qualifies as "everyday software development". Is math totally unnecessary for solving this problem?
but you see, my point is that the actual hard problem of executing a SQL query has been solved by those who designed the DBMS. our task boils down to writing SQL, which is way easier than designing the machinery that implements relational algebra.
EDIT: not to mention that you don't even have to understand relational algebra to write SQL. There are HORDES of programmers who don't know what it is yet they write SQL.
Relational Algebra is about executing the query. Relational Calculus is about formulating the query in the first place. Unless you copy-paste all your SQL code, you wind up using Relational Calculus. I would agree that most developers don't have a formal understanding of it (I sure don't) or even an awareness of it. They may not think of it as doing math. They may be thinking "how do I use a select with a join to get this particular set of data". But it's still math.
Yeah, I know from where come the relational databases. Still, claim that using SQL is using math is like say using a car is using math. Like using python is using assembler.. and at the same time is not.
This is kinda zend: If a developer don't think about math....
Nope, there's plenty of math and stats involved in solving this problem correctly.
The amount of math you would apply here depends on your familiarity with the problem domain (this is where CS education comes into play), and your willingness and ability to work with higher level math and stats (this is where math proves necessary even in mundane software engineering tasks). For the record, even basic relational algebra can be seen as part of applied math, but the rabbit hole goes way deeper.
The best solutions for de-duplication of records without direct clues like unique IDs involve pretty cool applications of probability theory and machine learning, you'd find things like the Expectation-Maximization algorithm as prerequisites for understanding the current research. The foundational solution in this space is Fellegi-Sunter record linkage [1]. More advanced solutions include things like hierarchical Bayesian models [2]. If you dig deeper, especially if you are dealing with large datasets and basic techniques turn out to be too slow, you'd look into locality sensitive hashing and approximate nearest neighbors, which is a very mathematical subject, see for example [3]. In other words, math is encountered in even the most mundane software engineering problems, and you have to know where to look and what to look for.
I do this sort of task routinely. Can you point to a specific dataset where the regular DBAs skills falls apart? Because just see a lot of formulas without the context is part of the problem with math education (ie: show the solution and the claims it solve a contrived problem.. but where is the actual problem?)
The actual problem I described above (bulk de-duplication of records without any direct clues, such as unique ids, to decide whether two records are duplicates) falls under this category.
The first paper I provided is a survey of commonly used methods in this space, it's the exact opposite of a lot of formulas without the context.
Given math is not going to taught any better than how it has been all these years, I don't see why some of today's and tomorrow's software stacks cannot be created/developed/maintained by say, liberal arts students and professionals.
Software developers don't need to know any advanced math the same way electricians don't need to know quantum mechanics, and plumbers don't need to know fluid dynamics.
Every now and then there's a discussion on HN about usefulness of math in software engineering / data science / economics / or another practical field. Some people claim it's not useful or relevant, and produce some use cases where elementary math is sufficient to solve the problem at hand.
In reality, math is ubiquitous in computing, at every level from hardware design to algorithms and data structures to coding and compression to UI/UX design to graphics to databases to every other field you can think of. People who are not well versed in more advanced math tend to apply simpler, more accessible techniques, and produce sub-optimal results. Which is why we have layers upon layers of broken, barely working, crappy software everywhere we look.
Mathematics are wide and diverse, with several branches. Arithmetic, algebra and calculus are not the whole of mathematics. Not even including statistics.
While some kinds of mathematics are not much related to modern development, like calculus, most development includes some kind of mathematics, even if it is too subtle or obvious to be classified as mathematics.
With a minimal including point of view there are discrete mathematics, as described in the Khuth book (the book is called Concrete Mathematics). Programming is full of discrete mathematics.
In the world of videogames, GPU programming is an application of linear algebra. Shaders are understood in terms of linear algebra.
A more including point of view dictates that logic is another branch of mathematics, and no one can't develop any software without logic.
Khan Academy is great, but only covers through high school / engineering university math, last I checked. Having a good grasp of that is helpful, but if you want to learn real math you'll need to branch out. It depends a lot on what you want to get out of it.
If you want to get actually well-versed in mathematics (say, undergrad math major level), you'll need real and complex analysis, linear and abstract algebra, naive set theory and formal logic, and it couldn't hurt to get some topology and geometry in there as well.
On the other hand if you just want a particular subject (say graph theory), the prereq list will be much shorter. Or if you just want a general competency, just learning naive set theory and formal logic will get you to the point of at least being able to read the notation used.
So again, really depends on what you want out of it. I'm happy to provide specific advice re books etc if you do end up deciding to start studying.
edit for clarity: If what you want is just HS math competency (trig, HS algebra, calculus) then Khan Academy is definitely the way to go, in my opinion.
82 comments
[ 0.27 ms ] story [ 136 ms ] threadIf you're chugging out html or css maybe you have used math to calculate an offset?
If you're working in a database maybe you've thought about the intersection of a set of two related collections of data?
Math is used and pretty darn necessary for programming. You are probably just taking it for granted.
Your response is a little bit like an article saying "studying literature isn't necessary to be a good software engineer" and someone replying "reading and writing names and 1-sentence comments is still reading and writing".
However I do think math is beneficial, verging on required, but that is because studying math (beyond just arithmetic) exercises a sort of problem solving skill that I find very similar to what is often encountered in programming.
Thats grade school arithmetic nothing to do with what is usually considered math ( cliche about mathematicians struggling to calculate tip ).
Math is about creating abstractions and using those abstraction to build even bigger abstractions much like software development.
I'd say these are essential skills for me, but I can see why some might see them as unnecessary.
Sure, you use general math in almost all programming. Up to basic algebra and maybe a little more. I've done well enough for myself, but never received more than a basic junior high algebra class. Of course, I'm not writing cryptographic systems, graphic engines, or some sort of predictive engine, either.
Others, say John Carmack, need an obscene amount of match knowledge (among other things).
But it hasn't really impacted me as a developer. I think there's a separation between specific mathematical concepts and logic - I get the latter, but not the former.
For myself, I have experience programming with no math at all, with high school math, and with self-taught axiomatic math (I've been programming since I was quite young). I can say with certainty that every time I've learned more math, I've been able to improve as a programmer as a direct result. This even applies to relatively esoteric parts of mathematics, like category theory.
I don't think anyone's claiming that you can't work as a software developer without a heavy math background. We're just saying that you can go a hell of a lot further if you take the time to learn the math.
If I had better math skills I don't doubt that it would benefit me. As it is, I've got some design skills and some product knowledge, so my broader skills just skew a little differently.
That's a shame. Trigonometry was the most fun I had in a math class before college. I'd recommend you give it another try, ever - the trick is to relate everything back to the unit circle.
Of course, once you get into back-end systems, data analytics, and algorithms, math becomes much more useful, if not a necessity.
I've done quite a bit of front-end work and one of the teams I was on built a large graphing application. It required algebra for some of the plotting routines, but nothing too major.
It wasn't until I got into relational databases that I saw you really needed more applied mathematics to be a good database designer. Then you start to read about Dijkstra and Codd and suddenly realize your HTML, CSS, JS world seemed rather small by comparison.
What kind of problem from another field were you thinking of that doesn't devolve to a mathematical problem in the end?
(Sorry if I'm reading into an implication that isn't there)
To clarify, everything is based on Math at some level, just like everything is based on Physics at some level. My question is does it follow that solving difficult math problems make you better at solving difficult Foreign Policy problems, for instance? That is, if one student studies 10 hard math problems, and another studies 10 hard Foreign Policy problems, which will be better at solving the next Foreign Policy problem? The next Literary Analysis problem?
I don't think it follows that math being a required part of a solution for difficult problems makes it the best tool for the task of solving the problem at hand. But its common to argue that rigorous mathematical education will make you better at solving problems in general; I just wonder if there's any actual evidence to it, or if its all based on belief (however logical and well argued).
Something like Foreign Policy involves so much nuance and understanding of History, human and organizational behavior that I think attempting to take a purely analytical approach to solving those problems will fail.
You reminded me of something an English professor said to my class decades ago when one of us complained about the amount of Liberal Arts classes we were required to take. As best I can remember it was, "as engineers, your job will be to solve problems, but you need to understand that not all problems can be solved logically. There probably is no better way to learn that than by studying Literature."
Yah I don't get the "math is not necessary" argument either. Perhaps in some very narrow and limiting definitions of either "math" or "software development" this is true. Logic, functions, data structures, all have sturdy foundations in mathematics.
Maybe you can get started in software without good mathematics fundamentals, but you won't get far without them.
It is, of course, possible to agree with a conclusion while disagreeing with the reasoning behind it. I completely disagree with a couple of statements here. Again, this is probably because as a math major (and as a short-lived doctoral student in an engineering department that was heavy on proof based math theory around optimization and stochastic processes), I've experienced "math" very differently from most people, including engineering or science students who have done a substantial amount of math (say, the calculus sequence through differential equations).
Math (I'm talking about the US based university approach) changes dramatically once you get to "upper division" coursework. Real Analysis is very, very different from the differential equations course that is about one-fifth math majors and four fifths engineering or hard science majors. There's very little "applying an equation" going on. And the notion that there is "one answer" is remarkably incorrect (I suppose it's correct if you define "TRUE" as the one correct answer to fermat's last theorem, but there are often so many different correct ways to go about a proof).
I remember a story about Graham Nash (the Nash equilibrium guy - this is all from memory based on his biography, so I may have some of the details wrong). Nash proved a very difficult and elusive theorem early in his career. It was later discovered that a different mathematician had completed a proof for the same theorem a short time earlier (I think it was a few months). Nash was apparently very depressed by this. However, he shouldn't have been - the other proof was by contradiction, whereas Nash's proof was more direct and contained the structure for an algorithm, and would probably be more influential.
This isn't at all unusual in math. There are a huge number of different angles on a problem.
Part of the problem here is what is meant by "math"... it is a shame that someone could get as far as second year university math in the US and still see it as a field where you simplify things to the point where you can apply a formula to arrive at the one right answer. In Ross Hunter's defense, he didn't say that's all that math is, he said "People who are good at math are good at breaking problems down into parts, recognizing patterns, and applying known formulae to those parts to arrive at the one right answer."
But you know, people who are good at math do far, far more than that. I know, because oh my god math got harder after the standard "calc through diff eq" sequence.
John Forbes Nash, Jr. is the math guy.
Graham Nash was the lead singer of the Hollies and a member of Crosby, Stills, Nash and Young.
Both of these guys' work is worth checking out.
Agree with you about Graham Nash, also worth checking out ;)
I think it's reasonable to assume, given what he stated, that Ross does in fact conceive of math that way. It blows my mind that one can get through a discrete math class and still think of math as basically computational in nature, since as far as I know most curricula treat the course as an opportunity to introduce the sort of concepts that typically figure into an introduction-to-higher-mathematics-type course, such as proof techniques, basic number theory, and so on.
this
Math education is mainly suffering from a PR problem right now. Most people associate the word 'math' with memorization of facts and rote learning of arithmetic steps. These are boring and unpleasant activities: if this is what math is like, then I don't like math either!
It's end time we re-associated math with abstract thinking and modelling of the real world. It will make it much harder to be a math hater... Anyone interested in rekindling their relationship with math and physics can check out my book http://minireference.com/
> Math (I'm talking about the US based university approach) changes dramatically once you get to "upper division" coursework.
It's not just a dramatic change; for most, it's a cliff thrown in the middle of the learning curve. There are many reasons for it: some high schools passing students along when they shouldn't, some professors doing the same thing when students get to college, and the ever-so-fetishized focus on applications over concepts. In short, it's a cultural problem. And at this point, I have no idea how--or if--it can be resolved.
When I transferred to a new university I was placed in their first year calculus program over my own protests. I had already done AP Calculus in high school, and completed the first year calculus course at my previous college, which was admittedly of much lower quality than the university I was transferring to. I thought this new one would be a complete waste of my time.
The first thing we covered in this new course were limits. I rolled my eyes; everyone knows how to find a limit. Was this really the kind of thing we were going to cover in this class? Then the professor said these words I had never heard in relation to limits before, "epsilon" and "delta." And here my troubles began.
That turned out to be one of the hardest courses I've ever taken, I had to relearn almost everything I thought I knew about math.
In Calc I, I kept my eyes out for two groups of students: those who did really poorly on the first exam, and those who did really well. The first I watched for obvious reasons, but some of the folks in the latter group--especially those who took some calculus in high school--would start to think "Oh, I know all of this now! Cool. Easy A." and then coast. And they'd be mincemeat somewhere in between implicit differentiation and related rates.
None of it really made any sense to me, and in retrospect, the only reason I even managed a passing grade in the course was because I'd been taking a statistics course at the same time that covered many overlapping topics (sets and relations, discrete probability, etc) in a "use these things to calculate this other thing" way that actually meshed with my previous education.
Proofs were the real killer out of all of it. I still today have barely any idea how to manage a formal proof or what elements are involved in one, because at the time trying to figure out what the hell was going on with this notation and formatting and abbreviations everywhere that I'd never seen before and trying to make any sense of the weird self-referencing logic of it was unpleasant enough that I just fumbled through the bare minimum to get a passing grade whenever they were involved.
Yes! Or from my perspective. "The love of methodical problem solving that you can discover in software development can help you overcome your math anxiety"
I've said it before: the job of college is to give you a solid understanding of fundamental concepts that you can apply to various situations, which [should] confer entry-level employment in various domains. College is not the place to go to learn yesterday's cool framework. Anybody can do that.
Slightly pedantic : you can do that anywhere. Just about anybody (who can teach themselves a development framework) can probably handle going to college as well.
I agree that college & Uni is a good place to focus on core fundamentals, and less on instant gratification or application.
3D graphics requires matrices, and more. You'll find blog posts all over the Net of game programmers teaching themselves quaternions. You don't have to be writing a physics engine to need them, just using one. Even 2D graphics often requires pretty fancy high school math, like testing whether a point is in a polygon.
Proofs. Especially when defining new data types, you often want to prove that certain properties hold in a pretty rigorous manner. If you've never had to prove anything before, even at high school geometry level, it seems unlikely you'd sit down and do this. Or maybe that's completely wrong, and proving things about code is just a programming skill like debugging. It seems worth mentioning, however, because proofs come from the domain of mathematics and require a huge amount of creativity sometimes.
Easing functions for animation; being able to reason about binary and modular arithmetic; having enough foundational knowledge to say sensible things about compression and cryptography. If you do anything in robotics, control systems, or simulation -- differential equations.
If you're not doing anything with numbers, graphics, or data structures, you might be safe.
That's what I did too, but I didn't think of it as math. It seemed like a cool trick for working with arrays of floats — not math.
"Math" I knew from school was always boring and useless. I was told to memorize formulas that did some abstract operations on on other things I had to memorize — nobody told me I could be rotating spaceships in 3D!
I've never been "good at math" (at least not in the Math Olympiad sense of "good at.") I really dislike math classes. But every class I've taken has given me new insights into programming. And I didn't even work in one of those obviously math-y areas like 3D. But so much of programming can be described by graphs, state machines, analyzed statistically or with proof methods, etc. You don't even realize it until you have the mathematical language to describe it.
They say that when all you have is a hammer, everything looks like a nail and with my narrow math education, I definitely feel that way (wait can we model this as a DAG?) But what about someone who doesn't even have a hammer?
:-)
[1]: https://github.com/id-Software/DOOM
[1] http://en.wikipedia.org/wiki/Fast_inverse_square_root
And how are you planning on doing that if you have no understanding of Maths?
But Doom and early Quake are bad examples of why math is needed. Those were ground-breaking games. Their math has been encapsulated and turned into libraries and things like DirectX and OpenGL. Today, you generally just take a physics engine and 3d engine off the shelf and tweak it a little here and there.
Once I began studying math, including Modern Algebra, Analysis, Graph Theory, Category Theory, etc., I realized I understood many topics on an informal level, in a non-rigorous sort of way, through programming. I had a good sense of major algorithms and data structures as well as their running times. Once I did have more math under my belt, things did become easier, and I started to see connections and commonality between problems across different domains, i.e. more than one way to skin a cat.
Part of the reason I began studying math, is that I felt it was my limiting factor. The range of problems I could tackle as a programmer was limited by math. It turns out this was partly true.
The biggest misconception is that in Math there is one "correct" answer. This is almost never the case. Some of the most interesting solutions in Computer Science come directly from Math topics that were once considered "abstract". Likewise, some of the most interesting problems are solved through approximation algorithms of seemingly intractable problems, often requiring a bit of "hacking" and real world experience beyond what you'd get from a formal education in Math or Computer Science.
I once had to write software that had to determine if two ellipses projected onto the surface of a common ellipsoid intersected in any points. That was a real bitch. In order to get acceptable performance, I had to break it down into a six-step approximation that could calculate the obvious trues and falses very quickly and still calculate the edge cases accurately. You are not doing something like that without knowledge of math.
So no, you're not going to need it, but without it, you are almost guaranteed to be less capable and competent. It's like saying that a carpenter doesn't absolutely need to have a framing hammer when nail guns are available--but if you want to be a master carpenter, you still need to know how to use your hammers.
It is necessary for interesting software development though. Someone has to build the core that all the other applications rely on, and these engineers actually need to know all that nerd stuff.
You are writing the simplest possible CRUD app for storing / retrieving some client records. You have a database of these records on the back-end, and users can add/edit/remove these records.
Now, your boss asks you to add a feature of bulk insertion of new client records from some other legacy data source, with proper de-duplication. There are no unique ids across the legacy and new data stores.
I hope this qualifies as "everyday software development". Is math totally unnecessary for solving this problem?
If a person know database/sql, then "math" is not necessary here. Or what exactly are you talking about?
SQL? Like in relational databases? Like in relational algebra?
I think this demonstrates the point someone made upthread that people don't consider a lot of math to be math.
EDIT: not to mention that you don't even have to understand relational algebra to write SQL. There are HORDES of programmers who don't know what it is yet they write SQL.
This is kinda zend: If a developer don't think about math....
The amount of math you would apply here depends on your familiarity with the problem domain (this is where CS education comes into play), and your willingness and ability to work with higher level math and stats (this is where math proves necessary even in mundane software engineering tasks). For the record, even basic relational algebra can be seen as part of applied math, but the rabbit hole goes way deeper.
The best solutions for de-duplication of records without direct clues like unique IDs involve pretty cool applications of probability theory and machine learning, you'd find things like the Expectation-Maximization algorithm as prerequisites for understanding the current research. The foundational solution in this space is Fellegi-Sunter record linkage [1]. More advanced solutions include things like hierarchical Bayesian models [2]. If you dig deeper, especially if you are dealing with large datasets and basic techniques turn out to be too slow, you'd look into locality sensitive hashing and approximate nearest neighbors, which is a very mathematical subject, see for example [3]. In other words, math is encountered in even the most mundane software engineering problems, and you have to know where to look and what to look for.
[1] http://www.purdue.edu/discoverypark/vaccine/assets/pdfs/publ...
[2] http://arxiv.org/pdf/1207.4180.pdf
[3] http://www.cs.princeton.edu/courses/archive/spring05/cos598E...
The first paper I provided is a survey of commonly used methods in this space, it's the exact opposite of a lot of formulas without the context.
In reality, math is ubiquitous in computing, at every level from hardware design to algorithms and data structures to coding and compression to UI/UX design to graphics to databases to every other field you can think of. People who are not well versed in more advanced math tend to apply simpler, more accessible techniques, and produce sub-optimal results. Which is why we have layers upon layers of broken, barely working, crappy software everywhere we look.
Mathematics are wide and diverse, with several branches. Arithmetic, algebra and calculus are not the whole of mathematics. Not even including statistics.
While some kinds of mathematics are not much related to modern development, like calculus, most development includes some kind of mathematics, even if it is too subtle or obvious to be classified as mathematics.
With a minimal including point of view there are discrete mathematics, as described in the Khuth book (the book is called Concrete Mathematics). Programming is full of discrete mathematics.
In the world of videogames, GPU programming is an application of linear algebra. Shaders are understood in terms of linear algebra.
A more including point of view dictates that logic is another branch of mathematics, and no one can't develop any software without logic.
If you want to get actually well-versed in mathematics (say, undergrad math major level), you'll need real and complex analysis, linear and abstract algebra, naive set theory and formal logic, and it couldn't hurt to get some topology and geometry in there as well.
On the other hand if you just want a particular subject (say graph theory), the prereq list will be much shorter. Or if you just want a general competency, just learning naive set theory and formal logic will get you to the point of at least being able to read the notation used.
So again, really depends on what you want out of it. I'm happy to provide specific advice re books etc if you do end up deciding to start studying.
edit for clarity: If what you want is just HS math competency (trig, HS algebra, calculus) then Khan Academy is definitely the way to go, in my opinion.