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.
Comments:

Having also come from the assembly to C to C++ to Java growth path let me answer you in two words:

Absolutely Yes.

Java handles threads far better then C or C++, having been deisgned for multi-processing environments from the outset. In that multi-trheaded world you just have even more ways to hurt yourself in C and C++. Now a wild pointer or array over/underrun can effect a totally different thread making it even harder to find the error. Also, you have parallism and race-conditiosn issues to consider. All of which Java gives you far better language structure to manage.

Java is far more then an environment with training wheels for the "mediocre" programmers you mentioned. It is a true productivity boon for anyone who does not write perfectly correct code 100% of the time-- and if we're honest then thats all of us. I find i complete fully debugged projects about 8 times faster then I did in C or C++.. and I was a master C programmer for 15 years and a highly skilled C++ programmer for 10.

The real question I think is, in the multi-threaded world can you afford NOT working in Java? If you want to produce as good results as fast as your competitor who IS working in Java, my answer is NO.

Posted by Jeff Kesselman on May 23, 2005 at 11:50 AM PDT #

welcome to the 21st century, try to let go of the past... it can be painful but hey only change is constant. Time and again we're seeing proof that dynamic systems like Java are much more efficient in a world where the underlying systems change rapidly. Dynamic code generation, profile driven execution, garbage collection, efficient libraries are some of the advantages you fail to mention in this blog. Even microsoft has awaken, smelled the coffee and post this blog - http://blogs.msdn.com/ricom/archive/2005/05/19/420158.aspx

Posted by guest on May 23, 2005 at 07:26 PM PDT #

<p/> In the software tools area, I think we need to invest in tools that work in the Java world and the native world equally well. <p/> This is difficult because the Java platform gives the tools a big advantage. It's easier to write advanced tools that only support Java than it is to create advanced tool that work across all languages. <p/> For example, UML integration is much easier when you can more easily parse/generate/regenerate the source code. Code completion is easier with Java than with C/C++/Fortran. Java doesn't have to deal with a pre-processor, but other languages do. <p/> If we can make it easier to switch back and forth, then parts of an application can be in Java and parts in native languages, when that's necessary. And you won't have to teach the developer a whole new set of tools.

Posted by Chris Q on May 25, 2005 at 07:31 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

swdeveloper

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today