Disruptive Programming Languages
I thought this post would be interesting, given my post “Taking on category leaders,” earlier this year.
A slide and video by a Microsoft researcher, Todd Proebsting, entitled “Disruptive Programming Languages” explains, using principles from the popular book “The Innovator's Dilemma,” why languages like C/C++ are losing steam to newer languages like Java, C#, and Python.
Proebstring coined the phrase “Proebsting’s Law” that states that that compiler technology doubles the performance of typical programs every 18 years. Thus, it cannot compete with impact of Gordon Moore’s law, which states that the capacity of semiconductor ICs double every 18 to 24 months.
New disruptive languages often come with a major disadvantage (typically, slow performance due to use of garbage collection, virtual machines, etc) but compensate with significant advantages in other areas such as developer productivity. Proebsting law suggests that research focused on developer productivity in programming languages will yield a better return than that focused on compiler optimization, since performance improvements are free from rapid hardware improvements over time.
Todd speculates on additional disruptive language features beyond garbage collections and virtual machines. His list includes “automatic function call tracing,” transaction support in languages, database integration, scannerless generalized LR parsing (Earley parsing,) compiler language support for XML manipulation, constraint solvers, and distributed programming.
He also adds that the next programming language will be slower than the one it replaces. However, I’ll probably add initially so. In the beginning, assembly coders outperformed the C programmers; now compilers can currently emit C code that can run faster than handwritten assembly code, because of better optimizations as well as new processors designed toward compiler-generated output. Also, if the compiler has the same information about a problem as a human, the compiler should theoretically alway be able to produce superior code. Because of this, I think we will see a longer term trend towards declarative language constructs, two of which were mentioned earlier including constraint solving and generalized parsing.
Some of these disruptive predictions aren’t going to need new languages. Automatic function call tracing is already possible by using the CLR profiling APIs. Systems.Transaction is being added to Whidbey and makes use of the Using keyword in C# and VB; however, the using usage is suboptimal in that it does distinguish between normal and abnormal termination, and actually treats abnormal termination as default. Database integration and XML integration are already be studied for future versions of C# through projects like COmega.