The next big language
November 26, 2009 – 1:33 amMy opinion on the next big language:
First, let’s talk about loosely-typed vs strongly-typed languages. Also, people argue that a string type system gives you a false sense of correctness, and you have to write tests anyway, so the types are just getting in your way. The problem, I believe, lies with the majority of software developers. The majority of developers bang on code until they think it works. This absolutely isn’t the best way to go about creating software, but it’s the most common way. For this majority, a type system helps development speed and correctness. And for the majority who aren’t going to write comprehensive tests, static analysis is a valuable tool. And while, in theory, static analysis can be just as effective on loosely-typed code, the most effective static analysis tools have historically been available only for strongly-typed languages. I’ve heard people describe Java’s type system as clunky. It’s important to keep in mind that Java’s type system is not the definition of a strongly-typed system.
Scala attempts to improve on Java’s type system. For people who are into languages, Scala is fun. There’s a lot of language to play with – which is its biggest barrier to becoming the next mainstream language. There’s more concepts to think about, more syntax and symbols. Version 2.8 of Scala cleans up many inconsistencies. I’m hoping that version 3 will shrink the language.
Speaking of consistency and shrinking a language, this brings me to Clojure. In contrast to Scala, Clojure has little syntax. In contrast to Common Lisp, Clojure provides consistent interfaces for data structures. I very much enjoy Clojure’s model for dealing with concurrency. Clojure’s challenge to becoming a mainstream language is that of every Lisp: for the masses, it’s too different of way of programming.
Java was explicitly designed to be easy for C programmers to adopt. I think the next big language will be one that is explicitly designed for Java developers to adopt, even if that language may not technically be the best general-purpose language at the time. I’d argue that the easiest of the alternative language to transition to is Groovy. Groovy is essentially Java but with a few wish-list items implemented, such as closures. But I’d argue that Groovy doesn’t differentiate itself enough from Java to incite large-scale adoption – most would look at Groovy and say Java is good enough.
I quite like C#, especially it’s support for declarative, composable, lazy queries a la LINQ. I also like type-safe function pointers, first-class properties and events, and the tooling is the best I’ve seen. The fact that the primary implementation of C# is restricted to running on the Microsoft stack is its major challenge for adoption. Yes, the Mono and Silverlight implementations may become solid enough for wide-spread adoption, but most people view any Microsoft technology as too risky to be used as a foundation.
I recently spoke to someone working in the ESB space who observed a cyclic patterns of the industry moving between a dominant general-purpose language to many general-purpose languages. Today, a most developers use many languages: the various XML configuration languages (Ant, Spring, Hibernate), HTML, CSS, shell scripts. So the thought that using multiple general-purpose languages is certainly a possibility, especially with interfaces between systems now commonly being defined in terms of language-independent REST, HTTP and XML. There’s much being said for polyglot organizations, but my guess that most businesses will stick with Java until at least a few years after it’s generally accepted that some other single language is the best to use. And with projects like Project Coin, Java probably has a decade longer as the dominant language.
–
Here are some videos that played a role in the formation of my opinion:
Comparing Clojure to previous Lisps and Haskall
How Clojure makes immutability fast and an introduction to how it manages concurrency
An argument for polyglot porogramming
Programming functionally with a non-functional language











