Saturday, February 10, 2007

The Next Big Language




There seems to be a long period of initial obscurity for any new language. Then after that comes a long period of semi-obscurity, followed by total obscurity.
—Paul Bissex

Note: after I wrote this entry, one or two commenters speculated that I might be talking about something Google is doing. They're barking up the wrong tree: I may not be the smartest feller ever to fall off the cabbage truck, but I'm not -that- stupid. The speculation in this blog is all based on stuff I've read on the net. It's purely my own ideas and opinions, and I don't speak for Google (nor in today's entry, even -about- Google). You'll have to look beyond Google for clues about NBL. Enjoy!

People are always asking me to comment on their new programming language they're designing. I don't know about you, but I find that pretty funny, given the general trend of my comments on existing languages. I mean, if you saw someone walking around kicking people directly in the metaphorical groin, would you go up and beg them to do it to you too?

And I feel bad about giving them my feedback, because I don't want to discourage them. It's just that nobody will ever, ever use their language. The odds are impossibly stacked against it. Not to be discouraging, of course.

But people are still always trying to make new languages, because we have yet to see a language that is (a) popular and (b) doesn't suck. Do you disagree? If so, I don't mind. It just means your standards aren't as high as mine. Nothing wrong with that.

Back when I was in the Navy, just out of boot camp, an otherwise entirely forgettable petty officer first class instructor of ours offered us, unasked and free of charge, his sage advice on how to pick up women at a bar: "Go ugly early." With this declaration, he had made it clear that he and I thought rather differently about certain things in life. But I had to hand it to him: here was a man of conviction. He didn't care what other people thought of him, or for that matter, what he thought of himself. He had defined his philosophy and he was sticking with it.

And in a sense, he taught me a valuable lesson, although it's not the one he probably thought he was teaching me. I'll pass it on to you, unasked and free of charge. If you want to spare yourself a lot of angst in deciding which programming language to use, then I recommend this simple rule: Go ugly early. C++ will go out with you in a heartbeat.

For my part, I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer. I've said it before, and I'm sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff. I say that without having the slightest frigging clue what "chaff" is, but let's assume it's some sort of inferior wheat substitute, possibly made from tofu.

But I really need to stop spending time telling people individually why their languages are doomed to fail. Instead, I'll summarize it in today's blog entry.

Summary: your language is doomed to fail, with probability 1 minus epsilon. If you fell off a thirty-story building, you might survive (anyone else watch the last episode of Heroes? wasn't that an awesome scene?) but for all practical purposes the odds are nil.

Before I go into slightly more detail, I'll let you in on a secret. Just between you and me. Nobody else will know but us. The secret is that last week I got an insider's tip: I know what the Next Big Language is going to be.

You probably imagine some sort of Old Boys Network that's responsible for deciding what we unwashed masses are going to use next. You know, a bunch of corporate executive cigar-chomping porcine thugs sitting on each others' boards, conspiring and maneuvering to wheel and deal with mergers and consolidations, and suddenly language XYZ is endorsed by all the big companies at once, so you have to learn it or you'll get fired and deported and have to go live on the streets in some fly-specked third world country where, ironically, you don't speak the language there either. Well, that's exactly how it works; how the hell do you think we all wound up programming in Java?

Seriously, though. I know I have a very slight tendency to exaggerate a wee bit now and again, for dramatic effect. And I don't always stop at stretching my metaphors; sometimes I drag them out to the back alley and beat the living crap out of them. But it should be clear that there's a grain of truth to my cigar-chomping executives: most successful languages have had some pretty serious corporate backing. C++ had AT&T and Microsoft. Java had Sun and IBM. C# and Visual Basic had Microsoft. Perl basically had O'Reilly. JavaScript had Netscape, Sun, and Microsoft (among others). And so on.

And I found a tip — a rather detail-packed one at that — as to which way the wind is blowing. Let's face it: I've been digging into this story for years, so it should be no surprise that I got the scoop. (Hint: the "tip" was synthesized from reading a bunch of public web pages, so you've got all the clues you need.)

Unfortunately I can't tell you what language it is. For one thing, you probably wouldn't believe me. For another, it wouldn't be fair; there are plenty of contenders out there, and it seems like they should all have a fighting chance. Instead, I'm going to outline the characteristics that a language needs in order to be a megahit. You won't like some of them, and I sure as hell don't like some of them, but we're talking stark reality here. It's not a matter of opinion.

I'm really killing two birds here: by telling you where languages are headed, I'm giving you enough hints to figure out what the Next Big Language is without committing to anything, thereby evading the inevitable jihad against me if I were to say its name. Second, I'm giving language designers valuable information that should help them get their language adopted, if that's their goal.

But first, some preliminaries and caveats are in order.

You won't be deported to Columbia

Just because the Next Big Language (NBL from now on) is going to arrive very soon (timeline: 18-24 months, as far as I can tell, which in language terms means "imminent") doesn't mean your language is going away. You won't lose your job, so don't freak out on me.

What it does mean is that there's going to be a massive momentum shift, so if you start preparing now, it's not going to hit you as hard when it happens. You'll be ready.

Heck, if you're lucky, you already know the language — at least the subset of it that exists today. If so, you've got a big head start.

NBL does not replace C++

NBL is garbage collected. There will always be a bunch of engineers who think that's evil, and they'll continue to use C++.

C++ does need to get replaced someday. It's just horrid, and everyone knows it. However, there aren't very many people trying to replace it, either. The only contenders I'm aware of are Objective C and the D Programming Language.

D's a really beautiful language. By rights it should be the next C++. However, C++ programmers won't have it because it's garbage collected (even though it can be disabled, and even though Stroustroup himself is now advocating adding garbage collection to C++). Walter Bright is one hell of a lot smarter than the C++ programmers who won't look at his language, and he has demonstrated that D is as fast as or faster than C++ and nearly as expressive as Ruby or Python. It's a secret weapon just waiting to be seized by some smart company or open-source project.

But nobody ever accuses programmers of being wise.

I don't know much about Objective C, to be honest; I've read one or two books about it, and it looks decent-ish, but not inspiring in the way that D is (for instance.) So I can't say much about it. Seems kinda ho-hum to me.

Anyway, most of the language research and effort and creativity out there, both in academia and industry, is focused on higher-level languages, so it looks like C++ will continue to struggle happily in its tar pit for some years to come.

NBL isn't about winning beauty contests

When I refer to NBL, the Next Big Language, I specifically mean the next popular language. I.e., a language that you yourself will wind up learning and actually using. You can point to all sorts of languages, both existing and in the works, that are prettier than NBL. Doesn't matter, though. Heck, as you'll see (Rule #1), beauty is one of the obstacles to adoption.

If your goal as a language designer is to design a language that meets your own personal sense of aesthetics, then you're an artist, and I salute you. For my part, I'm looking for the middle ground between hard-nosed I-don't-care pragmatism (in which case you go ugly early, use Java or C++, and be done with it) and idealistic better-world optimism. And I think a lot of other people are too.

In any case, I'm not claiming that NBL is a great language; I'm just saying it doesn't suck. In practice it's actually quite good, and it will be very, very popular. NBL isn't the 100-year language, but it will definitely be the 10- to 20-year language.

And now, on to the features. Get ready to get mad.

The Language Arena

Here's how you compete in the programming language arena today. Follow these rules and you stand a chance. Ignore them and your language will be Lion Chow.

Rule #1: C-like syntax

C(++)-like syntax is the standard. Your language's popularity will fall off as a direct function of how far you deviate from it.

There's plenty of wiggle room in the way you define classes and other OOP constructs, but you'll need to stick fairly closely to the basic control-flow constructs, arithmetic expressions and operators, and the use of curly-braces for delimiting blocks and function bodies.

This is because programmers are lame, but hey, it's your target audience. Give the people what they want.

People sometimes ask me why I think C's syntax is bad. The reason is pretty simple: it's too complicated. Well, C's wasn't so bad, but when you throw OOP into the mix (whether it's Java's, or C++'s, or D's, or anyone's), the grammar becomes enormously complex, with hundreds of productions.

It might feel, as a programmer using a C-like syntax, that the syntax is helping you out. Unfortunately, as soon as you try to write code that deals with the language itself, you hit a wall.

Case in point: Java folks always wish they had a better Java code formatter. The best one ever written was Jalopy, but it never took off, in part because it wasn't open source, but also in part because its manual was astoundingly long and complicated. Why? Because it provided rules for customizing every last one of the hundreds of edge cases in Java's syntax. And this was before Java 5 came along and made it even more complicated with generics and so on.

So people settle for the one built into Eclipse, but nobody ever goes in and messes with its actual internal mechanisms themselves, because even if they're unhappy with the way it handles certain syntactic cases, it's too damned complicated to bother with.

Most programmers don't realize how often they need to deal with code that processes code. It's an important case that comes up in many, many everyday situations, but we don't have particularly good tools for dealing with it, because the syntax itself prevents it from being easy.

That's why it's bad.

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.

Whatever. Now you know why I think C's syntax is bad. It's because it is bad.

But bad or not, NBL will have approximately C-like syntax because if it doesn't, most programmers won't give it a second glance.

Sigh.

Rule #2: Dynamic typing with optional static types.

There are two ways to make a language. The old way is to make it super static, to protect programmers from hurting themselves. 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. There's nothing more fun than having your compiler tell you: "Error: expected type (int, int, int) but got type (int, int, int)". Sheesh.

When you make a static language, you will be forced to add dynamism to it, because otherwise it's like programming in a straitjacket. If you don't add dynamic features to your static language, then assuming everyone hasn't ditched it entirely, they will start building in the dynamic features themselves, no matter how hard it is, and how awkward they are to use.

The other way to design a language is to make it dynamic, and then you'll be forced to add static checks in later. If you don't, then programmers will start simulating static checks using assertions and preprocessors and all manner of other hacks, in an effort to help lock things down once they've stabilized past the prototyping phase.

Adding in optional static types is the ideal solution. It helps with performance, it helps with code reliability and (possibly) readability, it helps IDEs navigate your code, and most importantly, it helps combat the incredible FUD that dynamic languages inspire in people who come from static backgrounds.

It should be pretty obvious that dynamic + optional static types is a better approach than static + optional dynamic features. The latter is premature optimization, plain and simple: the root of all evil.

So NBL will be a dynamic language with optional static types.

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.) Not that the standard system is any better, but it's what people want.

Rule #3: Performance

NBL will perform about as well as Java. That means if it's one of the big existing dynamic languages out there, something major is going to have to happen with performance.

It turns out that eval() is one of the key things that gets in the way of performance optimizations. It can easily invalidate all sorts of otherwise reasonable assumptions about variable bindings, stack addresses and so on. It's also pretty important, so you can't just get rid of it.

So NBL will have to do something clever about eval.

Generally speaking, NBL will have to have a much greater focus on performance than so-called "scripting languages" have had in the past. 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.

It sounds impossible, I know. But it's not. Those compiler writers are a tricky bunch, and they have decades of experience. A bunch of them got together and did a lot of head-scratching over NBL, and the result is going to perform quite nicely.

Rule #4: Tools

Let's face it: one of the biggest reasons people haven't adopted Ruby or Python is the lack of IDE support. IDEs like Visual Studio and Eclipse have set the bar and the expectations for most programmers out there.

I can't tell you how many times I've heard people say they wouldn't use Ruby because it lacks automated refactoring tools. Ruby doesn't actually need them in the way Java does; it's like refusing to switch to an electric car because there's no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want.

So NBL will have great tools. They might not be Java-great on Day One of NBL's reign, but they'll be a lot better than the options available for Perl/Python/Ruby/Tcl and the rest of the popular dynamic languages out there today.

Rule #5: Kitchen Sink

Word on the street is that all languages are evolving towards each other. It's another way of saying they all have feature envy. So NBL is going to have to play along.

Here's a short list of programming-language features that have become ad-hoc standards that everyone expects:
  1. Object-literal syntax for arrays and hashes
  2. Array slicing and other intelligent collection operators
  3. Perl 5 compatible regular expression literals
  4. Destructuring bind (e.g. x, y = returnTwoValues())
  5. Function literals and first-class, non-broken closures
  6. Standard OOP with classes, instances, interfaces, polymorphism, etc.
  7. Visibility quantifiers (public/private/protected)
  8. Iterators and generators
  9. List comprehensions
  10. Namespaces and packages
  11. Cross-platform GUI
  12. Operator overloading
  13. Keyword and rest parameters
  14. First-class parser and AST support
  15. Static typing and duck typing
  16. Type expressions and statically checkable semantics
  17. Solid string and collection libraries
  18. Strings and streams act like collections

Additionally, NBL will have first-class continuations and call/cc. I hear it may even (eventually) have a hygienic macro system, although not in any near-term release.

Not sure about threads. I tend to think you need them, although of course they can be simulated with call/cc. I've also noticed that languages with poor threading support tend to use multiprocessing, which makes them more scalable across machines, since by the time you've set up IPC, distributing across machines isn't much of an architectural change. But I think threads (or equivalent) are still useful. Hopefully NBL has a story here.

Rule 6: Multi-Platform

NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well.

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.

It's all about not sucking

The features I've outlined don't make NBL a great language. I think a truly great language would support Erlang-style concurrency, would have a simpler syntax and a powerful macro system, and would probably have much better support for high-level declarative constructs, e.g. path expressions, structural dispatch (e.g. OCaml's match ... with statement) and query minilanguages. Among other things.

The features I've outlined are basically the minimal set of requirements for not sucking. At least off the top of my head; I've probably overlooked a few.

Well... OK, I think C-style syntax kinda sucks, for reasons I've outlined, but it's a price I'm willing to pay, because I think there's no choice. Rule #1 is in there strictly to support popularity.

Looking at the list, it's amazing that you have to work so hard just to meet the minimum standard for not sucking. The bar has really gone up for programming languages.

Not to discourage you or anything.

Is NBL (the one whose name I won't tell you) guaranteed to be the Next Big Language? I think it's got about a 90+% chance, but there's still hope for the other runner-ups.

For instance, it might be possible to get away with non-C syntax, provided you offer everything else I've listed here, but you'll have to bear in mind that you're competing against NBL, which has all the features of your language plus C-like syntax. So your language would have to offer something not in this list that gives it a huge leg up on NBL. (And I'm afraid simpler syntax alone won't do it; you're going to have to offer something that compensates for your lack of C syntax, because that's just how programmers are.)

So it's possible. But my bet is on NBL.

And now, if you'd like to see some excellent variations on the old game of Shoot The Messenger, enjoy the comments!

139 Comments:

Blogger Chris said...

JavaScript 2 FTW

12:54 AM, February 11, 2007  
Blogger KissTheGoat said...

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.

1:01 AM, February 11, 2007  
Blogger Brian Guthrie said...

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?

1:51 AM, February 11, 2007  
Blogger Thierry Chatel said...

Groovy is not that far from the requirements list.

2:10 AM, February 11, 2007  
Blogger Sabin said...

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 :)

2:13 AM, February 11, 2007  
Blogger timmy said...

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.

2:22 AM, February 11, 2007  
Blogger Paul said...

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?

2:27 AM, February 11, 2007  
Blogger Jonathan said...

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.

2:31 AM, February 11, 2007  
Blogger Paul Johnson said...

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.

3:23 AM, February 11, 2007  
Blogger Alpha Man said...

You wrote all of that in an hour? :-)

3:26 AM, February 11, 2007  
Blogger kathy said...

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.

3:57 AM, February 11, 2007  
Blogger Andreas Bogk said...

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.

4:04 AM, February 11, 2007  
Blogger Justin D-Z said...

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.

4:13 AM, February 11, 2007  
Blogger Bart Vandendriessche said...

Sounds like scala fits alot of the description.

4:16 AM, February 11, 2007  
Blogger James said...

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

4:44 AM, February 11, 2007  
Blogger James said...

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

5:13 AM, February 11, 2007  
Blogger Bruce said...

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.

6:05 AM, February 11, 2007  
Blogger James said...

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.

6:23 AM, February 11, 2007  
Blogger Christopher S. Penn said...

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

6:31 AM, February 11, 2007  
Blogger markm said...

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

6:33 AM, February 11, 2007  
Blogger Sushovan De said...

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

6:34 AM, February 11, 2007  
Blogger hovik said...

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?

6:39 AM, February 11, 2007  
Blogger hovik said...

(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?)

6:52 AM, February 11, 2007  
Blogger pcloutier said...

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).

7:53 AM, February 11, 2007  
Blogger Neil said...

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?

8:38 AM, February 11, 2007  
Blogger Romulo said...

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.

9:22 AM, February 11, 2007  
Blogger bioprocessor said...

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

9:27 AM, February 11, 2007  
Blogger BillD said...

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

9:36 AM, February 11, 2007  
Blogger Igor said...

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

9:39 AM, February 11, 2007  
Blogger al said...

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

10:10 AM, February 11, 2007  
Blogger Mark said...

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

10:30 AM, February 11, 2007  
Blogger fishbane said...

ML# is the answer!

10:40 AM, February 11, 2007  
Blogger gnuvince said...

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?

11:10 AM, February 11, 2007  
Blogger Ben Kruger said...

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!

11:19 AM, February 11, 2007  
Blogger Leo said...

This comment has been removed by the author.

11:24 AM, February 11, 2007  
Blogger Ilyak said...

arc?

11:41 AM, February 11, 2007  
Blogger Karl said...

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. ;]

11:47 AM, February 11, 2007  
Blogger Ilyak said...

No, it really looks like javascript 2.0.

11:56 AM, February 11, 2007  
Blogger Matt Brubeck said...

> arc?

lol!

12:01 PM, February 11, 2007  
Blogger Aristotle said...

C-like syntax puts Ruby and Python out of the race. I was thinking Perl 6 might be it when I read “optional static typing”, but it seemed entirely out of character for Steve to call any Perl non-sucky. :-) And indeed then comes the “JVM out of the box” issue, which pretty much shakes the field down. Javascript 2 is the only good bet I can think of; although I don’t know it well enough to judge it only points in Kitchen Sink. There are some other interesting JVM-based languages, but they all seem way too obscure to suddenly hit the limelight. It does make a certain amount of sense too; you bet there will be pretty strong corporate backing.

12:16 PM, February 11, 2007  
Blogger tosch said...

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

1:22 PM, February 11, 2007  
Blogger Jerry said...

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.

1:50 PM, February 11, 2007  
Blogger hypermatt said...

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.

1:56 PM, February 11, 2007  
Blogger Parveen 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."

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

2:14 PM, February 11, 2007  
Blogger albert bulawa said...

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.

2:42 PM, February 11, 2007  
Blogger Jonathan said...

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.

3:35 PM, February 11, 2007  
Blogger Douglas Karr said...

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

3:46 PM, February 11, 2007  
Blogger JimDesu said...

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.

4:17 PM, February 11, 2007  
Blogger Doug said...

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.

4:19 PM, February 11, 2007  
Blogger m/k said...

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.

4:20 PM, February 11, 2007  
Blogger Anton said...

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

5:53 PM, February 11, 2007  
Blogger Sam said...

Personally, I think the details that make up the Next Big Language are irrelevant. The Next Big Language will be the one that makes it easiest to develop The Next Big Application. C had UNIX, C++ had MFC (gag, but still), Objective C has all the indie Mac software, Java has cross-platform server binaries... What will NBL bring to the table that will actually enable a new application? Because without, no one will switch.

If you want NBL to be the NBL for the desktop, it better have a kick-ass GUI-building tool, enable responsive UIs (unlike Java's default lazy dynamic linking), and have a fairly slim runtime. If you want it to win server-side, it better have great RDB support, integration with SOA architectures, etc.

In short, it's not really about the language at all, which is why sucky languages win. It's ONLY about the environment that gets built around the language, and what the language enables.

6:21 PM, February 11, 2007  
Blogger Vivek said...

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

8:49 PM, February 11, 2007  
Blogger Shawn Oster said...

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.

9:47 PM, February 11, 2007  
Blogger Mario said...

JRuby ... ;o)

1:23 AM, February 12, 2007  
Blogger Kyle's blog said...

+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.

1:44 AM, February 12, 2007  
Blogger Jatan said...

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.

2:02 AM, February 12, 2007  
Blogger Molly said...

Progress ABL?
Molly

4:38 AM, February 12, 2007  
Blogger Karl Guertin said...

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.


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?

JavaScript has a prototype based class system, which is definitely not a "standard" one.

JavaScript definitely has a prototype based class system. ECMAv4 layers a traditional looking system over it. See Brendan Eich's presentation on JS2. In particular, this is on slide 27.

The two additional platforms are the browser and flash.

The Next Big Language will be the one that makes it easiest to develop The Next Big Application.

Like... any new web app in the past year and a half? ;]

5:52 AM, February 12, 2007  
Blogger Cormac said...

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.

6:31 AM, February 12, 2007  
Blogger Lexx said...

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.

6:51 AM, February 12, 2007  
Blogger fatalis said...

JavaScript was backed by Sun? WTF are you smoking?

7:15 AM, February 12, 2007  
Blogger nymbyl said...

This comment has been removed by the author.

7:17 AM, February 12, 2007  
Blogger Daniel said...

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 ?

7:25 AM, February 12, 2007  
Blogger Trissie said...

Pike?

7:54 AM, February 12, 2007  
Blogger Danno said...

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

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

Mostly not written to yet...

9:47 AM, February 12, 2007  
Blogger Brendan Eich said...

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

12:32 PM, February 12, 2007  
Blogger marcell said...

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

1:05 PM, February 12, 2007  
Blogger al said...

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

1:06 PM, February 12, 2007  
Blogger Diogo said...

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.

1:48 PM, February 12, 2007  
Blogger Parveen said...

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".

5:58 PM, February 12, 2007  
Blogger DrPizza said...

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.

6:22 PM, February 12, 2007  
Blogger Jesse said...

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

8:00 PM, February 12, 2007  
Blogger Alexandre said...

"[...] 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?

9:40 PM, February 12, 2007  
Blogger Gabriele said...

Of course it's PHP!

12:51 AM, February 13, 2007  
Blogger Bill St. Clair said...

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

3:30 AM, February 13, 2007  
Blogger Terje said...

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.

3:50 AM, February 13, 2007  
Blogger Karl Guertin said...

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

You're assuming I haven't. I've been following concurrency research for years on LtU because I'm interested in being well positioned for the transition to concurrency. It's the sort of issue that you'd expect to affect people's choice in programming languages but I'm not convinced it'll be a deciding factor.

Your initial post stated that Steve's NBL has to be good for plumbing code and listed system level embedded code as an example. My assertion is that it does not. I pointed out that Java does not fill that role and C does. If Java is the current big language, the next big language does not need to fill the role of C either.

If you think that the current performance of Firefox is indicative of JS2, you seem to not be writing about at the same ECMAScript that everybody else is writing about. It's my turn to suggest you read the mozilla xtech slides that have been linked a couple times and Brendan Eich's thoughts on the subject of concurrency in Javascript and Mozilla.

All the best.

6:04 AM, February 13, 2007  
Blogger watters said...

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".

7:14 AM, February 13, 2007  
Blogger Tony said...

"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...

8:25 AM, February 13, 2007  
Blogger me22 said...

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

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

9:04 AM, February 13, 2007  
Blogger Yassine said...

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.

10:21 AM, February 13, 2007  
Blogger cayblood said...

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.

12:46 PM, February 13, 2007  
Blogger Parveen said...

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)

1:08 PM, February 13, 2007  
Blogger rami said...

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

1:52 PM, February 13, 2007  
Blogger Slobodan said...

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

3:35 PM, February 13, 2007  
Blogger Timasmith said...

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

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

6:09 PM, February 13, 2007  
Blogger Oliver said...

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

6:18 PM, February 13, 2007  
Blogger Yassine said...

adobe Apollo?

4:08 AM, February 14, 2007  
Blogger Bruce said...

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

7:40 AM, February 14, 2007  
Blogger Steve said...

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.

8:16 AM, February 14, 2007  
Blogger Ryan said...

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. ;-)

2:43 PM, February 14, 2007  
Blogger Les B said...

Interesting post, but also puzzling

The language will become the next big one only if it has significant advantages over any language currently in widespread use.

For that reason I was expecting the post to end by comparing the NBL with various popular language such as java and C++.

Perhaps that will be the next post?

4:24 PM, February 14, 2007  
Blogger Ken Egozi said...

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.

1:03 AM, February 15, 2007  
Blogger Peter said...

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?

1:37 PM, February 15, 2007  
Blogger garyLambda said...

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-

3:32 PM, February 15, 2007  
Blogger Brendan Eich said...

"As Dorothy Parker would say, there is no there, there."

That was Gertrude Stein.

JS has a soul, a fragment of Self's.

/be

6:07 PM, February 15, 2007  
Blogger Samantha said...

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

5:55 AM, February 16, 2007  
Blogger David said...

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

11:06 AM, February 16, 2007  
Blogger Ed Borasky said...

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

8:45 AM, February 17, 2007  
Blogger Ed Borasky said...

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

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

8:52 AM, February 17, 2007  
Blogger Peter said...

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

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

8:56 PM, February 17, 2007  
Blogger zooplah said...

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.

6:11 PM, February 18, 2007  
Blogger KBilly said...

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

1:54 PM, February 19, 2007  
Blogger Jesse said...

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?

11:33 AM, February 20, 2007  
Blogger Racer said...

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?

1:48 AM, February 21, 2007  
Blogger Vinay Sajip said...

"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.

6:31 AM, February 21, 2007  
Blogger E.Z. said...

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.

1:05 PM, February 21, 2007  
Blogger Evgeni Sergeev said...

That language is clearly Boblin.

9:33 PM, February 21, 2007  
Blogger Olie said...

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..." ;)

7:05 PM, February 23, 2007  
Blogger Duncan said...

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

5:08 AM, February 24, 2007  
Blogger z0ltan said...

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.

8:07 PM, February 25, 2007  
Blogger Dan Cross said...

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....

6:43 AM, February 26, 2007  
Blogger progga said...

F#

2:20 PM, March 01, 2007  
Blogger mr_mischief said...

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.

8:44 AM, March 02, 2007  
Blogger Inash said...

Probably C++0x.

4:55 PM, March 03, 2007  
Blogger Alok said...

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.

8:05 PM, March 05, 2007  
Blogger Ray said...

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.

1:57 PM, March 08, 2007  
Blogger JasonBunting said...

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.

11:50 AM, March 27, 2007  
Blogger JasonBunting said...

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

11:52 AM, March 27, 2007  
Blogger Austin said...

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...

10:46 PM, March 27, 2007  
Blogger Nicolas Cannasse said...

+1 for haXe !

7:12 AM, March 29, 2007  
Blogger bruno said...

haXe for sure!

12:54 AM, April 01, 2007  
Blogger Ravi said...

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.

11:46 AM, April 26, 2007  
Blogger Austin said...

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.

9:42 AM, April 28, 2007  
Blogger Chris said...

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.

7:30 AM, May 02, 2007  
Blogger george said...

Ed Borskiy, You are an idiot when it comes to computer processors!!! INTEL'S IMPLEMENTATION OF X86-64 IS A CLONE AMD-64

1:17 PM, May 10, 2007  
Blogger david said...

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

1:10 AM, May 16, 2007  
Blogger Juin said...

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. :)

4:29 AM, May 19, 2007  
Blogger Oscar said...

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.

4:17 AM, May 21, 2007  
Blogger Andrew said...

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

9:43 AM, June 25, 2007  
Blogger Keith said...

Not sure why anyone hasn't mentioned Lua.

Fantastic language.

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

5:40 AM, July 02, 2007  
Blogger kaldrenon said...

Visual Basic?

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

9:31 AM, July 06, 2007  
Blogger Lonnie said...

"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

4:45 PM, July 11, 2007  
Blogger Ghost Ship said...

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.

7:12 AM, August 08, 2007  
Blogger mjgiarlo said...

N00bz, clearly it -is- JS2.

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

2:56 PM, August 17, 2007  
Blogger Stuart Hacking said...

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++.

2:32 PM, September 24, 2007  
Blogger Jon Harrop said...

F#

10:46 PM, September 24, 2007  
Blogger Todd said...

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.

9:36 PM, December 22, 2007  

<< Home