Portability without Productivity

I said this was going to be a slow week, so I dug out something I wrote while I was on paternity leave. I was saving it for a rainy day, which is pretty silly since if it was raining I wouldn’t mind staying indoors and writing long posts about levels of abstraction, portability and productivity.


My father and I have a running argument debate about the value of platform independence in the system design and development process. As you might guess, as an employee of a platform company I stand firmly on the “platform neutrality is irrelevant” side of the debate. Having been around Bell Labs during the development of Unix and C as well as having done a stint for an ISV, my father is firmly on the “platform neutrality is important”. Typically, these discussions turn into childish argument where my father continuously says “what if” and I continuously say “that never happens” and neither of us actually makes any ground on convincing the other of the error of their ways.

So herein is yet another salvo in the discussion, for your entertainment. It’s long and drawn out, but since it’s written it means he can’t interrupt me to say “what if” 😄

As mentioned above, my father was at Bell Labs in the early 70′s when Unix and C were developed. I guess it’s no surprise that he harps so much on portability – going back and reading some of the papers that came out of Bell Labs at the time, it’s obvious that their culture heavily valued portability. On Dennis Ritchie’s site (the ‘R’ in ‘K&R’) there is a wide variety of relevant material including The Evolution of the Unix Time-sharing System, The Development of the C Language, and Portability of C Programs and the UNIX System. Given the drastic evolution in computing at the time, it’s not surprising that both Unix and C had portability as primary goals. While I jokingly refer to C’s portability as “write once, compile everywhere”, the reality is that the portability of C and Unix was a key to Unix’s success. According to the portability article, 95% of the C portion of the Unix kernel required no changes when they ported Unix from PDP-11 to the Interdata 8/32. Only the core kernel, which was written in assembly, had to be completely rewritten. Even a significant portion of the device drivers ported over to the new machine.

However, C isn’t just portable. It also provides significant abstraction above assembly code. Anyone who has done any assembly work knows how low level it is and how significant the abstraction jump up to C really is. For example, the simple C statement of “a = b + c” requires three lines of assembly code. Here’s how Ritchie describes C’s level of abstraction:

BCPL, B, and C all fit firmly in the traditional procedural family typified by Fortran and Algol 60. They are particularly oriented towards system programming, are small and compactly described, and are amenable to translation by simple compilers. They are `close to the machine’ in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers, and they rely on library routines for input-output and other interactions with an operating system. With less success, they also use library procedures to specify interesting control constructs such as coroutines and procedure closures. At the same time, their abstractions lie at a sufficiently high level that, with care, portability between machines can be achieved.  (emphasis added) [The Development of the C LanguageDennis M. Ritchie]

That last sentence is key. C’s portability derives from raising the level of abstraction. But raising the level of abstraction also had an important productivity impact. Even if you’re are only building for a single platform and you don’t care about portability, most people would rather code in C rather than assembly because the raised level of abstraction makes the developer much more productive. However, raising the level of abstraction comes with a performance cost. C is pretty ‘close to the machine’ as Richie put it, but there is still a small penalty. If you’re writing ultra-perf sensitive code, sometimes writing in assembly is necessary. There’s a reason why books on the topic keep getting written and the Visual C++ compiler supports inline assembly code.

So here’s my point: Raising the level of abstraction is powerful because it can enable both portability and productivity. However, it also typically carries a performance penalty. As long as the portability and productivity benefits outweigh the performance penalty, everything’s cool. The problem is that productivity is typically WAY WAY WAY more important than portability. So abstractions that enable portability without significant positive productivity benefits will not offset the performance penalty associated with raising the level of abstraction.

The canonical example of “portability without productivity” abstraction that leaps to mind today is the Java platform. Certainly, Java has been pretty successful, though I would argue that its success has been extremely localized. Java on the client has never had mass adoption (the only non-toy Java client app I can think of off the top of my head is Eclipse) and the many of the parts of Java on the server bear a striking resemblance to Microsoft technology. (ODBC vs. JDBC, ASP vs. JSP, Session beans vs. MTS, etc.) Either way, Java adoption has fallen below .NET adoption even though Java had the promise of platform neutrality as well as several years head start. [1]

I would argue that one of the main reasons that Java has had only limited success is that while Java is portable, it doesn’t provide much in the way of productivity improvements. Sure, garbage collection is much easier to program to than C++’s explicit memory management model. But Java’s primary competitor (at least in hindsight) was Visual Basic, not C++. While Java focused on portability, VB focused on productivity and in the end it was productivity that drove VB’s massive market share. If you were a Java developer, you had worse tools than VB and worse performance than C++ and the only advantage you had was portability which turned out to be more problematic and less important than advertised. Server apps are rarely re-platformed and Java’s UI implementation caused as many problems as it solved.

From a geek aesthetic perspective, you would have guessed that Java with its clean language and programming model would crush VB and COM in the marketplace, but it just didn’t happen. VB, with its software factory-esque approach, was easier to use and thus attracted more developers who got more apps written. I’d guess that ease of use / developer productivity is the key indicator of success for programming environments. If Java had focused on productivity and portability, I might be working for Sun today.


  1. Obviously, there are varying opinions on this point. SteveB said @ TechEd that .NET is the weapon of choice (my words not his) for 43% of all developers. Java was second with 35% and non .NET Windows development was third (no percentage given).  Even if you want to nit-pick on the numbers, you’d be hard pressed to argue that Java hasn’t been losing ground dramatically to .NET in the past three years since VS 2002 RTMed. ↩︎

Comments:

Your point is a good one, but it's harmed by your choice of Java as an example. If you chose server-side development as your benchmark, Java would come out ahead of VB in adoption. Meanwhile, your point on the relationship between productivity, performance, and abstraction is strengthened when memory management is taken as the subject: is the abstraction of managed memory a productivity boost? Absolutely. Is it lower in performance? Yes, when compared to a skilled developer. Saying that Java is/was primarily competitive with VB is too revisionist. Java came out at the beginning of the massive wave of server-side / Web development and crushed C++ and Perl as the preferred environment for that type of programming. Java's original APIs included network and threading libraries that were both easier than any others and standardized, creating a perfect little ecosystem of programmers, educators, and business people, all eager to move into this new realm. At that point, server-side portability _was_ important because business people _did not know_ if Microsoft would deliver a stable and scalable server OS. In the mid-to-late 90s, hedging your bets over server-side OS choice was a good decision from both a business and technical perspective. Now, that's no longer an issue and part of the reason that .NET has more momentum than Java is precisely because the /. crowd is the only one left that thinks that MS hasn't proved itself on the server.
You have made a perfect point about productivity. In late '90, when first Java app servers came out, most of the server development was either on RS6000 or on Solaris. The only abstractions available were those provided by Rogue Wave toolkits and CORBA IDL. So Java introduced an enormous productivity boost for server applications. At the same time, however, it was portability which made Java viable economically for IBM, BEA and others. It changed recurring cost of chasing OS/library versions into much smaller cost of upgrades to subsequent JVM levels. SUN has helped a lot in that area with relatively slow pace of innovation between JDK 1.2 and JDK 1.3. There is no doubt that portability brings little benefit to developers of business applications. Maybe with exception of programming on Windows/ hosting on Unix scheme. But there would be no Linux and no Java without it.
Larry, while I apprectiate your comments, I have to disagree with some of your points about Java. Java was originally pushed as a client side technology. Remember the failed WordPerfect for Java project? Sun started pushing Java on the server because of the rise of web servers and the failure of Java on the client. As for the stable and scalable server OS point, that would be much easier to agree with if the Java server stack wasn't so obviously cloned from Windows. Also, if you include VBScript under the general heading of VB, I'm not sure that Java would come out ahead of VB in adoption. I don't have access to numbers right this second, but if memory serves, there were ASP than JSP sites out there in the late 90's.