Why do most programmers work so hard at pretending that they’re not doing math? • Hacker News Board

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#61

Post by bartonfink » Sat, Jan 14, 2012, 4:03 PM UTC

buff-a wrote: post #48

jond3k wrote: post #44

Earlier quoted context omitted.

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 thes…

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

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

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#62

Post by anamax » Sat, Jan 14, 2012, 5:29 PM UTC

tikhonj wrote: post #23

anamax wrote: post #15

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.

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 i…

> Routing is heavily based in graph theory, as far as I know, and so is actually fairly mathematical

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.

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#63

Post by loup-vaillant » Sat, Jan 14, 2012, 7:09 PM UTC

InclinedPlane wrote: post #24

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 comp…

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

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#64

Post by jond3k » Sat, Jan 14, 2012, 7:26 PM UTC

dextorious wrote: post #59

jond3k wrote: post #44

Earlier quoted context omitted.

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 thes…

"""Other cases I can think of are systems where high-throughput or low latency are major requirements but there aren't many of those.""" 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…

Well observed, but I think we need to tell apart cases where performance is mandatory and where it is optional. People wouldn't just complain if it was mandatory, it simply wouldn't be a viable product.

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#65

Post by loup-vaillant » Sat, Jan 14, 2012, 7:28 PM UTC

celoyd wrote: post #26

semisight wrote: post #19

Earlier quoted context omitted.

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 find it hard to believe that Haskell could not be friendlier. And I say that as a fan of Haskell.

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

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#66

Post by tikhonj » Sat, Jan 14, 2012, 7:52 PM UTC

gbog wrote: post #56

tikhonj wrote: post #8

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

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') t…

Yes, I understand that. What I meant is that math is a tool in the same sense a programming language or methodology is a tool--it's something we ultimately use as a means to an end. If our only goal was math, we would actually be mathematicians ;)

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#67

Post by buff-a » Sat, Jan 14, 2012, 10:51 PM UTC

bartonfink wrote: post #61

buff-a wrote: post #48

Earlier quoted context omitted.

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

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

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

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#68

Post by InclinedPlane » Sat, Jan 14, 2012, 10:52 PM UTC

loup-vaillant wrote: post #63

InclinedPlane wrote: post #24

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 comp…

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

That implies that you can specify all requirements in a mathematical form, which is not the case. How do you specify a usability requirement? Software is for humans, that makes it messy, even down to the requirements level.

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#69

Post by buff-a » Sat, Jan 14, 2012, 10:53 PM UTC

rdouble wrote: post #55

buff-a wrote: post #45

Earlier quoted context omitted.

Then show me a counter example and by that I mean name a specific, complex, in-production project written in a functional language. Also, can you define "this problem" because I'm not sure which one you are referring to.

If you mean functions are first class and lambdas exist, any project written in Ruby or Javascript.

Do these programs meet the OPs definition of functional programming, or are they, in fact, a whole bunch of imperative code that use closures as a method for scheduling more imperative code?

Re: Why do most programmers work so hard at pretending that they’re not doing math?

#70

Post by cgopalan » Sat, Jan 14, 2012, 11:03 PM UTC

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.