Thank you for your perspective. I think we are 100% on the same page here and take your point. The lack of formal programming for even graduate students is a crisis in the profession. And not just programming, but basic software engineering and numerical analysis principles as well.
Perhaps the only difference is that I see the DSGE oriented stuff as of sufficiently narrow interest that people are better off learning those tools for other sorts of models (and then just let Dynare take care of the basic perturbation solutions) and spend their time learning to program on global solutions/etc. wher there isn’t a package that implements it. But I acknowledge that part of that may be my bias in what are likely to be useful methods for cutting edge research.
These things are also not mutually exclusive: teach people to program a basic perturbation solution, maybe using autodifferentiation as an example, replicate the dynare solution, then tell them to throw out there own code (since using trusted and tested packages is the first rule of software engineering).
That Theodore Gray piece was very good, thanks. The unthinking or uninformed use of tools certainly occurs quite often. In economics, people often use econometric software that has canned routines (e.g., Stata, Gretl, or many others) to estimate models that are wildly inappropriate for their data. This isn’t the fault of the tool, it just means that the student has not learned well, or their program of studies is not getting through to them for some reason. In amateur carpentry, I bet that many people pick up the wrong saw more often than not!
Students are increasingly demanding training in computation and data analysis from graduate programs (and also undergraduate), and I expect that this sort of course will become fairly standard in the next several years. A free language like Julia that runs well on the main operating systems is well positioned to grow within economics.
It was great to read such an interesting discussion on Dynare, where I can agree with almost all sides to a large extent. I can’t resist adding my 2 cents though.
The main goal of empirically oriented subfields of economics (macro, intl macro, finance, trade) is to understand economic data using structural models. This usually involves solving the model, estimating (or calibrating) its parameters, and then (in the ideal case) model criticism to understand its limitations.
The problem is that this the current state of the art for the above requires so methodology that it stretches the limitations of a graduate program, even for students with a macro or related focus. Teaching the very basics of the foundations for numerical linear algebra, first- and higher-order perturbations, global methods, sparse grids, AD, let alone the various practical tools for Bayesian estimation, could easily take 3–5 years. This is a huge investment for what is a very useful, but at the same time very narrowly focused set of skills.
So while black-box can be misused without deeper understanding, it is great that they exist, otherwise teaching macro would become impossible, it is just too overwhelming. What the Julia ecosystem could strive for is a composable set of tools which can be tweaked and modified on demand as necessary.
So what can young people do to advance the field, and advance in the field? Keep pushing less demanding publications, while learning on the side until reaching a productive stage?
Not sure I have good advice on this. I would recommend joining a project with more senior coauthors so that one does not have to learn everything at once. My understanding is that this is quite common in the natural sciences, which have similar methodological demands. But I am aware of the trade-offs regarding career advancement.
Also, I think that that demand for numerically trained quantitative macroeconomists outside academia is very countercyclical. When things are going well, no one really cares, when the next crisis hits then it is “we need estimated structural models about X ASAP”… until it is over and we don’t. But maybe I should not complain, quantitative epidemiologists had it worse before COVID hit.
At least from a pedagogical perspective, perhaps there could be an “Assumptions” flag, like the verbose flag we have for warnings, that autogenerated alerts for students/users on the assumptions being made on the calculation.
This would be moving towards Mathematica-type output, where assumptions are usually coupled with answers. This would be useful for audits as well, if these assumptions were assertible conditions.
Since this thread is about the econ use of Julia, I’d like to take the opportunity to introduce my package SFrontiers.jl which provides commands to estimate stochastic frontier (SF) models. SF models are often used in productivity and efficiency analysis. I just put the package online two days ago and haven’t registered it yet. The web page has a detailed example in Jupyter notebook for easier exploration. Comments and suggestions are welcome.
There are at least two reasons why Julia is particularly useful for estimating SF models.
The parametric versions of the models are almost always estimated by MLE. Because they are highly nonlinear, the estimation is often numerically challenging. Julia’s Optim.jl coupled with ForwardDiff.jl substantially reduces the problem. The coding time is much shorter now and the estimation quality is higher. I used to code in Stata and spent a lot of time getting the analytic forms of gradients and Hessians to assist in the estimation. They really helped. But that’s 20 years ago. It’s not a smart thing to do today when you have Julia.
Simulation-based methods are becoming important in this field. The speed of Julia makes those methods much more practical. I haven’t done a serious benchmarking, but I have seen a maximum simulated likelihood example where a typical (not optimized) Julia code runs more than 10 times faster than a typical Stata code does, and at least 2 or 3 times faster than a quite optimized code (which uses compiled functions).
A lot of effort was put into software engineering tooling, workflows, etc. in this revision.
My personal feeling is that changing people’s workflows to support reproducibility is our most important goal, and the tools can help. To me, the eventual nail in the coffin of matlab is not its speed (it is actually pretty fast in practice since so many algorithms are dominated by linear algebra) nor its clunky syntax (far superior to python in some cases), but rather that it cannot support modern software engineering.
Julia is a great language for reproducibility and collaboration partially because it is new enough that these things (e.g. reproducible environments, CI, unit testing, collaboration workflows, package discovery) were designed in from its inception. So if a student learns these things correctly with julia, they can apply them with R, Python, Stan, etc.
I created a double entry book keeping package, that I’d like to get a point I can register. If I do the same thing with relational database, I should be able to tie to inventory management and track expenses to perform optimization.
Hey all, this classic textbook now has some Julia code (in addition to Fortran-Python-GAUSS).
-They have a YouTube video w/ code performance comparisons
(Seems like their Julia code can be optimized)
Is QuantLib.jl under active development? I was trying to see if I could use it for some basic stuff like USD swaps curve fitting, but some bits are either sale (for example the US business calendars don’t include June 19th) or not ported from upstream (overnight indices like SOFR).
I’m an end user (ie, I’d run a curve fitter to live data streamed from Bloomberg for my trading needs) but I probably don’t have the skills to contribute to the port itself. Happy to help from that end though.
thanks a lot!