The Next Big Language

JavaScript 2 FTW

Dylan?
C# 3?
Perl 6?

Does it have deterministic destructors, even as blocks like Python 2.5?

Generics? A powerful macro system?

Even as described it sounds like magic, but not a moment too soon.

Some variation of ECMAscript would fit the bill, but very few people seem to take it seriously. Its OO semantics also don't jive with the current fashion.

If this is true, then thank God. I prefer Ruby, but I'm about to graduate, the jobs are in Java, and I'd give just about anything to not have to work in THAT for the rest of my life.

Google has the clout and deep pockets to push a new language standard but it sure does look like most of the other big players are already deeply committed to either Java or C#. Even Google is pushing GWT pretty hard in an attempt, it seems, to escape JS. So who are the other players? Are they big enough to make NBL a reality?

Groovy is not that far from the requirements list.

hehe... actually the current version of Javascript/ECMAscript comes pretty close to your description:
* C-like syntax
* dynamically typed, but you can say x = new String()
* multi-platform
* PCRE
* functions are first-class objects; together with closures, this leads to...
* the object system can be made to look/feel "standard", with classes, intrefaces, public/private/protected, iterators, generators, etc... you can implement mostly anything that is possible with a Lisp (even macro-like constructs, although there is no stadard here); the added benefit is that once users get better their code will look a lot like Scheme/CL OOP :D
* GUI: DHTML, XUL, SVG

But
* due the the lack of a "standard" non-browser implementation, performance is hard to assess
* there is still no decent server-side implementation
* there are some annoyances like using "+" for string concatenation
* no destructuring for binds
* no(?) operator overloading

There are several toolkits that accomplish a lot of stuff, there is also JSAN, so the future looks good :D; I guess we'll have to wait for JS2 (which seems to be backed by Mozilla, Microsoft and Adobe, speaking of cigar-chomping execs) and see what it can do ;)

OTOH, it appears that there is a tendency to have a common virtual machine running bytecode generated from the language of your choice; Microsoft did this with CLR, Perl6 will do it too, probably also future JVM versions, so things will probably be more relaxed in the future, just use whatever you like and know it will run :)

Windows programmers will always use whatever MS puts out. So obviously they will use C# till MS decides to ditch it for the next big thing.

It will be up to the rest of the world to pick the NBL.

In any case every language is either trying to re-invent lisp or smalltalk. Let's just learn those and be done with it.

On typing you suggest that dynamic + static is better than static + dynamic (which is "evil".) I guess I don't understand the point you're making; aren't these identical?

It is clearly ECMA script. In fact, I knew it was going to be ECMA script before even reading the list of points.

Adobe's now open sourced ECMA script Virtual Machine is as fast as java, only it starts faster.

Not to mention that it supports a much more dynamic language then the JVM wants to be any time soon.

ECMA/Javascript has always been a nice language its just that its API got fagged up by browser implementers. Go figure.

Still, standards are coming and soon its going to take over the world.

You heard it here first.

I think you used to be right about C-like syntax. Its the reason C++ won over Eiffel or Smalltalk, and probably had a lot to do with Java wining over C++. Anything else reminded people of the Pascal they were forced to learn at Uni.

But now most programmers are of a generation that was forced to learn Java, and Python and Ruby have taught a significant number of programmers that curly brackets are not necessarily the best way to delimit blocks. So I think the prejudice against languages without curly brackets may well be fading.

Paul.

So sad, I was hoping for something more revolutionary. But what the masses want is not always the best it's what follows the path of the least resistance.

Feature-wise, Dylan is halfway there, and most of what's missing can be added as libraries. Unfortunately, with its Algol-style syntax, it doesn't meet requirement #1, and also alienates Lispers. But it does #2, if not to say was the first language to have that designed into it (first language to have it was Lisp, but it was added as an afterthought). And it was designed with performance in mind, and so satisfies #3. There's an IDE, which covers the "Tools" requirement, and there are ports of the compilers to many popular platforms (altough neither JVM nor .NET at the moment). Some of the "kitchen sink" features need addressing, admittedly.

The one thing I don't agree on with you is the requirement to support call/cc. Even hardcore schemers, like the people who maintain PLT Scheme, agree that call/cc is a bitch to implement, and destroys lots of valuable optimization opportunities. The worst problem is that there are no clearly defined semantics for exceptions in the presence of call/cc. Threads are computationally equivalent and much easier to grok for the average programmer. And since they follow a stack discipline, they allow for stack allocation and present a clean semantics for exceptions.

Dylan does have first-class continuations, though, but they have dynamic extent, unlike Scheme continuations, which have indefinite extent. That means they are only valid as long as the creator's stack frame is still active. They are better described as non-local exits.

A requirement that I think is missing from your list is clean separation between exception handling and stack unwinding. Exception systems that unwind automatically before calling your handler don't allow for clean restarts of the computation.

Also, I think a powerful macro system is not a nice-to-have feature, but a hard requirement. Dylan goes a long way with pattern-matching macros, but I think the NBL really needs procedural macros.

All in all, I think Dylan could be evolved into mostly the NBL you're dreaming of.

ECMAScript has another leg up. There are millions of kids already doing it frequently and badly on the web--it's familiar to a young generation and browser implementations/GreaseMonkey have made it easy for people to putz in it enough to be dangerous. They can dovetail that in to a mediocre career quite easily.

That sounds bitter. I guess it is. I find Javascript to be horribly aggravating and use tools Rails to avoid writing it as much as possible. I do have to admit that JSON is useful, though.

Sounds like scala fits alot of the description.

Don't discount Flash and Apollo being driven by ActionScript 3 (a dialect of the new ECMA script which is JavaScript 2). The fact that Flex applications are a hybrid of this new language and XML means incredibly rich applications (desktop enabled) can be delivered via the internet.

The optional static typing is awesome; I agree it is the best ground between fully dynamic and the fully static straight jacket of c++ (never mind void*)

Thankfully I am an expert at ActionScript. Not so thankfully is this article on native GUI from coding horror

I hope you are right Steve since my wage will increase dramatically if you are talking about JavaScript 2

Posting again, but kind of a give away:
Mozilla Javascript presentation

On Javascript: JavaScript's a great language but I don't think it's the NBL being referred to. It lacks tools support and imho general purpose use. It might be that I'm wrong, because my only real experience with it is for Firefox extension development, though I know Adobe are hot on it for Flex.

A more important question to me than "what is the NBL?" is "does it matter?". Is the NBL going to enable us to do stuff we couldn't before? Is it even really going to make hard things that much easier? Every new car that comes out is a good piece of technology, but the game changer was the first car.

Not to dominate this discussion with constant posts, but the Tamarin project looks pretty sweet.

It seems unreasonable to assume Steve was talking about anything but this.

Chaff is the stuff around wheat grains, like the hull, husk, etc. It's not really edible, and definitely not the good stuff.

I agree with Thierry Chatel's guess. Groovy sounds like a shoo-in for NBL

PHP! PHP! Thats what you are talking about!
:D

So, in other words, the NBL should satisfy anyone switching from any mainstream language by 90% at least. All mainstream + Lisp, perhaps. Dynamic typing? - you got it. Static? OOP? eval() or alike? Packages/modules? - you got it all.

Which partly explains the success of C++: it gave about 70-80% of possibilities to anyone adopting it after some other language. I remember I forgot Pascal literally overnight after I realized that in C++ I can implement character sets the way I want.

But wait, where is the Next Big Feature? Is NBL possible without it?

(And BTW, this Blogger.com sucks, it's absolutely not suited for big posts and in general, blogs like yours. Dates are least important in your case, yet visitors waste their time by wandering the debris of the calendar, instead of just having article titles as a main menu here. I don't care WHEN you wrote it, see? Can you change it, please, Steve?)

I am interested in reading your article. I like to print long articles so I can read them at breakfast or on the can.

Why does your post look like heck when printed with FireFox?

I have to switch to IE (yuch) to print your article. Consider adding a 'print' button

Thank you.

(I only started programming in 1965. Still have lots to learn).

Steve, ES4 doesn't include first-class continuations. Perhaps Google's planning on building that into GWT, but that's fudging things a bit, don't you think?

Lets face it: the Next Big Language will be the one in which enterpriseys will be able to hire cheaper programmers and be able to "build" "programs" "faster". Java gives you a HUGE library of packages and it also forbids you to mess what is already working.

Good programmers already chose their languages: functional languages and languages with pointers.

That simple.

The NBL is Java, not in its current incarnation but the open-source version of it.

Fortress perhaps? Designed by Guy Steele, backed by Sun and probably will have support in the NetBeans IDE.

http://www.nemerle.org - that's what you are talking about.

Well I would love it to be Groovy, but it is not platform prolific enough, thus it must be ECMA. Not that this is any real suprise..

great article though
regards
Al

Interesting that the second poster brought up Dylan, because it's a pretty obscure language, but very powerful, and satisfies rules 1,2, and 3. Apple did have a powerful IDE in the works before they laid off the Dylan team and OpenDylan has the foundations for a powerful IDE, but windows-only at the moment because of the lack of a gtk+ backend for Dylan's gui (DUIM).

But I don't think Dylan will be the NBL. Objective-C is pretty much a Mac-only phenomena and D, while a nice language, probably won't be it either.

In fact, I don't think it's really about languages anymore, but platforms and tools, and that's why a fairly craptastic language like Java can be so popular. Take away the IDEs and you've got nothing.

But IDEs are important and that's why I think the NBL is not a language per-se, but a tool. And that's whatever the Intentional Programming guys put out eventually.

I think at this stage in the game (and for most non-performance critical apps), it's really about DSLs and bringing tools to the table that bridge the semantic divide between domain experts and programmers.

My $0.02

See my blog post for my long comment on this. In a nutshell, Perl 6, D or Python. D only lacks the dynamic typing, and Python lacks the more C-like syntax and optional static typing. Perl 6 fits everything, but will it be production ready in 18-24 months?

Stevey said it correctly when he said that NBL will be foisted upon us. So if it aint broke don't fix it. I say we keep programming with whatever we like, try to learn a new language each year and wait for the NBL to be foisted upon us.

Doesn't really matter what it is if it has good tool support. However, if some big entity like MS or Google isn't behind it, is it really going to hit the streets with tools? I doubt it. Furthermore the Current Big Language aka CBL is Java and that came about because of the Internet. Perhaps what is really going to usher in the NBL is other technological shift.

Finally, if Stevey knows, why is it a secret? The NBL a secret, come on!

This comment has been removed by the author.

arc?

Man, I'm slow. I was hoping all the Java-heads would come up with some screwy JVM language, and I'd get to be the first to say ECMAScript.

Only ones that are questionable are:

17. Solid string and collection libraries

JS's are passable but not what I would call good.

18. Strings and streams act like collections

Not aware of the concept of streams in ECMAScript. Do infinite iterators count?

Additionally, NBL will have first-class continuations and call/cc.

Saw a comment asking about this, you can implement continuations if you can copy generators. There's a Python library that does this but not much has come of it.

* there is still no decent server-side implementation

Rhino is supposed to be pretty good. Haven't messed with it.

* no destructuring for binds
ECMA v4

* no(?) operator overloading
ECMA v4

arc
He said not a 100 year language. ;]

No, it really looks like javascript 2.0.

> arc?

lol!

Seems like this might be relevant. A new potential target device with the potential for cigar-chomping style cooperation from GOOG and MSFT, etc.
http://seattlepi.nwsource.com/business/303204_msftgoogle10.html

It does sound like you're describing a next gen JavaScript/ECMAScript.

I'm guessing that at least one of the 'platforms' you didn't want to mention was the broswer. With AJAX and other rich-web concerns gaining so much traction, it seems that being able to run code "in the browser" would be very important for the NBL.

I think you totally missed the fact that Domain specific languages are getting more and more popular. In 5 years we'll have more languages with specific purposes. Look at SQL, if you narrow the scope of a language you can make its syntax different from c and more powerful.

"I mean, if it's really the Next Big Thing, it'll have to run on mobile devices, game platforms, and all sorts of other hardware-constrained devices."

Prologue: I'll constrain my comment to issues on performance rather than all of the other issues you discuss.

If you are going to advocate what the NBL will be for game developers, you should probably sit down with developers and ask them what their greatest pains are at the moment.

Hardware is moving away from code that is straight-line with out-of-order execution. Future hardware is massively concurrent and executes instructions in-order.

NBL will have to have great concurrency support. Dataflow and layout is much more important than it used to be in the past.

For more elaboration, read anything and everything Herb Sutter has written in the last two years. A great place to start would be The Free Lunch is Over.


The next version of C++ is addressing this by introducing a memory-model geared towards concurrency. Instead of continuations there is a proposal to add futures. Link here.

Reading over the previous comments, it seems everyone comes from a web development background. There aren't too many people that have to write high-performance, system-level software for embedded and handheld devices.

Everyone seems to be advocating ECMAScript or Ruby or Python.

Please remember that somebody has to write the kernel for your cell phone, the font renderer for your browser, the compiler/runtime for your favourite scripting language.

For a great example, there is a five-part series about programming for the cell processor here. For better or for worse, the cell processor is going to start showing up in servers, TVs, handheld media devices, PVRs as well as in the PS3.

The NBL will have to handle these use cases.

This is just touching the tip of the iceberg. I'll write up a longer, more coherent blog entry soon.

http://parveenkaler.com

You all are trying to guess what this NBL is really, but nobody challenges reasons why it should be Next Big. Steve is right - to be Next Big, you have to have corporate support, to say the least and corporations want to cut the software maintenance costs as much as possible. That is why I think the next big language (ie. the next that will be used as Java is today) will be mostly like Java 1.5 but with improvements:
* no annotations, but some (like @Override) promoted to modifiers
* working generics
* no autoboxing
* no anonymous classes
* no anonymous objects of any kind but primitives and few select types (String, BigInteger, BigDecimal)
* no exception chaining
* only interfaces and primitives allowed for formal method parameters, declared variables' or method return types
* most of reflection removed, only loading classes, instantiating objects and invoking public methods will stay

Some of those can already be implemented in Java with a coding policy and an enforcing tool: I really recommend doing that, it makes the team slow to start but it really makes maintenance much less painful.

ECMAScript actually has some interesting characteristics for Windows programmers.

It runs in Windows (JScript/Windows Scripting Host), on .NET (JScript.NET), and on IE. And the next version of Visual Studio is promising some serious tool support for it in the next version of Visual Studio.

I don't think there is a "Next Big Language". Remember when computers didn't have graphical user interfaces ? Guess what?! Great programming interfaces will no longer have languages either. Check out http://pipes.yahoo.com - this is the future of programming.

PS: Please open your comments to folks without blogger accounts.

Thanks! Doug

From the perspective of someone in the middle of implementing his own new language, I can't see why popularity would be important compared to just getting valuable feedback from someone who's good at languages. Art may or may not require audiences, but it certainly doesn't require mass audiences.

If NBL isn't just a metaphoric construct for purposes of argument, even though I personally dislike it, I'd nominate Scala. More interesting, though would be what killer-app/framework/etc. would be coming to attract that much developer momentum. *That*, I'd really like to see.

I hope he wasn't talking about javascript. That means that when Steve mentioned "Cross-platform GUI", he basically meant the browser. I'm all for the improvements to javascript, but if JS is the NBL this means basically nothing is going to change. Javascript has been the language for the browser for ten years.

What about desktop applications? Like games, etc.? What about server-side apps? Javascript doesn't cut it.

I thought he might have been talking about Fortress or F3:
http://edtechdev.blogspot.com/2007/01/f3-new-statically-typed-scripting.html

Both have all the features mentioned, have corporate backing (developed by Sun employees).

He couldn't have been referring to Fortress though, because it has a nice macro system. F3 is due out in a month, not a year and a half. Fortress has already had a preview release.

Steve probably was referring to javascript or java 2, which is unfortunate. When people see what you can do with macros in languages like Fortress, Nemerle, boo, etc., it's a very nice feature to have for creating DSLs and other uses.

JavaScript seems like a good match to the listed features, but two things don't seem to add up.
The first is this part of the essay:

"As a special sneak preview, its static type system will include a "standard" class system (i.e. the kind you're used to if you do any conventional OOP using C++ or Java or Python or whatever, as opposed to Common Lisp's object system or some other unconventional one.)"

JavaScript has (or claims to have) a prototype based class system, which is definitely not a "standard" one (just google for articles on inheritance in JavaScript to see how different it is and in how many ways it can be gotten wrong).

The other reason is that Steve seemed quite open about recommending learning JavaScript until now and seems way more hesitant about NBL.

I'd really like Scala to be NBL, but its ties to the JVM and the teams intention to view it as an experiment seem to contradict that.

"And there are two other platforms that NBL will run on which, more than anything else, are responsible for its upcoming dominance, but I'd be giving away too much if I told you what they were."

This is the part I'm most curious about. LLVM sprang to mind, but I haven't heard about anyone apart from Apple investing in that, and Steve's ignorance of Objective-C seems to rule out the Obj-C 2 they seem to have in the works.

ISTR having heard about plans to "officially" incorporate Parrot into Mozilla apps; having a runtime in every browser might at least let a language challenge JavaScript's dominance.

Oh, and the part about optional static typing brings Gilad Bracha to mind, but Smalltalk or Cadence's work with (possibly) Squeak are definitely too much of a stretch -- and lack Rule #1, obviously.

Your not really writing these posts in 1 hour are you?

I think you forgot: good support for concurrency. This is going to be important in the coming multi-core world.

As long as it's not even remotely like Java. Java's like this mutation that at first everyone thought was going to give them super powers but it turned out to just be a huge freaking brain tumor. JVM strikes fear into my heart. JVM should die. The NBL better run *much* faster than the bloated apps that crawl around in the JVM if it hopes to be anything more than a niche server-side language or something trapped inside the locked box of browser-based apps.

You haven't mentioned UI. Another reason Java is such a horrid creature is any UI created with it looks like a pig with hooker red lipstick. It tries so hard to look pretty for you but it never feels quite right. I will send a silent prayer to whatever demigod is listening for anyone that has to Frankenstein UI's in Java.

So add that to your list of requirements for the NBL, if it can't create apps that look, feel and act 100% like a native app then it can just step in front of a bus.

Someone said "Windows programmers will always use what MS puts out." That's only partly true. I do a lot of coding in Delphi (Pascal) for my native Win32 apps as do a lot of others. Of course, platform programmers will always code in whatever IDE + language produces the fastest native apps and traditionally the tools put out by the platform creator are the ones that will run the best. It's why when you write apps for OS X you should use the Cocca framework and not something like Java or GTK.

JRuby ... ;o)

+1 for ActionScript 3 / ECMAscript. With Apollo out shortly, you'll get deployment cross-browser, plus cross-platform desktop. Sounds like a compelling reason to adopt. Certainly makes more sense to the business community than elegance of code.

I think the NBL should have Embedded SQL facility, where programmer can write SQL statements right away in code and the results will driectly be pushed into given arrays / UI list elements (like listboxes, dropdowns, etc...)
I dont know but if you are aware of Prolifics Panther (JAM) platform, it has all such facilities that I described above and I believe that is the fantastic development tool to develop fast, reliable GUI business applications on Windows & Unix both. However due to lack of insufficient marketing / management problems, it is vanishing out of market.

Progress ABL?
Molly

I fear it will be Javascript 2. And it will be a nightmare. It seems to be that they are just shoehorning a bunch of random features in there, on top of a fundamentally nasty language. There are going to be about 50 different ways to do any simple task in JS 2.
Also, there are no sane use cases for call/cc in an OO language.

Did someone already make a table with languages in rows and Stevey's NBL features in columns?

Post a link here - we're going to jump and help you fill it up, and then show Steve his dream language.

It should have the following rows: GC support, C-like syntax, dynamic typing with optional static, "standard" class system, Java performance, eval(), then one row for each of the 18 points from sink list, standalone implementation, JVM implementation, at least two other platforms implementation, continuations & call/cc, hygienic macro system.

It is obvious that NBL won't have ALL of the rows filled now, but it will have the MAJORITY. I am sure we will wind up with 1-2 most probable choices.

JavaScript was backed by Sun? WTF are you smoking?

This comment has been removed by the author.

Steve didn't mentioned the sources that inspired him so I'l post a few:

a) MochiKit makes JavaScript suck less :-)
www.mochikit.com
b) support optional static typing
http://ajaxian.com/archives/javascript-marriage-of-dynamic-and-static-a-killer-feature

c) performance ActionScript Virtual Machine (AVM2)
Adobe's Flash player executes applications written in ActionScript, a programming language that (in its current version, ActionScript 3.0) is based on the ECMAScript language specification and is therefore a sibling to JavaScript. As part of Flash Player 9 Adobe introduced a new virtual machine (AVM2) for executing ActionScript applications; among other things, AVM2 features a Just In Time (JIT) compiler that can convert ActionScript bytecode (the form into which ActionScript is initially compiled) into native machine instructions for much faster execution of ActionScript 3.0 applications.
(In its own testing Adobe has seen up to a ten times speedup of ActionScript applications due to the introduction of the AVM2 technology.) BEAT THIS !
http://hecker.org/mozilla/adobe-mozilla-and-tamarin


I guess everybody figured out the answer by now ... didn't ?

Pike?

Here's a Wiki we can post on...

http://www.bluwiki.com/go/Nbl

Mostly not written to yet...

Brian Guthrie wrote "Even Google is pushing GWT pretty hard in an attempt, it seems, to escape JS."

I'm not at Google, but I've met Brett and I think the point of GWT is more to help the broad bell curve of server-side Java hackers who will *never, ever* grok "Ajax" or the client DOM (never mind JS itself) to write browser-targeted code. Smart move, but nothing to do with Google attempting to "escape JS".

Perhaps Steve could say whether Google uses GWT much internally. I heard that gcal uses it.

My limited experience with code generators that target decoupled runtimes is that the abstraction leaks when you can least afford it, so you end up having to learn how to program the target runtimes anyway.

But code generators are becoming more popular, in addition to JS libraries that ape other languages (Prototype for Ruby, Mochikit for Python, etc.). They help sell to server-side hackers with various source language preferences and religions. So they may become a big thing, if not the next big language.

And in spite of my leaky abstraction fear, even I have been promoting the idea of a JS2 to JS compiler, but what that has to do with this blog post, I couldn't say ;-).

/be

as easy as:
http://nekovm.org as vm and
http://haxe.org as scripting.. everyone with ecma were pretty close ;)

In addition to Danno 's wiki
here is a matrix :
NBL Matrix

the next best language:

LISP with erlang concurrency and better support for foreign code.

too bad it'll be too good for programmers.

i hate programmers. i love computer scientists. such is the dicotomy of my world.

That's what C is for. It's not like Java is doing this now, so this type of programming definitely isn't required for Steve's NBL. To be honest, not many people need to write plumbing code, so why would plumbing code be a factor?

Because if you had followed the links that I posted, you would have read how there is a fundamental shift in how hardware is designed.

Von Neumann is dead.

Hardware is going absurdly parallel. In the end, your Javascript eventually runs on a piece of hardware. For your Javascript to run on these devices, the people in the trenches need help to build all of that plumbing up again.

I have Core 2 Duo machine and Firefox locks up all the time when trying to render fairly simple pages.

Now take that browser and run it on a machine without out-of-order execution and without branch prediction.

Developers need help. Lots of help.

Do yourself a favour and read "The Free Lunch is Over".

D is crap because it's just not very well put together. The claim that strings are arrays of char is horrible (strings can have additional constraints that arrays of char do not; consider any kind of multibyte encoding (UTF-8, UTF-16, Shift-JIS, etc.), which prohibits slicing the string in various places, because codepoints should be treated as indivisible; conflating strings and plain arrays is just not right). And the performance claims aren't all they're cracked up to be.

Obj-C is a considerably more interesting language, but the syntax is jarring (though Obj-C 2 will allow you to do away with all the square brackets, apparently), and it's not great if you want extensive static typechecking.

But to apparently dismiss Obj-C and prefer D just seems weird. Obj-C isn't perfect, but it has a lot more interesting and enabling features than D.

JavaScript is a good (and obviously popular) choice that nearly fits the bill, but I don't think it quite makes it, although it will continue to grow in popularity alongside NBL. I think the NBL will be Groovy. It hits every rule in the list and there's every reason to believe the powers that be will get behind it. Plus, it already has a killer app in Grails...

-Jesse
Refactr LLC

"[...] I think Java, seemingly at the very crescendo of its fame and glory, is actually about to get blown away by some other language. And it's going to happen in about a year, with the new language actually becoming the most popular language on the planet by 2008 or so. By then, it'll feel like it happened almost overnight, just as C, C++, Perl and Java all took off like wildfire. [...]
[...] I can tell you what I think it is. I think it's going to be Ruby. Yup. Not Lisp, not Scheme, not Arc, not Haskell, not OCaml, not Python. Not XML (please, not XML.) Not Perl 6 or C++ 18 or Java 29. [...]
[...] Next, Ruby hasn't poisoned the well. I don't think Python can ever be the Next Big Language because it's already been written off by too many programmers. [...] And Perl -- well, I think people have started to realize that they don't want to memorize another gigantic language. [...] Ruby's tight. It's basically tied with Haskell as the most concise language I've ever seen. [...]
[...] You can't expect an in-development language (e.g. Perl 6 or Arc) to be the next big thing, unless perhaps it's got heavy sponsorship from a big company willing to invest a lot of money in developing and marketing the language. [...] I doubt anything will come out of Microsoft that's interesting to programmers using Unix or Linux systems. I doubt Sun will support anything that's not Java. And I haven't heard of any others. There's the D language, of course, but it doesn't make programming that much easier than it is in Java already. [...] Am I 100% sure it's going to be Ruby? Nope."
-- Steve Yegge, "The Next Big Thing" (http://steve.yegge.googlepages.com/next-big-thing)

Steve, are you dreaming yet again? So, which languages are still canditates to become the NBL?
Java, C# 3.0, D Language, Perl 6, Python, Arc, OCaml, XML, Common Lisp, Scheme and Haskell are all eliminated. It is still Ruby? Or is it Javascript 2.0? Or maybe even Erlang?

Of course it's PHP!

Add a portable window system and lots of Java's class library to Lisp, and you've got a programmer's heaven. IMHO.

Personally, I'm waiting for a more fundamental change: A language-generating language (or meta-language, if you will) - something like "Intentional Programming" (http://www.intentsoft.com), where new abstractions can be added to a language, and the code itself can be rendered in a multiple representations, text being only one of them (with selectable formatting - an end to the "style wars"!).

In the mean time, I'm not terribly excited about yet another C-type language, and that also goes for much else that is apparently considered "cool" today, such as Java, C#, Python, Perl and Ruby. Even with cool new stuff like lambda, closures, coroutines, and what-have-you.

Thinking about features and abstractions can be useful in itself, but we shouldn't stop there. We need to see much farther than this - beyond syntax, individual languages, features and abstractions.

We also need to be able to work on a much higher level of abstraction. The idea of "Intentional Programming" is to create one or more DSLs that allows you to design the system more or less directly in the application domain.

I also take objection to that C++ is a bad or ugly language. As far as I'm concerned, it's one of the best languages we have (and, yes, pretty. These things are very subjective). Before you object, be aware that deciding what is "best" depends on a lot of factors, but let me list a couple of important ones for me:

1) Large user base, and consequently a large body of knowledge, books, libraries, job opportunities, and so on.

2) It doesn't remove features that "can be misused", because it's more important that they are available for the situations where they _are_ useful (such as multiple inheritance, operator overloading, and so on).

If you make a moron-proof language, you'll likely end up with only morons using it.

3) Facilities for resource management (such as RAII and smart pointers), beyond the one-size-fits-all garbage collection way (which can also be used, with a library).

If you think you need garbage collection for a system, you may not have thought deeply enough about ownership issues. Note that GC only handles memory allocation, no other resources, and it doesn't handle lifetime management at all.

Just pointing out that Steve is already on on record about his strong belief in the importance of JavaScript, describing it as "probably the most important language in the world today".

"The open source PHP language is intensifying its enterprise challenge to Java this week, thanks to a new version of the enterprise class Zend Platform."

http://www.internetnews.com/dev-news/article.php/3659141

I think we have a winner...

Actually, in SML it's int * int * int, not (int, int, int) :P

The "got double expected double" is a MSVC++ error message.

As long as we are used the same paradigm, i dont expect some value added from any new language.

java already provides the best suited language for domain modelling. and the question now is which language is best suited for the presentation layer.

I think NBL also has to have parallelization primitives, that is, array primitives whose operations automatically get distributed across multiple CPUs, a la ZPL, for example.

Karl Guertin said:
"Your initial post stated that Steve's NBL has to be good for plumbing code and listed system level embedded code as an example."

I said no such thing.

Steve said:
"I mean, if it's really the Next Big Thing, it'll have to run on mobile devices, game platforms, and all sorts of other hardware-constrained devices."

And then I said:
"If you are going to advocate what the NBL will be for game developers, you should probably sit down with developers and ask them what their greatest pains are at the moment."

I am saying the exact same thing as you are saying. At least I think I am.

Steve's NBL can not simultaneously be the high-level, javascript-like NBL and the low-level, concurrency aware NBL. These are two different domains and will most likely have two different solutions with some sort of glue that helps them work together.

For the record, I don't think there will be one NBL per se. I think it will consist of a language-agnostic runtime with and a bunch domain specific embedded languages. (XAML/XUL for UI, SQL for data access, some other language for job management, grepping, etc)

Java is drawning and I doubt that it will have a place in the future. It is far away from the new generation of programmers needs and expectations. It lack alot of stuff
1- operator overloading.
2- multiple returns out of a method. Even there is no single way to get multiple values out of a method except by creatting meaningless classes...... Its a major defect in the whole language.
3- Plus the java community is actining oblivious to whats going on in the .Net world ....... I mean the LINQ project......... There doesnt sound to be any plan for similar thing.

I blelieve the LINQ introduced in C#3 will change the way programmers write their codes. I alwasy thought OOP is the ultimate that can be achieved in PL but MS surprised me. ......... Its a revolution not evolution. When I first saw the article it really touched my heart. It addresses adaily problems and will releive you from alot of redunduncy in code and make far more readable and more compact.

It seems C# and .NET will dominate .... One of the main reasons for this is Visual Studio is such a smart novel IDE. While in the java you hava a bunch of IDEs and you are never happy with any of them. Everyone is missing something

by the way I am a java professional programmers and have much less experience in .NET ....... And believe it or not guys java is stuck in the emotions of its old programmers ..... They are againist any new thing. If you dont believe me get to any of the sun java forums and talk about any new idea to the language and see how many haters you will find

I hate Javascript, no doubt due to the browser implementations.

I loved ML at university, it seemed quite beautiful at the time.

Man, your wife is hot !!!
My colleague if envy of you, u lucky man :) :) :)

adobe Apollo?

I'll just stick with good ol' Visual BASIC, thanks! I'm just an Old Country Programmer!

Two points of information.

1. People used to prepare wheat by threshing (which separated the grains and their fibrous shells from the cut stalks) and walking on the result. They would then toss what was left into the air from a sheet on a breezy day. The chaff (husks and residual pieces of stalk) would blow away and the grains, being heavier, would fall back into the sheet.

So now you know what chaff is. That's why the tiny metal sheets dropped by the thousand to confuse air radar systems are also known as chaff.

2. There have recently been reports of a free-fall parachutist who dropped from 12,000 feet and survived to tell the tale. This is probably about the equivalent of COBOL becoming the NBL.

2. There have recently been reports of a free-fall parachutist who dropped from 12,000 feet and survived to tell the tale. This is probably about the equivalent of COBOL becoming the NBL.

A 12,000 foot fall would hurt less. You'd either die instantly or survive with a great story. COBOL kills you slowly, and you don't even have a good tale at the end. ;-)

93 comments, and only one 'boo'.
Boo has it. Just look at things that can be made with it quite easily, such as 'Webbness', and 'brail'
It's exstensible, it's powerfull, runs on .NET and mono so it's cross-platform, has a strong IDE (#develop), and enjoys the .NET framework's rich libraries.
Think "Ruby in .NET"
Oh, and QUT are working hard on a Ruby-to-.NET compiler, currently passing all of Ruby's unit tests afaik. That can boost Ruby to the next level, by giving it much better speed, and access to the .NET libraries.

There is noooo Rule 6!

Well, yes there is, actually. Look at it carefully. Rule 6 implies Tamarin, very strongly. "At least two other platforms," pah! "Exactly two industry-dominant ones," more like.

Of course, I don't know what Tamarin is, apart from some drug-crazed attempt to jump ahead of the pack on ECMA4, but that's probably good enough. Oh joy, another iteration of the Javascript paradigm -- the only language purpose-designed to have features and syntax shoe-horned into it. From the beginning, Javascript has had no soul. As Dorothy Parker would say, there is no there, there.

Groovy doesn't fit because (a) it's been dragging on for years and years, (b) it's tied to JVM, (c) it has no discernible industry support whatsoever (there's a rather bathetic pro-forma on one of the home page thingies for "groovy success stories. No takers, apparently. Such is the glare of the spotlight) and (d) it's crap. Don't take my word for it, search around the Web.

Scala doesn't fit because it's academic, and, well, it's just too complicated. This is a pity. I would love to program in Scala. I would happily jettison my current programming languages for it. However, mention "tail recursion" to the average programmer (let alone CTO), and they'll freak out. This is without considering the fun to be had with type inference, contravariance, currying and the like.

Never going to happen.

Off topic slightly, it's interesting to note that so many commenters make a plea for their favourite programming languages -- which was hardly the point of the blog. I find the fact that anyone would propose PHP rather sad, but then most of the rest are equally guilty of not reading the goddamn article. It may take the man only an hour in earthling time to write it, but for god's sake: try to stay germane.

Tamarin, O ye gods. Life is not going to get better any time soon.

Anybody got any idea how to find out what the bloody thing does?

Hey Steve! The next big language is going to be Chinese! Javascript2 my foot...Who is going to write a phone switching tool in Javascript?

Every next big language has had corporate support but that alone doesn't guarantee success. For that you need millions of lines of code. What easier way than to have millions of software engineers?

-Gary-

I have died a Natural (similar to Cobol) death so anything new would be a life-saver ... :-p lol

I'd be willing to bet that one of those unnamed platforms is 'web'.

Wow! I'll post a couple of minor notes first:

1. If Steve said in one post that Ruby is the next big *thing* and now posts about the next big *language* but won't say what it is, that says a lot more about Steve's writing style than it does about programming languages.

2. You *can* in fact program Ruby with curly braces and semicolons, parentheses and all the other C syntax that makes code readable by C programmers. That's the way I code in Perl and the way I used to program in R and Ruby.

3. Theoretical underpinnings: the Pi-Calculus, Petri nets and business process modeling languages based on them have a lot of momentum, and to be a success in the not-too-distant future, a "NBL" will have to support that semantics and provide tools to make it easy.

4. Performance: yes, "scripting languages" are slow, and Ruby is probably the slowest of the bunch. But YARV, Rubinius and jRuby will fix that.

5. Concurrency: Steve, I think you're dead wrong about Erlang-style concurrency being "nice to have". I think it's the most important thing there is! In fact, I personally think Erlang *is* the next big language, and it's the one I'm learning! Now if that was a subtle attempt to throw us off the scent, OK. :)

6. Platforms: I'm not a big fan of virtual machines and feeble attempts to be portable across a variety of "platforms". You can limit your platforms/implementations to the *Intel* implementation of x86-64 and not hurt yourself in the slightest economically. You don't have to care about AMD, PowerPC, AS400, whatever they're calling System\360 these days, Itanium, MIPS, etc. And you probably don't have to care about any operating systems except Windows and MacOS on the desktop and Solaris, Linux and Windows on the server. Anything else is VMware's problem. :)

Now: lets all head over to *my* blog and review the history of programming languages -- as in, "those who don't learn from history are condemned to repeat it." On the other hand, those who *do* learn from history are condemned to bore the doodoo out of their friends. :)

http://borasky-research.blogspot.com/2006/11/eight-most-significant-programming_9754.html

Oops ... that url got cut off ... it's (on two lines)

http://borasky-research.blogspot.com/2006/11/
eight-most-significant-programming_9754.html

http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7

http://developer.mozilla.org/en/docs/Introduction_to_the_JavaScript_shell

Well, my favorite language is Object Pascal, bar none. It's object oriented and has all the elegance you'd expect from Pascal. C obviously won out over Pascal because it was there on the Unix computers that the CS students were using, but it's time for a comeback.

My guess is that the NBL is either the Nice Programming Language or JRuby.

C++0x is looking very good to me, and although I suspect it isn't what he has in mind it is well on the way to meeting pretty much all of his requirements.

Add a compiler targeting a truly open and ubiquitous VM, I think many language complaints start to look like lame ducks (I know, they won't go away). Sure, it's often ugly. Adopt modern practices, and forget about how we /used/ to use it. Write more elegant code. Use a dynamic language when it makes more sense. Deal. There are much bigger problems.

The biggest stumbling blocks are usually a matter of having good, relevant libraries, mature programming techniques, and competent programmers.

I don't know of a language that saves anybody from this. Hasn't our industry played this "let's rewrite everything in..." game long enough now?

Aren't you approaching this from the wrong angle? Big shifts in language were always domain-driven. In 1990, everyone went to C++ to do Windows applications. Around '97, everyone was sick of DLL hell -- always having some PC somewhere that wouldn't run your app. So the switch was to web-clients, and Java was a garbage-collected, better language targeted to exactly that solution. Ten years has passed and many of these apps need to start from scratch again. But this time, the reason is missing. Every language switch is a risk/cost, and there needs to be a justification of that cost. Your list sounds like just another rung in the C - C++ - Java/C# ladder. Who needs it? If it doesn't have a compelling reason, what's the use?

"Unfortunately, even Ruby and Python (which "feel" simpler, syntactically) both also have very complicated grammars, making it nontrivial to write code that processes them, even with parsers that hand you the AST directly."

Why do you say that the Python grammar is hard to process? It's not that hard - there are enough implementations around (CPython, Jython, IronPython, pypy) to show this. The indent/dedent stuff might seem a little tricky but can still be implemented without too much difficulty. OTOH the C# grammar (with generics) is a lot more work to implement.

If it weren't for the JVM requirement at the end, I'd assume you were talking about C# 3.0. It satisfies every other requirement. And it even includes the query minilanguage feature you mentioned as a nice extra.
The timeline (18-24 months) fits, too.

This comment has been removed by the author.

I'm afraid I don't understand what douglas karr [sic] meant when he said "Guess what?! Great programming interfaces will no longer have languages either. Check out http://pipes.yahoo.com - this is the future of programming."

* What are "great programming interfaces"?
* How will they exist without a language?
* In what way is pipes.yahoo "the future of programming"?
* Lastly, "Bartender! I'll have four of what he's having..." ;)

I think that you might be talking about http://groups.inf.ed.ac.uk/links/

Boy, your wife is really beautiful! Apart from this, I'd say I thoroughly enjoyed the slightly long but highly informative blog! Thanks for the insights.

Surely you meant "you won't be deported to Colombia," not, "you won't be deported to Columbia." How can one be deported to an Ivy League university? Or perhaps that *is* what you meant after all....

F#

This sounds very much like Perl6.

I has grammar modification built in.

It has static typing as a simple attribute in the variable's declaration.

It runs on Pugs and Parrot, will be natively compilable, and there are efforts to run in on JVM and .Net as well. Heck, much of the new thing sin Perl6 can even be run on Perl5 with some extra modules.

Performance is a primary goal.

The object syntax will be much more like other languages than Perl5's was.

Concurrency is one of the stated goals.

There is some final syntax work going on. There's final work on the VM and compiler to support everything. It's conceivable that it'll be less than two years for that to get finished to production standards.

The VM acts as a backend for other languages, too. Compilers for Ruby, PHP, Python, and other languages are being written that target Parrot. This is partly to get other languages to port to the same places as Perl and to allow multiple languages to use each other's libraries directly. It's also partly, at this stage, to find edge cases and issues that any particular single language's compiler to Parrot may or may not catch.

Probably C++0x.

I don't have a clue what the next programming populace would be using. I am off to checkout tamarin, the current ECMA and the future one. Always wanted to pickup some more browser scripting know-how for yet another Greasemonkey hack. This articles comments inspire me to checkout Javascript 2.0.

Although it has yet to really take off, I thought Martin Oderskys experiment with Scala was an interesting way of lowering the barrier to entry to functional programming for java developers.

It introduces alot of ideas from FP and borrows the erlang concurency model.

In addition it runs on the JVM and .NET platforms, with all attendant advantages.

It's my candidate for the next big thing.

That last point may help Scala (or another new candidate) spread quickly. It's not all about the best solution, marketing and accessibility are important as well.

I don't care to sift through the comments on this one, but I just wanted to take issue with the whole statement that C-style syntax is complicated. Are you smoking crack? How is it any more complicated than anything else? I write C# and JavaScript all day long and never feel like the syntax is a problem.

Languages should be judged on how easily you can express what it is you are actually trying to do; code is a means to an end, and the better it expresses the means in a way that the simplest of people can understand it, the better the language is. The syntax should be a side-effect of that goal and not an end in itself.

Oh, and Erlang is going to eventually get more respect and adherents as we move into the future. It may not be the *next* big language, but it might be the one after that. :P

JasonBunting, write a parser for ANSI C in ten lines of code (in any lang). No dice? Write a C# or JavaScript parser in 10 lines of code...

Write a Smalltalk parser in 10 lines of code. Now, we are getting closer to to something that isn't intractable.

Now write a parser for Lisp in 10 lines of code. What you need 10 lines?

Lisp has no syntax (all those stupid parens are an AST) and Smalltalk's syntax is incredibly small and regular.

The complexity is for code treating code as data, no for programmers writing code at design time.

I think the NBL will be knuth's WEB system. Finally the power of TEX and Pascal in one super-powerful system.

Oh and there is no NBL, unless someone wants to spend the market $$$. I am getting sick of those Bruce Eckels web ads though...

+1 for haXe !

haXe for sure!

You just won't get a world class IDE with all the features without strong typing. The main reason strong typing exists is for tools, not for developers.

Ravi, Smalltalk isn't strongly typed, and yet during the 80's and 90's had the most advanced IDE features. Features such as Eclipse's refactoring for Java are lovingly and knowingly borrowed from the ST RefactoringBrowser.

Someone has already put Apollo out there, so in light of very recent news, let me be the first (only?) to throw Silverlight in the ring as well.

I don't know, what will be your Next Big Language, but I'm quite sure, my NBL has a name Rebol3

I don't agree with rule #1 (C syntax). Bad thing will not remain bad. It will be trashed off. Thesedays killer app is not a kind of PC Package SW. iPod or iPhone(?) can be the killer-app candidate. I mean embedded system SW is getting more important. They are still made with C. But, Hertz NeverLost GPS receiver was made with Ada. I think there exist the possiblity of future. :)

I would have to agree with Parveen - most of the readers seems to be web developers here.

I think NBL needs:
1. C-like syntax.
2. Huge framework.
3. Fast execution.
4. Good abstraction.
5. Tool support.
6. Platform independence.

The only language that seems to fit the bill is c# 3.0. It got c-like syntax (no kidding :).

Huge framework: MS is developing new libraries for .net for everything from game programming (XNA) to web-applications (WPF/E or Silverlight and ajax-support).

Fast execution: c# got pointers so you can easily interop with c-libraries or write highly optimized code. The 2% of your application that takes 50% of the execution time can easily be rewritten using unsafe code so you'll end up with c++-speed.

Good abstraction: c# got delegates, interfaces, structs, classes, operator-overloading, etc. With LINQ it will also get better threading. People are working on PLINQ which will make multi-core programming even easier.
The only thing c# lacks is macros, nested methods and tuples.

Tool support: Visual Studio/SharpDevelop, NUnit, dotTrace, NCoverExplorer etc.

Platform independence: c# is an ecma standard. There are c# compilers for linux, macosx, etc.

Just my €0.02.

John Lam's guess is Javascript. (via http://www.iunknown.com/2007/06/steve-yegge-por.html)

Not sure why anyone hasn't mentioned Lua.

Fantastic language.

Though, I wouldnt currently pick it as the NBL just yet.

Visual Basic?

(I picked the worst answer I could find. Correct me if there's a worse.)

"The classic example is SML, which is so fanatically typed that you're guaranteed never to get a runtime exception, because you will never get your goddamn program to compile."

That's very funny!

Lonnie Best
www.lonniebest.com

The NBL should be in a position to create any framework for any domain, not just web apps.

This is clearly not JS or PHP. Very hardcoded specifically for web.

Perl and Python are too "hard-coded" and don't take the soft DSL approach to designing the framework.

The winner seems to be Ruby...again.

N00bz, clearly it -is- JS2.

Because he says so here: http://blip.tv/file/319044/

My Vote is on Haskell

...


...you can all laugh, but Haskell is neat :-)... there's a kind of natural readability in a functional langage that supports infix operators.

It would also be nice to see erlang take off, and I'd like to say this is possible with the kind of programming problems muticore processors will introduce later (to the mainstream).

However, neither of these languages will actually become popular in the grand arena of commercial development because neither of them are C++.

F#

ECMAScript 4

But I think they should remove the "Script" and just call it "Ecma" since it will be more than a simple scripting language.

Despite that fact that Steve says it sounds like someone clearing their throat, it makes sense to alot of us and doesn't sound so "cool" that management will run scared from it. Probably should throw an 'X' in there somewhere.

eXma? Sounds like a disease though.

I guess you could just call it JavaScript 2 but then you can't drop the "Script" portion.

After working in a reporting environment that used JavaScript as their scripting language I still have nightmares where power users that suddenly thought they were programmers refer to the language simply as "Java". Sooo...not the case.

I was thinking Ruby or Groovy until I read this post. Okay, maybe not Groovy unless they come up with a "management friendly" version of the name (Neal Ford's idea is ebXl or 'Enterprise Buisness Execution Language' I think).

I'm down with ECMAScript4 as NBL since I just started using ActionScript3 in Flex UI development. Nice language. A pleasant break from Java and static typing. Although still seems to be missing some stuff.

I like the way ES4 is going. I think they will fix some of the things I wish JavaScript/AS3 would do more like Ruby. I'm no Ruby expert, but if I thought I'd get a chance to do it regular at my day job, I'd focus on it more. But all static 'bashing' aside, I still like a language where I can chose to be static when it makes sense. I don't know how comfortable I'd be if I had to "run with scissors" all the time.