Martin Heller at InfoWorld raises questions about the desirability of Write Once Run Anywhere systems like Java, JavaScript, and a host of other scripting and cross platform programming languages. In the process Martin raises fundamental issues about the Dynamics of Programming Languages and specifically : Locally Optimized versus Globally Adaptive. Already, Martin has raised issues with the dynamics of JavaScript. More broadly he has been raising objections on Java/WORA (Write Once Run Anywhere languages – read Java, Flash, and other fairly robust cross platform languages) which appear to be directed to 2 major issues:
1) Java/WORA-Write Once Run Anywhere is really more WOTE-Write Once Test Everywhere.
2) Performance of Java/WORA languages and systems developed with them have performance gaps with systems developed with hardware specific compilers and assembly languages of 10 to 1 or greater – as in the Pascal P-systems of 30 years ago.
In addition Martin could have easily added on 5 more objections to the current flourishing of Java/WORA languages and scripting:
3) Every system is a local system with its own specific problems and over time constantly improved local solutions will develop TCM-Total Cost to Maintain and as well as performance advantages over Java/WORA systems.
4) Java/WORA systems are more vulnerable to viral epidemics – a security exploit discovered on one Java/WORA system will be much more likely to bealso incident on other Java/WORA systems while C/C++/LOPS-Locally Optimized Programming Systems(think non-portable C/C++ , Fortran, or Assembly languages) will be much less vulnerable the more specific to the hardware the C/C++/LOPS is.
5) Java/WORA systems are more likely to be targeted for hacker subversion simply because they have more users and present more opportunity for attack and attack opportunities.
6) Java/WORA Open Systems are going to be less agile and swift in incorporating change than C/C++/LOPS Proprietary Systems simply because more parties have to agree on what and how changes to the Java/WORA system are going to be made (Java Community Process versus .NET Suggestions). However, Java/WORA should outperform proprietary C/C++/LOPS in being responsive to change since presumably there will be more bidders and the height/value of their respective bids will determine the priority of the changes to the languages and systems. In contrast, C/C++/LOPS will have fewer bidders and so change should be slower.
7)If ever a C/C++/LOPS system gets 80-90% market share in a market, like Windows on the Desktop with its supporting COM-slowly-morphing-to-.NET Framework, why then the C/C++/LOPS system(s) clearly dominates the Java/WORA system. Why re-invent the clearly optimal C/C++/LOPS-ized wheel?
So for these seven reasons we should consider C/C++/LOPS such as Assembly Language, .NET Framework languages, Fortran and other locally optimized systems as better candidates for use than Java/WORA languages for certain applications – and perhaps, over time for a broad range of applications. Now to be sure, Martin is not saying this; but he does raise two key issues that would lead to broader discussions on suitably of languages and their approaches to system development.
First: In Defense of Java/WORA
Martin is certainly aware of the Agile Movement in system development. So he knows above all else, the major trade-off in system development: greater abstraction, adaptiveness and applicability of more abstract and Java/WORA programming languages versus locally optimized programming systems (LOPS) with tight but also highly performant ties to specific hardware and/or software platforms. IT developers are constantly assessing and making this one of IT Architectings major trade-offs. Currently that trade-off is being made more often in favor of Java/WORAs agility and flexibility over LOPS performance gains, especially in server side systems.
1) And so Martin also knows that Java/WORA naturally means WOTE(Write Once and Test Everywhere) an app is to be deployed. It is one of the best principles of Agile and Extreme Programming – it should be understood that thorough testing is the name of the game in development; so I am surprised that Martin even raises the issue. Porting always means testing and adapting to the new platform. But let me assure readers that the WOTE effort is miles, huge dollars, and weeks if not months ahead of TRIL -Try to Rewrite Incompatible LOPS code when porting even C/C++, JavaScript, Cobol, Fortran, SQL and other applications between major platforms (Windows to Linux, Apple to Windows, any desktop to Web via HTML/AJAX or whatever) – conversion developers know these woes big time and the UEE – Unreasonable Executive Expectations that drive TaHUT-Thankless and Hopelessly Unrewarded Tasks .
2)The Bagley Set of Benchmarks show programming languages breaking out into roughly three groups:
I)-Hardware or OS Platform specific and optimized like Assembly, C/C++, Pascal, Forth, etc;
II)-WORA enabled through cross platform runtimes like Java, Ruby, Python, etc;
III)-DCS-Dynamically Changeable Scripts like JavaScript, Scheme, Smalltalk, etc.
Those same set of benchmarks show that the languages tend to cluster in descending performance capabilities (great caution on this, how you create your statistics will show wide ranging results while the benchmarks themselves get updated constantly). But its safe to say the performance range is I)LOPS = 1.0; 2)Java/WORA = 1.5 to 3 times slower than C/C++/LOPS; 3)DCS = 4-10 times slower than C/C++/LOPS.
In sum, Java/WORA does not currently see the 10 times slower that Martin cites in the original P-System disadvantages to 1980 era apps, and by not citing contemporary benchmarks, implies might still be the case.
3)Evolution of lowest TCM-Total Cost of Maintenance by C/C++/LOPS systems may simply not apply ever. It is dependent on two phenomenon. First, the local app must have a very large population to spread the cost of continuous development and refinement over; otherwise continual hardware improvements means Java/WORA performance plus feature improvements will catchup and displace the more static(“we have deliberately decided not to optimize this app for another 2 years”) C/C++/LOPS apps. Second, the C/C++/LOPS system must be able to support interoperability APIs as collaboration, consolidation and cross platform with realtime monitoring and control become more prevalent in IT systems. These are obviously doable in C/C++/LOPS systems; but more readily doable in Java/WORA based packages and so IT staff might very well spawn these processes/tasks to a Java/WORA system.
4)Vulnerability of Java/WORA and C/C++/LOPS falls into two distinct eras. Pre-Web versus Post-Web when implied safety of coding complexity and simple passwords no longer protected apps from the knowledge, determination and unhealthy fame and profit motives of hackers. Some Post-Web languages were specifically designed for security and reliability. WORAs Java is a prime example. Ada is another. In contrast Microsofts C/C++ did not have a uniform TRY/CATCH and Exception handling syntax+semantics until the great security rewrite that is still ongoing in .NET 1, 1.1, 2, and now 3. Security and reliability driven languages and programming systems like Java will perform better than those not designed from the ground up to be secure and reliable. The real programming vulnerability as Martin has pointed out recently is in the dynamic coding systems like JavaScript/AJAX, Smalltalk, C#, etc which may be forced to go with some identity or checksum/handshake protocol or protected containers to verify and protect the validity of dynamic routine calls.
5) Java/WORA systems present more attack opportunities because of their common use. That used to be true; but the Security industry now describes a current organized crime and/or profiteering hacker community redirecting their efforts to using systems with known high vulnerabilities(think ActiveX and dynamic change of program systems), infrequent monitoring and attention, or subject to social engineering neglect and opportunity as being their prime targets. This profile fits C/C++/LOPS systems more often than Java/WORA; but both are vulnerable if the latter two factors of infrequent attention and vulnerable to social engineering exploits come into play.
6) Java/WORA systems are inflexible and harder to change because they have to go through community and Open Source processes. This is one of the major arguments of Microsoft in citing the advantage of their systems versus Open Source, Java, LAMP, and others. Given how long it has taken Microsoft to update Windows and IE – more than 5 years in both cases, one can safely say “case closed” on this argument against Java/WORA.
7) C/C++/LOPS is so near a monopoly in development. This is the other Microsoft argument – give us a monopoly and see what we bring to bear in the Web, database, application server and other markets in which we do not have a monopoly position. Fortunately, Microsoft has released Vista as the counter proof that monopoly is a good thing. After 17 years and keeping at least 70%++ market share, Windows software is finally approaching but not yet matching the reliability, security, availability of its competitors like Apple Mac/OS, Linux and Solaris. However, Vista has had to concede a lot of former Windows advantages. The software is bloated – requiring twice the hardware of its competitors. It still has nagging reliability and performance defects with Windows Rot and Clot. Meanwhile its has had to sacrifice lowest cost of entry. And given the major rewrite Vista now has a huge driver availability problem that make Linux and Apple look attractive. And the new UI, the complexity of all its options plus the rash of security prompts impose a learning curve that lowers its usability. But the real kicker is interoperability and pricing. To win customers, Redmond is playing borderline nice – imagine what would happen if they added monpolies in the graphics, Web server, and database markets to their resume – “St. Peter dont you call me cuz I cant go …. I owe my soul to the Redmond roll”.
So WORA systems like Java, Ruby etc stand up well and even outshine the C/C++/LOPS systems in many important regards. So now IT Architects can focus on the broader question – does the abtraction, ease of development and reuse opportunities of Java/WORA systems outweigh the performance advantages of C/C++/LOPS. And are there specific case where there are reversals of the trend where Java/WORA and C/C++/LOPS find themselves reversed on say performance, ease of use, or cross platform usability? This is called Strategic Development.
Second: Programming Language Conundrum
The C/C++/LOPS versus Java/WORA debate just spelled out is a reflection of the broader programming problem – do I code for a specific application and its environ or do I generalize the code a little so that its routines and methods can be applied and re-used elsewhere. Locally and quickly achieved optimal versus more time for more globally applicable code. Myopic versus Expansive. Currently in vogue methods as such Extreme Programming fall strongly in favor of a myopic approach. So obviously the issues raised by Martin are always just below the surface in system development.
But there are other questions to be considered as well in the assessment of any programming approach to be used. That will be the topic of a later discussion of the issues.
(c)JBSurveyer 2007
If you liked this, let others know: 
Slashdot 
Digg 
del.icio.us 
reddit 
newsvine 
Y! MyWeb