In 2014 Aruoba and Fernández-Villaverde published A Comparison of programming languages in (macro)economics (official Elsevier link here, codes on GitHub, recently updated computations here). The article also mentions QuantEcon in [5]. Both Python and Julia were included in the review.
There, the authors announced a follow-up titled “Functional Programming in Economics” [1] where (more purely) functional languages would be discussed. As far as I could see, this article did not appear (yet). Of course I could try to send an email to the authors - and perhaps I will - but I would also appreciate your opinions very much.
For definiteness, let us restrict ourselves to discrete-time (deterministic or stochastic) dynamical systems such as those studied in Stachurski’s “Economic Dynamics”. Apart from the clear scarcity of purely functional software libraries, is there a fundamental reason why a functional language would not be well suited for this context, or is this indeed a very practical matter: Presently, the role of such languages in numerical computation as a whole is simply too marginal?
My question is not meant as any form of criticism, nor do I want to start a pointless “which language / paradigm is better” discussion. Indeed, like many others I hold QuantEcon in high regard. Yet, it seems to me that features such as function composition, currying and higher-order functions could allow for a very natural translation from mathematics to software in the specific field of discrete dynamical systems, perhaps even more so when considering their actions on metric spaces consisting of functions (or: measures) themselves.
I hope this thread does not take us too far off-topic. In any case I thank you very much in advance for your insights. They are much appreciated!
There is a difference between pure functional software, and a “functional-style”. I think that tpapp (Tamas K. Papp) · GitHub did a bunch of stuff with common lisp, but he moved to julia. Doing things in lisp, haskell, etc. is too much of a pain in the ass (revealed preferences abound) for doing what we do on a large scale. But… using functional-style is a completely different story, and something that works will in Julia. In fact, it is one of the main reasons Jesus likes Julia.
Couldn’t agree more (although currying may be more trouble than it is worth in many languages). But I don’t think you need a true functional programming language to do it.
Yes, I understand. Julia - and even Python, although perhaps to a lesser extent? - offer the possibility of writing in a functional style, but the languages do not enforce it and also omit - probably after careful design considerations - certain functional constructs. Following the 2014 article by Aruoba and Fernández-Villaverde, I was really wondering about more purely functional languages, such as:
This is the core of my question. Without wishing to be a pain in the ass myself, I would like to ask: Why would that be?
My challenge to you. Go to a potential coauthor in economics and (1) try to explain why using Monads are in haskell and Maybe and Just; (2) describe to them why they are a perfectly reasonable alternative to simple for-loops with input-output that the potential coauthor is used to doing when they write code; and (3) see if they are willing to write code with you on a project…
I have seen economists use and contribute to the development of beautiful abstractions in various branches of mathematics, so I myself would not underestimate their ability to do the same in computer science.
Thank you. I do not know enough about CL to make strong statements about this work, but isn’t CLOS precisely meant to extend the language’s object-oriented - and not so much its functional - capabilities?
In any case, thank you for your responses so far. As I said in my initial post, what really got me thinking about this is the curiously missing sequel to the 2014 article I cited. Perhaps I will indeed ask the authors about their particular reasons for this.
Certainly no “pure” functional programming languages there, for all the reasons of practicality you can imagine.
Of course there are many people who could handle and contribute to it, and you may be one of them! The problem is that the sort of computing you were talking about (discrete dynamical systems) is about using existing (but potentially bleeding edge) frameworks rather than making contributions to computer science… (although there are those applications in economics, the connection is more to theoretical computer science/algorithmic game theory).
If you are doing the type of research that requires network effects for coauthors and RAs and reuse of libraries, then going with pure functional languages is a tough equilibrium to live in. If you are doing stuff for yourself which can exist largely autarkically, doesn’t require many libraries to use, and won’t require people after you to read, then go ahead and use Haskell!
Alternatively… just use all of the awesome functional programming tricks you can inside of more mainstream libraries with lots of users and lots of packages, and you get (most) of the best of both worlds. Maybe you can’t use as much currying as you would like, but it is a step forward.
Yes, I gave that link in my initial post. Indeed, it contains updated test computations in the (not (purely) functional) languages from the 2014 article.
Yes, there clearly is a trade-off between the appeal of a purely functional language on the one hand and the popularity and availability of third-party libraries on the other hand. This is something I am carefully considering at the moment.