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.
- The difference in productivity between a develpoment team that knows a framework and one that is new to it is a factor of 10.
- It will take 2 years for an individual to get to that factor of 10 improvement with a framework.
- 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.
- 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.
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 may be less common and less understood by many, but it’s no less object oriented IMO.
You wrote: “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”. In fact, JavaScript does not have a threading/concurrency model at all. Callbacks are indeed OK because they are executed in sequence; never concurrently. JavaScript, and the browser tab itself, are totally single threaded, utilizing an event driven approach. Nothing mad about it.
(Recently browsers have been enhanced with the WebWorker mechanism for multi-threading, but this is an enhancement to the environment, not to JavaScript. As a result, JavaScript in each worker cannot share objects with JavaScript in other workers. There is only a simple mechanism for asynchronous data transfer between workers.)
JavaScript is also a true functional language. Functions are first-class citizens. JavaScript also has closures and currying. The latest JavaScript standard also adds continuations and array comprehensions. Good stuff.
The funny thing is, you profess to disliking JavaScript, yet believe it will rule the world. I like JavaScript a lot, yet am doubtful that this will happen.
@DanShappir
This post is part of an internal discussion we are having, it may be a slightly argumentative piece 😉 Hopefully other posts will come out over the next little while. I think it’s an interesting area.
I think we both know what I meant about using functions in Javascript instead of classes. It does feel a bit strange. And the mad concurrency model is indeed that it is single-threaded – the same as the MSDOS concurrency model if I remember rightly.
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 to the server, whereas no language is succeeding in spreading from the server to the browser.
> 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 to the server, whereas no language is succeeding in spreading from the server to the browser.
That is indeed a very valid point, though I think it’s still way too early to assume JavaScript’s success on the server side. Node.js notwithstanding. I also definitely agree mastering a single programming language is easier than mastering two or more. It certainly makes it easier to hire proficient developers that can work on any component of a project.
But presenting data exchange as a prime reason for using JavaScript on both ends, isn’t a valid argument IMO. My own experience is that exchanging data over the wire isn’t much easier, or much harder, when it’s all JavaScript vs. JavaScript and some other environment. If this particular problem had not been solved years ago, the web itself would not exist.