Programming languages

Reading the Cell technology documentation got me thinking about abstraction levels in programming languages. C vs. Java is the popular example; let us extend our view and consider Assembly vs. C vs. Java vs. .NET. (Orthogonal to productivity or higher abstraction levels is performance, which we don’t consider in this discussion for sake of simplicity.) (Our definition of productivity in the context of programming languages is development ease provided by the language itself, excluding, for example, the use of tools like IDEs).

Assembly is arguably at the lowest level of abstraction from a software expression point of view. C is relatively better, i.e. provides relatively higher abstractions – abstraction in the base language (for example, c = a+b vs. add c,a,b. The former is more intuitive), with subroutines (also good from a software engineering viewpoint as it provides better modularity), with a rich set of standard libraries etc. Java goes further – better abstraction in the base language (for example, Java threads objects vs. threads in C), with Object Oriented paradigm abstraction, automated memory management (no need for programmer to worry about mallocs/frees is likely stripping out an aspect and automating it by runtime features – very nice), a very rich set of standard libraries etc. The Just-in-Time compiler is fascinating technology. However, it solely exists for performance, not for productivity, which is our current focus. Aha, what about virtual machine abstraction? Virtual Machines as a general concept are fascinating things; however, in the current context, specifically, provide deploy-time ease (write-once-read-anywhere characteristic that stems from VM concept alleviates the need to recompile applications when moving to different platforms) and arguably, no development ease or productivity. So, platform-neutrality provided by Java technology is cool, but does not add to development productivity.

Moving onto the .NET platform, the main programming language for it, i.e. C# adds some syntactic sugar but no significant abstractions beyond the Java language. However, the .NET platform adds a significant abstraction when compared to the Java platform – language-neutrality. Our discussion is about programming languages and perhaps the reason why several languages exist rather than one unifying language, beyond the obvious temporal evolution, is perhaps because expression maybe optimised by some language for some problem domain. So, language-neutrality allows one to develop a unit of software in the most suitable language, and mix it with other units of software, possibly written in different languages by same or different person. This is a macro-level mix-n-match in the .NET platform. Additionally, languages like C# 3.0 are likely to allow micro-level mix-n-match with a hybrid of imperative and functional semantics. A philosophical question comes to mind for micro-level mix-n-match – does this improve or worsen complexity? A pragmatic question comes to mind for macro-level mix-n-match – do we have skills base to develop and support n languages in a given team? Since, both micro-level and macro-level mix-n-match are optional, and not mandatory aspect, they must be good things?

In imperative programming languages, ignoring the memory management aspect, programs are essentially linear sequence of instructions to be executed or one of the two control blocks – conditionals (branches) or loops (backward-branches). All other abstractions – like subroutines, OO, etc. maybe optionally added on top. The core set is linear sequence, conditional or loop. Additionally, we have non-imperative programming languages – declarative, functional, logic-based etc. which are outside the scope of this append, but valid for our productivity comparison; however, my understanding of programming languages is limited to make such a comparison. Beyond a technical productivity comparison, it is widely accepted these are niche languages and the skills base is far smaller than imperative counterparts.