Comment by spitfire | Hacker News Reader

Comment by spitfire | Hacker News Reader

Parent Full thread

Sure. During the rap genius debacle there were a bunch of people taking time to figure out what was wrong with Heroku's routing. I was entertained because there were two parts to the problem A) queueing and B) optimizations.

So with a line of code you could represent heroku's queues and determine exactly how many dyne's you needed. Or, you could try different queueing methods and determine how much money you could have been saving.

In some sense Mathematica is further down the What vs How line of language power. Even in ruby, Clojure or Haskell you're still left specifying HOW to do optimization, integration, etc. Not what you'd like to optimize, integrate or manipulate.

[1] http://reference.wolfram.com/mathematica/guide/QueueingProce... [2] http://reference.wolfram.com/mathematica/guide/Optimization....

So what's this line of code?

Well, here's a quick simulation assuming request servicing follows a Poisson process. The Manipulate function takes a function and generates an interactive version of that function. So in this case it has a graph (list plot) of the simulation, along with a slider to manipulate the number of new requests (arrivals).

If you wanted to be ambitious, you could simulate different servicing distributions, and times. But that might add a whole 2-3 lines of code to the solution.

http://imgur.com/66wczZu

Manipulate[ ListLinePlot[ RandomFunction[QueueingProcess[arrivals, 60/8] , {0, 50}][ "Path"]], {arrivals, 1, 30}]

So how does generating a graph actually solve the problem in the real world? Or am I misunderstanding what the problem is? I was assuming the problem was with some real world application, most likely regarding the implementation of some complex networking algorithm for Heroku's system. But if it's just some abstract math problem, of course it would make sense to use something like Mathematica, MATLAB, etc.

That was just to demonstrate the problem. You could solve it by using NSolve[expr, vars] and giving a limit for the response time you'd like. You'd get back the number of dyne's you'd need to meet those requirements.

On heroku's side, you could model their network with a few lines of code and experiment with different types of queues to find things that work well and are affordable.

As PG said in beating the averages, it's one o those things that's easy to dismiss when you're looking up the power curve.

Reply on news.ycombinator.com