Why Clojure?

Ronny Li
CTO
October 14, 2021
Engineering
Thoughts

We are not unique in our choice to use Clojure. Please check out a list of similar pieces at the bottom of this article.

Our decision to go with Clojure happened by accident. Unlike most companies that use a niche technology, the founders had never even heard of Clojure before, much less had any experience with it. While only time will tell if this choice was truly a good one, so far the benefits have been greater than we expected and the cons (heh) have been smaller.

History

  • We originally wanted to build Composer on top of the Python library bt. We loved how the strategies were composable and both Ben and Ronny are really comfortable in Python. Unfortunately, bt had two serious flaws:
    • Extremely slow for slightly complex strategies. Some would take 10 minutes to run and then crash.
    • You could run the same backtest on the same data and get slightly different results, which made absolutely no sense and eroded all trust we had in the library.
  • We decided to build our own backtesting engine, which meant we could write it in any language. Java and C++ were the first to come to mind since they are heavily used in the finance space.
  • In parallel, we were building the frontend. Ronny's average Javascript skills had produced horrible spaghetti code within a few days. State management was a mess. Redux was the "solution."
  • Ronny is panicking regarding finding an excellent Javascript developer who wouldn't make the same mistakes. Even a great developer might just be delaying the inevitable. They would have to be incredibly experienced to know what they shouldn't do and to avoid jumping on every shiny new bandwagon.
    • At this time, Composer had no reputation and little money. We were most likely going to find an average JS developer.
    • We even experimented with a no-code frontend, which unfortunately didn't work out.
  • Ronny re-reads an old Joel Spolsky article on identifying excellent developers, taking him to an even older Paul Graham article on Common Lisp.
  • Ronny reads that Figma's WebAssembly stack allows them to write frontend code without Javascript. Starts investigating other languages that do the same.
  • At the same time, Ben is doing research on other Common Lisp companies and the results are pretty disappointing. He stumbles on a Paul Graham tweet that updates the recommendation to use Clojure instead.

Our Requirements

On the backend side we care more about accuracy than raw speed (~100ms per backtest is good enough for us). For this reason, we place heavy emphasis on unit testing to make sure our backtesting engine doesn't have the same issues as bt. Pure functions are incredibly easy to unit test. We rarely have to mock anything and there's no boilerplate.

On the frontend side, we were looking for an opinionated language that was designed to prevent spaghetti code. Clojure's emphasis on immutability and pure functions mean that it's very easy to follow the chain of events leading to a bug (it is also easy to refactor). This is possible to do in Javascript but requires a level of self-discipline that would be difficult to scale.

Clojure effortlessly straddles both backend and frontend. Using a single language would allow our engineers to flow between the two functions as needed, eliminating unnecessary overhead.

Our biggest risk was, and is, hiring but we concluded that companies at our stage should focus on minimizing false positives over reducing false negatives.

Around July 2020, we decided to take the plunge.

Surprises

  • Experienced engineers with a love of functional programming will come to you! It turns out, people want to spend most of their time doing something they enjoy 🙂
  • Clojure engineers are 5-10x more productive so a tiny team of 2 is at least equivalent to 10!
  • Clojure enthusiasts are willing to walk off the beaten path. Most did not choose Clojure for economic reasons. They genuinely enjoy programming and expanding their horizons.

Similar Articles

https://www.reactiongifs.us/wp-content/uploads/2013/08/dozens_of_us_arrested_development.gif

Common themes

If you read the above articles you'll notice the following patterns:

  • An emphasis on simplicity, which means your codebase is easy to learn and easy to remember.
  • Concise code without sacrificing readability, which means it's easier to learn and maintain.
  • Consistent syntax, which - once again - means it's easy to learn.
  • Did I already mention easy to learn?
  • Powerful. In fact, many existing languages and frameworks are still trying to incorporate features already in Lisp/Clojure.
  • Stable

If you're interested learning Clojure or you're already a fan, check out our Careers page or reach out to me directly at ronny@investcomposer.com!

Important Disclosures

Investing in securities involves risks, including the risk of loss, including principal. Composer Technologies Inc., is an SEC Registered RIA. The SEC has not approved this message.

Certain information contained in here has been obtained from third-party sources. While taken from sources believed to be reliable, Composer has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; Composer has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, as it was prepared without regard to any specific objectives, or financial circumstances, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not intended as a recommendation to purchase or sell any security and performance of certain hypothetical scenarios described herein is not necessarily indicative of actual results. Any investments referred to, or described are not representative of all investments in strategies managed by Composer, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see Composer's Legal Page for additional important information.
Composer is a registered investment advisor with the US Securities and Exchange Commission (SEC). While such registration does not imply a certain level of skill, it does require us to follow federal regulations that protect you, the investor. By law, we must provide investment advice that is in the best interest of our client.

With any investment, your capital is at risk. The value of your portfolio with Composer can go down as well as up. Past performance is no guarantee of future results.

For further details see our Legal Disclosures. By using this website, you accept our Terms of Service and Privacy Policy.