Desktop Application Programming
There has been an interesting discussion going on about the future of desktop applications, involving John Gruber, Jesper, and Daniel Jalkut, with many comments form other luminaries in the Mac programming world. There were a number of themes in the conversation, but the one that struck a chord with me came from this quote from John Gruber:
I think a few years from now, desktop application programming is going to look more like web programming does now, with most of the lines of code written in scripting languages, and the performance-sensitive parts written in C / C++ / Objective-C.
Now I have a lot of respect for John and the other folks involved in this conversation, but I have to say that this whole line of reasoning suffers from several flaws:
-
First of all, what John is predicting has already happened to a good extent. On the server side, languages like C have long been supplanted, first by Java (JSP, J2EE, etc.) and .NET (ASP.NET, etc.), more recently by PHP, Ruby on Rails, and so forth. On the desktop, many games have a substantial portion of their functionality implemented in dynamic languages like Lua (a.k.a. scripting languages, but I hate that term). Adobe’s Lightroom has a substantial amount of code written in Lua as well. Safari and Firefox contains functionality implemented in JavaScript (not to mention Dashboard) and the next version of Firefox will use JavaScript extensively. Most of the Adobe CS2 applications have extensive ExtendScript interfaces. Photoshop CS3 allows extensibility via Flash/ActionScript. And so on and so on. The trend is for less and less of the code to be written in C/C++ over time.
-
John qualified his prediction with the statement that “most of the lines of code” would be written in scripting languages. The inadequecies of measuring LOC are well known so I won’t belabor them here. A better measure would be to compare the number of man hours spent developing C/C++ code vs. the number of hours developing dynamic language code, or the percentage of functionality implemented in dynamic languages, or some such. My prediction is that any one of those measures will show a continuing trend towards dynamic languages over time.
-
It assumes, incorrectly, that dropping down into native C/C++ is the only/best way to get good performance. This is often not the case: JIT-ed languages can often outperform native code on certain types of algorithms, particularly those that benefit from whole-program optimization. That said, there are certain types of operations that do perform better in C/C++ than in current implementations of dynamic languages, and dropping down into C/C++ is often the most expedient way of correcting those problems.
-
A more compelling reason for dropping down into C/C++ is that there is so much good C/C++ code out there that it doesn’t make sense to rewrite. Look at Lightroom, for example: it heavily leverages Adobe’s decades of work on image processing. I don’t have hard numbers, but I wouldn’t be surprised if a majority of the new code in Lightroom was written in Lua. I expect more and more applications to evolve in this manner: taking an existing code base and building new functionality onto it using dynamic languages.
-
It ignores the problems associated with scaling existing C/C++ code into “our megacore teraflop future”. When you think about things like Intel’s recently announced 80-core system, the massive parallelization available in GPUs, and so on, leveraging existing single-threaded C code (even when using MMX intrinsics) suddenly doesn’t seem so compelling compared to code written in languages that were built for parallelism like Haskell and Erlang, especially when combined with a multicore-aware JIT compiler. There is a ton of good discussion going on in this area lately.
-
Can’t comment on this without mentioning Apollo. Desktop applications built on top of a high quality JIT compiler, with security, portability, and good performance.
Bottom line is that the future is here. Desktop application programming is not what it once was. Dynamic languages are an integral part of programming applications today, and will be even more so in the future due to the advent of massive parallelism.
Shebanator 
Agreed.
We’ve been embedding Lua in our Mac apps for a number of years now, driving an optimised, low-level engine, and it’s been a major win for us, both in terms of time and creativity.
As for LOC, well, yeah, it’s a completely worthless metric. There may indeed be more lines in a script, but the script often does more, much more, than the typical line of code in a low level language.
For example, the following single line of script:
table.insert(myTable, myObject);
There is no meaningful way to compare just how useful this is in comparision to a corresponding line in a low level language, except to say the ability to provide that functionality, as effectively part of the language, is a big win.
Simply put, using a scripting language (or whatever term you prefer) has allowed us to add application benefits (i.e. things that really benefit our customers) that would have been too hard or too costly to do in C++ or ObjC.
Many developers on Lightroom go weeks at a time without writing anything other than Lua.