Slashdot Mirror
Brendan Eich Explains ECMAScript 3.1 To Developers
VonGuard writes "On April 9, ECMA International produced the final draft for the first major update to JavaScript since 1999. It's called ECMAScript 3.1, but will soon be known as ECMAScript, Fifth Edition. You'll know it as JavaScript, the Next Generation. Mozilla will begin implementing these features after Firefox 3.5, and Microsoft is already showing prototypes behind closed doors. The question, however, is what this will change for JavaScript coders. To get those answers, I tracked down Brendan Eich, Mozilla's CTO and the creator of JavaScript. I transcribed the interview without any editorial since he explains, perfectly, what's changing for programmers. Long story short: Json will be safer, getters and setters will be standard, and strict mode will make things easier to debug."
From TFA, it sounds like they are moving a lot of the stuff you normally find in the more popular libraries into the language itself. That makes sense, but hardly a game changing innovation that web application development companies should be gearing up for.
With Microsoft cooperating to improve the language, now we can move on beyond the fifth edition, toward ECMAScript harmony.
Whatever happened to Embrace, Extend, and Extinguish?
Extend is right there in bold
Summation 2
FTA: A lot of JavaScript is forked. If the DOM is IE, use this version of the code, otherwise use this.
Until this changes throughout the entire web, ECMAScript will only be that other part of css. It's just too problematic to have to code separate DOM funtionality for every browser on the market.
As long as using jQuery doesn't change, I'm good. :)
I fear for all those poor websites with red backgrounds...
biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
I remember when Microsoft was "not unfriendly" to developers, before they decided that everyone producing a broadly useful application was their competition to be either absorbed or destroyed.
It is possible for them to be competitive without being the force of destruction that they became in the mid 1990's.
I'm holding out for ECMAScript 3.11 for Workgroups!
Probably around the time you realise that object-oriented doesn't mean class-oriented.
It is very sane right now. It is just a matter of thinking a bit differently than you were used to when having your c++ or java course.
Take plain c - it does not have classes either, only "objects", i.e. structs with function pointers. You have to construct the objects yourself.
Many people can live without c++/java style classes - they have for years and have created fantastic software. Javascript is fine the way it is, please don't opt to change it into something it is not. If you want something else, write a java interpreter and push it into firefox yourself.
JavaScript does OOP in a sane manner. It's not the same manner as many traditional OO languages, to be true -it's prototype-based instead of class-based- but it's every bit as sane in its own way. It's just different.
The major reason you find OOP in JavaScript to be "insane" is that you are tearing your hair out trying to shoehorn in this particular paradigm that the language wasn't designed to use: sure, you can do it, but it's a lot of extra effort for very little gain in the end. That's not a problem with the language, but with programmers who resist the flow of that language. Just let JavaScript be JavaScript, and you'll find that things get much saner, or at least a lot less maddening.
Seriously: what harm ever came from learning new ways to do things?
Everybody knows TNG just copied half its stuff from the original!
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
If you don't understand the expressive power and usefulness of functions as first class objects, you should really try using JavaScript differently. As for why you're using Object instances as classes, have you never used Java?
Also, you don't have to set the prototype all at once in a single object. The prototype keyword is used for functions that are common to all instances of the object; you can just as easily set the functions inside the constructor, but that creates a new function object for each instance instead of using one function object defined in the prototype and thus requires more memory. This allows you to change your object's behavior on the fly (if you so choose).
In short, OOP in ECMAScript is not 'totally retarded' at all, just outside your comfort zone. Try it first, THEN flame it, if you still think it's awful.
ECMAScript is a prototypal functional programming language. You don't just set members of an object by defining its prototype in an object literal.
You can also, by the power of closures, have private functions, private variables, and protected functions. (ECMAScript is interesting in that public member functions cannot access private variables, but protected functions can. Downside is that protected functions (defining them as this.foo = function() {}; in the constructor) are created new for each instance of the object, unlike the prototype (public) members.
While ECMAScript isn't built to enhance tail recursion, it's actually possible. For example, a continuous passing style fibonacci sequence calculator.
Not quite as readable as haskell or lisp, but still - proves that JavaScript is a true functional programming language.
Json has dethroned XML for pure data interchange
</quote>
Somehow I don't think so. "AJAJ" just doesn't have quite the same ring to it.
"No matter how cynical you get, it is impossible to keep up." -- Lily Tomlin
Anyone have a link?
Old story, "no it's not java" or "ECMAwhat?"
We get a new rev, add a name change update; let's call it something cool, oh, say ruby++ ?
you should be able to code in straight javascript in all browsers the same. obviously, you can't do that now. but that doesn't justify the existence of libraries, it just means they are temporary bandaids that should go away with the implementation of the next javascript (crossing fingers)
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
How are thee irrelevant, inflammatory and offtopic? Let me count the ways...
Seriously, what the eff does this have to do with the new release of JS? Pointing out that there was a bit of a struggle between Eich/Mozilla and Microsoft about the new additions to the language would at least have been on topic, but this?
Seriously, get out of the basement, wash and stop the useless bashing. There's such a lot of useful bashing to be done...
"I think it would be a good idea!"
Gandhi, about Internet Security
The names and version numbers are really confusing. The following is my understanding, which may be wrong -- if so, please correct me.
ecmascript 4==javascript 2==actionscript 3 ... If I'm understanding correctly, this was overambitious, turned out to be a dead end, won't happen.
ecmascript 3.1==ECMAScript, Fifth Edition ... This seems to be the more modest thing that they backed off and got a consensus for instead.
Find free books.
First, JavaScript is a very nice language indeed. If you've never learned functional programming, JavaScript is a good language to learn in. Why? You can actually do real work while learning! As for the new language spec...
Getters and setters are nice, but I'm not sure they serve a purpose in javascript--javascript is more functional than it is OO and I think people learning the language should change mindsets rather than the langage get bastardized to something it is not. I dunno, somebody can challenge me on this.
Good to see they are thinking about adding a "use strict". You aren't an adult language until you have a way to force variable declaration. Hopefully "use strict" will apply to a module or block, not to the entire project. I want to "strictify" my own JavaScript, but I dont want the browser to choke on some sloppy copy-and-paste deal from AdSense or analytics.
Lastly, JSON. There are a couple "gotchas" with it... namely when you generate JSON using a loosely typed language like Perl and try to feed it into a strongly typed language like C# (i.e. silverlight). Depending on the serializer / deserializer used on the strongly-typed side, you'll run into things.
For example, the deserializer in C# just might choke on this: // it will puke on this: // i am a string! // I am a postgresql date, but I'd also barf on ISO8601 // puke free: // I am an int! // i am a legit Date()
"themes": [
{
"theme_id": "34",
"last_mod": "2009-04-09 13:04:27.232-07"
},
{
"theme_id": 34,
"last_mod": new Date(3000, 00, 01, 00, 00, 00)
}
]
Why? Perl serialized the integers as a string. Depending on the deseralizer, it might choke on those strings if it was expecting a number. YUI would also be pissed off about the date not being a javascript Date()--good luck finding a serializer that produces such a thing! My point? These are some surprise gotchas you have to worry about when dealing with JSON. Not sure who is to "blame"--perl for being loosely typed, the deserializers for being to strict. This would be a problem with XML as well though.
aHahahahahahahahahahahahaha. Why it's the best thing about Javascript, writing the same code*browers different ways, and with chrome and safari Javascripting is just gonna get more and more fun. More Fun, MORE F.U.N.
The evil javascript hurts me. Evil I tells you!!!!
My ism, it's full of beliefs.
It sounds like they decided to go with shoring up the language as it is currently used rather than make sweeping new changes. Good for them. I'm not sure if it was Adobe's doing or Macromedia's, but they really threw out the baby with the bathwater with the "transition" from ActionScript 2 to ActionScript 3. Rather than fixing up the obvious problems with AS2, like silently swallowing errors and gaping holes in the functionality of core objects, they abandoned it entirely and replaced it with some bizarre mutant language from a parallel dimension. I still have to wonder why, if they were willing to completely abandon both backward compatibility and developer familiarity, they didn't just decide to switch to an existing language. As far as I can tell, the only thing that AS3 really accomplished was to reimplement Java, and poorly.
For a while, it looked like the next version of JavaScript was following down a similar path. Glad to see that's not going to be the case.
If I don't put anything here, will anyone recognize me anymore?
ECMA script, Java The Next Generation, JSon, WTF? Whatever happened to version numbers?
Currently hooked on AMP
...yes, but, does it work with java?
Good people go to bed earlier.
Not really. In "EEE", "extend" implies that the company unilaterally extends the standard that they've previously implemented ("embraced") with new features - for example, what MS did with Java in J++ in the past. In TFA, "cooperating" meaning "working as a part of language committee" - and that committee consists of many other companies, including direct MS competitors. There's no hidden catch here - MS is participating in proper discussion process, not overriding it.
In a similar vein, Microsoft "cooperates to improve" ISO C++, by having a number of people on the corresponding ISO committee (e.g. Herb Sutter). The same goes for HTML5, WS-* stack, XQuery, and many other standards that are implemented in whole or part in MS products.
Ah, so they can't even do EEE right anymore? ;)
I'd imagine the "Extend" bit is much harder if you're sharing your extensions with the community.
All comments are properties and trademarks of the voices in my head. Not like I'm gonna claim them.
C# and Perl happen to be also strongly typed and losely typed, respectively, but that isn't essential to your example. The distinction you're looking for isn't "strongly typed" vs "loosely typed", but "statically typed" vs "dynamically typed".
"ECMA" tells it all.
FTA: A lot of JavaScript is forked. If the DOM is IE, use this version of the code, otherwise use this.
Not much of *Javascript* itself is forked. The *DOM* is quite thoroughly forked. One might even say forked over. But as other people have pointed out, Prototype and Dojo and jQuery and the like tend to mitigate that problem.
Tweet, tweet.
JSON's not always fatter. Particularly when you have information stored as child nodes rather than attribute nodes (one-many relationships rather than one-one relationships tend this way), XML can get fatter pretty quickly.
I suspect the JSON love has to do with the fact that if you're already working in Javascript, it's just more javascript, and there's zero mystery about how to work with it. Not that XML is rocket science, but with JSON, it's pretty much as easy as eval() if you trust the server.
Overall, I like what Steve Yegge had to say: "XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text." It's probably a little more complicated than that (the fatter/thinner issue is one, compression is another), but it's a decent heuristic.
Tweet, tweet.
You really think I was gonna fill in the guts of a sample function? .click() hooks the onclick event.
{"name":"Jack (\"Bee\") Nimble","format":{"type":"rect","width":1920,"height":1080,"interlace":false,"frame rate":24}}
<o name="Jack ("Bee") Nimble"><format type="rect" width="1920" height="1080" interlace="false" frame_rate="24"/></o>
Anyway, it's a difference of 8 characters in JSON's favor. Unlike XML attributes, no whitespace between JSON properties is necessary. And for that matter, while they can be shoehorned to present the same information, they can serve somewhat different purposes. But really, as a data format, the advantages that JSON sways me with are:
- JSON is identical in text form to the same data structure in JS, which is great since JS is where I do most of my work
- JSON is a hell of a lot more readable, particularly as the data grows (it is also less annoying to write, for whatever little you may be writing either)
- Parsing JSON is dead simple in every language I work with, which is not the case for XML
Yes, it also has marginal bandwidth benefits, but that's not the only thing one looks for in a data format.
You know that for many programmers, that's sort of like saying "not quite as humid as Death Valley", right?