Compare all the funcs! - Part 1
Whilst my day job keeps me incredibly busy, I have been looking around for a project to take on in my spare time (not that I have much of that); one that can serve as a long term project . Recently I have been thinking about the commonalities in functional languages. There are a lot of comparisons between functional languages but these often take the form of versus articles, i.e. Rust vs Scala or Haskell vs F#. Another common factor is that these articles are often centered on domain specific features like building an API or querying a persistence store; or a general comparison of low level language constructs and syntax. To my knowledge there aren’t many books, articles or projects that construct real world systems in multiple languages. Maybe this is because in the real world there is seldom the luxury of building the same system in multiple languages to see which one really is the best fit for the job.
Before going on, I would like to put up a disclaimer that I love functional languages, but I have had the privilege and pleasure of getting to know, and coding in, a lot of functional languages. I appreciate these languages for their own merits and I can also acknowledge them for their shortcomings. The hardest thing for me when reading articles and posts in a specific language is that a certain percentage of developers, particularly those new to the language or new to functional programming as a paradigm, seem to focus on that language to the exclusion of all others. While I can appreciate that not everyone has the time or inclination to learn five to six different languages, I have long been a believer that the future of coding belongs to polyglot programmers.
The idea behind this sequence of articles, and open source code repositories, is to build a multipart system that will span a number of application types. Moreover, each part of the system will be built in each of the selected languages:
The journey of building each component in the different languages will be documented to draw comparisons between the languages and, hopefully, highlight the similarities between the languages. To achieve this, features that are very specific to a particular language will try to be avoided and those features that are common functional constructs will be prioritised. The only exception to this rule will be for languages that support higher-kinds and IO, mainly because this will draw an interesting comparison between sub-groups of functional languages. Of course, there are some things that are so specifically embedded in the language that they are unavoidable — the rust memory model for example is very specific to that language and is unavoidable when coding in that language.
The system that I will be building is a automated trading system. This choice is partly because that domain covers many application types but also partly because I have experience in this area. The system will be composed loosely of the following parts:
- Domain model libraries.
- Api to support configuration and components (Rest or GraphQL).
- BI connectors for popular tools like PowerBI and Yellowfin.
- A web/mobile application for updating configuration and viewing artefacts of the trading process like backtest results and live trading results.
- Pricing components to pull tick and candle data from brokers.
- Deal and Order components to execute and monitor trades.
- Valuation components which will evaluate indicators and strategies.
- Backtesting components for testing indicators and strategies on historical data.
- Data science and machine learning components to further refine valuations and backtesting.
To assist in keeping things as consistent as possible between languages, I will be using Nix for reproducible development shells and build processes. Nix is a very large subject in its own right so I will not be discussing in depth within these articles but the code within the open source repositories should give insight into how Nix is used. As a Nix advocate I wholeheartedly hope that, if you are reading this, you search for the many excellent articles and posts regarding the package manager and OS. I will add some links to good Nix articles in the readme for each project for those that are interested in that side of the project.
As a final note and disclaimer, please bear with me if the speed of production of these articles is a little on the slow side.
This article is available in: