For the naysayers, there’s little value to be found in exploring new programming languages. After all, most languages today are Turing complete — they can implement everything that is implementable — so what’s the point of learning something new? For self-confessed language geeks like myself — I’d learned five of them before leaving university — 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.
That said, when Thoughtworks first published the Technology Radar, it wasn’t a particularly interesting time for programming languages. Essentially, it was either a choice of Java, C#, or C++ — these covered the vast majority of enterprise applications.
So the most notable thing about the early Radars was that initially we had simply a ‘languages’ quadrant. We soon realised 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. So our quadrant became ‘languages and frameworks’ to reflect that.
In November 2010, we put “Java language end of life” in our Assess ring — we were really worried that innovation in Java had ground to a halt and we wanted to signal our concerns to fellow developers.
Now, you could say that was something we got wrong. After all, Java didn’t die out. But at the time, our concerns were very real. This was when Oracle had just completed its acquisition of 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. It came about because 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?
I remember at the time speaking to colleagues in Bangalore, India — they were full of enthusiasm for Clojure, and wanted to be the first team in Thoughtworks to deliver a project in Clojure. On that same trip, I travelled to our offices in Pune, and the story was the same there — except they were swinging behind Scala.
At the time, 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. F# never even made it out of our Asses ring into Trial — which is to say, it was something we thought was interesting to explore, but never had teams that had used it successfully in production. For all we had clients committed to the Microsoft ecosystems, we never got there with F#.
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’. And I think this raises some fundamental issues about 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.
One person I spoke to at the time thought it was an abomination. They even suggested that the person that created Go must have fallen asleep for more than a decade and only just woke up — because the choices made in Go were repeating the kind of things we were all doing back then.
Meanwhile, another person I spoke to loved Go. They loved the things that the language gave them that makes it incredibly simple to use.
Both of those people were experts in programming languages, and it just goes to show you how two people can have completely different experiences when using a language. That’s because your experience of a language is not just about what the language brings to you as a software developer but how you view that language. We all think about problems in different ways. So don’t be surprised if you pick up a new language and become wildly enthusiastic about it, but find your colleagues aren’t.
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. This poses an interesting question: 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.
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.
That said, when Thoughtworks first published the Technology Radar, it wasn’t a particularly interesting time for programming languages. Essentially, it was either a choice of Java, C#, or C++ — these covered the vast majority of enterprise applications.
So the most notable thing about the early Radars was that initially we had simply a ‘languages’ quadrant. We soon realised 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. So our quadrant became ‘languages and frameworks’ to reflect that.
Java end of life?
We also spent many of the early editions of the Radar pondering the fate of Java. As I’ve mentioned, it was one of the big languages at the time — but that didn’t mean we were always confident in its future.In November 2010, we put “Java language end of life” in our Assess ring — we were really worried that innovation in Java had ground to a halt and we wanted to signal our concerns to fellow developers.
Now, you could say that was something we got wrong. After all, Java didn’t die out. But at the time, our concerns were very real. This was when Oracle had just completed its acquisition of 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. It came about because 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?
During the time we’ve been publishing the Radar, we’ve also seen the emergence of the so-called 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 speaking to colleagues in Bangalore, India — they were full of enthusiasm for Clojure, and wanted to be the first team in Thoughtworks to deliver a project in Clojure. On that same trip, I travelled to our offices in Pune, and the story was the same there — except they were swinging behind Scala.
At the time, 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. F# never even made it out of our Asses ring into Trial — which is to say, it was something we thought was interesting to explore, but never had teams that had used it successfully in production. For all we had clients committed to the Microsoft ecosystems, we never got there with F#.
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’. And I think this raises some fundamental issues about 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 around Go in 2014. Go, as a language, tried to provide an alternative to C for systems programming. However, it also created more conflict between people that really care about languages than any other I can recall in a long time.One person I spoke to at the time thought it was an abomination. They even suggested that the person that created Go must have fallen asleep for more than a decade and only just woke up — because the choices made in Go were repeating the kind of things we were all doing back then.
Meanwhile, another person I spoke to loved Go. They loved the things that the language gave them that makes it incredibly simple to use.
Both of those people were experts in programming languages, and it just goes to show you how two people can have completely different experiences when using a language. That’s because your experience of a language is not just about what the language brings to you as a software developer but how you view that language. We all think about problems in different ways. So don’t be surprised if you pick up a new language and become wildly enthusiastic about it, but find your colleagues aren’t.
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. This poses an interesting question: 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.Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
