Live data from Hacker News

A comparison of programming languages in economics

marginalrevolution.com

51–60 of 83 posts

Re: A comparison of programming languages in economics

#51
post #32
post #3

Their code is on github [1]. I am a C++ programmer so I'm happy that C++ came out on top, but the comparison is obviously flawed (as these sorts of comparisons always are). The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version. See Russ Cox's response [2] to a Google paper [3] of a similar nature comparing C+…

>The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version One of they authors addresses this in the comments on the OP: > As we explain in the paper, this was a “design” parameter. We did not want to “adapt” the algorithm to each language to improve speed, because it will open the door to too many “uncontrolled…

> One of they authors addresses this in the comments on the OP:

>> As we explain in the paper, this was a “design” parameter. We did not want to “adapt” the algorithm to each language to improve speed, because it will open the door to too many “uncontrolled variables” (how good a programmer in that language you are and so on). The only partial exception was with Mathematica for reasons explained in the paper.

Sure, but this makes the paper less useful for answering the question, "which programming language should I use?" Or, "which programming language should I learn better?"

But, yes, most economists are pretty bad programmers, so "which language should I use poorly?" is probably a useful question to answer.

Re: A comparison of programming languages in economics

#52

In case anyone missed the Java results, I do think it is worth mentioning that it is very competitive: "Our fourth result is that Java imposes a speed penalty of 110 to 169 percent. Given the similarity between Java and C++ syntax, there does not seem to be an obvious advantage for choosing Java unless portability across platforms or the wide availability of Java programmers is an important factor."

There are legions of reasons to choose Java over C++, or vice-versa, none of which have anything to do with syntax. Is this a strawman on the part of the authors, or are they unaware of the legion of things that make C++ a far more complex and dangerous language than Java? Or are those things irrelevant to the needs of economists?

I think it's a combination of unawareness and irrelevance (or perceived irrelevance): many economists are essentially running simulations on a workstation, and that's the use case of the paper.

Re: A comparison of programming languages in economics

#53
post #47
post #40

Earlier quoted context omitted.

The "study" does not account for nuances in each language. JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed. The tests did not account for JVM warm-up time, nor allow the code to become "hot" before running their tests. They also executed their test code on poorly performing operating systems not designed to execute high performance code, ie. they ran their…

JIT'ed Java code is lacking a major facility that truly performant native code has, and that is cache locality. That is, it isn't enough that the code to perform the algorithm is "well tuned" if the data structures are not. (Well, unless I am just wrong on the feats that JIT'ed code can perform nowdays.)

While I agree Java makes writing cache-friendly code much harder than C, it is no-way impossible. Nor is any C or C++ code implicitly cache-friendly. Generally, in both cases you must know what you're doing. I also hope some of those problems are going to be addressed in Java 9.

Re: A comparison of programming languages in economics

#54
post #4

I used to be gung-ho about convincing economists to use Python (started econpy.org in the 1st year of my PhD in economics, stopped updating it after 2 years). But now I just don't care. The vast majority of economists are horrible programmers, however most know how to script in at least 1 language, and a small number of them are actually really good at scripting. An extremely small number of economists know they're w…

"The vast majority of economists are horrible programmers, however most know how to script in at least 1 language, and a small number of them are actually really good at scripting. An extremely small number of economists know they're way around at least 1 entire general purpose programming language." As an economist whose hobby is the study of programming languages, you can imagine the frustration that I feel. What I…

I'm sorry, but that it's a wasted emotion. Economists are not software developers. They do the minimal they need and nothing more. It's like complaining that a masseur has poor baking skills.

Get over it! It's a support tool for them and until they demand that you take their code as a perfect example, developed have no need to complain.

Re: A comparison of programming languages in economics

#56
post #3

Their code is on github [1]. I am a C++ programmer so I'm happy that C++ came out on top, but the comparison is obviously flawed (as these sorts of comparisons always are). The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version. See Russ Cox's response [2] to a Google paper [3] of a similar nature comparing C+…

Given that their code is on github and many people criticized the unidiomatic nature of their code, wouldn't it make sense to set up a competition to improve the code? Everyone can submit pull requests with their improved codes and the authors should simply rerun the codes on a standard machine to get a benchmark. Obviously, a couple of rules should apply:

1. when you improve the code, do not move any elements outside the benchmarked language, i.e., don't use mex files in Matlab, c++ in R etc.

2. maybe create two or three different versions of your code - single processor, multiple cpus, gpu and run it on a single machine with a predefined set up.

This will remove at least some of the criticism thrown at the economists and has an additional benefit: researchers trying to find the best-suited language for their problem can not only use speed but also expressiveness, aesthetics, code length, boilerplate and ease of use to guide their decision.

Re: A comparison of programming languages in economics

#57

Earlier quoted context omitted.

"The vast majority of economists are horrible programmers, however most know how to script in at least 1 language, and a small number of them are actually really good at scripting. An extremely small number of economists know they're way around at least 1 entire general purpose programming language." As an economist whose hobby is the study of programming languages, you can imagine the frustration that I feel. What I…

I'm sorry, but that it's a wasted emotion. Economists are not software developers. They do the minimal they need and nothing more. It's like complaining that a masseur has poor baking skills. Get over it! It's a support tool for them and until they demand that you take their code as a perfect example, developed have no need to complain.

It's more like saying a masseur doesn't have a deep knowledge of anatomy. For most healthy people it wouldn't be an issue if the masseur just did what they were taught, but they'll consistently be suboptimal and will occasionally do some real damage. See the recent high profile errors with economists using excel.

Re: A comparison of programming languages in economics

#58
post #40
post #32

Earlier quoted context omitted.

>The problem is that the implementers don't have the same level of skill in each language and who knows how much time they spent analyzing and refining each version One of they authors addresses this in the comments on the OP: > As we explain in the paper, this was a “design” parameter. We did not want to “adapt” the algorithm to each language to improve speed, because it will open the door to too many “uncontrolled…

The "study" does not account for nuances in each language. JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed. The tests did not account for JVM warm-up time, nor allow the code to become "hot" before running their tests. They also executed their test code on poorly performing operating systems not designed to execute high performance code, ie. they ran their…

>JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed

No way. It may be native C, but it's not native C you've hand-coded yourself.

Re: A comparison of programming languages in economics

#59

Earlier quoted context omitted.

"The vast majority of economists are horrible programmers, however most know how to script in at least 1 language, and a small number of them are actually really good at scripting. An extremely small number of economists know they're way around at least 1 entire general purpose programming language." As an economist whose hobby is the study of programming languages, you can imagine the frustration that I feel. What I…

I'm sorry, but that it's a wasted emotion. Economists are not software developers. They do the minimal they need and nothing more. It's like complaining that a masseur has poor baking skills. Get over it! It's a support tool for them and until they demand that you take their code as a perfect example, developed have no need to complain.

When you have to review their code, you have a very good reason to care about what it looks like. I also feel that I have an obligation to do what I can to improve the accuracy of our research.

"They do the minimal they need and nothing more."

In other words, they work on their program until it runs to completion without throwing an error message.

Re: A comparison of programming languages in economics

#60
post #58
post #40

Earlier quoted context omitted.

The "study" does not account for nuances in each language. JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed. The tests did not account for JVM warm-up time, nor allow the code to become "hot" before running their tests. They also executed their test code on poorly performing operating systems not designed to execute high performance code, ie. they ran their…

>JIT'ed java code will run at native C performance... because it essentially is native C once it's been JIT'ed No way. It may be native C, but it's not native C you've hand-coded yourself.

C doesn't enter into it, any way you look at it. Unless you are using some obscure Java -> C compiler.
Post reply on HN