Programming Language Wars are Dumb

If you’re a grad student in economics, you’re likely to encounter “language wars” from time to time. There will be folks claiming “Stata is better than R”, “everyone has moved to Python”, and lots of other crazy things. You need to ignore them completely (or as completely as possible - your advisor might have personal preferences). As with most things in life, you shouldn’t devote much energy to strong claims that are not accompanied by strong evidence. Worry about the things you’re paid to do rather than following the latest trends.

Which Language Should You Use?

There are a ton of good options for doing research these days. It’s very different from the state of the field when I started writing my dissertation in the late 1990s. Every option back then was horrific.

Today you have R, Python, Stata, Julia, Matlab, and others. Some, like RATS and SAS, might not get much attention, and they’re definitely not my first choice, but they’ll do the job. It’s important to understand that languages today are often interoperable: R can call Python and Julia, Python and Julia can call R, SAS can call R, and so on. Choosing R, Python, or Julia gives you the functionality of all of three. The notion of “language ecosystem” as the reason for choosing a particular language is outdated.

Programming languages don’t disappear. They do get less attention from bloggers and on social media. If you’re tempted to start looking for a new language, keep in mind that programming languages don’t write papers, they don’t analyze datasets, and they don’t handle hostile referees. Don’t get distracted from your research. By all means, have fun evaluating alternative languages, but keep in mind that it’s a hobby, not something that’s going to help you get tenure.

What You Should Actually Worry About

This is what you should be worried about:

Correctness. Are you writing tests? Are you sure your code is giving you the right answer? Are you sure the libraries you’re calling are doing what you think they are?
Sharing. Especially with coauthors. Be ready to share your code with others once the paper is published. Be ready to hand over all of your files to a coauthor if you get sick. To state the obvious, open source environments like R, Python, and Julia make this easier.
Readability and returnability. How easy is it to read your program? Do you have functions that are hundreds of lines long? If so, break them down into pieces that handle individual parts of the problem. By returnability, I mean the ability to come back to your program after two years and figure out what you did. Your brain will have forgotten everything, so your only option is to read your program. Comments and documentation help, but only if they’re up to date. LLMs have a lot to contribute here.
Replicability. If you submit a paper, you need to have all your files in one place, and when you run the programs, you need them to print out exactly the results you’ve reported in your paper.

Sometimes You Really Should Change Languages

There are times that changing languages is optimal. I made such a change in 2005/2006. My tenure clock was ticking but I dropped GAUSS and moved to R. It turned out to be a great career decision - R allowed me to complete more research as an assistant professor.

Ask yourself these three questions when considering a change:

How well do you know the new language? You need to be sure you’ll get a high return on the investment of your time. You might energetically jump into a new language only to discover dealbreaking problems two months down the road. Or you might realize you’ve been chasing a shiny new object but it hasn’t made you a more productive researcher. That time could have been better spent revising a paper for submission. In my case, I knew the shortcomings of GAUSS, and because I was using R as the language to teach my classes, I knew what it could do. Do realize that times have changed. GAUSS versus R in 2005 is different from R versus Stata in 2026. GAUSS of 2005 (actually, the earlier version I was using at the time) was a primitive language, one step up from using an abacus, so the value proposition of moving to R was obvious. That is not the situation for the languages we’re using today.
Does your current language do the job? If so, you should be cautious about moving away from it. Your career is a business. You need to generate a good return on your time. In my case, it was clear that GAUSS wasn’t doing the job. I had to write functionality that came for free with R. Worse, I found it hard to write code I trusted to be correct because I was writing so much foundational stuff. As I wrote above, we have a good interoperability situation today, so even if your current language doesn’t do something perfectly, you are likely able to call into another language for that part of your project.
Do you enjoy using your current language? One of the reasons I gave up on GAUSS was that I found the language painful to use. Take your socks and shoes off and walk on gravel painful. My advisor told me to use it, and that was honestly the right advice for the time, because it was the primary language economists were using for time series analysis. You could find code on the internet to do unit root tests, cointegration analysis, impulse response function calculations, and so on. By 2005, GAUSS had fallen miles behind R for time series econometrics. I read about R on Chris Sims’s website and realized quickly that he was on to something.

Last updated August 28, 2026