Ignoring the (fantastic) content, I think this is how Julia slowly wins users. I keep find myself doing parallel implementations like this.

Agreed, amazing content but also a great tutorial for Julia. This is my first stab at it and it's great (as a daily R user).

Sorry, guys, there's an unfortunate pattern:

In parts of applied math for business, there are lot of talks and papers of the form "Problem X: A Y Approach".

That seems to suggest that there is something really promising about Y. Instead, more appropriate would be "Solving Problem X". If Y was involved, then fine; if not, still fine; that Y was involved really doesn't mean much.

Then also in computing there are talks and papers of the form "Problem X via Programming Tools A and B". So, for the part "A and B", can substitute Python and Julia, Fortran, C and C++, C# and C, C# and C++, C# and Visual Basic, Common Lisp, anything Turing equivalent, etc.

To me Quantitative Economic Modeling is a big enough subject and quite challenging. That some of the computing was done in Python and Julia instead of C, C++, C#, Fortran, Algol, Folderol, etc. strikes me as nearly irrelevant. That is, I see nothing about Python and Julia that promises especially good results on the main challenges of the very challenging problem of Quantitative Economic Modeling.

Where am I going wrong?

> Where am I going wrong?

I don't think the goal of the site is to solve the problem of, or even serve as a textbook for, "Quantitative Economic Modeling."

Each chapter presents a popular model that most academic economists are already familiar with and shows, in a practical way, how to implement the models in Python and Julia. I see it more as a resource for economists to learn to program than an an economic theory text.

Good answer. Thanks.

"Solving Problem X" is not an exciting headline if the community is aware that Problem X has already been solved. The point is that the community may not be aware that tool/approach Y can solve problem X, and might want to see how it is done, to learn about Y, and consider how Y is better/worse than existing tools/approaches.

Good. Thanks.

In addition to the other answers you've gotten (which I agree with and are probably more important than this one) the same advantages that are normally given for working interactively with a REPL apply to scientific computing in economics, probably more than in most fields. (Programming efficiency becomes more important relative to computational efficiency when you're only going to run the program once.) Both Julia and Python are easier to work with interactively than C and Fortran.

>Both Julia and Python are easier to work with interactively than C and Fortran.

Especially considering the people this is targeted at have a weak programming background.

There are entire companies, many worth well into the hundreds of millions, built around dynamic languages. The notion that they can't scale to enterprise-grade application quality is a vestigial exhortation of a bygone era of pedanticism, perpetuated by nerds who saw 'barriers to entry' (obtuse language design) as a way to artificially inflate their own stature. Don't drink the Kool-Aid.