So now back, to our version of “In Search of…” with your host, the guy who planned on studying with Umberto Eco and got Fisher Black’s files instead. On that last comment, I would have much preferred speaking with Fisher Black himself, but short of Houdini’s Séance Room, I was stuck with only a stack of correspondence with Fisher that was turned over to me when I arrived on Columbia’s campus in the Summer of ’95. To my great disappointment, after I had read everything and asked to talk to him, I was informed that he had passed away, literally days before. First Eco, then Black. It was as if I was cursed. Columbia was turning out exactly as I didn’t plan it. That said, to put this in context, I should explain something else.
Steve Jobs and NeXT Improv(isation)
I received my bachelor’s degree at Brigham Young University (BYU), a place that had cultivated a fascination with languages in me that had been started by my great teachers in Italy studying Dante. It was at BYU where I had continued my Dante studies, and it was also there where I worked with the head of the Statistics Department in one of the only NeXT Computer Labs in the world (Steve Jobs had “seeded” academia with a dozen such labs, BYU being one of them). While I had pretty much been obsessed over Turbo Pascal (followed by Turbo C) and my personal hero had always been Philippe Kahn rather than Steve Jobs (sorry Jobs fanboys, but this guy could really code…kind of like Woz and Jobs in one), I was intrigued by Jobs’ NeXT, and its integrated object-oriented structure and as a result, I really dug in. Basically, every spare moment I had for a year, I either had my nose in Dante or my rear in front of a NeXT.
For my first year after returning from Italy, in my “spare time,” I pretty much lived in that lab and tried to code a new “object-oriented” investment research system that worked. As it turned out, pretty much every research group on Wall Street was doing the same thing, entranced by “the Jobs factor.” These efforts were centered around Lotus Improv, Mathematica, and Database Integration. While I could easily code up Black-Scholes options trading systems and “simple things” like that, I quickly discovered, Jobs without Woz, was really not something to bet on in a start-up. I tried everything, cobbling together additional technologies but by 1992 my tests proved it would never be possible to build a proper research platform with Improv, Mathematica, or any other reasonable combination of tools on the NeXT. Keep in mind, in the lab I had millions of dollars worth of tools that Jobs had donated–pretty much whatever NeXT or its partners had. After banging my head against a wall for a year, I finally gave up and decided that I needed something else and so I started looking for a new platform.
The Lessons from the NeXT Lab
That said, my time on the NeXT was not a waste. There was all I learned about architecture and then there was Kozy Boren and his investment portfolio (a story I will tell later), something that funded my own lab when I was at Columbia. In short, my time spent in the NeXT lab was an investment that continued to pay dividends for a long time. To start, I loved and came to appreciate the Object-Oriented Architecture and I was able to experiment in a “toy way” on how I wanted my data to be structured to accommodate financial modeling. As a result, when I finally settled on SAS and relational databases, I pretty much knew where to start with organizing my Compustat, CRSP, ValueLine, and hand-collected sell-side forecast information.
I short, instead of being in front of sleek black cubes with colorful displays, I spent my next year in front of terminals running SAS which, I then ported to a PC version connected to PC versions of databases before I left for Columbia. By the time I arrived at Columbia, I had a working model at home that I could keep evolving while I studied. It was that model that eventually landed me a lead article in The Journal of Finance, but more importantly, it got me my first job (where the model was implemented in a $20 billion macro portfolio).
SAS as a Working Solution in Transition
These SAS-based systems were what I coded everything at Columbia and every firm that I was asked to rebuild systems for years, but I always kept my eye on new language developments and used them for what was appropriate. For example, when we needed really fast code for trading, we did that code in C, or when we needed to data munge, we used Perl. No surprise, the right tool for the right problem. This said, I always used SAS as my core, even in areas such as matrix manipulation (IML) but especially to interact with my relational databases (the versions of which evolved over the years).
My SAS malaise continued for years, but over time, I started to notice that what I’d used as “satellite” code around my core started to become more and more Python, so I finally switched exclusively to Python for a scripting language to interact with the core. This said, I found that Python could increasingly and more effectively substitute for my core language. I also found that my core was increasingly lagging and there were certain things we simply could not do. Like I said, for my purposes, I did attempt to fully switch to Python but, I just found it too slow and always a bit “clunky.” This brought me to my partner Hal and my solution for core code (it’s really his solution more than mine), something which we call the Argento framework, but that’s more of a code name. I will leave that discussion for the last installment of this session of “In Search of…” because I will now discuss Python and it’s sudden emergence in FinTech.
The Ascent of Python in FinTech
Python was always an exciting language, but it never really had the mathematical chops required as a proper dev language until three distinct things happened. First, some researchers started working on some math code that was to form the foundation NumPy and SciPy, with no one being more central than BYU’s Travis Oliphant (yes, it all started in Utah). Second, AQR (a quant hedge fund) began a project of consolidating all their SAS, R, and Matlab code into Python. As a result, AQR acted as a hotbed for the development of the Pandas library (basically a port from R). In this case, it was Wes McKinney that was the leading player (with all due respect to Clint Asness). Third, simple and easy distributions of Python were made available to the world via the Anaconda distribution (again thanks mainly to the work of BYU’s Travis Oliphant, who had left to start his open-source masterpiece, Anaconda). In short, while the projects were open-source and had many contributors, it was Travis and Wes that really laid the groundwork for Python to become ubiquitous in FinTech. This was because the world was hungry for a more general-purpose language than R, which could do what SAS, R, and Matlab could do. That said, that is where all the problems came in.
Don’t get me wrong. I love Python, and even more, I love Cleese and crew, but as I’ve already pointed out, there are some things that Python just isn’t the right tool for. Simply stated, Python is not a universal solution. However, it was soon treated in FinTech as if it were. That is why CTOs at bulge bracket banks all started trying to port whatever crucial code they had to Python, something that has resulted in unmitigated clusters in the world of finance. As I already stated, billion-dollar Python projects are de rigueur, with not one paying off. Now this works for the consultants, but not for the firms.
Question: Why Does my Building Keep Falling Down?
This Python problem has led to what I call “FinTech’s Bizarre Bazaar,” or “Why does my building keep falling down?” The answer is that “your building” is a tent. It’s quick to set up in the Bazaar, and easy to move, but not optimal as a permanent structure. It is unwise to persist doing something that doesn’t work, it is insane to do so with things that can have catastrophic consequences like in nuclear weapons, or running the stock market. People have slowly started to figure this out with their “Python migrations.” To be clear, I still view Python as a necessary research language, kind of like JavaScript for web pages, but it’s not something that we will ever use for “permanent structures.”
So why has no one gone back to the drawing board with SLANG? After all, Goldman started making SecDB available to the world via Marquee, but there have not really been that many takers. That is because the language optimized to work with it, SLANG, “stopped working.” In short, Goldman’s offer was not unlike the offer that my corner bottega Beni’s made with old H&H’s.
So where does that leave us in pursuit of our Perfect Language? We will explore this in my next entry.
2 Replies to “In Search of the Perfect Language, Part 2 – FinTech’s Bizarre Bazaar”