
Why do most programmers work so hard at pretending that they’re not doing math? - plinkplonk
http://richardminerich.com/2012/01/why-do-most-programmers-work-so-hard-at-pretending-that-theyre-not-doing-math/
======
InclinedPlane
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.

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

~~~
gbog
I'm not sure. The OP raise the fact the SQL is modeled after set theory. I
happen to have learnt set theory a very long time ago, and to use SQL as much
as any web developper around. Then I read a book about foundations of SQL, and
found out it can and should be seen as an implementation of the set theory.

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

~~~
dextorious
"""because MySQL is sadly /not/ a correct implementation, while PostgreSQL
is"""

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

------
szany
_Imagine if physics was done this way._

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...](http://groups.google.com/group/sci.physics.research/browse_thread/thread/197c7bd30c78e1c7/9bb83d11d54c5062?pli=1)

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.

------
code177
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?

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

~~~
pornel
I think you can learn SQL as SQL, without math background. OTOH just knowing
mathematical model of SQL is not enough to write good SQL.

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

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

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

~~~
celoyd
I find it hard to believe that Haskell could not be friendlier. And I say that
as a fan of Haskell.

~~~
loup-vaillant
Someone should define "friendly" at this point.

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; }
    

(I saw that yesterday in production code!) Those people think too procedurally
to be able to understand Haskell, or even ML. You have to fix that flaw first.

(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; }

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

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

~~~
matwood
Exactly. Let me also add that math isn't so much a tool as it is a way of
thinking. Learning (or should I say understanding) more math helps in all
sorts of non-obvious ways. From thinking logically, to seeing intuitive
shortcuts, to proofs (used nearly every time a program is debugged), to
algorithms, programming is one of the greatest concrete implementations of the
math abstract.

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

~~~
rckclmbr
Your post reminds me of what xkcd says about it:

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

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

~~~
buff-a
Video games are all about high-throughput and low latency. Nobody writing
commercial games in functional languages that I'm aware of.

~~~
bartonfink
I believe the Jak and Dexter games were written in a Lisp dialect, although
I'm not sure of the success.

~~~
buff-a
Naughty Dog created their own version of lisp called GOAL to control game
objects. Scripting languages are common in games, but the "heavy lifting" is
done in C/C++, as is the case in Jak and Daxter and Crash Bandicoot. Naughty
Dog don't use GOAL any more. Have their games gotten worse?

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...](http://www.gamasutra.com/view/feature/2985/postmortem_naughty_dogs_jak_and_.php?page=3)

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

~~~
regularfry
There's interesting maths to be around proving the IO glue correct, though.
Opa is an fun take on that problem.

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

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...](http://en.wikipedia.org/wiki/Mu%E1%B8%A5ammad_ibn_M%C5%ABs%C4%81_al-
Khw%C4%81rizm%C4%AB)

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

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

------
wyclif
Yet another instance of content not set up to handle traffic. Anybody got the
copypasta?

------
hhjj
>>> 1.1+2.2 == 3.3 False

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

------
amalag
An article is needed, On why programming is not mathematics.

------
agumonkey
On everyday reality job, you often work to change a system, this is some kind
of science besides the other common cs math fields.

------
anamax
Because they're not doing math?

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

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

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

~~~
bitops
Modern IP networking relies extensively on graph theory. The Spanning Tree
Protocol is a prime example of this.

~~~
4ad
Graph theory is a very complex, and broad field of mathematics. The routing
algorithms are an absolutely trivial application of it in a minuscule amount.
Anybody, without formal training in mathematics can understand routing
algorithms, because they are so simple and _easy_.

~~~
bitops
Yes, that is true. But, how those algorithms happen, is based in graph theory;
is what I meant. If you saw Jamis Buck's "Algorithms" talk, I believe there's
a reference to a "spanning tree" graph in there.

That said, I do agree with your point.

