A seductive idea, but ultimately of stunningly limited use in software engineering. By far the most costly defects in software creation are due to incorrect requirements or poor systems design. Knowing with mathematical certainty that your software component does exactly what you have specified it to do helps little when what it does is still the wrong thing.
And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.
Absolutely. Most of the code being produced around me is of the "When button X is clicked, send an XML message to service Y letting it know the contents of textbox Z."
I'm sure this can be modelled mathematically, but I'm not convinced this would help.
> By far the most costly defects in software creation are due to incorrect requirements or poor systems design.
I'm willing to bet those can be fixed with math. By formalizing the requirement, you're bound to spot any inconsistency, and probably even some other kinds of errors. Same with systems design. "Small is better" and "low coupling is better" for instance, can be formalised and measured.
By the way, you can't escape the fact that ultimately, the final program is supposed to be a formalization of the requirements. Inevitably, the messy ideas in the brain of the customer are bound to be reduced to math. Better use simple math as early as possible, so you can easily check them against the requirements. (Of course it won't happen because most people either won't be able to see the math behind the requirements, or won't bother).
Agree, bur if you don't know how that relatest to math, then you will not discover how math fixes "poor system design" and, as a side effect "incorrect requirements"
A theory that gives correct results for a limited range of phenomena but isn't absolutely correct or mathematically consistent is still useful. Same for programs, I would think.
Simple answer - the vast majority programmers rarely see more than rudimentary math on most projects, unless those projects are specifically math orientated (actual sciences, for example).
The rest of us working on our sites, platforms, apps and what-have-you usually only see anything resembling math when dealing with things like UI and Interaction models, or typically soft-math areas like rating systems and segmentation.
Possibly inflammatory, but perhaps a better question would be: why do most programmers work so hard at pretending they're engineers?
I've never regretted missing out on a formal CS education but I bump up against the limits of my math knowledge all the time. This wasn't the case when I was writing CRUD web apps, of course, but over the last year I've been working in DSP and machine learning and getting my head around the math has been much harder than the coding.
Most programmers know about SQL statements... But rarely identify it with set theory and that difference has a big impact on how you design and program databases. Being able to get by without that understanding is no excuse.
why do most programmers work so hard at pretending they're engineers?
In my experience, this is a regional thing. For my first ten years in the industry (on the east coast), I never met another programmer who called herself an engineer. We were "analysts," "developers," or "programmers." Then I took a job with a local company with a tech office in SV, and everybody, including some of the testers, were "engineers" (hey, even I'm an engineer now!).
Perhaps we should consider that Programmers its a super class of Scientist, Engineer, Designer, Technician.
And that not everybody should know everything about the subclases.
If you think of yourself as developer(?), and Rick as a mathematician its fine!; the problem comes when Rick think you should behave as a mathematician because you are a programmer or viceversa.
The sort of maths the article is referring to has very little to do with arithmetic computation, and is present in the type systems of those languages you're developing sites and apps in.
We work in an environment where heresay [sic] and taste drive change instead of studies and models. We are stumbling in the dark.
Another way to look at it is that we’re making progress, but with lots of false starts, like most progress. Hearsay and taste are what happen when people are working with imperfect information. Probably not even Knuth has perfect information about all the studies and models that might be relevant to any nontrivial project.
The author’s point seems to be not that programmers should understand the math behind their work, but that they should do work that’s more like math. It’s true this would mean fewer bugs. But there are a lot of problems that people in the real world would rather have mostly solved by a slightly buggy dynamic program with mutation and state hiding than not solved by a formally proven program.
A lot of programming is stuff like simple CRUD web apps. I’d rather do that in Python than Haskell for the moment. If the author wants to argue that Haskell could be made friendlier without giving up its advantages, that’s an essay I would welcome.
I'm writing a bunch of webapps in Scala making heavy use of Scalaz, which is Scala's Haskell-envy library of typeclasses. The typical pattern is to compute everything as a Validation, which you can think of as the Maybe monad, except there is information attached to the failure case. It's a very nice way of coding. Everything composes and at the end of the request handling chain you just convert to a response and you're done.
It took a bit of thinking to get the basic patterns, and there is the occasional bit of head scratching to get the type right. This feels very much like algebra.
Anyway, the point is that this style of programming is both "mathematical" and practical.
Haskell's advantages lie in being pure. It can't be 'friendlier,' because friendly languages let you hack things up (and are impure) as opposed to the planning required to lay down some Haskell.
I like to think that CS is just a different approach to math.
Of course, I say this as somebody who likes Haskell where the programmers work really hard at pretending to be mathematicians :)
However, even when I'm writing in other language, I think about things in terms of math. Additionally, my CS courses so far have all been heavily influenced by math, except for systems that was much more heavily influenced by EE.
So, at least for me, programming is very much like math. Just shinier. And I do think that more math--or at least mathematical thinking--would help most programmers.
However, the rant against testing is just silly. Tests are not a replacement for math--they augment it. We need tests because, at heart, CS is an engineering discipline: math is just a tool we use very pervasively.
Haskell is one of the more extreme typed functional languages, and yet Haskell programmers are very amenable to testing. In fact, Haskell programmers tend to go above and beyond normal testing: we use property-based testing (QuickCheck). Instead of just having unit tests, we actually generate random tests.
Besides, lets look at physics: they have great mathematical models. However, as soon as you actually apply physics--basically engineering--you need to test everything extensively. There is a reason we have exhaustive crash tests, after all.
So: math is good for programmers. Tests are also good for programmers. The two cannot replace each other.
I tend to think of Haskell as a language designed by mathematicians but not for mathematicians. Not even to say that it's not useful for doing math but simply that it's not structured to explore ideas via proofs. Consider Coq or Mathematica which are definitely designed with that goal in mind.
I think programmers aren't doing math at all, but I think what programmers do is better, more adroitly, done when its guided strongly by math. For that reason I think programmers should learn lots of math, even if they don't spend much time proving things for their own purposes.
Agree with the rest, but not with "math is just a tool".
Math here is not about answering a question like "what are the coordinates of the point in the middle of those two points here". It is not a tool helping to solve a restricted set of computation problems. Math here is the model for the deterministic handling of a data system and its evolution in time. The silliest glue code is still math: "if button.push('a') thing.do_action('a_action')" translates to "For any x in A_Button_Pushes, action = f('a_action')".
Walking is math too, it can be modeled in math, but that doesn't mean all people who walk are mathematicians.
Physics is math too, but the difference is that while Physics uses the same constructs as math, Programming has radically different constructs.
Math and Programming does not require the same mindset, in math you need to find the absolute truth, when programming, 99% is good enough.
Being good at Math does not make you a good programmer instantly, and vice versa.
> This is also why programmers who use typed functional languages frequently brag about their low bug count yet eschew methodologies like test driven development: tests pale in comparison to the power of actual models.
If I brag about something does that make it a fact? I think writing this in math context is silly to say the least. It doesn't matter what you program in, you still need to test most of the time, this has nothing to do with how you program, it's what you program, I highly doubt that you could model a video game, and get it right the first time, without ever testing it.
Overall this article is pretty confusing, it tires to raise some good points, but gets stuck on the details.
"This is also why programmers who use typed functional languages frequently brag about their low bug count yet eschew methodologies like test driven development: tests pale in comparison to the power of actual models."
I've written complex systems. Games. Graphics modelling tools. Network game engines. I've seen a lot of code.
I've never seen anything that complex written in a functional language.
Why?
My hunch is that models are powerful, but brittle: they don't stand up against constantly changing requirements. A great quote I read the other day was "If it compiles, it works". Great. Now change the requirements. The "beauty" of imperative languages is that they continue to compile and continue to provide some value of "work" even while they are morphing from one requirement set to the next. Functional languages are cast-iron. Imperative languages are steel.
UPDATE: I should also be clear: I think in models all the time. I just don't have to get it down perfectly on paper for the code to compile. I used to hear, back in the day, C++ programmers opining that we should all use C++ because object-oriented programming is superior. Regardless of whether or not OO is superior, they completely failed to comprehend how one could do object-oriented programming in assembly language, or that we'd been doing it the whole time.
So its entirely possible that there's something I dont get about functional programming that means I don't understand what I'm missing. But its also possible that I understand the theory better than you and so I don't see the distinction you are making because there isn't one. To discern which is true, however, I'm going to need concrete examples, not opinion pieces.
I disagree. Generally I see this problem when trying to program in a functional languaged with an imperative thinking. This is not a weakness of the language, but of the developer.
I think the hunch of the original article is that few programmers understand the correlation between math and software, hence the lack of use.
I think the point is that there's something intrinsically verifiable about a mathematical model since you're dealing with quantifiable output.
Other cases I can think of are systems where high-throughput or low latency are major requirements but there aren't many of those. Most of what we do is about getting more users or making more profit - good engineering performance and decisions are not directly related to these.
Many modern web apps where many programmers are employed are simply IO glue (request in, database in/out, web page response out) and don't involve many algorithms other than sorting and using hashtables and trees.
"We work in an environment where hearsay and taste drive change instead of studies and models. We are stumbling in the dark."
I completely agree. Programming became a lot less fun once I entered industry and realised most decisions are driven by fashion and office politics. It's not so bad when it's you and a couple of friends hacking all night on a project because you likely have closely aligned interests. Being an employee, however, means you're a slave to other people's ideals.
I suppose this is why most of us are interested in startups.
> In the early days programming was considered a subdiscipline of mathematics
But then the Electrical Engineering guys come and conquer, then CS evolve closer to EE than to Math.
And these days, well... your boss always look at you and say that does not want to now about math or performance, he want to know about accomplished deadlines and nice UIs.
I just began work on a new project that was half modeled. I initially tried to understand the existing model and wasted quite a few weeks for understanding that incomplete model. My problem is had i spent that time understanding the system...testing it as i would test a black box, i believe i could have constructed a better model..Ofcourse, this doesn't say anything about pros or cons of either approach..
And am beginning to get annoyed at the boiler plate generated by OOPS style programming.
But, to be honest, creating a model without looking at data first doesn't appeal to me either. I guess models will have evolve in sync with tests.. i.e: generate model/hypothesis,test, refine model/hypothesis test, repeat.
Requesting the database with some SQL inner join should get you less lines than both tables ? No ! It gets you a deadlock exception because some other program locks you...
Doing a DNS query to get IP address of an host ? Getting an IP ? Yes ? Everything ok ? No because some bit flipped somewhere and caused the result to be the IP address of foogle.com
So yes you are using maths but you are not doing maths.
There are a lot of famous people in programming that produce world-class output without using typed functional languages. Therefore I am going to interpret this as : typed functional languages are cool to work with, but not necessary to produce excellent software. And producing excellent software is probably the only thing that matters.
Routing is heavily based in graph theory, as far as I know, and so is actually fairly mathematical.
Memory management can also require a good bit of math. A perfect example would be taking an existing algorithm and optimizing it to use fewer memory accesses. We covered this sort of optimization in my recent algorithms class (for some algorithms) and it figuring out how to do required a good bit of math.
Really, the issue is that a programmer who doesn't use math is much less likely to see how math would be applicable to any particular situation. This is just like the programmer who does not know about, say, hash maps--he would not realize what he is missing.
[+] [-] InclinedPlane|14 years ago|reply
And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.
[+] [-] AndrewDucker|14 years ago|reply
I'm sure this can be modelled mathematically, but I'm not convinced this would help.
[+] [-] loup-vaillant|14 years ago|reply
I'm willing to bet those can be fixed with math. By formalizing the requirement, you're bound to spot any inconsistency, and probably even some other kinds of errors. Same with systems design. "Small is better" and "low coupling is better" for instance, can be formalised and measured.
By the way, you can't escape the fact that ultimately, the final program is supposed to be a formalization of the requirements. Inevitably, the messy ideas in the brain of the customer are bound to be reduced to math. Better use simple math as early as possible, so you can easily check them against the requirements. (Of course it won't happen because most people either won't be able to see the math behind the requirements, or won't bother).
[+] [-] jorgeleo|14 years ago|reply
Agree, bur if you don't know how that relatest to math, then you will not discover how math fixes "poor system design" and, as a side effect "incorrect requirements"
[+] [-] szany|14 years ago|reply
But it is...
1) We test theories with experiments to see whether they fail for that particular "input", we don't prove them correct.
2) One of our two best theories (QFT, the other being GR) doesn't even make sense, mathematically.
In fact the great challenge of physics today is that we have neither experiment nor mathematical rigor to stand on: http://groups.google.com/group/sci.physics.research/browse_t...
A theory that gives correct results for a limited range of phenomena but isn't absolutely correct or mathematically consistent is still useful. Same for programs, I would think.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] oelewapperke|14 years ago|reply
[deleted]
[+] [-] code177|14 years ago|reply
The rest of us working on our sites, platforms, apps and what-have-you usually only see anything resembling math when dealing with things like UI and Interaction models, or typically soft-math areas like rating systems and segmentation.
Possibly inflammatory, but perhaps a better question would be: why do most programmers work so hard at pretending they're engineers?
[+] [-] cageface|14 years ago|reply
[+] [-] atarian|14 years ago|reply
[+] [-] jorgeleo|14 years ago|reply
[+] [-] bmj|14 years ago|reply
In my experience, this is a regional thing. For my first ten years in the industry (on the east coast), I never met another programmer who called herself an engineer. We were "analysts," "developers," or "programmers." Then I took a job with a local company with a tech office in SV, and everybody, including some of the testers, were "engineers" (hey, even I'm an engineer now!).
[+] [-] Sufrostico|14 years ago|reply
And that not everybody should know everything about the subclases.
If you think of yourself as developer(?), and Rick as a mathematician its fine!; the problem comes when Rick think you should behave as a mathematician because you are a programmer or viceversa.
[+] [-] regularfry|14 years ago|reply
[+] [-] celoyd|14 years ago|reply
Another way to look at it is that we’re making progress, but with lots of false starts, like most progress. Hearsay and taste are what happen when people are working with imperfect information. Probably not even Knuth has perfect information about all the studies and models that might be relevant to any nontrivial project.
The author’s point seems to be not that programmers should understand the math behind their work, but that they should do work that’s more like math. It’s true this would mean fewer bugs. But there are a lot of problems that people in the real world would rather have mostly solved by a slightly buggy dynamic program with mutation and state hiding than not solved by a formally proven program.
A lot of programming is stuff like simple CRUD web apps. I’d rather do that in Python than Haskell for the moment. If the author wants to argue that Haskell could be made friendlier without giving up its advantages, that’s an essay I would welcome.
[+] [-] noelwelsh|14 years ago|reply
It took a bit of thinking to get the basic patterns, and there is the occasional bit of head scratching to get the type right. This feels very much like algebra.
Anyway, the point is that this style of programming is both "mathematical" and practical.
[+] [-] semisight|14 years ago|reply
[+] [-] tikhonj|14 years ago|reply
Of course, I say this as somebody who likes Haskell where the programmers work really hard at pretending to be mathematicians :)
However, even when I'm writing in other language, I think about things in terms of math. Additionally, my CS courses so far have all been heavily influenced by math, except for systems that was much more heavily influenced by EE.
So, at least for me, programming is very much like math. Just shinier. And I do think that more math--or at least mathematical thinking--would help most programmers.
However, the rant against testing is just silly. Tests are not a replacement for math--they augment it. We need tests because, at heart, CS is an engineering discipline: math is just a tool we use very pervasively.
Haskell is one of the more extreme typed functional languages, and yet Haskell programmers are very amenable to testing. In fact, Haskell programmers tend to go above and beyond normal testing: we use property-based testing (QuickCheck). Instead of just having unit tests, we actually generate random tests.
Besides, lets look at physics: they have great mathematical models. However, as soon as you actually apply physics--basically engineering--you need to test everything extensively. There is a reason we have exhaustive crash tests, after all.
So: math is good for programmers. Tests are also good for programmers. The two cannot replace each other.
[+] [-] tel|14 years ago|reply
I think programmers aren't doing math at all, but I think what programmers do is better, more adroitly, done when its guided strongly by math. For that reason I think programmers should learn lots of math, even if they don't spend much time proving things for their own purposes.
[+] [-] gbog|14 years ago|reply
Math here is not about answering a question like "what are the coordinates of the point in the middle of those two points here". It is not a tool helping to solve a restricted set of computation problems. Math here is the model for the deterministic handling of a data system and its evolution in time. The silliest glue code is still math: "if button.push('a') thing.do_action('a_action')" translates to "For any x in A_Button_Pushes, action = f('a_action')".
[+] [-] voidr|14 years ago|reply
Physics is math too, but the difference is that while Physics uses the same constructs as math, Programming has radically different constructs.
Math and Programming does not require the same mindset, in math you need to find the absolute truth, when programming, 99% is good enough.
Being good at Math does not make you a good programmer instantly, and vice versa.
> This is also why programmers who use typed functional languages frequently brag about their low bug count yet eschew methodologies like test driven development: tests pale in comparison to the power of actual models.
If I brag about something does that make it a fact? I think writing this in math context is silly to say the least. It doesn't matter what you program in, you still need to test most of the time, this has nothing to do with how you program, it's what you program, I highly doubt that you could model a video game, and get it right the first time, without ever testing it.
Overall this article is pretty confusing, it tires to raise some good points, but gets stuck on the details.
[+] [-] rckclmbr|14 years ago|reply
http://xkcd.com/435/
There's a truth to it -- CS is just applied math, that doesn't mean you have to understand math to program, but it will be very beneficial.
[+] [-] buff-a|14 years ago|reply
I've written complex systems. Games. Graphics modelling tools. Network game engines. I've seen a lot of code.
I've never seen anything that complex written in a functional language.
Why?
My hunch is that models are powerful, but brittle: they don't stand up against constantly changing requirements. A great quote I read the other day was "If it compiles, it works". Great. Now change the requirements. The "beauty" of imperative languages is that they continue to compile and continue to provide some value of "work" even while they are morphing from one requirement set to the next. Functional languages are cast-iron. Imperative languages are steel.
UPDATE: I should also be clear: I think in models all the time. I just don't have to get it down perfectly on paper for the code to compile. I used to hear, back in the day, C++ programmers opining that we should all use C++ because object-oriented programming is superior. Regardless of whether or not OO is superior, they completely failed to comprehend how one could do object-oriented programming in assembly language, or that we'd been doing it the whole time.
So its entirely possible that there's something I dont get about functional programming that means I don't understand what I'm missing. But its also possible that I understand the theory better than you and so I don't see the distinction you are making because there isn't one. To discern which is true, however, I'm going to need concrete examples, not opinion pieces.
[+] [-] jorgeleo|14 years ago|reply
I think the hunch of the original article is that few programmers understand the correlation between math and software, hence the lack of use.
[+] [-] jond3k|14 years ago|reply
Other cases I can think of are systems where high-throughput or low latency are major requirements but there aren't many of those. Most of what we do is about getting more users or making more profit - good engineering performance and decisions are not directly related to these.
[+] [-] bickfordb|14 years ago|reply
[+] [-] regularfry|14 years ago|reply
[+] [-] MortenK|14 years ago|reply
[+] [-] jond3k|14 years ago|reply
I completely agree. Programming became a lot less fun once I entered industry and realised most decisions are driven by fashion and office politics. It's not so bad when it's you and a couple of friends hacking all night on a project because you likely have closely aligned interests. Being an employee, however, means you're a slave to other people's ideals.
I suppose this is why most of us are interested in startups.
You may also be interested in this post by Zed Shaw: http://zedshaw.com/essays/programmer_stats.html
~~~
Surely the first person to write an algorithm wasn't Babbage or Lovelace, but more likely to have been the middle-eastern mathematician the word was named after? http://en.wikipedia.org/wiki/Mu%E1%B8%A5ammad_ibn_M%C5%ABs%C...
[+] [-] Sufrostico|14 years ago|reply
But then the Electrical Engineering guys come and conquer, then CS evolve closer to EE than to Math.
And these days, well... your boss always look at you and say that does not want to now about math or performance, he want to know about accomplished deadlines and nice UIs.
[+] [-] aangjie|14 years ago|reply
And am beginning to get annoyed at the boiler plate generated by OOPS style programming.
But, to be honest, creating a model without looking at data first doesn't appeal to me either. I guess models will have evolve in sync with tests.. i.e: generate model/hypothesis,test, refine model/hypothesis test, repeat.
[+] [-] wyclif|14 years ago|reply
[+] [-] hhjj|14 years ago|reply
Requesting the database with some SQL inner join should get you less lines than both tables ? No ! It gets you a deadlock exception because some other program locks you...
Doing a DNS query to get IP address of an host ? Getting an IP ? Yes ? Everything ok ? No because some bit flipped somewhere and caused the result to be the IP address of foogle.com
So yes you are using maths but you are not doing maths.
[+] [-] cgopalan|14 years ago|reply
[+] [-] amalag|14 years ago|reply
[+] [-] agumonkey|14 years ago|reply
[+] [-] anamax|14 years ago|reply
Seriously - what is the useful model for a router or malloc?
Oh, and Babbage was not the first person to write an algorithm.
[+] [-] tikhonj|14 years ago|reply
Memory management can also require a good bit of math. A perfect example would be taking an existing algorithm and optimizing it to use fewer memory accesses. We covered this sort of optimization in my recent algorithms class (for some algorithms) and it figuring out how to do required a good bit of math.
Really, the issue is that a programmer who doesn't use math is much less likely to see how math would be applicable to any particular situation. This is just like the programmer who does not know about, say, hash maps--he would not realize what he is missing.
[+] [-] glidey|14 years ago|reply
[deleted]
[+] [-] losethos|14 years ago|reply
[deleted]