4 ms·
I was an economist doing econometrics in excel when in 2014 the datasets went being a few 10,000's rows to a few 1,000,000's rows. I found R easiest to learn as
by nomilk 4y ago
I was an economist doing econometrics in excel when in 2014 the datasets went being a few 10,000's rows to a few 1,000,000's rows. I found R easiest to learn as a CS outsider because it was less strict about package versions and installation requirements, which made it easier for a beginner to setup and get going. I learned it by googling every little step ('how read in csv', 'how create new column in data.frame' etc) until I had a ~40 line R script that did what I was previously doing by hand in excel. It ran in a few seconds and did what took excel about 10 minutes.
A few years later I wrote an open source economics library in R: https://github.com/stevecondylios/priceR#pricer- https://github.com/stevecondylios/priceR#pricer- It converts between nominal and real prices, converts between 171 currencies, and has a few regex's for pulling numeric data out of text (e.g. salaries out of job descriptions).
Some specific observations regarding the article:
- Comparing computation speed seems a bizarre metric to care about. 6x faster matters on things that take minutes, hours or days, but less so for operations that already run in under 1000ms. Developer experience is usually more important IME.
- The article mentions R library support is superior (which may or may not be true), but it would nice to see the most useful highly-regarded libraries from each language reviewed, or at least mentioned.
- The statement "(Julia) does not have any historical baggage" seems odd since a language doesn't need to be old before people find problems with it. Example from recent HN post: https://yuri.is/not-julia/ https://yuri.is/not-julia/
- y_lin 4y agoComputation speed is only one of many criteria. It can be important. We have R code that takes hours to run, and for another paper it takes 5 minutes for the R code every time we change something. Speed is certainly important but not the only criteria. I agree, it would certainly be useful to compare the most useful libraries, for economists dynlm is fantastic in R. But we only have so many words in blog piece like this, and we didn’t have space I stand by the historical baggage. If you compare R (and the others) to Julia, there are so many bizarre and inconsistent language features they carry with them. Julia doesn’t have a lot, it might have made bad design decisions as Yuri argues, but it’s not historical baggage.
- nomilk 4y ago5 minutes for every change definitely justifies language/library selection based on optimising for compute time. I do operations that are nowdays computationally trivial, for example, tinkering with model specifications, which, even for rows in the millions, typically takes <1 second of compute time. A typical workflow would involve minutes/hours of wrangling, minutes/hours of model spec, and perhaps only a small number of minutes actually waiting for computation to complete. With some exceptions, of course. Btw thanks for a very interesting take on a generally neglected topic (language choice for economists). I hope you do more and deeper discussion on this as I think a lot of economists never make it to open source and get stuck using whatever they learned in university (eviews or spss).