The entry today is done in homage to the great scholar Umberto Eco and his masterful work The Search for the Perfect Language in the Making of Europe Series (I actually have a signed copy in my office) and Spock (or rather the guy who played Spock in Star Trek TOS, Leonard Nimoy) who had an awesome show when I was a kid called “In Search Of…” in which he went “In Search of…” Big Foot, Dracula, and things like UFOs. I loved Spock, and for reference, I commonly call my best friend Hal, Spock. So with that said, let’s discuss computer languages as they relate to the ULISSES Project.
Before starting, not to be obscure, the reason I’m structuring this discussion as an “In Search of..” rather than Eco’s “The Search for…” is that just like the show, the fun was in the ride and bluntly (spoiler) there is no perfect language, we just have Turing complete languages that aid us in specific contexts either by their underlying design, associated libraries or integration possibility. I’m the furthest thing from a zealot in this regard. So on with the narrative.
Linguistic Learning by Doing
Today I had a conversation with a student that really brought home how much the current generation of researchers’ general knowledge of computer languages is lacking. To put this in context, the student I speak of was studying computer science and was not your average student, having received numerous early offers to work with some of the best tech firms. This not taking anything away from the CS student who came to talk to me, but when he said he knew a language, I found that he just knew certain libraries and not even why one would use one language over another. It was a little like talking to someone who had studied tools, but didn’t know how to build anything with them.
So in deference of the old “when I was your age,” I will state instead “when I was a kid…” we grew up with the evolution of computer languages, with everyone knowing BASIC and those defined as jocks knowing things like machine code, C and more commonly deployed languages such as Fortran IV. You didn’t ask the jocks if they knew a language, but if given the opportunity and the desire they could pick it up. By the time I and my confreres got in college, fourth-generation languages such as SAS and Matlab were really just starting to catch on. We then saw the transition from these proprietary, special-purpose languages to open-source, more flexible scripting languages with large special-purpose libraries, specifically seeing the rise of R (sorry Octave) and now Python. The simple fact is that students today have not had the benefit of seeing these changes, and in general, I believe this is a problem that should be addressed in our university curriculum.
Languages as Teaching Tools
My own introduction to computer languages started with Fortran. It then went “back and forth” to machine code and things like BASIC and Pascal, the latter of which really came alive to me via Borland’s masterful implementation in Turbo Pascal. Those lower-level languages were immensely useful in helping me learn things like algorithms and recursive structures, ideas that are taught today in a much more theoretical manner. This is a shame because while I think there is quite a bit that can be learned by figuring out the hard way how to do something. I guess in that sense, except for those rare few, I think that little can be gained by studying “linguistics.” I am and always have been a firm believer in “learning by doing.”
My analogy is that while many years ago, there were people in my “entering class,” venturing into Italy who had studied Italian and got great marks in class, those that truly mastered the language were those that really engaged with the people, learned to love communicating, and pushed themselves into new domains. For example, while several of my companions could understand me reading Martin Mystere fumetti after three hours of intensive language study a day, precious few understood why I would follow that with Il Sole 24 Ore (basically the Italian version of The Financial Times). Incidentally, those few who pushed themselves were also the people that came to understand that certain things could be conveyed in Italian, which really couldn’t be easily expressed in English. Thus, the old Italian saying, “tradurre e’ tradire” (or to paraphrase “to translate is to betray”), something that anyone who has ever tried to translate Dante’s Divine Comedy into English immediately comes to know. Now, this brings me to a topic dear to my heart—what is the proper use of languages?
The Right Tool for the Right Problem
My confrere Hal likes to repeat that “as long as a language is Turing complete…” (fill in the blank), with the main gist being that I sometimes obsess about languages a bit much. This said Hal is often the first person that will bring up the fact that some languages are better for some tasks than others. In other words, they are tools, but I’d add languages are specific tools that actually change the way we look at the world. With this concession, I will borrow a metaphor from ESR, that of the Cathedral and the Bazaar. In short, this metaphor was used by ESR to explain the benefit of bottom-up open-source efforts versus top-down proprietary efforts, specifically discussing operating systems. I would like to extend his metaphor to languages.
There is no doubt that Python has become one of the most beloved and used languages in the world, after all, who couldn’t love a language named after one of the greatest comedy troupes of all time? This said, at its core, Python is a scripting language that facilitates quick and dirty construction, much like ESR spoke of open source being like a Bazaar that could be thrown up with tents very rapidly to accommodate what the market wants. This is in contrast to something done with the watchful eye of a Grand Architect (props to the Masons) directing the work form the top down (these languages are typically referred to as system programming languages). The prototypical language with this structure was and continues to be Ada, a language dutifully sculpted by the great language architect Jean Ichbiah which came about in the Department of Defense’s (DOD) High Order Language Working Group (HOLWG) and its ever-escalating strawman to Steelman language requirements. In short, the DOD understood that with Jets and nuclear bombs, it’s best to have a reliable structure because an error could genuinely be catastrophic.
Columbia, Fisher Black, and Proto-SLANG
With this in mind, I will go back to my initial days at Columbia, working on some cutting-edge technology for finance. While Columbia had wooed me with the offer to work on projects with big banks and studying with Umberto Eco on the side when I did my dissertation, I was shocked how connected the two would eventually prove to be. While my plan to study with Eco was disrupted with his sudden cancellation literally days before Fall began, my pursuit of “the Perfect Language” went on in another way completely unanticipated and it all started when I had a pack of correspondence turned over to me between Fischer Black and certain Columbia faculty.
It is important to note that the legendary Fischer Black was a bit more than just a finance jock, he was also a computer science Ph.D. who was well-schooled in language design and loved his Nintendo Gameboy. In other words, Black was a nerd Renaissance Man. In the Fisher Black documents turned over to me (that I was told absolutely not to photocopy…something I wish I had not complied with), Black had quite clearly laid out his own Steelman language requirements, having done so in such a detailed manner that even after his death, SLANG (or Securities LANGugage) could be developed and implemented by Goldman Sachs. Keep in mind, this is something that not only made Goldman one of the most successful financial companies in the days of its implementation but years later, it also helped Goldman navigate the Financial Crisis. So, if SLANG, arguably one of the most successful domain-specific languages in history, was much more similar in spirit to Ada than Python, then why is the investment industry rushing to rewrite their core code in Python?
Python and AWS, Special-purpose & Dev Tools
Call it a collective delusion or a massive echo chamber. If anything works in finance, you find that everyone talks about it. Add to that some early evangelists that used to work for Goldman who knew that SLANG had an Achilles heel and they then incorrectly extrapolated from the problems and applied it to other systems’ programming languages and they simply were not good enough computer scientists to know the inherent problems that existed in Python that would practically never be overcome. For reference here is a graph presented by one of the best researchers in parallel processing showing how truly slow Python is at processing information, and speed is important in finance.
This is how much faster we can speed up Python–over 60,000 times (that’s not percent…that’s times!) for Matrix operations…a staple in finance. That leaves a lot of time that people can trade ahead of you if you’re using Python. That is something that I will have to leave for a later entry, but suffice it to say that it’s one of the reasons that several massive financial firms have done billion-dollar implementations around Python, and not one was turned out as envisioned. It’s best for prototyping or for interacting with stable systems like they do in the Gaming Industry (yet one more thing to learn from Gaming).
The more one thinks of building large scale stable systems with Python, the more one realizes that that whole idea is kind of like the collective delusion around AWS. AWS is great for rapid prototyping (dev work) but horrible once you know what you’re doing (prod). This is something that most firms don’t figure out until they migrate fully to AWS and get their first bill. When that happens, you almost immediately find it’s a lot more money than it would cost you to do it differently. That’s what companies like Walmart and people like me, both earlier adopters of AWS, found.
When I was at the Emerging Markets hedge fund where I was testing systems and doing joint development with Bloomberg on a novel optimization routine, AWS was great for getting things up fast, but once I pushed the limits and got my first bill, I was horrified. Other than the latency (which was unmanageable for my application), it was still a lot of money, made even worse by the fact that the servers couldn’t do what I wanted to do. Bloomberg was smart and did it on their own boxes from the beginning.
With that said, we will have to discuss the Bizarre Bazaar of FinTech next time.