And that doesn't even touch on the fact that crafting components is but a tiny part of the work required to produce software.

I'm sure this can be modelled mathematically, but I'm not convinced this would help.

And you know what? It was like a revelation to me. It is incredibly helpful. And, by the way, it make me laughing inside each time I query MySQL (because MySQL is sadly /not/ a correct implementation, while PostgreSQL is). The "dots connecting" between set theory and SQL made also much clearer to me the NULL "mess" and why it has to be like that.

So, on this part I'd push the same way as the author, and would go as far as saying that doing correctly a "button X pushed -> notify API Y + persist the action to Z" simple glue code thing /is/ requiring a mental activity that (probably) uses the same parts of your brain as any mathematics and the use them the same way.

However I don't get why the author seem to be ranting against Test Driven Development. In my experience it is unrelated to how you model you data and interactions, except TDD will do exactly as the author is advocating: it will force you to write stateless atomic functions, to make them testable.

NB: From all I have read about mathematics on HN, it seems to me possible that we are not talking about the same thing. Maybe you and many other refer to some "sin a + sin b = cos sin ..." memorization exercise, and some multiple choice questions one have to check as fast as possible in order to get some good enough ranking.

I am talking about a teacher spending around 20 hours a week during several years in front of young people, telling them step by step how the world can be described, analyzed, understood with their brain. It started with: first predicate, there is something, at least one thing. Let's take this thing in your hand, and nothing else: you have a set. In your other hand let's take nothing: you hold now another set, the empty one. Then you have two different things. And on this the teacher built the set theory. (I was educated in France, when math were still on their pedestal).

Of SQL maybe, but of Relational Algrebra/Set Theory, neither PostgreSQL is.

Why would a mathematically modeled system of key-value observing would not help? For one, it would enable one to prove and examine all kinds of assumptions about the model working correctly.

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).

I concede that requirement themselves can't be completely reduced to math. But most of them can. Also, the system itself (excluding human operators) can definitely be reduced to pure math.

What I was proposing was to check the pure math specification against the mostly math requirements. If such math are simple enough, it should be easy enough to make sure the specs match the needs.

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"

You can spend all your life building the perfect implementation of a crappy system, but that won't rescue it. Good CS fundamentals (even provably correct algorithms and implementations) has its place in the software craft but that place is a fairly small niche, not the top of the heap.

Math is not just arithmetic or geometry. Is also a way of thinking and a way to sort and structure your analysis. Which helps you to know how to use psychology to ask the right questions, which leads to understand what needs to be done better than the customer.

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.

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?

SQL in practice is not a purely mathematical construct: you have to know how to make use of spinning platters, indices, caches, locks, network connections, intricacies of data types and bunch of quirks and bugs of the RDBMS.

I've learned SQL before learning set theory properly. It turned out that I did understand (SQL-related parts of) it, I just didn't know it was called set theory :)

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!).

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.

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.

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.

You also sometimes use ErrorT which is a way to slap an Either on any other Monad. The T just denotes that it's a monad transformer.

Coincidentally, I agree wholeheartedly about how practical programming like this is--this sort of error handling is at once easier and more explicit than exceptions.

Haskell certainly seems friendly enough to me. It catches most of my errors before I even run the program, it let me hack things relatively quickly with very little code. Yes, there is that "purity" discipline, but I mostly think like that anyway.

Now, it certainly won't be friendly to one who routinely writes code like that:

  if (foo)
    if (bar)
      do_something;
  
  if      (foo) {} // OK, do nothing
  else if (bar) {} // OK, do nothing
  else          { do_something; }

(For the few who don't see the code above as utterly ridiculous, here is the better version:)

  if (foo && bar)
    do_something;
  
  if (!foo && !bar) { do_something; }

It is often an egocentric excuse to not lean new tools... As if programming was about making he programmer comfortable, as opposed to producing the best result possible.

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 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.

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')".

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.

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.

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 think the hunch of the original article is that few programmers understand the correlation between math and software, hence the lack of use.

Also, can you define "this problem" because I'm not sure which one you are referring to.

Calculus should change the way you understand and perceive the world around, if it didn't, either you got bad teachers and need to ask for your money back, or you were studying only for the test.

And there are a lot of examples, but you can see that AFTER you understand and apply the math behind the concept. Getting by without it is not a proof of its futility, it is only a defense mechanism of the ego.

Javascript. It is closer to functional programming than to object oriented. But most developers don't see this and believe that since they can get by shoehorning "classes" into a prototype then they are back to what is familiar. Prototypes are templates, no classes. Once you develop in javascript with a functional mentality, boy it becomes easy and elegant.

Sql and set theory is another example.

On the more abstracted side... Requirements modeling and calculus. Calculus classes should change the way that you percive

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.

Also note that the effect on performance and throughput are cited as downsides of using GOAL.[1][2]

I met the Naughty Dog team back then and Crash was an awesome game. Their use of a custom scripting language for so much of a real-time game (as opposed to an RPG) was pioneering. They did other innovative things, like baking in radiance transfer to their models to get the lush levels in the game. But at the end of the day, when the Lisp evangelists left Naughty Dog, they stopped using it almost immediately. Apparently, despite using Lisp, and learning from "one of the best lisp programmers in the world", none of that rubbed off on what appears to be an excellent programming team.

The only explanations are:

a) In 7+ years of working with a foremost Lisp programmer, that knowledge did not transfer, or

b) It did transfer, and the other programmers did not see a net advantage.

The OP would like us to believe that the answer is (a). Subsequent games from Naughty Dog would suggest that it is (b).

[1] http://c2.com/cgi/wiki?LispInJakAndDaxter

[2] http://www.gamasutra.com/view/feature/2985/postmortem_naught...

Actually, I haven't met many cases of systems were high-throughput or low latency are NOT major requirements.

Sure, you can wait for your admin script to do something for half an hour, if it means you get to write it in, say, Python, over some faster language. But you don't want to wait for most things, including most end user software. Here's a list people complain all the time about the slowness of:

1) text editors, programmer editors etc. 2) spreadsheets 3) media players 4) compile times 5) image editing programs 6) web pages/apps 7) mobile apps 8) games 9) file managers 10) IDEs 11) video/multimedia editing 12) sound editing 13) word processors 14) window management 15) databases 16) ftp 17) file management 18) asset management 19) browsers

If there's a program for something, there are people complaining it's slow/bloated.

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...

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.

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.

Seriously - what is the useful model for a router or malloc?

Oh, and Babbage was not the first person to write an algorithm.

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.

I didn't write routing, I wrote router. Routing, figuring out what to send where, is just one part of what a router does.

> Memory management can also require a good bit of math.

Yes, but that part isn't the whole of the problem. It isn't even a large part of the problem. (Note that you quickly switched to a completely different problem from malloc to argue for a mathematical basis.)

Math is cool and important, but it often isn't the big problem.

That said, I do agree with your point.