Presented by ThoughtWorks

For the naysayers, there’s no point in exploring new programming languages. Most languages today are Turing complete — they can implement everything that is implementable — so why learn something new? For self-confessed language geeks like myself that line of argument misses the point. There’s always something interesting and exciting about finding a new language that lets me express myself more clearly.

Languages are an integral part of the tech landscape. That’s why we have a whole quadrant for them in the ThoughtWorks Technology Radar — our opinionated guide to technology frontiers. And as we approach the 20th volume of the Radar, I wanted to explore the changes and evolution of languages over that time.

When ThoughtWorks first published the Technology Radar, developers essentially had a choice of Java, C#, or C++ — these covered the majority of enterprise applications. But we quickly realized that the ecosystem that surrounds a language can be as important as the language itself. We saw it first with C++, followed by Java and C#, and we see it today with Kotlin.

Java end of life?

We also spent many of the early editions of the Radar pondering the fate of Java. In November 2010, we put “Java language end of life” in our Assess ring — we were worried that innovation in Java had ground to a halt and we wanted to signal our concerns to fellow developers.

Now, you could say we got that wrong. After all, Java didn’t die out. But at the time, our concerns were very real. This was when Oracle had just acquired Sun Microsystems, and we hadn’t seen a new release of Java in ages.

One thing we definitely got right but it took everyone else time to catch up was calling out ‘JavaScript as a first-class language’.

First-class languages have the tools, such as unit testing, and approaches, such as refactoring, that you’d expect for production environments. We were seeing JavaScript being used for some serious, enterprise projects. At the time, we felt dismissing it purely as a scripting language did it a disservice. It’s taken a bit of time, but you see today that people treat JavaScript as a serious language.

Around the same time, we put into Adopt that people should care about languages. We were starting to see language innovations being built on top of the JVM. At that point, as a developer, you’re confronted with the choice about the appropriate language to build something in. It’s not just a case of “I work in a Java shop so I write this in Java”. When is it appropriate to use something like Clojure, or JavaScript?

Scala or Clojure?

Over the course of the Radar, we’ve seen the rise of the functional wave. Of course, languages such as Lisp and Haskell have been with us for literally decades — what was really happening was that we started to see enterprises become interested in functional languages.

I remember at the time we had colleagues who were firmly in the Clojure camp, while others in a different office were swinging behind Scala. It wasn’t clear which was going to win. Perhaps it’s still not. Both bring the power of functional languages into the enterprise — they just took very different approaches.

Clojure was purer in the functional paradigm; Scala was trying to ease the path, using a syntax that was familiar to Java programmers. Scala was in some ways more advanced in the ecosystem around it, like the Play framework, but that soon changed.

The other notable functional language at that time was F# — as Microsoft’s primary contribution to functional languages, it was impossible to ignore. Or at least, it should have been. For all we had clients committed to the Microsoft ecosystems, F# never really took off.

What we’ve seen more recently is that there are aspects of Scala that make it a bit more problematic. The whole design idea of making it look like Java meant you could have people writing even in the same application using very different idiomatic styles of Scala.

We tried to capture this on the Radar. We had a blip called ‘Scala, the good parts’. This raises the question of what makes a good choice for programming languages: There may not be one right answer; whatever you choose as a team, you need to agree on what how you’re going to use that language, and how you’ll approach similar problems. You don’t want one developer solving a problem one way and another taking a completely different approach.

Mind your language

I can illustrate why that agreement is so important by looking at Golang. We first started to pick up on the excitement — and conflict — around Go in 2014.

One person I spoke to at the time thought it was an abomination. They thought its creators had repeated decades-old mistakes. Meanwhile, another person I spoke to loved Go. They loved the things that the language gave them that makes it incredibly simple to use.

It just goes to show you how two people can have completely different experiences when using a language. That’s because we all think about problems in different ways.

One language to rule them all?

I mentioned at the outset, that some people see no value in developing new languages. It’s closely aligned with the idea that you should make a single choice of languages to do all your development work in.

At ThoughtWorks, we think this is a mistake. Sometimes there are things you can express more clearly in one language that you’ll struggle to do so in another. And one of the most important things you can do as a developer is to write code that’s easy to understand.

But we also recognize that developer anarchy — where you give every single developer free rein over what language to choose — is a recipe for trouble, or at least resume-driven technology selection. So, what is the right number of languages for your organization? We use the phrase polyglot programming to capture the idea that we should judiciously expand our language choices to address different problem spaces.

It’s hard to be prescriptive, but we think that promoting a few languages that support different ecosystems or language features is important for enterprises, as it enables them to accelerate processes and go live more quickly. Meanwhile, developers benefit through having the right tools to solve the problem at hand.

So, what’s next?

We’re optimistic that the wave of innovation in programming languages and frameworks will continue. Look for more activity in this quadrant as we embark on the next 20 Radars.

Rebecca Parsons is Chief Technology Officer at ThoughtWorks.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. Content produced by our editorial team is never influenced by advertisers or sponsors in any way. For more information, contact sales@venturebeat.com.