The Next Big Language?
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?
February 12th, 2007 at 10:55 am
I guess you’re talking about XQuery?
XQuery replaces no existing technology, but might replace SQL applications. It seems to fit well with your clues 😉
Why do you think it is the RNBL?
February 12th, 2007 at 11:08 am
Yegge isn’t talking about Javascript, he’s talking about Javascript 2. It has all of the things that you say are missing from Javascript – optional static typing and traditional class-based OO in addition to prototype-based OO – and more besides. It also has everything else he outlines.
February 12th, 2007 at 11:09 am
XQuery? It replaces SQL for many but not all applications (in principle), and it matches the other clues.
It can’t be what Yegge is talking about, however. He’s talking about a performant language people would use to implement XQuery, HTTP, XML, etc.
I haven’t thought through all the technical clues he leaves about the NBL, but he strongly implies that it will get its impetus from political factors not technical excellence. Groovy probably meets the technical clues, but it doesn’t make sense that some cigar chomping dudes in smoke filled rooms are scheming to make us all work in Groovy. It does make political sense that the various robber barons in Redwood Shores, Mountain View, Santa Clara, Redmond, Armonk, etc. have been forced to agree that excellent implementations of Javascript / ECMAScript / E4X / or whatever is critical to their customers and a potential differentiator from their competitors. We could plausibly see an arms race of Javascript tools, CLR/JVM optimizers, etc. that will make it *the* language that everyone knows, sees as the PHB-safe option by default, and borrows from to create the next generation. It’s a bit of a stretch to see it as the language of choice for implementing infrastructure, however.
February 12th, 2007 at 12:41 pm
Yegge can’t be talking about Groovy: he says that the language “will run both standalone and on the JVM”. As far as I know, Groovy only lives on the JVM; so, it’s out of contest.
February 12th, 2007 at 12:48 pm
Perhaps ActionScript 3, which is basically JavaScript 2. It has all the properties. And Adobe quite recently gave away the runtime to Mozilla, who are now incorporating it into its JavaScript runtime under the name Tamarin.
ActionScript is dynamic with optional static typing and uses classes but is really prototype based under the hood. You can use it as if it was C# or Java, but you can also use it as were it plain old JavaScript. Tamarin has a JIT compiler.
It doesn’t have “Destructuring bind” (Rule #5, list item #4), no operator overloading (list item #12) and I’m not sure about “First-class parser and AST support” (list item #14) but the rest of them are all there. No continuations, though.
What he talks about seems to be the mother of all kitchen-sink languages, it’s got everything and a little more. I doubt that it would be a pleasure to use, but that seems to be the criteria for a successful language: it has to hurt a bit to use it.
February 12th, 2007 at 1:02 pm
PHP?
February 12th, 2007 at 1:44 pm
> performs as well as Java,
Groovy is thousands of times slower than Java. It is really poorly designed.
> 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.
Prototype-based OOP is still OOP. Keep learning.
February 12th, 2007 at 1:45 pm
Oh, and I wouldn’t count on CS students to grok closures or even QBASIC. They’re notoriously thick.
February 12th, 2007 at 2:40 pm
@Slava: FUD! Shameless FUD! Groovy is definitely not thousands times slower than Java! It’s funny what jealousy makes you write… Groovy will always have a little overhead compared with Java because of the runtime nature of message passing, but it’s not slow.
February 12th, 2007 at 2:40 pm
Python is a failure ? Can you elaborate on this a bit ?
February 12th, 2007 at 3:54 pm
Heh, I was wondering who would take the “Python is a failure” bait.
To be clear, I love Python, but it’s not going to be the next big language, and as far as I can tell, there’s less of a market for it than there is for Objective C. Yeah, I get to use it in my current job, but only by sneaking it in the back door for projects where my boss just wants a .exe file, and doesn’t care how I create it. Is that a success? I don’t think anyone could honestly claim that.
On a side tangent, my only hope for the next big language is that it’s one that handles concurrency in a sane (by which I mean not threaded/shared-memory) way.
February 12th, 2007 at 4:10 pm
Erlang, maybe? Because it supports concurrency very well, it will let programmers take advantage of multi-core processors.
February 12th, 2007 at 4:44 pm
Guillaume, I stand by my claim. I don’t think its FUD. Perhaps you can tell me what I’m doing wrong here, and how to make Groovy as fast as Java; I’m genuinely interested.
So I create a file named fib.groovy:
def fib(int n) {
if(n <= 1) return 1;
else return fib(n-1) + fib(n-2);
}
s = System.currentTimeMillis();
fib(30);
System.out.println(System.currentTimeMillis()-s);
I compile it:
sh bin/groovyc fib.groovy
I run it:
sh bin/groovy fib
20450
Now I create a file fib.java
public class fib {
static int fib(int n) {
if(n <= 1) return 1;
else return fib(n-1) + fib(n-2);
}
public static void main(String[] args)
{
long s = System.currentTimeMillis();
fib(30);
System.out.println(System.currentTimeMillis()-s);
}
}
I compile it
javac fib.java
I run it
java fib
19
So 19 milli seconds -vs- 20 seconds.
February 12th, 2007 at 5:01 pm
OK, I give up. What is the NBL?
February 12th, 2007 at 8:29 pm
cache = [:]
def fib(n) {
if (n groovyc fibscript.groovy
C:\TEMP>java fibscript
225591516161936330872512695036072072046011324913758190588638866418474627738686883405015987052796968498626
251
February 13th, 2007 at 5:43 am
Elliotte thinks it’s XSLT/XQuery I bet! I would agree with the posters who mentioned parallelization support as a language feature will be the NBL killer feature.
February 13th, 2007 at 10:16 am
@Slava: You ran the script, not the compiled class; hardly a fair comparison.
Here, even the script ran in under
February 13th, 2007 at 11:03 am
Uh… under 10 seconds.
February 13th, 2007 at 11:17 am
>It doesn’t have “Destructuring bind†(Rule #5, list item #4),
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7#Destructuring_assignment
> no operator overloading (list item #12)
http://developer.mozilla.org/presentations/xtech2006/javascript/#slide39
>I’m not sure about “First-class parser and AST support†(list item #14) but the rest of them are all there.
Possibly Narcissus, which is the self-hosted JS parser mooted for developing JS2 features
http://wiki.mozilla.org/JavaScript:Narcissus
Though there’s not a lot of info on that.
February 13th, 2007 at 11:57 am
The NBL very much depends on context. I gather that the context is data driven web sites, more or less. Not game or spreadsheet program writing (a better Excel, for example). Garden variety application programming in a browser talking to a (relational) database. For this, something along the lines of middlegen or Firestorm or even Django makes sense. Executable data structures, in the sense that whatever code is needed is generated from some declarative store. That would be groovy.
February 13th, 2007 at 12:11 pm
Most ‘new’ language features have been implemeted very nicely in Smalltalk for years; maybe it’s time has finally come, this time as Strongtalk!? http://www.strongtalk.org/ It would be the moment I’ve been waiting for.
February 13th, 2007 at 12:31 pm
Forth NBL !
February 13th, 2007 at 1:48 pm
I don’t think that Yegge has an actual NBL in mind; I think he was just trying to set off a constructive debate among his commenters and elsewhere. (And obviously his dastardly plan succeeded.)
That said, I think ECMAscript 4 (aka JavaScript 2.0, aka ActionScript 3.0) comes closest to filling the bill, on both technical and marketing/political grounds. Adobe (Flash/Flex/Apollo), Mozilla (XULrunner), and Microsoft (WPF/E) all seem to have settled on the idea of an interface specified in XML, driven by ECMAscript. And throw in dark horse OpenLaszlo to round out the offerings.
Personally, I’d bet on Adobe’s solution, since it’s based on the Flash player, which is cross-platform, cross-browser, and already deployed everywhere.
February 13th, 2007 at 5:09 pm
Hi Elliotte, any reason not to publish the code/timings I submitted yesterday showing fib(500G) taking 250ms in Groovy? Or did it get lost when the article went from uncategorized to programming?
Cheers, Paul.
February 14th, 2007 at 6:16 am
I never saw any such comment. Possibly it got hung up in the spam filter, but it doesn’t seem to be there.
OK. I found it in the spam queue, and manually unblocked it. If I had to guess I’d say the very long result number, combined with the non-English nature of your post fooled Akismet into treating it as spam.
February 15th, 2007 at 5:57 am
2 Langaguages that allow devs do thing they can’t before
– Erlang
– GLSL (OpenGL shading language)
February 19th, 2007 at 9:42 am
One interesting language proposal I’ve seen recently is Fortress. This would qualify under your gotta-have-a-gimmick rules, the gimmick being “write programs that run on multiple processors”. It has other gimmicks, notably the source code rendering, which are arguably less useful. I don’t know that it’s simpler than Java, there is quite a bit of complexity there, but the current implementation compiles down to Java bytecodes so it ought to be at least as performant (and considerably better on multiprocessor systems).
February 26th, 2007 at 7:04 pm
Python is a failure? I use far more python applications than Java. Zope, with IsssueTrackerProduct, etc, PySlsk, and various databases, vs… I run BlueJ in Java, and that’s about it. Despite Java’s massive head start in terms of marketing.
February 28th, 2007 at 7:17 am
Someone mentioned that Groovy only runs on the JVM …. if we can compile Groovy to Java 1.4 byte-code, then I would imagine that we might be able to use GCJ to compile it down to native. I haven’t tried this, but it seems that it should work.
“like closures that only CS Ph.D students actually understand”
Non-sense! As *I* understand it, closures are easy … not requiring a Ph.D at all!
They’re like passing functions which “enclose” the local state from where they are passed.
An example of when you could use a closure would be to make a Collection-like object which handles the iteration internally. Instead of doing the for-each syntax everywhere, we could imagine a container object with a single method “forEach” that took a function as a parameter.
final String x = “Hi “;
specialList.forEach( new Closure() {
public void run(Object each) {
System.out.println(x + each);
}
});
Of course, in this particular case, the syntax of standard external iteration (especially with 1.5 “enhance for”) is light enough compared to the very heavy-weight anonymous inner classes that no-one would bother … but hopefully this illustrates the point.
Notice that in order to “enclose the local scope” we had to declare our String x as final. Very ugly, I know. But it demonstrates that we can do this in java. And if we want them to behave in a pass-by-reference way, we could do the stupid java-trick of a single element array. Again, very ugly.
http://c2.com/cgi/wiki?BlocksInJava
http://www.martinfowler.com/bliki/Closure.html
As ugly as doing this is in java, there are times when being able to pass around a closure or “function object” is just the best solution. Anytime I have a bunch of boiler-plate setup and teardown code around some slight variation in behavior, and I find that I consider this technique. We can create a method which does all the setup, then calls the function object that was passed in, then does the teardown. Elsewhere in the code, we would just have to think about the “middle bit” and we won’t have to duplicate the boiler-plate.
Once we have this tool in our box, it becomes evident that there are many uses for it … but given how heavy-weight closures are in java, it isn’t always the best hammer to pound in every screw with.
I understand that Groovy makes this much lighter weight, and that is really exciting.
One of the things that really makes ruby shine is that passing these little bits of code around is so light and easy …. Of course small talk figured this out a quarter century ago, but that’s okay.
March 6th, 2007 at 6:29 am
How about SPARQL
March 6th, 2007 at 7:11 am
It’s fun to hear a Java fan claim that Python is a failure.
Because it is not Java that installs Windows XP on Thinkpad at first boot.
Also, Java is not the standard system administration language for the Debian GNU/Linux distribution.
And it’s not Java that glue Google together.
Python does all that.
So, considering Python’s quietness and all the hype about Java Applets, Java OS, Java Chips or Java everywhere, who failed to deliver on its promises?
March 6th, 2007 at 9:30 am
My bet is a language that is of a “higher level” than the 3rd generation OOP languages around.
To put it in known terms you could call it a “Module Interconnection Language” or “Executable Architecture Description Language”
It has to be platform independent by providing a common language syntax with fast bindings to 3rd level languages.
It glues existing modules together without the (visible) overhead of SOAP (even so the compiler could translate module calls to remote SOAP requests).
Implementations must be running on a JVM (and maybe within .Net)
It has to provide module interconnection by means of “Complex Event Processing” with Events being generated by the language runtime.
When connecting to Java these events could be generated by dynamic Aspects or ByteCode processing.
Some EAI systems with workflow engines come close to the needed environment, but are vendor and domain specific and need way too much resources.
Generally current languages are still to procedural to come near to a “higher level” without becomming too domain specific.
What we need is a new declarative (like SQL did for database access) abstraction from our procedural languages
March 6th, 2007 at 6:57 pm
@Laurent: Don’t take the Python comment so seriously. Also don’t let your anger lead you to make wildly defensive claims against Java. Python is great, (I’m a Ruby fan myself), but in terms of current adoption, Java is still a top language on several different scales (TIOBE, Bookscan 3000 report). I’m not saying its the best, but why claim that Java is a failure?
Back on topic: my opinion, i think the NBL is EMCAScript. But I should add that I’m not entirely sure that this NBL is going to sweep the world and take over. There are always going to be ruby and python people out there attacking windmills after all.
I do think there needs to be a change however, Java and C# are not going to be “it” and lately I’ve been worried that Java was bloating to the state that C++ was when everyone decided that Java was the next big language.
For those reasons, if you go by Stevey’s criteria, ECMA/JavaScript is promising. The AJAX thing is definitely getting people across many languages involved.
March 6th, 2007 at 8:28 pm
@john haro
I’m not taking the comment about Python seriously, because it is not a serious comment.
Actually, it is quite laughable.
Because, as you explained, applications drive the adoption of software and there is a certain level of investment beyond which technological lock-in occurs: the alternative cost is too high.
I also agree with you about the importance of JSON as a new network protocol
http://laurentszyster.be/blog/json-is-the-model/
The reason why Java developers have a tendency to belittle Python is that it has been more successfull in many niches where all that matters is short-term productivity, high performances and long-term stability, not market muscle.
Python has made its way to the back-office.
Actually, it’s been available in Java as Jython since 1997 😉
Ten years later the Java community embrace what it disdained or shamefully tolerated, a Not Invented Here scripting language inside the JVM. Meanwhile Jim has ported Jython to the CRL and it apparently runs 5 times faster. I believe that’s what makes Python adopters go frosty about JRuby … even more if they adopted Java too.
Like me.
March 15th, 2007 at 11:19 am
* I’m not sure it’s right to say the NBL is garbage collected, but it definitely doesn’t require manual memory management.
Lua has a full garbage collector.
* It is not object oriented.
Lua, although it can do that too…
* It is Turing complete.
Otherwise, that’s not a programming language, right?
* It is platform independent.
Lua, of course, including small embedded platforms.
* There are already open and closed source implementations.
Lua. Well, that’s one implementation (the official one) with some variants…
* It has reached 1.0.
Oh, Lua is at version 5.1, so that’s not it… 🙂
March 28th, 2007 at 3:12 am
This thread is over a month old, so Elliotte can you reveal what was the subject of that book you didn’t write ?-) I’d venture erlang to get the ball rolling, but i barely know what i’m talking about. None of the languages you consider successful are particularly well equipped for parallel development, that much is sure.
March 28th, 2007 at 4:58 am
XQuery. 🙂
March 29th, 2007 at 5:08 pm
[…] Obviously this would makes a lot of sense for Google – and fits well with Steve Yegge’s post about the next big language. […]
September 4th, 2007 at 10:24 am
“Java and C# are not going to be “it†and lately I’ve been worried that Java was bloating to the state that C++ was when everyone decided that Java was the next big language”
LOL!
That is why Java had to be implemented in ?
What a farce this entire entry..
August 31st, 2008 at 3:38 pm
Groovy/Grails are perfect for building applications that uses DSL, Spring, Hibernate, can you suggest an alternative that works out this purpose ?
March 8th, 2010 at 6:02 am
I think you all have some valid points to this argument but i feel that you are all wrong!
big statement i know. But the “NBL” will have to have these key factors to even have a shot at taking top spot from Java!.
“open source” of course for anything to have a shot its gotta be free and have a strong community backing as seen by php and ruby!.
“Simple” one thing learned from Visual Basic that the easier it is to learn and build with the more popular it will be!.
“powerful” the language will have to be diverse and integrated with more than Windows, Mac, and Linux but able to do web and desktop programming as well and more.
“Tools” gotta have the tools to do the job. One thing learned from Microsofts “VS” is the better the tool the better the language.
but i myself am a newer programmer learning from all these old dogs that remember the days when computers ran on gas!. well wake up this is the 21st centry work smarter not harder the NBL will be powerfull and simple look at basic and C lasted longer than most becuase of the main to simple and powerfull.
March 24th, 2010 at 10:39 am
Either JavaScript2 or Go. I’d actually put my bet equally on both. I can see js getting bigger and bigger and bigger. There’s even server-side js implimentations now, and even game engines using js for scripting.
Go is sponsored and created by google and open/free. Almost all BLs so far have had corporate backing, and with google’s new huge presence in world today Go can’t help but catch on. Plus it has garbage collecting and C like syntax. It’s more pretty yet still has some ugliness just like Yegge says the NBL will have. Plus it only bodes better for it considering that *Yegge works at google!*