Sinclair Schuller is the co-founder and CEO of Apprenda.


When was the last time you thought of David Hasselhoff? Hard to remember, right?

It’s odd to think that “The Hoff” was the once chisel-jawed, sun-kissed “cool kid” of the 80’s and 90’s, starring in shows like “Knight Rider” and “Baywatch.” But like many Hollywood celebrities, he was known more for his looks and “It” factor more than his acting, and his time in the limelight faded away as fast as you can say, “KITT.”

Today, “The Hoff” is known more for a YouTube video of him shirtless and drunkenly eating a cheeseburger on the floor, in addition to a fairly desperate commercial for Cumberland Farms.

maxresdefault 520x292 Java and .NET may not be cool, but theyre here to stay [Updated]

I tell this story whenever I talk to new and alpha developers about developer languages. Much like “The Hoff,” flavor-of-the-day languages like Ruby On Rails (ROR) and Python might seem like the next big thing, but when we look at sheer numbers, old-school .NET and Java are still the leading languages in the enterprise by far.

According to Forrester, 71 percent of enterprises still use .NET, and 64 percent of enterprises use Java.

As a disclaimer, most of my development experience occurred while working for the State of New York and Morgan Stanley. I’d call myself proficient in .NET and Java. I’ve dabbled on Ruby and Python for kicks, and I’d rate my skill level there as intermediate.

Developer languages compared

Why are these two frameworks so pervasive? At the time of Java and .NET’s development in the 90’s, Sun and Microsoft, respectively, were seen as trying to modernize software development in a world of client side and mainframe programming.

Today, they’re seen as clunky and inefficient, but decades of work were put into these efforts and most of these stacks are still in use today in banks, hospitals, insurance companies, etc.

On the flip side, as consumers of technology, it’s easiest to compare programming languages by their applications:

  • Java: Citibank, United Airlines, U.S. Government
  • .NET: JPMorgan Chase, Geico, Verizon
  • Ruby on Rails: Basecamp, Hulu, Funny or Die, Zendesk, Github
  • Python: Google, Dropbox

Clearly, there’s a big difference in the cool kid factor of applications built on the various programming languages and frameworks.

If you don’t work in enterprise, here’s why should you care…

For starters, Java and .NET aren’t disappearing anytime soon – the opportunity cost is too high. Twenty years is way too much of an investment for companies to abandon these technologies now. Plus, the risk of moving away from legacy mainframe platforms has a very high risk associated with it.

Imagine if a bank decided to try a new piece of software that wasn’t interoperable with its legacy system. Would you freak out if your bank account went from $10,000 to $0? What would happen if this happened to millions of users? Chaos.

Thus, enterprises leave these legacy systems alone. And while alpha developers may complain about enterprises and legacy software, many of them overlook this point they don’t work in environments filled with legacy software, because people who don’t work in these environments simply don’t get this.

This is why .NET and Java will continue to reign supreme in the enterprise today and in the future. Thus in the enterprise world, interoperability with legacy systems is a requirement for any new technology purchase.

PaaS will bridge legacy and modern enterprise applications

So what are we to draw from this? Should all beginner developers familiarize themselves with .NET and Java first? Should old-school developers completely ignore flavor-of-the-month languages? Should enterprise developers completely ignore newer languages?

Not at all.

What we’ve seen is that cloud, specifically Platform-as-a-Service (PaaS), is the best candidate for creating new value based on crappy legacy systems. Enterprise-grade PaaS solutions bridge both developer paradigms, and now enterprises can import their mission-critical legacy applications onto a PaaS, while building modern applications to meet today’s needs.

As a result, you will see more organizations moving towards a software-defined enterprise model in order to create new revenue streams.

And while some PaaSes support multiple languages, it still makes sense to look for ones that support .NET and Java as they are the most widely-used, reliable runtimes in the enterprise. While there are some popular websites built on ROR and Python, we’re still three to five years away from enterprise adoption of both languages.

So I’m not suggesting we should ignore the David Hasselhoff languages of the world. At the moment they’re cool, they’re fun, but for how long? I simply ask that you don’t let perceived popularity – which is as fleeting as a cheeseburger on an empty stomach – dictate practical decisions.

Addendum [Added 2/28/2014 4:30 PM EST]:

After sorting through the comments, I realize that I made a few mistakes with this article, most notably not distinguishing languages from runtimes and frameworks. The intent of the article was to show that mid to large enterprises are still predominantly using .NET and Java, as opposed to more popular runtimes and languages like Ruby or Python, and that many of the mission critical apps that we use in everyday life are built on these runtimes.

While someone in a multi-national bank might use Ruby, Java and .NET are much, much more pervasive in that demographic (.NET and Java runtimes have 71% and 64% penetration in the enterprise).

In addition, my use of the term “new” in regards to Python and Ruby was incorrect from an invention perspective, but Python and Ruby are new from a commercial use perspective. I should’ve described those types of languages as non-standard enterprise languages.

Being a developer myself, I should’ve been more careful with the nuance of how I characterized Python and Ruby, knowing that the dev community would catch this.

I had fun writing this article, especially considering that I could work in a David Hasselhoff angle. I acknowledge that the article could’ve been more accurate, and I apologize for the frustration voiced in the comments. Hopefully the revisions clear up the confusion.