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.

Gadget History with the Galaxy Gear Smartwatch

Gadgets are proliferating again. When smartphones were first introduced in the early 2000s, they promised to reduce the gadgets we all have to tote around. Instead of carrying a GPS, cell phone, MP3 player, and flashlight (because one of the first apps for all smartphones is inevitably a flashlight app), all these devices consolidate into a single one. Then came the tablet and e-reader. They supposed to target a different market, substituting for laptops and physical books. Now comes the beginning of what may be a bevy of smartwatch announcements with the Galaxy Gear Smartwatch from Samsung, despite a number of smartwatches being introduced years before. Don't forget Google Glass. Looks like we've moved from carrying around a lot of cheap gadgets each of which have limited capabilities to carrying around a lot of expensive gadgets each of which have extensive and potentially overlapping capabilities. This is great for advertising brokers. Now they can push ads to you on multiple screens. They might even figure out how to make the ad experience across gadgets seamless under the guise of enabling you to continue where you left off on another device.

Galaxy Gear boasts 70 native Android apps that can run on its 315 mah battery. From the looks of things, there is a good sampling of phototaking and fitness apps. For fitness, wearable tech isn't uncharted territory. Companies have been linking heartbeat monitors, pedometers, and such to portable consumer electronic devices for a while, first with the mp3 players, then with phones. What is really the killer app here?

C++ Parsing Gotchas

C++ is a complicated language. Even just parsing the language is troublesome. Scott Meyer included the most vexing parse as part of his Effective STL book (Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library ). Recently, I encountered another parse issue that ultimately warranted new syntax in recent C++ revisions: the dependent type parse. The idea is simple, type names and value names (i.e., functions or variables) may overlap. That is to say, one might have a type t and a function or variable t in the same namespace. Thus, the parser has to disambiguate. This potential overlap comes up when parsing dependent type names (e.g., set<T>::iterator). Specifically, when declaring a function with a dependent type parameter such as void f(set>T<::iterator I), the compiler will complain that the keyword typename must be inserted in front of the whole dependent type name. Thus, void f(typename set>T<::iterator I) compiles.

What C++ parse gotchas have you encountered?