I respectively disagree on Dynare. It isn’t a black box at all… even if the economics of those sorts of models often are.
Dynare itself is an outstanding piece of software, with an enormous amount of testing and engineering embedded in it. Sure, you hit the occasional bug, but nothing like what you would have for custom code (which you might not even notice until someone else tries to replicate your results). Unless you are pushing the limits on what it was designed for, I would trust Dynare’s results over any custom code. Re-implementing dynare features on their own is a distraction that PhD students and practitioners should avoid - to let them focus on interesting underlying economics. Maybe implement a perturbation solution once as practice and then throw out your code.
There is a separate issue though: Dynare is almost too good at what it does! The fact that dynare is so easy to write models may have led people to use DSGE-style models where they aren’t appropriate from an economic perspective, or are leading people down the wrong modeling path because it is a huge effort to break out of its framework. But we can’t blame dynare if PhD students are using it for economic models that don’t make any sense, or they don’t understand how constraining perturbation solutions might actually be… that is the fault of their economics education, not the tool that implements it.
The broader issue with dynare is related: it can’t support cutting-edge methodological concepts in its current Matlab form - and would have limitations even if designed carefully with julia, so for many applications it just can’t help. But for the right economic models that fit into its structure, it is risky to rewrite things.
I believe that all of the work on the Julia side of dynare is in DynareJulia · GitLab My guess is that the direction it will take in Julia is that it will be componentized to whatever extent it can, so that for the cases where you can’t use the full dynare stack, you can write custom code that uses pieces of it.