Programming languages in economics: Cool research, bro, but what about, er, economics?

Well duh

Engineering is the art of compromise.

Different problems need to be tackled in different ways.

If you're building millions of something then it pays to spend a 100k or more optimising the code so it can run on a 20cent CPU vs a 50cent CPU.

If the code is going to be run once then speed of writing the code and being confident in the output is far more important.

Hence actuaries doing one-off calculations us APL or matlab or such while embedded programmers use assembler, C or whatever.

Call cost/benefit supply/demand analysis economics if you want, but to an engineer it is just normal decision making.

Treasury Economic Model?

I thought that was actually quite simple -

1) Run program

2) box pops up on screen "Please enter the answers required by your political masters"

3) Type in required answers

4) Print out results (see 3 above)

5) Send output to political masters who then use it to prove whatever lies they are currently peddling.

pings

Python sounds reasonable. But I'd be likely to do it as a cron job, written largely in bash. It might well call a bit of python for some reason or other.

p.s. I am well acquainted with optimising the sh*t out of things in C (or asm if necessary) having, for example, been involved in writing a commercially successful (right up until iPhone and Android came out) compiler to turn Java games into native code on cruddly little feature phones with 1 MHz CPUs and as little as 400 KB of RAM.

I just bought another world for my playbook. I wonder if that means the port has more or few resources at its disposal.

re. Another World

Is that a buffalo with a frickin' laser strapped to its groin?

> They code the same model, the same algorithms (without changing them at all even for the known differences with which different languages can handle them)

Is this this even possible without skewing the whole test to the point of meaninglessness?

Or at least being even more meaningless that it already was?

From (personal) experience

The choice of language often has less to do with rational economic analysis, and more to do with what the customer, technical architect/technical assurance/standards committee and management's personal biases currently are.

Speaking as a one-time VBA, VB.NET, C#, JavaEE, BPEL and Python developer. Still at least it gives us code monkeys variety and a broad knowledge base!

If this was such a dull & almost-pointless paper ...

... why didn't you choose to write about an interesting one instead? I mean, we all do like to sneer at economists a bit, if even only for entertainment, but actually I was hopng for something fractionally more informative.

crazed models of how macroeconomists think the real world works

models of how crazed macroeconomists think the real world works

FTFY

No word on optimisations, multithreading, support, maintainability, interoperability, ease of modification, ability to strap it to a pretty GUI or anything else that in the real world should determine which code should be used to do models that could, push come to shove, be done with a frigging glassblower having a coughing fit in the 40's.

http://en.wikipedia.org/wiki/MONIAC_Computer

"They code the same model, the same algorithms (without changing them at all even for the known differences with which different languages can handle them)"

Yeah, I bet they did the equivalent of comparing string slicing by comparing

result$="":FOR a=start TO length:result$=result$+FNmiddlecharacter(source$,a):NEXT a

instead of just using MID$()

I've seen people painstakingly write a substring comparison function instead of just f***g using INSTR().

dead simple programs are equally fast to write in any language

If you look at their code, it's just some statically allocated multidimensional arrays, some simple nested loops (corresponding to array dimensions), and a small amount of arithmetic and occasional if statement.

The C code doesn't give you the safety net of array bound checking, and the for loop syntax is annoying to the uninitiated, but there's really not a lot of difficulty in using C or C++ in this way. Certainly the development time difference between it and Python would be absolutely minimal.

Interesting that their test Mac is a 2.3 GHz quad core i7 (model unspecified), while the Windows machine is a quad core i7-3770 at 3.4 GHz, and yet the execution times are pretty much identical or even faster.

The conclusion from that is the Mac is a laptop with massive SpeedStep taking it up to to around 3.3 or even 3.5 GHz (current 15" Retina MBP).

This was peer assessed?

I stopped reading when they were confusing speed with execution time in the section on Julia.

Oh dear...

just ignoring parallelisation makes the whole thing a bit moot. Most of the languages listed would have access to the well written and well tested libraries that should be doing the donkey work here.

Even this creaky old laptop has two cores on it and you would like to think people 'doing economics' might like to make their code 'future proof' as well as reality proof.