Does the Cloud Need a New Programming Language?

Agile Cloud Development

The question of whether there is a specific cloud programming language has emerged in our internal discussions at TVP. We’ve noticed a tendency amongst “born in the cloud” companies like Cloud Physics to follow the example of Twitter and develop server-side components in the Scala programming language. Scala runs on the JVM and is supported by a significant number of PaaS, including CloudFoundry. Does this mean that enterprises moving to PaaS should now be coding in Scala?

There are different views amongst the TVP analysts, but my personal thought about Scala is, “Just what the world needs… yet another programming language. ;-)” I think this language and frameworks thing is an important feature of the emerging PaaS landscape, but not specifically Scala.

There is no doubt that full-blown JEE  is out of favour because it is very verbose, large, and very old. There are new languages and frameworks emerging, some of which are Java-based or close to Java, while some of the interpreted languages are growing at the expense of Java.

Of this whole set of languages and frameworks, the one I would view as having the best long-term prospects is server-side JavaScript, as in the node.js framework. Personally, I think Javascript is a rubbish language—you even have to spoof up object-orientation by using functions—but we are stuck with it in the browser, more so now with the emergence of HTML5. At the end of the day, in an enterprise application delivered inside a browser, there will be some JavaScript executing. If you have a server-side component that isn’t in JavaScript, you end up translating data between the two languages as you pass it about. There are ways of doing this—you can map via JSON and/or XML—and if you look at the frameworks for your favourite server-side language, there are libraries to deal with this, but they don’t really work with complex objects, and with dates, it’s a complete nightmare.

Also, JavaScript’s threading model is completely different from anything else in the world. Semaphores, mutexes? What are they? Stick it in a callback and I “promise” it will be OK… So people are inexorably drawn towards server-side frameworks that can cope with JavaScript’s mad concurrency model and the JavaScript data serialization format JSON,  and it seems the answer is to run the same rubbish language server-side as well as client-side.  The other option is to get a server-side framework to write the JavaScript that runs in the client for you, but as with most autogenerated code you lose flexibility when things don’t quite work the way you expect in the user interface, and in JavaScript there is enormous scope for that (mainly because you’ve got at least 4 different browsers to support).

Whilst node.js is in my view a likely leader, there is not going to be a single winner any time soon (or even at all).  Obviously there are some applications where scalability is a problem, but for many new enterprise applications scalability is a secondary concern—as I found out to my cost when I ran a load testing company. These frameworks and languages are entirely about improving programmer productivity, and in most cases they do that. However, most of the improvement lies in the ability to map requirements to the “grain” of the framework; in other words, to understand both the framework and the requirement well enough to deliver a design which can be simply and effectively realized. You are much better off getting an experienced team that can properly manage the requirements process and really understands a sub-optimal language  and framework, than you are using a great language for which you can’t find a good team.

I would like to propose some rules of thumb in all of this.

  1. The difference in productivity between a develpoment team that knows a framework and one that is new to it is a factor of 10.
  2. It will take 2 years for an individual to get to that factor of 10 improvement with a framework.
  3. Individuals are more comfortable in either weakly- or strongly-typed languages. You rarely find anyone who is comfortable in both. Personally, I prefer weakly-typed languages. Hence I like Groovy and have an embarrassing fondness for PHP, and I can (just about) cope with JavaScript.
  4. For a given application, the difference in productivity between different frameworks once mastered is about a factor of 2-3.

So, if we come back to the cloud, I keep reiterating the point that the PaaS (or more generally the software-defined-datacenter) has to support any current language/framework that has traction in the marketplace. It has to be flexible enough to address future requirements for languages and frameworks and to allow some back-porting of historic applications. In my view, one of the  most salient events that has happened recently is the acquisition of Nodester by AppFog. The node.js server-side implementation is being chucked in a bin and replaced with Cloud Foundry. I believe all the reference implementations for the server-side of all the emerging frameworks  will be built on Cloud Foundry—and CloudFoundry is the real jewel in VMware’s crown.

Posted in SDDC & Hybrid Cloud, Transformation & AgilityTagged , , ,

Leave a Reply

3 Comments on "Does the Cloud Need a New Programming Language?"

Sort by:   newest | oldest | most voted
Mike, Good article, but there is much I disagree with. Let’s start with a specific topic: JavaScript. You wrote: “I think Javascript is a rubbish language—you even have to spoof up object-orientation by using functions”. In fact, JavaScript is a fully Object Oriented language – everything in JavaScript is an object. This is unlike languages like C++ or Java where many things are not objects, e.g. an int. JavaScript also supports polymorphism, encapsulation and inheritance. What JavaScript is not is a class-oriented programming language. Maybe that is what you meant by “spoof up object-orientation by using functions”. JavaScript prototype approach… Read more »
> I think we both know what I meant about using functions in Javascript instead of classes There are indeed several warts in JavaScript. Some are addressed by “use strict”, some by newer language features, e.g. “let”, and some by building another layer on top of JavaScript, e.g. CoffeeScript and Dart (though I personally don’t like that route.) In any event, I’ve yet to find a programming language without it’s share of warts. > That said, I think the key point I was trying to make is that Javascript has a bright future because it is spreading from the browser… Read more »