Reality Check

Blog archive

Don't go chasing waterfalls … or programming languages

In the last year, a new programming language seems to pop up every few months promising huge improvements over past languages. Just last week, Wired magazine presented a new language called “Julia” and proclaimed it was “the one programming language to rule them all.”

Before that, we had Go, Rust, Dart, Scala and Ceylon just to name a few. (There are many more out there, like F#, Opa and Fantom). Tired yet? Well, as one blogger recently pointed out: “The programming steamroller waits for no one.” 

Personally, I have not yet found a new language that is significantly better than the current dominant languages like Java, C# or Javascript. Marginal improvements at the edges just don’t interest me, nor do they pass the barrier to entry. Furthermore, as I have previously written, programming languages no longer matter – platforms matter

On the other hand, the government notoriously suffers from technological inertia with major initiatives using mainframes and their archaic languages like Ada and even MUMPS (circa 1966). 

On one hand, government IT managers should not be enamored by the latest shiny new language, but they should also not be mired in the tar pits of outdated technology. The sweet spot lies in utilizing the dominant language by platform (i.e. clients, servers, mobile, cloud). Don’t be fooled by niche promises of over-zealous techies who like to live on the bleeding edge. I myself, in my younger days, have been guilty of this – chalk it up to youthful exuberance. Now, I know better, and so should you. 

Some of the niche improvements these languages are pursuing are performance (a perennial favorite), easy parallelism (like goroutines in Go), functional programming (like Scala), cross-platform (like Fantom), and syntactic sugar promising either more intuitive or faster coding. 

I once witnessed a major, mission-critical initiative bow to techie demands to use a hot new dynamic programming language that was over 30 times slower than the dominant language. That system is still in development but given that the performance requirements and volume of data were expected to triple, choosing a dynamic language, for that set of requirements, was downright foolhardy. 

And that brings us to the moral of this story: A programming language is merely a tool to achieve the business objectives of a robust and efficient IT system.  Be wary of techies steering the conversation to the hottest new language of the month in the name of feature X or improvement Y. The dominant programming languages for each platform type are dominant for a reason. 

As platforms like cloud computing mature, we could see new languages tailored to the that platform become dominant. Then, and only then, a switch is warranted. As TLC says in the song, “Please stick to the rivers and the lakes that you’re used to.” 

Michael C. Daconta ( or @mdaconta) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.

Posted by Michael C. Daconta on Feb 12, 2014 at 10:45 AM

inside gcn

  • digital model of city (

    Why you need a digital twin

Reader Comments

Sat, Nov 29, 2014

"current dominant languages" i can do more in a few hours with perl or simple command line concatenations than any of your so called dominant languages can accomplish in a year... Use what is easy and simple and always works. Otherwise you'll find yourself getting cast off like many of the IT departments that I've never been a part of but have out lived. If it ain't broke, don't fix it. Java is a language written for people who don't want to or can't actually accomplish any real work.

Fri, Apr 11, 2014 ...

These techies keep forgetting the business criteria! It is good to learn new languages, paradigms, and so on, but one must not hurry to go applying them to every project.

Tue, Feb 18, 2014 JoJo

@no_name...This is not obvious to everyone. I think the subject deserves an article.

Thu, Feb 13, 2014 Patrick

Using a different language should only be done where there are significant advantages to do so. An example of such an informed decision would be augmenting the use of C# with F#, as the latter has significant advantages for applications where correctness, robustness and the solution to complex problems is involved. Below are some features that make F# a much better choice for a large class of problems ..... Immutability by default Option types (eliminates null exceptions) Algebraic Data Types Units of Measure Pattern Matching Computation Expressions Type Providers Real nested functions Hindley–Milner type inference Curried functions and partial function application Simple immutable record types Non-nullable reference types Function in-lining Succinct tuple syntax and manipulation Object Expressions (create interface implementations on-the-fly without a concrete class implementation) Elimination of uninitialized variables Statically resolved type parameters (aka type-safe static duck typing) Type synonyms/aliases Type-safe string formatting

Thu, Feb 13, 2014 Matt McKnight

"That system is still in development but given that the performance requirements and volume of data were expected to triple, choosing a dynamic language, for that set of requirements, was downright foolhardy. " That's a misleading statement, as a "dynamic" language is not particularly slower than a "non-dynamic" language, especially as regards your mention of C#, Java, and JavaScript. First of all, JavaScript is essentially a dynamic language (where dynamic refers to non-statically typed). Second of all, in common usage of statically typed languages like Java, people use frameworks like Spring that make it perform like a dynamic language by introducing relying on reflection to instantiate classes. Finally, C# and Java are designed to run as interpreted bytecode in virtual machines, JavaScript runs in things like the V8 Engine which compiles it down to machine code. Aren't these more important concerns than the language used to generate the bytecode? Concerns like these are vastly more important than the choice of language, and the overall architecture of the application, use of caching, database replicas, etc .are usually more determinate of the bottleneck in an enterprise application. The real problem with picking a new language, such as Scala or Clojure, (over something well established like Ruby or Python) is the lack of available tools and available expertise. Even though they all can run on the JVM...

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above


HTML - No Current Item Deck
  • Transforming Constituent Services with Business Process Management
  • Improving Performance in Hybrid Clouds
  • Data Center Consolidation & Energy Efficiency in Federal Facilities

More from 1105 Public Sector Media Group