The Real Power Behind the Curtain (WhatsApp Edition)?

By now, you probably heard all about Facebook's $16B acquisition of WhatsApp. To put that in perspective, that is more than the total GDP of hundreds countries such as the likes of Iceland and ~30% the market cap of GM or ~10% that of Facebook itself. Consider how it was just a few years ago when Oracle bought the former behemoth Sun Microsystems (whose former campus is now Facebook's) for $7.4B in 2010. An interesting tidbit is behind the curtain is a modern, low-latency messaging backend powered by Erlang, a functional language optimized for concurrency and availability, which originally gained a following in the telecom community, especially from the likes of Ericsson. This is what ultimately powers the slick, reliable user experience of the messaging system that serves hundreds of millions around the world. Rick Reed, one of the engineers at Whatsapp, gave a talk on the use of Erlang at Whatsapp. One specialty of Erlang, which is also used by Facebook itself, is hot sliding, a kind of on-the-fly code module loading to enabling updating a system and pushing code without ever taking the system down.

Experimental Human Factors Take on Functional Programming

As a functional programmer, one often takes the productivity advantages of functional programming as an article of faith: Versus imperative and object-oriented counterparts, functional programs must be shorter, more robust, quicker to develop, and easier to maintain. Designers of programming languages and compilers harp on the supposed benefits of their languages and implementations. But when it comes down to it, where is the evidence? There is admittedly a lot of problems when forming a rigorous question and experiment to compare languages. An empirical study is even more difficult because there are really few large software systems that are implemented equivalently in multiple languages. Still, there turns out to be a few studies on the productivity and usability side of functional languages and mixed paradigm languages (e.g., Pankratius et al's "On the Benefits of Combining Functional and Imperative Programming for Multicore Software"). The results appear to be quite consistent: functional programs are shorter but they aren't any quicker to develop for even relatively skilled programmers. Performance is generally found to be on par. Moreover, fancy type systems have the disadvantage in that they could complicate the programmer's understanding of the program and prolong the debugging process.

High-Level Programming Languages for Embedded Systems: Garbage Collection and FPGAs

Just when it looked like the big guys (well, basically Apple, that big chunk of the NASDAQ) were moving away from tracing garbage collectors, researchers from IBM Research has taken the leap to bring garbage collection to FPGAs [PDF]. Though hardware-assisted garbage collection isn't new, this degree of implementation of a complete concurrent garbage collector on an FPGA is. The authors consider this a first step in bringing high-level languages to the FPGA and embedded computing realm. It should be interesting to see where this goes.

What is the ML Module System?, Part 1

Browsing through the heated Scala mail list discussion from 2009 on OOP versus functional programming, I ran into a number of messages which indicate some confusion as to the role and mechanism of the ML module system. The natural question that was raised is how is a module system different from a "low-level" object system. I am not entirely sure what a "low-level" object system is but in this post I would like to compare and contrast the ML module system and object systems, principally class-based object system but also classless object systems. First, what role do these language features serve? There is some overlap in purpose but also significant differences. The ML module system was originally designed to serve to roles:

1. To support programming-in-the-large organization of large system architecture
2. To facilitate the construction of a type-safe container library

In contrast, OOP is typically defined as supporting design goals of encapsulation, inheritance, and subtype polymorphism. On the surface, this suggests some overlap. Programming-in-the-large may sound like encapsulation, but as I will discuss, the reality is considerably more nuanced.

Functional Languages and Call-By-Value, Part 1

A whole lot of work goes into avoiding unnecessary copies in C++. Much of this responsibility lies in the programmer with manual optimizations such as passing large objects by pointer or by reference rather than by value. This concern is pervasive in the language, from the choice of increment/decrement operators to the implementation of constructors. Many compiler optimizations are also target copying such as the return value optimization (RVO) and, more recently, the move semantics in C++11. The reasoning behind the emphasis on copying seems intuitive enough: pass-by-value of any data larger than a primitive type (i.e., larger than a pointer) gets too expensive especially if the data in question is in a temporary which must be destroyed anyway. C++'s machinery to work-around this inefficiency isn't representative of imperative and object-oriented languages. For example, Java makes references the default way for manipulating objects even though the primitive calling semantics is pass-by-value. However, in functional programming, copying is seldom the overriding emphasis. Why isn't copy as big of a deal in functional languages? For the sake of argument, I will take ML as the canonical functional language. Lazy evaluation in languages such as Haskell adds another layer of complexity which I won't address here.

POPL 2012 Papers

It's just a few weeks until POPL 2012 (Symposium on Principles of Programming Languages, one of the top programming language theory research conferences) in Philadelphia. The program has been out for a while. This time, there are three papers on C/C++ semantics. Apparently we have gotten to the point where researchers have (mechanically) formalized interesting chunks of that large, complicated edifice. The one coming out from INRIA [PDF] has a mechanized (Coq) semantics for C++ construction and destruction including C++11 features. The authors actually give a formal proof of the RAII (resource acquisition is initialization) pattern, specifically that in a terminating program every construction of a subobject is indeed matched by a destruction. The process of developing a formal semantics also helped identify issues in the C++ standard both C++03 and C++11. On the type systems side, there is also a paper from Adobe Research on gradual type systems, especially a type inference scheme with support for dynamic types. One paper describes a type system and language design supporting probability density functions for custom probability distributions and continuous probability. Apparently probability distributions are monads too!

Data-Driven Language Design

One recurring issue with the evolution of programming languages is the tension between feature creep and stagnation. Some programming languages manage to evolve very rapidly, incorporating all kinds of features in response to developer requests or the language architect's leading. Brian Goetz has an interesting article on DeveloperWorks which argues for using "corpus analysis", studying the actual frequency of use of language constructs in the corpus of source code, to guide the evolution of a language. In his article, he describes two examples, precise exceptions rethrow semantics and type inference, where corpus analysis played a role in determine how Java evolved. When I was working on SML/NJ, we informally used this technique to determine the best design in terms of certain type checking/inference and module system elements.

Save bits, save power, save the world, Part 2

The GHC Haskell and OCaml compilers do not have builtin popcount support, so again I precomputed the bit pop count for each ASCII letter. Using the same ~9 Mb 4x concatenation of /usr/share/dict/words from last time I measured the performance of the resultant code. This time, the test machine was a Macbook Pro 2.16 GHz with 2 Gb of RAM. The microprocessor is a Core Duo T7400 which has no support for the popcnt instruction anyway.

Programming Language Gotchas

Looks like I spoke too soon. The October rally was looking a little long in tooth, and a little warning from the credit agencies was enough to get the market to go risk off at least for this afternoon. At least yields did not decline too much (2.01% for the 10-year according to MarketWatch). The Dollar Index (DX), however, has certainly been in an uptrend since the end of October trough.

Coming from the Standard ML world of languages makes me take many things for granted. It also gives me a probably pretty narrow perspective. Hacking on my trading analysis tools in other languages helps me broaden that somewhat, though I have certainly worked in the mainstream languages long before I encountered ML and its brethren. I would like to keep a record of these gotchas as I encounter them. I do not intend this as value judgments but rather a documentation of noteworthy differences from a higher-order typed programming language perspective.