Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

An anonymous reader writes "Currently, the nature of most programming work is such that you don't really need math skills to get by or even to do well; after all, linear algebra is no help when building database-driven websites. However, Skorks contends that if you want to do truly interesting work in the software development field, math skills are essential, and furthermore will become increasingly important as we are forced to work with ever larger data sets (making math-intensive algorithm analysis skills a priority)."

I did the highest level of maths in my Australian higher school certificate, but didn't really do much in the way of physics at school or Uni. Even with what I am programming in my spare time (a space based build/conquer/explore type game) I am finding that I have to resort to buying coffee for friends that DID do physics and higher levels of maths at Uni to get some of the formulas I need to work out the things here. Also, I work with numbers ALL day pretty much at work (Senior Performance Analyst for a multinational) - so I ain't exactly derpa derpa derpa when it comes to numbers.

Can I google and find the formulas? Sure, yeah, but do I have the level of understanding with all of Kelper's Laws and bits to change them to what I want for my game? Nope.

Anyone who says that maths isn't needed for a programmer is utterly kidding themselves - or working at the low end of the food chain.

I'd go further than that - most chunks of maths are things that are absolutely essential for some area of programming. You may not need to know everything all of the time, but for any particular task you will need to know some of this (non-exhaustive) list :

Statistics - useful just about everywhere, but in particular if you have to do any kind of data analysis in your work. Knowing particular distributions and how to compute the properties of them is essential.

Probability - if you use any kind of randomness in your work this is essential and in quite a few places where you don't deliberately use randomness but you are using non-determinism to model lack of knowledge i.e packing and filling of sparse data-structures.

Algebra - the daddy. Knowing a simple formal language that lets you rearrange expressions is an essential first step towards understanding a programming language. The more you learn the more it will help. If you head down to the Category Theory end of the pool then Monads and Arrows come in useful if you swim away from imperative languages and find something more interesting.

Logic - the other foundation. Learning to apply logic is relevant in any area of programming as it is an elementary part of programming. A deeper understanding of propositional and predicate logics is essential to do any work in compilers and will aid your understanding of control and data-flow in any language that you work in.

Linear Algebra - anything that touches the "real world" requires a bit of LA, as the parent mentioned physics, 3D graphics and I would add Vision to that list.

Set Theory - these are your basic building blocks, use them well. Whether it is building the right data-structure or using a database this is the foundation that you need to understand.

Graph Theory - some people never need anything more complex than a relational database, but some people only care about the relations. If you want to model any large network (the internet, or social interactions, economics), or perhaps programs within a compiler, or just the relationships between discrete objects then you will either learn some Graph Theory first, or rediscover it yourself the hard way.

Combinatorics - counting is fun! Counting (and enumerating in the programmer's sense) complex objects is basic problem that crops up in almost every area. For people without some grounding in combinatorics it is the kind of question that will get kicked up to the "office guru".

Now, if only maths graduates could program their way out of a wet cardboard box, then we could truly start designing giant flame breathing killer robots.

Programming as a skill in itself is totally separate from most of those .

But to be a good programmer you don't just have to be able to write good code- you have to be able to write good code which does useful things and unless you have a decent understanding of a few of the above you're going to be missing a number of very useful and powerful tools.

I dare to disagree. Programming is basically putting algorithms into a form a computer can understand. Nothing more. And where do these algos come from?

It baffles me to no end every time I see "programmers" apply who consider math as some sort of secondary skill. It's not. It is the primary skill for a good programmer. I do not need someone who can "translate" my algorithm into code. I need someone who can take my problem and develop an algo for it. Coding it is the most trivial part of the solution.

I dare to disagree. Programming is basically putting algorithms into a form a computer can understand. Nothing more. And where do these algos come from?

It baffles me to no end every time I see "programmers" apply who consider math as some sort of secondary skill. It's not. It is the primary skill for a good programmer.

.

Absolutely. And an old dog like me can even provide a classic example: older OS's like DOS and CPM had to cram a lot of functionality into a relatively small amount of memory. They also had to perform decently on small, slow (by today's standards) processors. The approach that they used was the vector table.

Simply put, the functions were numbered in order: get OS version was typically the first (function 0), and successive numbers were for all of the other important functions: open file, write file, get system time, and so on.

Now: can you imagine how inefficient that would be if the original programmer had used a "switch" statement (or the assembly equivalent, with a bunch of "compare and jumps")? Instead, the function number was left shifted (equivalent to multiplying by a factor of two), then used to find an index in a vector table that contained the addresses of all the functions. Neat, compact and lightning-fast.

This technique is still used today in small embedded processors that suffer from similar low speed and limited memory problems. I used it myself on a small controller in a contract job back in the 1990's. It allowed me to cram everything (read keyboard, activate relays, check temperatures, and more... even including a quick and dirty "config" option... in a PIC micro with 2048 bytes of memory.:)

I have never met a really good, really world-changing programmer who wasn't also good at math. Not necessarily with high-end math, but just good at the fundamentals of algebra, and with the ability to "think" in numerical calculations and offsets.

Those are all things I did as a CS undergrad, but there was also huge importance put on proofs. Everyone is talking about writing good code doing useful things quickly, but (and this is especially important in real time applications, such as autopilot on planes), if you can't prove that the code you have written is going to do what you want 100% of the time or its not 100% accurate, then really what is its worth.
Maths is vital (ok not if your connecting up a website, although it does have applications in

Proofs are somewhat overrated: you CAN prove that code matches a formal specification, but you can't prove that the specification is correct.“Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
You're right about the maths being important though.

Programming is programming; it's a discipline independent of anything else. It involves logic, but not math. (Unless you include logic in math, in which case the answer to this question is "duh" and there's no point in having this discussion.)

If you're writing a program in a domain where math is important, for example calculating spaceship orbits or rendering 3D graphics, then math is important. This is also kind of a duh.

Totally disagree. It has been found that the universe reflects math, and much discovery in the field of physics is driven by a previous understanding of mathematical principles.

Furthermore, there are extremely numerous cases where math skills come in handy for totally unexpected applications. For example, I learned about statistical concepts (standard deviation, interquartile ranges, median, mode, mean, etc) long before I had any application that actually meant anything in my life. In the 11 years since high school, I've lost count of the number of times that that has been useful. From analyzing web statistics to finding patterns in sales in my shop, I've used these skills to great effect. This is even more the case with trigonometry.

Math does not have to be limited by immediate application of the principles being taught, and doing so results in an unnecessarily constrained syllabus that denies students skills that they may find useful later in life. Mathematics' usefulness just appears in front of you as you go through life encountering problems, assuming you have the skills.

Math does not have to be limited by immediate application of the principles being taught, and doing so results in an unnecessarily constrained syllabus that denies students skills that they may find useful later in life.

I agree. I wish it was easier or perhaps more common to teach the ability to apply more advanced mathematics to a situation when possible. I remember going through school you always heard the line, "We're never going to use this anyway," when referring to math anywhere above algebra, and I have to say that I generally agreed with it. There have been some advanced mathematical skills that I've used since leaving school, but they've all been applied inside of IT or programming, so perhaps I'm a bad example.

My personal largest problem, though, has to do with literacy. Though I'm quite skilled with language, excessive comma usage notwithstanding, I find that when trying to read about advanced math or physics principles on Wikipedia for example, I'll see a theorem written using symbols and functions that I know were covered in the math classes I had in high school but I can't look at those same symbols and functions and turn them into words that accurately explain or describe the principle I'm reading. Perhaps I'm alone in that situation, but attempting to read advanced theorems and math does give me insight into what text must look like to illiterate people who still know their ABC's.

>My personal largest problem, though, has to do with literacy. Though I'm quite skilled with language, excessive comma usage>notwithstanding, I find that when trying to read about advanced math or physics principles on Wikipedia for example, I'll see>a theorem written using symbols and functions that I know were covered in the math classes I had in high school but I can't>look at those same symbols and functions and turn them into words that accurately explain or describe the principle I'm reading.>Perhaps I'm alone in that situation, but attempting to read advanced theorems and math does give me insight into what text must>look like to illiterate people who still know their ABC's.

I share your exact sentiment.

I have been a definite non-traditional student. I started school in 1988 at Georgia Tech, and failed out after 2 years. Some 17 years later, I finished my BS in Computer Science.

I have taken and retaken math classes many times. When I was at Georgia Tech I got a C in Calc I, and then in Calc II I got W, F, D, F, and finally passed with a B. Then I moved to another state and had to take Calc II yet again. A few years ago I started working on my Mechanical Engineering degree, which requires Calculus III, so I took Calc I and II again to brush up. I got a B in Calc I and a B in Calc II and got a D taking Calc III. I am currently re-taking Calc III.

My problem is, I believe, that I have strung out my mathematical education over so long a period of time that I am not FLUENT IN THE LANGUAGE OF MATHEMATICS. It is, exactly as you state, a LITERACY PROBLEM. I firmly believe, as you seem to, that MATHEMATICS IS A LANGUAGE. Moreover, I believe, as you seem to also, that people who are fluent in mathematics actually "SEE" mathematical equations.

For example. I believe many people when they look at x^2 + y^2 = r^2 instantly recognize the equation of a circle. Now I have finally gained that understanding, BY ROTE, of that fact also. But I believe that people who are mathematically literate see more than just the pattern recognition that that equation means circle. I think they see equations and actually see WHAT IS GOING ON. I never do. I have to sit down and plug in values of X and Y and see what comes out. It's very tedious.

I think your last sentence was exactly dead-on. I liken the problem to handing an encyclopedia to a 5-year-old and asking them to read a passage. They will be focusing so hard on each word that they will not know what they have read at the end of a sentence. That is exactly how I feel trying to do Calculus. I am focusing so hard on the basic mathematics that I find it very difficult to put it all together to see the big picture.

It is very much a literacy problem, and I find it confounding. The only thing for it, I'm afraid, is to do more and more and more maths until one gains the familiarity one has just as one does with reading. The problem is time. I just don't have the time, with a full-time job and a family, to do it.

I haven't been able to help but think, over the years of taking higher-level math classes, that there must be a better way to learn this stuff. The science of Calculus is some 400 years old, some parts much older. Yet the way it is taught has not changed hardly at all. Now maybe there is no better way to learn it than doing it over and over until knowledge turns to understanding, but what keeps coming to me is that there must be a better way to VISUALIZE the abstract into something more concrete.

Example. The other day in Calc III we were talking about minimums and maximums, and how they might occur on the surface or along the surfaces boundary. So I said out loud, "So, the surface can either be a volcano or a potato chip but either way there is a high or low spot somewhere on it." And half the class said aloud, "Aaaaaahhh!" - they got it because they were able to VISUALIZE the abstract concept as something concrete.

I have no doubt you are correct sir. By my elementary and secondary test scores, I should be a mathematician. I was doing college algebra in the sixth grade. However, I found in 11th and 12th grade (pre-calc and calc) that I just plain didn't understand the math anymore. I could do the equations, and I knew when to apply them, but I no longer had any understanding of why I was doing what I was doing. I never developed that relationship with math that the truly gifted people I knew developed. As a result, I

Einstein did not find out what he found out by calculatign[sic], first he understood the physics behind it after eh calculated for us the formula E=MC^2

Man, you have no idea what you're talking about. Einstein was having severe problems with General Relativity until his mathematician friend, Mercel Grossman, looked at what he was doing and pointed out, "hey, you need to describe this using these things called tensors.": look here [suite101.com]

Before that, Hermann Minkowski, a mathematician, had looked at Einstein's Special Relativity and thought, "hey...if we describe these things in four dimensions, these equations become really elegant." Yes, Minkowski space was d

No, absolutely not... Physics uses Math: Physics without Math is unthinkable. Math without Physics is absolutely possible. There was pretty much maths before physics. The old Greeks were more Mathematicians than Physicists.

There is little need for calculatign stuff you don't know what it's your calculating.

I present to you Complex Numbers [wikipedia.org]. For all intents and purposes we don't know what we're calculating *but* they are used in all kinds of engineering to find actual useful results. (Scroll down to the Applications part). Understand that Complex Numbers were first, then came the applications.

I am by no means a Mathematician and I wasn't a big fan of it in school, but loved physics and excelled in it. In a way, I was like you, but I understand that Maths is used in Physics but not limited to Physics.

Maths is great for some coding problems, I'm not saying it isn't, but you rarely bump into a commercial coding problem that requires any degree of serious maths. I've been commercial coding for nearly 20 years, and I've hit a maths problem 3 times (and the last two were solved by a half-day of Googling).

But you will bump into a people problem in commercial coding. Every. Single. Day. Knowing how to cope with those is massively more important (and Google can't help you with them).

But the article wasn't really talking about this. The article was talking about becoming a Great Programmer.To become a Great Programmer, don't spend your days coding CRUD websites. You're never going to build/discover something amazing while doing commercial coding.

Math KNOWLEDGE may be debatable, but Math skills are essential.If you don't have the ability to break up and solve mathmatical formulas, how do you expect to be able to solve complex programming tasks?

Plus linear algrebra is awesome. And everytime I do anything even remotely 2d or 3d related, I always wish I had paid more attention in Geometry.

But more than anything, its good to know that there's an equation for that. Even if you don't remember what it is, or how it works, having the simple knowledge that it exists to look up is more than worth the time of taking the class.

Another person who is ill defining mathematical thinking. I consider mathematical thinking not only Linear Algebra, Infi et al, but everything that requires exact abstract thinking and has the properties of consistency and a formal and defined "language" to represent ideas.

For that matter, I think that mathematical thinking should be defined more broadly, such as conceiving design ideas and representing them with, say, UML or DFDs as mathematical thinking as well.

Exactly. You need to understand maths to, for example, predict what a particular SQL query will do, or to perform any more than the most basic reasoning about how two parts of a program will interact. Maths is a lot broader than dealing with numbers and vectors.

People are saying two things here, and thinking that they're mutually-exclusive. Some point to areas of commercial programming beyond basic CRUD operations, saying that math would be a big help there. Others point out that for standard CRUD and gluing together pre-written software libraries, math skill doesn't much matter either way.

Hey, they're BOTH right. However, the trend is moving toward the latter type of programming job. Forget high-level math... I seldom use my COMPUTER SCIENCE skills on the job

I would hope that if you are in the computer programing world you understand that cranking out solutions to formulas is way more suited to computers than it is to humans.

If you want to solve a bunch of math problems then boot up maple, matlab, or any number of programs.

Doing a bunch of calculus or whatever is _not_ the reason that you want mathy people to be computer programmers. Analyzing and quantifying problems, applying appropriate algorithms, optimization, etc are all areas where someone who understands the math behind a problem can far outshine those who don't.

Absolutely. I do blender and if I didn't understand vector rotation and normals it would be virtually impossible to any good work. You can get the computer to do the heavy lifting, but you have to know what you are asking for. The advantage that exists now is that if anybody is weak on math skills, MIT and others have plenty of open course ware to cover the bases all the way to multi variable calculus.

...but it's not the kind of math you might be thinking about, like calculus, etc. Rather statistics, discrete math, combinatorics, etc. are becoming essential skills if you want to be better than average.

Not many people do work with data sets that size. However, some people only consider their work "interesting" when they are on the cutting edge of their field. It's one of those words for something subjective that people regularly take for objective. It also happens to be central to the orignal question. If the poster of the question has a different set of interests than the author of the cited article, then he could easily find that there is work interesting to him which doesn't require math more advanced

All of those except combinatorics were *required* for my Bachelor's degree in CS.

That's interesting, because I always considered combinatorics to be fundamental in my college program. I do find it very relevant when talking about software, because even having the ability to compare control-flow paths makes a difference. Code littered with poorly-organized conditionals makes my eyes melt, and it all boils down to counting.

Math is necessary for programmers but also for life. That wasn't the best thing in TFA though. The most insightful nugget in this piece was that we should think strategically about what we choose to learn. One the one hand, a programmer can chase the buzz...Rails, Struts, and the Twitter API and get jobs with the cool kids. Far better is to learn general tools that will be around a long time. This is why I like free software and gnu/*nix. The community has built a core set of tools(scripting/database/web) that stands to be around for 20-50 years or more. Just something to think about as you build your programmer/sysadmin toolset (assuming programming/sysadmin work isn't just a temporary thing for you).

No one's going to argue that you need to understand arithmetic, basic algebra, maybe even some geometry, statistics, and trig depending on what you're doing. That's true frankly not just for computer science and IT, but for any even semi-technical field. But integral calculus? Differential Equations? Nonsense. But yet most colleges require two to three years of calculus for CS majors. A lot of this is probably because CS is part of the Engineering department and it's easier to just make the core requi

For graphics you obviously need trigonometry. Lots of things we used to develop earlier is now available as free libraries. Much more important then advanced mathematics is, IMHO, having good estimation of how will certain solution or algorithm perform in various situations. This is developed in programmers head with time.

If you have to even ask that question, then you won't get a programming job that requires math skills. You'll be the bottom of the barrel in your programming group, and then a few of years later promoted as their manager because you can't do any of the technical stuff but are great friends with the boss, or you'll end up doing system support swapping out tape backups and fixing printer jams.

Asking if math-skills are necessary for a programmer is kind of like asking if people-skills are necessary in the field of law. Some lawyers find success by performing in the courtroom and for the camera, while others find success in their skills with research, interpretation and analysis.

But if I had to hazard a guess, I'd guess that the majority of programming jobs out there don't require very much mathematical heavy lifting. And often times if you do run into something that could be tricky, it's already been solved by someone else, complete with copy and paste source code.

TBH I don't know if some of the best software engineers I've met are any good at math. They're good at interpreting API documentation, good at structuring code to meet the strengths of the language they're using. Good at project planning, time estimation, and risk analysis. Good at understanding how computer and network systems work and -- often more importantly -- how they fail. They understand how users interact with software, and what users expect and want.

The truth is, software development has become as broad as life & human interest itself, and generalizations about the practice are becoming more and more meaningless.

Leslie Lamport's contributions should be more widely appreciated. He has the knack for reasoning very hard about apparently simple problems that aren't as simple as they first appear. This is a distinct mathematical talent from being able to solve tricky integrals. It's surprisingly hard to reason about computational processes in a completely convincing way. The effort does wonders for the correctness of my embedded code. Note that with the modular behaviour of integers, the normal rules of algebra don't always apply (this shows up most often dealing with pygmy integers).

Long ago when I was a beginning C programmer I managed to implement a simple binary tree in a wonky way. My comparison operator was deterministic, but didn't form a full order. The tree seemed to work fine. I could add elements and test for membership, it was all golden. Then I tried deleting an element. This worked. But I noticed something funny about the tree afterwards. Since my comparison operator was not a full order, the tree rebalance operation following a deletion could orphan some elements so that they wouldn't be found.

I showed this to a coworker who told me "What are you worried about? It mostly works doesn't it? Your tree insert and membership test passes doesn't it? We need to move onto another task." But I was stubborn and a voice inside me went "this can't be right". Element inserts and searches in that system were common (like #define in C) but deletions were fairly rare (like #undefine in C). That broken code could have been out in the field causing nightmares for a long time before we tracked the problem down. Half an hour of consternation later, I had figured out how I butchered the order operation in violation of the full order requirement. I had cases where A B && B C && C A. This is not good for a binary tree with deletion. The nasty part is that it limps along further than you expect.

In that same job I had an improperly initialized pointer that scanned through a memory data structure comparing on a string field on some odd field size such as 23 bytes. (Sue me for my youthful indiscretion if you've ever had to label diskettes by compiler phase). Strangely, the pointer scanned several hundred k of memory not part of the table, then properly aligned with the table it was supposed to find, and returned the correct field. It seemed to work under testing, but I noticed the performance was a bit odd in some cases. This lead me to investigate and I found the unitialized pointer. Once again, if this code had been released, it was a ticking time bomb the first time some random values in low memory simulated a match with the search key.

I learned a lot in that job about defensive programming. A couple of years later I came across one of Dijkstra's books and the spark jumped from his finger to mine. Bugs have been a rare event in my code ever since. Dijkstra taught me to think properly about all possible orders of statement execution where the program remains correct. The order you first write isn't necessarily the only one that works. The mental discipline is a lot like classifying all the components in your BBQ kit into formal symmetry groups before you begin assembly. It pisses me off immensely when I miss some obscure drill hole and conclude that two panels are entirely identical, only to discover much later they weren't (usually after I've pounded in those flimsy plastic wheels that resemble a hip joint with rickets).

Try next time *before* assembling the BBQ to formally write down the symmetry group for every little flim flam and see if you can still F up the first assembly. I bet you can't.

What it comes down to is that math is an attitude as much as a skill. I tell my GF from time to time that math is fundamentally the attitude that 100% of what you don't understand is smaller than a grain of rice. How many programs have I screwed up because of a big mathematical mistake? Can't think of any. Going way back, how many times have I screwed up

Programmers should cherish the mathematics and abstract thinking - it's the only part of our expertise that is guaranteed to remain useful until retirement, when all our favorite languages have become either obsolete or unrecognizable. (And visual interface design has been rendered obsolete by brain implants.:P )

The thesis in TFA is that developers are mostly busy building CRUD code and 'websites' and that if you don't want to get completely tired of it 5 years down the road, you need to do other things, possibly just for yourself (because at work you only are building CRUD/websites) and then come up with problems where math is King, and this is so that you will get more 'respect' like those great software guys like Dijkstra, Knuth etc.

Well, I'd say if you are only doing CRUD/websites now and that's it, you should

Similarly, people who are good at logical thinking tend to be good at math.

Relevance? To be a good programmer you need to be really really good at logical thinking - without it, you'd take way too long to "crack" a problem or devise a new algorithm or plan an inheritance hierarchy, etc. A strong background in math is therefore advantageous, but is not an absolute necessity.

You do need them for theoretical computer science, and in turn, you need theoretical computer science to invent something new that you could program. Most programmers don't do theoretical work themselves, and most theoretical computer scientists don't finish their software;-) It's a completely different type of job.

A coder with great math skills can write some really slick algorithms. However, more often than not, despite how well their algorithms are documented, if they're working with a team of developers they are usually pushed to dumb down their code so as to accommodate the skills of everybody else on the team ('team' more accurately meaning 'project manager') to make it more 'readable'.

Count the loop nesting, look up any well-studied algorithms, and don't be a dummy about computation/storage hidden behind layers of object-oriented obfuscation. It's easy.

Seldom does anybody need to determine things down to the last byte or CPU cycle. You can't do that anyway unless you use something like assembly. In the time you might spend improving your estimate, computers will get faster and your software project will get later.

Just doing rough estimates puts you way ahead of everybody else, allowing

most of programming inevitably consists of creating logic constructs in algorithms. if this happens it has to be that, but also if that happens with that and it also has to be this and that and so on. they constitute the backbone of programming. anyone lacking understanding of logic would have a hard time. the rest, can easily remedied - we have innumerable libraries, classes, frameworks performing many complex mathematical operations. its better to have very strong logic, and make up for the rest with this approach, and efficient. furthermore, you can receive interdisciplinary help, hell, even help from internet in that regard, if you come up with some problem that has to be solved with a math equation. a mathematician can also help you with that. but the rest, the logic part, you gotta be sharp at that.

What I would like to know is what are the best resources to learn math? I find wikipedia's math pages are written in such a way that they are pretty near impossible to read, they are all technical accuracy and no explanation.

Are there better resources that don't involve taking 3 years off work to go back to university?

Wikipedia's entire mathematics section is pretty much useless for learning new concepts--its only value is as a reference for specifics about things one already understands well. Hell, even when I look up stuff I already know their explanations of it often make no sense to me.

Yes, you will have to have *some* understanding of math, but how much and what kind is really dependent on what you are developing. If it is a database fed, scripted web page, the required calculus won't be that much compared with a missile guidance system or a 3D rendering engine / driver (because it is a completely different problem domain).

In most development cases you have to break down complex problems to many simpler ones to make it maintainable. This breaking down strongly reduces the math complexity

Skorks contends that if you want to do truly interesting work in the software development field, math skills are essential and furthermore, will become increasingly important as we are forced to work with ever larger data sets (making math-intensive algorithm analysis skills a priority).

It partially depends on the definition of "Truly interesting work".

The point of math skills is mostly that they are problem solving skills. You want programmers to have those skills.

...which often benefit from a fruitful relationship. That said, I would point out that in my experience programming and mathematics are two distinct disciplines, and neither requires the other. You really can be a professional programmer without knowing anything beyond the most basic arithmetics.

Programming is application of pure logic, the latter isolated from the all but basic mathematical concepts. Mathematics is application of logic in a specific manner which springs from simple arithmetics and has evolved into own world, not in the one of the most important "worlds" we have.

One important remark would be that programming is often APPLICATION of mathematics, which is one case where the two disciplines cannot, for a time being, be separated. In that case, one obviously needs a programmer who is also a good mathematician.

Also, obviously, given two programmers with equal programming skills, pick one with the better math skills over the other, if no other qualities affect the choice. It is like picking any other job candidate - you pick one with more qualifications, even if these apply only remotely to the field of work the company does. And since mathematics is a close cousin here, the choice should be obvious.

Pizza analogy: You can't work in a pizzeria without profound knowledge of chemistry

Car analogy: Automotive engineers are the best drivers, the rest are tinkerers

General: Tool makers vs. tool users

Just because most (all?) programming is based on mathematics it doesn't necessary follow that math is essential or even particularly important to the practice of programing. It could be argued that problem domain knowledge plays a similar role. For example, one could equally plausibly contend that without a profound knowledge of banking you shouldn't write banking software. In my experience hiring managers prefer domain knowledge over generalist skills such as math. Personality is another biggie.

I suspect that the tone of this thread is reflecting the prevalent commodization of programming. We wish that smarts, maths skills etc. are important factors, so we can feel good about ourselves, feel smart, important whatever. In reality very few of us will ever again have jobs where math skills are truly important. Dumbing down? Maybe. Some might see it as a natural consequence of the fall of the "priesthood" that ruled computing decades ago.

Oh for [whatever]'s sake, who on this earth started spreading the "wisdom" that all apps are database-driven web applications that do nothing more than displaying user-input two-line texts with images and videos?

I could list dozens of algorithms - even from my day-to-day use - that nobody on this earth would be able to correctly and efficiently implement without proper math skills. And even the term math is too broad, natural language-related stuff, image/video/vision content processing stuff, simulation stuff, overall machine learning stuff plus ai-related fields, control systems - and I could just go on forever - don't come without their associated - sometimes fairly deep - math topics.

The social web will come and go, but apps and algorithms that do something even remotely useful, won't ever be accomplished by math-knowledge-lacking code monkeys.

the bottom line is: yes, you can use libraries (for this, you don't need much math), but to be a GREAT programmer, you need to be able to program things yourself (for this, you need math). If you can only piece together other peoples code (which you don't even remotely understand), then you are a tinkerer. It will be complete coincidence, when your code works reliably and fast.

You need to understand it, but how often do you actually analyze non-trivial algorithms (one that require more than counting the number of loops and multiplying by known algorithm times)? In a 10 year career I don't think I've ever done more than that. Not saying more math hurts, and its interesting in and of itself. Unless you're doing 3D graphics (which require trig and linear algebra), you rarely use more than basic algebra and some discrete math concepts. I honestly say I've never used calculus or differential equations professionally.

Looking at whether math is necessary to be a good programmer could be like putting the cart before the horse. I think it's more likely that good programmers are usually good at math because that's they way their brain works.

That's a good way of putting it. I'd also point out that programming and math are very similar- they're both formal languages for discussing abstract concepts. I'd think if you're one of those people who see a line of math and have to puzzle out each symbol individually, you'll have problems with programming. If you can actually think in terms of those symbols, you'll be able to do the same in $LANGUAGE_OF_CHOICE.

Heck, perhaps my favorite college course was the one where we proved the equivalence of various math and programming problems. The more ways you learn to think about problems, the less details like the "language of choice" matters, and the more you can think in terms of "what's the right tool for this job".

Plus, as Feynman noted, if you merely have a different toolbox than those around you, people wil think you're a genius, as you can often see immediate solutions to problems they've been struggling with for a long time (and the fact that the converse is true only comes up if you let it). Having a large toolbox has worked quite well in my career.

You need to understand it, but how often do you actually analyze non-trivial algorithms (one that require more than counting the number of loops and multiplying by known algorithm times)? In a 10 year career I don't think I've ever done more than that.

Yes, but you at least know of big-O notation and what it means. You know that the "cost" of an algo can be measured and calculated. And that it's important.

There are far too many "programmers" out there who don't even know that.

And to really understand big-O notation, you need to know quite a lot about real analysis.

Programming is 99% math, but if you've never had a rigorous mathematical education you'd never know it. Discrete math/combinatorics has been mentioned. You also have coding theory, set theory, ring theory (we do all math over a quotient ring), many ideas from linear algebra, graph theory. If you have a job that doesn't suck, you probably deal with numerical methods and number theory a bit (e.g. why Karatsuba's algorith

That's true, and if someone is doing more with their life then I applaud them. But if you are spending 1/4 or more of your life doing something it seems to make sense that you would want to focus on improving that, and making it fun if possible.

If you are a typical programmer, you'll be using libraries that already have the difficult math-y stuff worked out.

If you don't have any clue about what these libraries actually do, then they're basically as useful as a typewriter to a monkey. You don't need to reinvent the wheel every time, but at least you need to have a clue about how and why a wheel works.

Day to day programming work now hits problems with lots more mathematical angles than in the old days.

I have the opposite opinion and experience, if you go back 15-20 years and look at the state of software development back then it involved a lot more math for "day to day" programming, platforms where drawing a line across the monitor required writing your own function/subroutine which did the drawing and antialiasing where still quite common, these days you just do "import System.Graphics.Routines; Surface srf = new Surface(width,height); srf.DrawLine(x1,y1,x2,y2,color, width);" or something along those li

This was of course just an example but it's true for a lot of stuff, back then you had to spend a lot more time optimizing your code as well, these days premature optimization is generally considered a bad thing (since in most cases it ends up being a waste of $500 worth of programmer time to squeeze out a performance gain that $50 in hardware would've have gotten you.

If you're planning to sell a million units containing both hardware and software, then "wasting" $500 of programmer time to save even $0.01 in hardware per unit is a really sweet deal.

That's because you've never used it were not shown its applications. Functional analysis is one of the most powerful weapons in the applied mathematicians toolkit - it's essential to quantum theory and financial mathematics, for example.

To develop algorithms, Yes, you will need math skills but that will not be sufficient. you will need also the knowledge of the dataset you want to process. You do not analyse Facebook data the same way as Afganistan images from UAVs or LHC events.

So you will have specialists that will tell you how the data need to be analysed.
You as IT specialist will need the basic math skills to apply what they told you to.

Math is not sufficient in most cases.
The best mathematician in the world will not be able to tell you how to simulate a galaxy or how to go from a diffraction pattern to the structure of a protein.

If it is these stuff that you want to code. CS is not the major you should have chosen.

The question was not whether maths was sufficient, but whether it was necessary. If you had any math skills, you'd know the difference 8-P