Why Visi is written in Haskell January 24, 2012
Visi and Visi.Pro started life based on ideas I had when I was working on Apache ESME. One of the key features of ESME, a feature I wrote in a couple of hours 'cause I was bored, was "Actions".
Actions allowed a user to declare what to do with messages that arrived in their timeline. You could filter messages (only show 20% of the messages from my overly chatty co-worker). You could email messages (if it's an @ message to me and it's from my boss, email it and text me.) You could cause arbitrary actions by generating HTTP POST requests to external services based on certain criteria (post to Twitter all messages in my timeline with the #Lift tag.) Actions made ESME different because it allowed a user (not a programmer) to define what to do as stuff flowed into their timeline. ESME was an SAP ecosystem project and we imagined that items in your timeline would include events generated from ERP systems: shipping exceptions, sales events (closed an order, received payment, etc.) and using Actions to manage the events seemed like a really cool idea.
ESME was and is based on Scala and Lift. I do not think ESME could have been written in such a short time with such a small team back in 2008 with any other technology.
I wanted to start an exploratory project within the then incubating ESME project and see what we could do to create an event based system and event-based grammar for defining complex systems. The Apache overlords where not happy with the exploration or the fact that I wanted to explore using Git on GitHub, so I shelved the project, but not the idea.
For the next couple of years, the idea of an "event processor in the cloud that could be managed by anyone" rattled around in my head. I've got pages in notebooks here and there about how the system could work, what the revenue models were, etc. In June 2010, I wrote a complete business plan for a cloud-based event management system. Having revenue from users to pay for the service plus a cut of revenue from data feed providers (a model influenced by Apple's App Store) seemed to make sense. At that time, I envisioned the system was built on Lift and Scala.
I got side-tracked in the summer of 2010 assembling a team and writing a business plan, etc. and I put the cloud event thing on the shelf. I ultimately did not join the team that I assembled and by the time 2011 rolled around, I was up to my eye-balls in family stuff. My wife went away to run a trial for 4 months (she won $310M for her client) and my mom passed away. Sometime in the Spring on 2011, I bought an iPad for the kids so they could watch Sponge Bob and other stuff on the flights down to visit my wife in Southern California.
The iPad changed my world-view on computing devices. The iPad is, in my mind, the first material change in the way people use computing devices since the Apple ][. Everything between the Apple ][ (the IBM PC, the Mac, laptops, netbooks, etc.) were incremental advanced on the technology that preceded them. But the iPad was different.
It was in May, after I had spent a week with an iPad and no other computing device, that I realized that PCs and the Web were legacy. This isn't "disappear tomorrow" legacy. This is "in 15 years, most people will not starting new web app project" legacy. Just like client-server is legacy, but there's still plenty of Windows-specific client-server code being written.
It was in May that I added "and a client component that runs on the iPad and iPhone" to my "event processor in the cloud" idea. Having a client component, a beautiful, rich, interactive, tactile, wondrous client component because the driving force in my thinking. Chatting with folks like my friend Bill Fernandez (Bill also did some amazing work on ESME) about the idea drove my thinking to making a programming system like HyperCard that was useable by lots of people. Given my spreadsheet background, especially my real-time spreadsheet background, gave rise to ideas around how to imagine a language for describing event processing and user interactions and such. Those ideas crystalized into Visi and Visi.Pro.
One of the gating factors with iOS, the operating system on iPad and iPhone, is that there's no JVM or anything JVM-like. There's only native code (well, there's LLVM as well, but the Scala-LLVM project is not that far along.) So my choices of language for the project were reduced to things that compiled to native code. I no longer have interest in manually managing memory and I like functional programming... it's how my mind has been re-wired. Plus, I'm a statically typed kind of guy... that meant that my language choices boiled down to OCaml and Haskell. Both had ARM cross-compilers and both were mature languages with mature ecosystems. Sadly, because Scala is still the language I'm most comfortable with and the language I'm most productive in, I could not use Scala for Visi.
OCaml is arguably the easier choice for Visi. It's conceptually a lot closer to Scala than is Haskell. The iOS cross-compilation tools for OCaml are much more mature than those for Haskell (although Stephen Blackheath's GHC-iPhone is coming along very nicely.) Interacting between OCaml and ObjC is much easier than any Haskell/ObjC bridge. Unfortunately, as many times as I try and as much excellent encouragement I get from Paul Snively, I just can't get into OCaml. I don't know why and it's purely subjective and it's probably something broken in my brain... but OCaml always feels like an ill-fitting scratchy wool sweater to me. This is not meant as a criticism of OCaml, but I don't like eating brussel sprouts either... it's just a taste thing.
So, that left Haskell for me. Haskell has some really helpful stuff. The Haskell parser-combinator library is excellent and mature... helpful for writing a language. Haskell's runtime is amazing in the way that computations (threads) can be suspended nearly costlessly. This makes as lot of the stuff in Visi easy to write... basically some of the computation logic (including laziness) is already built into Haskell, so rather than writing a lot of the pieces myself, I get them for free. The cost with Haskell is that pure, lazy, monadic is hard and slow and long-slogging (although it's proved remarkably solid.)
I revisited the Haskell vs. OCaml decision last week because Paul kindly spent a lot of time discussing the strengths of each language/runtime. But at the end of the day, Haskell keeps proving itself the right choice for Visi.
I hope that going through the history of Visi and Visi.Pro and the choices I made in the system and in the tools will help folks understand why Haskell (okay, there's no compelling Haskell vs. OCaml argument that I've made) and more importantly why the choice of platform dictated a language choice other than the language I am most comfortable in: Scala. Put another way, this is the first time since I wrote Mesa in Objective-C and C++ that I was not serially monogamous with a language. ;-)