Live data from Hacker News

The Next Big Language

steve-yegge.blogspot.com

21–30 of 75 posts

Re: The Next Big Language

#21
post #15

I'm really asking myself when ECMA Script will take over the world. Everyone is talking about that it will be the NBL. It's not that I don't like ECMA Script but there is a shit lot to do to implement all those language features into ECMA Script. All those stuff and sure much more have to be done: - performance of eval() (yes, I even don't know if this is ever possible) - tools (great-eclipse-visual-studio-like IDE)…

performance of eval()

This will probably not happen, the general consensus is that eval is basically considered harmful and you should use new Fuction(argname, argname, argname, code) to do the same thing. ES5 strict mode places a number of restrictions on what eval can do.

tools (great-eclipse-visual-studio-like IDE)

This is tricky and less necessary for non-C/Java/C# languages but I assume you mostly mean code completion and minor refactorings. The mozilla JS team has a type inferencer for JS, which is the first step, but it's not particularly useful. I've been poking at this, so we'll see if I come up with anything. Someone will get to this at some point even if I don't actually manage to make anything useful. For integrated debugging, I know the cloud9 IDE (web based) has been messing with node.js/Chrome debugger integration but I haven't messed with it.

Destructuring bind (e.g. x, y = returnTwoValues())

http://wiki.ecmascript.org/doku.php?id=harmony:destructuring

Standard OOP with classes, instances, interfaces, polymorphism

http://wiki.ecmascript.org/doku.php?id=strawman:classes

Visibility quantifiers

access control via proxies: http://wiki.ecmascript.org/doku.php?id=harmony:proxies

Iterators and generators

Support available in Mozilla's implementation with the correct mime type. Brendan Eich wants to add them, but I can't find a harmony strawman for it (maybe it was accepted?). I do know yield is a reserved keyword in ES5 strict.

Namespaces and packages

Called modules: https://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v

Operator overloading

Not aware of anything.

Static typing and duck typing

Static typing is available in ActionScript3. Not aware of any efforts beyond this. I know there were proposals for type annotations in ES4 but I haven't heard much from ES5/Harmony in this area. I think most JS developers aren't particularly interested.

Solid string and collection libraries

Unlikely to be in the standard, look to implementations/userland libraries.

Re: The Next Big Language

#22
post #15

I'm really asking myself when ECMA Script will take over the world. Everyone is talking about that it will be the NBL. It's not that I don't like ECMA Script but there is a shit lot to do to implement all those language features into ECMA Script. All those stuff and sure much more have to be done: - performance of eval() (yes, I even don't know if this is ever possible) - tools (great-eclipse-visual-studio-like IDE)…

All that stuff would be nice to have, but I don't think they're required for it to be a widely useful language. What I think the minimal required set is:

- Fix "this". Even people who know what they're doing screw it up.

- Make keywords not reserved unless the language actually uses them. I mean seriously.

- Namespaces / packages / something.

- A package manager, like CPAN / Rubygems / whatever.

- A good IDE (even a half-assed attempt at code completion) and a debugger. I happen to really like Dashcode, I think it would be good if it were more generic.

Everything else on your list is great, but I think it can wait until later, or it's really just a feature of the language (not all languages have Smalltalk-style OO and That's Okay). Iterators and generators it actually has; operator overloading is widely reviled so I don't think that'll be a barrier to adoption.

Re: The Next Big Language

#23
I keep thinking that the Next Big Language will be a thing of re-evolution, e.g. someone going back to C and retracing steps of C++ but in a more sensible way.

Also, on a tangential note -- the garbage collection is a huge deal if an adoption of the NBL among C/++ programmers is considered. The only way is to have the garbage collection optional. Similarly to how D has it, but much much simpler. Something like adding new_gc operator (or a malloc_gc function) and to have two kinds of memory blocks - manually managed and garbage collected...

Anyway, it's just a thought from an old fart camp :)

Re: The Next Big Language

#24
post #20
post #2

Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community. I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline…

How was that a great guess? Certainly things could change, but very very very few people are doing server side JS right now. That could change, but I'm still pretty skeptical. Node.js (if that's what you're thinking of) is still very much in the experimental stage.

This coming from the guy who used to work on Google Apps Script.

Re: The Next Big Language

#25
post #20
post #2

Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community. I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline…

How was that a great guess? Certainly things could change, but very very very few people are doing server side JS right now. That could change, but I'm still pretty skeptical. Node.js (if that's what you're thinking of) is still very much in the experimental stage.

Incidentally, i actually am doing server side javascript, but on Rhino, instead of node. I'm certain that Stevey meant Rhino, rather than node when he wrote that particular blog post.

Re: The Next Big Language

#26
post #15

I'm really asking myself when ECMA Script will take over the world. Everyone is talking about that it will be the NBL. It's not that I don't like ECMA Script but there is a shit lot to do to implement all those language features into ECMA Script. All those stuff and sure much more have to be done: - performance of eval() (yes, I even don't know if this is ever possible) - tools (great-eclipse-visual-studio-like IDE)…

All that stuff would be nice to have, but I don't think they're required for it to be a widely useful language. What I think the minimal required set is: - Fix "this". Even people who know what they're doing screw it up. - Make keywords not reserved unless the language actually uses them. I mean seriously. - Namespaces / packages / something. - A package manager, like CPAN / Rubygems / whatever. - A good IDE (even a…

On keywords: "ES4 allows the use of keywords in contexts where they were prohibited in ES3, e.g., as field names in objects: {function:37}, o.try, and ns::catch are all legal." (http://www.ecmascript.org/es4/spec/overview.pdf, p35)

Re: The Next Big Language

#28
The NBL is not going to be Javascript but Lua. It's got some of the same architectural strengths as Javascript (functions are first class citizens, closures, good scoping), it's very fast (LuaJIT), integrates well in any environment and is highly customizable. See http://stackoverflow.com/questions/1022560/subtle-difference... for some differences....

Re: The Next Big Language

#29
This is exactly why I killed my own PL. My language was amazing for the class of problems I was solving until a new problem came in and I had to solve it down in the lower tier like a dog with my tail between my legs.

Re: The Next Big Language

#30
post #20
post #2

Ahh... I think we all miss Big Stevey. He role was never replaced and it's a shame for our entire community. I'm glad this was posted. It was written four years ago (Feb. 2007), and his quote is, "[The NBL] is going to arrive very soon (timeline: 18-24 months ...)" He later gave away that he was thinking the NBL was to be server-side Javascript. You have to hand it to him; that was a great guess, even if the timeline…

How was that a great guess? Certainly things could change, but very very very few people are doing server side JS right now. That could change, but I'm still pretty skeptical. Node.js (if that's what you're thinking of) is still very much in the experimental stage.

He doesn't say it will be ubiquitous in that timeframe. You'd have to be pretty crazy to think that. He means it will arrive. Which is correct. The thing is, javascript is what's available in all devices. And it's a pretty nice language.
Post reply on HN