Java and Native Programming Languages
I still remembered the painful days of developing my first commercial software at Daisy Systems in early 80s. We developed software in PL/1 on the Daisy proprietary workstation called Logician which was sold for around $150,000 per unit. A single I/O task such as printing a text line requires 8-9 routine calls. Even much worse was the debugging capability. We need to punch the assembly codes into a tape and load the tape into ICE machines for debugging. There are around 100 programmers in our building to share 3 ICE machines. So I usually signed up the ICE debugging time around mid-night during intensive debugging period. That was my first experience of programming for a serious thing. You can guess my productivity at that time.

Several years later in another job at a start-up company called IKOS, C/C++ was our primary development language. Comparing with PL/1 and Pascal at Daisy, programming in C/C++ felt like a transition from riding a bike to riding a motorcycle. It ran so fast, but it also hurt big when it fell. We spent very big portion of time in debugging instead of developing new code. If we could deliver IKOS software a little faster with a little better quality, its IPO market cap would be different and my working years might count less.

Therefore when I first learned Java language and see no wild pointer and no memory corruption, my first reaction was to learn it hard and take adavantage of it in my future programming life. I implemented several small projects in Java. The experience was exactly as what I expected, I rarely spent much time in debugging. The codes would function well after it went through compilation stage. However so far I still never have a chance to manage or develop a large scale application software in Java only. If I need to develop a large scale application software in the future, honestly I don't know if I can afford developing the entire software in Java either. The critical productivity issue to me comes down to programming style and programmer's competency more than the language representation. In past decades , people like me learned from the experience to write a program defensively and tools such as Sun Studio Run Time Checking and Rational Purify software help too. But most importantly my decision on programming language would be based on business reason and the technology trend. Some main stream industries such as the manufacturing have invested millions and millions lines of native codes for basic infrastructures and product components. The application software vendors cannot ignore all these existing big investment. They must leverage or salvage these legacy codes. It may be appropriate to wrap the native codes into a service module to fit in a SOA environment in some cases. But it only occurs at the higher functional level to provide the services. People still need to develop lots of plumbing native codes to connect basic code units. Some programs use interpretive languages such as Perl and Python for such plumbing work. But it needs the same native programming language to tie things up when they were not designed to connect originally.

The emerging technology trend of parallel computing from CMT machine to cluster of machines will intensify my view of not affording developing the entire application software in Java for many main stream industries. No doubt Java and JVM can benefit significantly from CMT, the Java threads can be mapped and execute on multiple processor strands or cores on a CMT machine. But many application developers will feel more comfortable to create and manipulate the threads directly. An industry standard such as OpenMP is a good example for software people to write multi-thread program in both C/C++ and FORTRAN every efficiently. The interconnect of near zero delay latency and high bandwidth make an application runs on multiple machines become very appealing now. SOA is also riding on this cluster technology trend. But the interactions among web servers are kind of loosely coupling. The boundary lines of service modules must be at higher level and the transactions cannot be too frequent. A high performance application software cannot be parallelized in this way. Another industry standard MPI (Message Passing Interface) becomes quite popular in native programming world to parallelize a large scale application up to thousands of computing nodes.

If you are patient enough to read through here, you may think I am so biased toward native programming. No quite. I really like Java's simpler and cleaner language semantics. It extracts better programming productivity out from an mediocre programmer with less mangement hassle. Java's extensive API libraries and community software infrastructure and its universal portability will trim an application development cost very significantly. I would still consider Java first when I want to start an application software project. Here I just ask a question if I can afford designing the entire software project in Java in many circumstances, especially for parallel computing applications.