General comments on Java, C++ and C# for Enterprise Solutions

 Good technology won't make up for poor design and programming.  The problem seems to be that trade studies and aquisitions on technology are relatively easy.  It is much more difficult, even though valuable, for the customers to demand quality craftsmanship.  The fastest, most compact, code in the world isn't much good if it is full of defects in basic craftsmanship and logic errors.

C# is not a compiled language in the style of C or most C++ implementations.  As noted, in this regard, C# is like Java, Visual Basic, and a number of other languages.  The source code is psuedo-compiled into bytecodes that are then executed by the Common Language Runtime (CLR) environment.  There isn't really an option to compile natively to particular operating system (OS) and processor platform. This incurs a set of trade-offs with impacts (positive and negative) on runtime operations that should be considered with some due diligence.

 C# is not really related to the Visual Basic legacy.  It is true, that C# used the general idea of a psuedo-compiler and run-time (as classic VB did) but the evidence is pretty clear the Microsoft had Java in it's sights (and was co-opting those ideas) more than carrying on the VB legacy.  Further, one of the key contributors was Stan Lippman (of C++ fame) and much of the .Net team came from the OS side of Microsoft - not the Office-Developer nexus that nurtures VB.  VB.net proved to be tied to classic Visual Basic (version 6 and before) only as a marketing ploy - one that didn't work out very well when hordes of VB programmers found VB.net nothing like the language they know and loved. 

The general C# performance environment is different than for Java (or C/C++).  In my opinion this is largely the consequence of competition - or lack of it.  In the Java world, several companies make Java compilers (SUN, Borland, IBM, etc.) and several companies offer Java runtimes (SUN, IBM, etc.).  Further, SUN and IBM both try to make lots of money selling hardware - often based on performance characteristics.  Years of these competitive forces have produced some pretty impressive results in terms of performance - such that it is no longer an automatic performance "win" for the traditionally compiled languages (C, C++, etc.) over Java.  In contrast, the dominant "compiler" for C# comes from Microsoft - with only little competition from Borland.  The only operational runtime for C# comes from Microsoft - no significant competition from Mono.  Finally, Microsoft doesn't sell hardware. This has not produced a similar outcome for .Net (C# et al)  However, there are plenty of enterprise grade systems built on .Net (C# etc.) but they had to solve the performance problems differently then they would of had they used Java/J2EE, native C++, or some other solution.

"Common knowledge" isn't very valuable for making informed choices about  a programming language for a major system. It is all to easy for project in trouble to make a change that repeats the mistake that got them into trouble in the first place. If we proceed too far based upon general experience, common knowledge, rules of thumb, information in the general process, etc. then things don't work out very well.  For big important systems, it deserves purposeful modeling, experiments, testing, proofs of concept, etc. to determine based on facts (not opinions - mine or anyone elses) what will work for the system to be solved.

No comments: