Steve Yegge tantalizes us with a post on the next big language, but he won’t say what it is. A lot of people think he’s talking about JavaScript, but I’m betting he’s writing about Groovy.



Why Yegge isn’t talking about JavaScript

JavaScript is just too weird when you really dig into it. I don’t think it has optional static typing that Yegge thinks is so important; it has a massive eval problem; and it’s really object-oriented. (Aren’t Java and JavaScript object-oriented? Well, not really. At least not compared to JavaScript. Java and C++ are really class-oriented languages. In JavaScript there are no classes, just objects. I only learned this a week ago, and it blew my mind. ) This violates Yegge’s requirement for “Standard OOP with classes, instances, interfaces, polymorphism, etc.”

Why Yegge is talking about Groovy

I think Groovy is the only language that meets all his requirements: garbage collected, optional static typing, C-like syntax, runs on a VM, performs as well as Java, supports lots of hot buzzwords like closures that only CS Ph.D students actually understand, etc.

Oh, and one thing he doesn’t mention: Groovy has just hit 1.0, so the time is right if it is the next big language.

Why Yegge is wrong and Groovy is not the NBL

Now, do I think Yegge is right, and Groovy is the next big language? No I don’t. Groovy is a confusing mess of kitchen sink features, and I can’t see it pulling anyone away from Java. I think the next language has to be simpler than Java, not more complex. Java beat C++ by taking features away (multiple inheritance, operator overloading, unions, structs, macros, etc. ); not by adding them. The NBL will be a language that simplifies Java by removing features that aren’t needed any more and replacing them with simpler ones. Groovy doesn’t do that.

More fundamentally, I think Yegge doesn’t understand why some programming languages win and others don’t. He’s right that the most elegant languages do not necessarily win. (When’s the last time you saw a job ad for Eiffel?) However, he then goes on to focus only on programming language features, as if those were somehow the determining factor for why some languages win and some don’t. They’re not.

You Gotta Have a Gimmick

Languages succeed if and only if they enable a significant number of developers to do something critical they couldn’t do before. Programming languages succeed if and only if a significant number of programmers have to write in them. Consider the successes:

Fortran Let engineers write code without becoming computer scientists C Write Unix programs Basic Write programs for the Apple II, TRS-80, Commodore 64, etc. SQL Talk to relational databases Perl CGI programs on web pages Java Write applets on web pages JavaScript Embed code in web pages C# Write .NET applications Objective C Write Mac OS X applications Ruby Rails

C++ is an interesting corner case. It succeeded only because it was very nearly a strict superset of C. It should really be considered as an evolution of C rather than a new language in itself.

It’s not just programming languages either. HTML, SGML, and XML all succeeded for the same reason: they let developers do enough that they were worth learning, despite their obvious flaws.

Notice that a lot of the successes are platform tied. For instance C# is a much bigger success than Objective C because Windows XP is a much bigger success than Mac OS X. In fact, it’s hard to even call Objective C a success, but it at least qualifies within the small space of Mac developers.

Also note that it doesn’t necessarily matter that the language isn’t very good for its intended use case. Java applets were (and are) horrible. But they were enough to get people to look at the language and like it for other reasons. However without that initial teaser, the language never gets considered outside a very small community. (Lisp may be a counterexample to this claim though. It had a bad use case, artificial intelligence, and never really recovered from that. )

Now consider the failures:

Eiffel

Smalltalk

Haskell

Dylan

Algol

Modula 2

Modula 3

Python

TCL

Guile

Scheme

D

These are all wonderful languages, and programmers may well have been more productive working in them than working in the languages they did choose. However, nobody bothered because none of these let programmers do anything they couldn’t already do. These languages were doomed to failure.

What about new programmers who don’t know a language already and have no existing investment in learning to protect? They’re irrelevant. They learn from programmers who already do know a language and choose the language for them.

That’s why Groovy is doomed to failure even if it’s a beautiful language (and it’s not). It doesn’t let programmers do anything they can’t already do with their existing languages. Game over.

The Real Next Big Language

I do know what the next big language is. I’m kicking myself for not writing the O’Reilly book on it when I had the chance a year ago. Here are a few clues:

It will absolutely not replace Java, C++, C#, etc. It has a very different use case that is not adequately addressed by any of those languages. Conversely, it does not aim to address the use cases to which Java, C++, etc. are put.

It will replace one of the languages in my list of successes, at least for many though not all applications.

I’m not sure it’s right to say the NBL is garbage collected, but it definitely doesn’t require manual memory management.

It is not object oriented.

It is Turing complete.

It is platform independent.

There are already open and closed source implementations.

It has reached 1.0.

Any guesses?