I usually do a blog entry a week, but considering that I took a three-month hiatus, I have a massive backlog of information and ideas to convey, so I will likely be doing blog entries for the foreseeable future more frequently than once a week.
The last entry was about looking back, we can often find a model for the future. I pointed out that the dominance of AWS today was matched in the past by the “IBM platform,” and the Berkeley researchers who won the “Risk Revolution” rejected that platform and instead used an emerging and more flexible platform. Related to this was what language they used, something related to our newest Advisory Board member Travis Oliphant, who I will introduce to you later in this entry.
The Tower of Babel
Right around the time that IBM and the East Coast financial institutions were fighting it out with Berkeley and the West Coast groups, a linguistic Babylon had been caused in computer science. Every company that secured a big government or industry contract built proprietary languages to address the contract’s particular needs. There was always an argument for this, but the reality was that all the companies viewed it as a competitive advantage if they could convince their clients to adopt their language. This meant that every large industry or government contract almost inevitably sprouted a new language. This was the very issue that brought the Department of Defense to articulate the Steelman language requirements to eliminate all these linguistic dialects in Defense.
In this linguistic milieu, the “IBM platform” launched its language for financial forecasting. It was a proprietary language that used as a base RPG and was released to the world in 1963. Unfortunately for IBM’s effort to gain stickiness for its new language, their earlier work on Fortran had already gotten out to the masses and the relatively new variant Fortran IV was gaining wider acceptance by the day. Not incidentally, the Berkeleyites used Fortran IV almost exclusively to coordinate their work. Because of the openness and flexibility of Fortran IV, the IBM variant of RPG was relegated to the dust bin of history. So, what can we learn about this today?
Times of Change require Linguistic Flexibility and a broad-based Ability to Create
The IBM RPG variant was a “high-level language” that allowed one to convey very specific ideas with just a few commands. For years there has been an argument that such code allowed end-users to be much more efficient. The world’s IBMs always push this self-serving argument, but it is precisely what is not needed when we have to address complex issues without fixed solutions. So, in times of relative stability, there seems always to be a rise of these proprietary, domain-specific languages, but in times of change, the more flexible languages that facilitate creation seem to ascend. This is an exciting concept when one understands that the markets are getting faster and changing more frequently, with the only constant today being the change.
That was precisely why Fortran IV won in the past period of change. It is also why today, every major financial institution is looking to migrate from proprietary languages such as SAS and MATLAB to open source languages such as R and Python. AQR started it, and others such as JPMorgan and Bank of America followed. That said, there is a smart way to use a language like Python and a foolish way, but that is a discussion topic for a later date. Spoiler alert: most large companies are not using it correctly, but many tech companies like gaming shops are. Follow-up question: Are gaming shops or big banks better known for creativity?
When making this decision, I first came into contact with Travis Oliphant, our newest member of the ULISSES Project Board.
Languages of Creativity and Unifiers
In this blog, I have previously written on computer languages and how they are tools, a concept that I was taught by my mentor Joachim, a former rabbi who was educated in Jerusalem and subsequently taught in Naples. Joachim loved ancient Greek, teaching me that it was a language of creativity that facilitated a vast, flexible empire emerging in the ancient world and that Spanish was a modern language with a similar purpose. He thought this characteristic of Spanish contributed to the magical realism in Spanish literature and allowed the Spanish to rapidly build an empire stretching the world, which he said was destined to fracture much as happened with the Greeks before them (it was not a language of structure or control). In explaining this concept, Joachim told me that a great unifier must emerge for a language to achieve prominence as a lingua franca.
Joachim taught that the unifier creates a body of knowledge that, in essence, defines the structure of the language and a corpus of literature around which disparate individuals can be forged into a people. Such was that case with Homer in Greek, Virgil in Latin, Goethe in German, and Cervantes in Spanish. This unifier who takes upon him or herself this great work and responsibility. It is then from those unifiers that the common structure, phrases, and images emerge—in other words, the “common libraries.”
The Unifier of Python Travis Oliphant and a Base Bigger than Greece
With this perspective, I looked for some great unifier to emerge in the world of “creative computer languages” or a statistical language that could facilitate analysis. None ever appeared with R, but I eventually found one in Travis Oliphant, a former BYU Professor. He took it upon himself to forge a nascent Python into a tool that could facilitate human creativity, specifically in the area of analysis. As an observer of languages, I watched as Travis’ innovations started to pile up. Travis’ initial work at BYU included the foundational libraries NumPy and SciPy. Then when Travis left BYU for Austin, Texas, he architected and co-founded Anaconda, Inc., a company built around a distribution of Python that made the language more accessible, unifying the dialects into a common language for data analysis. Anaconda morphed into Continuum Analytics.
To date, 20 million people were using its packaged libraries and tools to analyze data in ways that were never possible or even contemplated with more rigid tools like SAS, S, R, or Octave. To put that in context, that’s twice as many people in Greece. As I saw this occurring, I had my students switch from R to Python, understanding that as a Cervantes emerging around Python, R would soon be relegated to merely a dialect of analysis. With this perspective, a few years ago, we began taking the corpus of applied finance material that I had accumulated over the past twenty years and transferring it into a set of Python-based Jupyter Notebooks.
It’s a long story how Travis and I met, but suffice it to say that the ULISSES Project and MSCI brought us together, and since that point, Travis has made some meaningful connections for us that you will soon be hearing a lot about. With Travis joining the Board, we now seem to be having a triumvirate of cities emerging on our board, New York, Austin, and Salt Lake. This is something that I will discuss in the next entry.
P.S.
For those of you that have followed this blog, it will not surprise you that Travis received his Ph.D. from the Mayo Clinic, the same place that Homer Warner received his Ph.D. It should also not be a surprise that Travis came to finance from biology, two areas where the technology is continually converging, an idea I discussed last week when I mentioned Lee Hood.