It seems like this is a comparison of speed. Not a comparison of languages. Each language has their own pro's and con's. For instance, I use R on a daily basis. I don't require speed to do my job because I'm analyzing data and drawing inferences to help make business decisions. I like the fact that there is a huge library and an active community that can help me implement solutions. Perhaps if a solution/product I come up with needs speed then I'll implement a tool that will do that job well. But my "toolbox" requires fast prototyping and development.
A comparison of programming languages in economics
21–30 of 83 posts
Re: A comparison of programming languages in economics
#22Their 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 stochastic growth model, which is the workhorse of modern economics, cannot be easily vectorized, and usually requires tight inner loops to get good performance, or rewrite the computational kernels in C. Codes such as Dynare ( http://www.dynare.org ) do exactly that. In my opinion, this is where Julia shines - it provides high performance in a dynamic language, much at the level of R or MATLAB. Then again, being…
The two things I like about Julia are actually using it and all the smart people I have met who are also using it. It's awesome. After playing with this particular problem a bit, I do see how it is a pathological case for R due to the recursive nature of the value function. I still think I could do better than 500x slower than C++.
Re: A comparison of programming languages in economics
#23Their 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 stochastic growth model, which is the workhorse of modern economics, cannot be easily vectorized, and usually requires tight inner loops to get good performance, or rewrite the computational kernels in C. Codes such as Dynare ( http://www.dynare.org ) do exactly that. In my opinion, this is where Julia shines - it provides high performance in a dynamic language, much at the level of R or MATLAB. Then again, being…
The stochastic growth model is the workhorse of a narrow subfield of economics. It is not in any way representative of the research we do. Further, you will not find any examples that are better suited to compiled languages or less suited to using R than the one in this paper.
To my knowledge, value function iteration isn't even used much in this area of research, so the claim that the stochastic growth model is a "workhorse" is a bit misleading - the stochastic growth model gets used, but it is not solved very often using the methodology in this paper.
Re: A comparison of programming languages in economics
#24Their 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+…
I almost gasped when I saw that their R code[1] does the bulk of its computations inside a while(...for(...for(...for(...if(...){...}else{...})))) block, instead of using functionals like apply and 'vectorized' operations like ifelse . If this criticism seems harsh, compare the authors' R code to Hadley Wickham's advice at http://adv-r.had.co.nz/Profiling.html -- or just search Google for "speed-up loops in R". -- [1…
Many of the bioinformaticains I know use R. Not knowing how to use it properly wouldn't surprise me in the slightest. I struggle to get some of them to indent their Perl code.
Re: A comparison of programming languages in economics
#25In 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."
In my professional life I have rarely (if ever?) seen a language chosen on the basis of it's syntax.
Plenty of people claim they won't use Python for its whitespace. Not quite the same, but it seem that elements of syntax are influencing peoples decisions.
I would also recommend Python to new programmers, partly for the syntax.
Re: A comparison of programming languages in economics
#26I 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…
Hey, that's really neat. I'm doing a post-masters right now in energy economics and have been transitioning into using python for everything (from previously using Matlab or whatever was available), but I'm eyeing an economics PhD down the line. You have any advice/opinions on economics PhDs?
Do you have any specific questions? I teach in a PhD-granting department and do research in energy economics. (I'm an associate editor of one of the energy field journals.)
Re: A comparison of programming languages in economics
#27I 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 have found works best is to make grad students use basic functional programming techniques. Everything they do is just a few lines long. As opposed to a 250-line heap of garbage with three nested for loops.
Re: A comparison of programming languages in economics
#28Two economists judge the relative suitability of a bunch of programming languages.
I have to wonder how it would be received if two computer scientists wrote an article judging the relative merits of a bunch of economic models.
Re: A comparison of programming languages in economics
#29What about Excel?
I know, I'm also horrified of how economists use excel. But it does tend to be their go-to tool, and they are all comfortable in it. It'd be nice to show them just how poor the performance is in excel, to tempt them into learning scripting languages if they have an excel workbook that will barely refresh.
Re: A comparison of programming languages in economics
#30In 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?