3 ms·

JavaScript is a strange beast. The semantics of the language are, in my opinion, awesome and awful in different ways. Awesome: prototypes, first-class functions

JavaScript is a strange beast. The semantics of the language are, in my opinion, awesome and awful in different ways. Awesome: prototypes, first-class functions, dynamic function scope (not sure if there's a proper name for this), jQuery. Awful: the this keyword is confusing (but powerful once you learn it), type coercion, the API. The standard API is the reason that people care about "the good parts" of JavaScript. jQuery is so popular is because it allows you to turn away from the document.getElementById sort of operation (ugly code) and turn it into $("#id").filter().each().etc(). People don't like JavaScript because of what it is, but what it can be. There are so many examples to choose from: jQuery (DOM API, data requests, standard library "extensions"), jPlayer (multimedia), Node.js (server, native API), Mustache (templating), Meteor (dynamic MVC). I am by no means an expert, but I can appreciate that JavaScript has turned into a serious language. JavaScript is not the holy grail of web programming languages, and I am sure that something greater will succeed it, but for now there is a lot we can do with it.

pilif 14y ago
> the document.getElementById sort of operation which looks like it was designed in 10 days (all due respect to Brandon Eich) document.getElementById() isn't part of JavaScript but part of the DOM Level 2 spec that came out years after JS. JS was first seen in Netscape 2.0 in 1995 whereas DOM level 1 was specified in 1998 but didn't in fact yet contain document.getElementById. That one was added in DOM Level 2 in 2000, so five years after JS. As such it was not designed by Brendan Eich, nor was it created in 10 days. No. This is the work of a committee that was heavily influenced by the way Java does it which is understandable because when DOM1 came out it looked like Java is going to be the be all end all of Computer languages. The "library" that comes with JS is really small (methods on String, RegEx, Date and Array). Everything else we owe to the W3C which has created an API that was all but made for the language it was going to be used from most of the time. (edit: I got my dates and dom levels mixed up - fixed)
- fruchtose 14y ago
  Ah, my bad. Next time I will do more research before running my mouth.
- yuhong 14y ago
  Actually it was in DOM1 HTML and moved to Core in DOM2.
masklinn 14y ago
> Awesome: prototypes Meh. I still have to write that rant, but javascript's "prototypes" are a boondoggle, they've got nothing to do with Self's prototypes[0] and don't provide anything more than classes do in nice dynamic languages (you can, in fact, do more fucking around with Python's types than with Javascript's prototypes). For all intents and purposes, Javascript's so-called prototypes are shitty single-inheritance classes without the sugar. > dynamic function scope (not sure if there's a proper name for this) Not sure what you mean by "dynamic function scope", since you don't seem to like `this` (which is indeed complete garbage, but is sorta dynamically scoped) I'm guessing you mean lexical closures? The part where a nested function has read/write access to bindings created in its outer functions/scopes? > for now there is a lot we can do with it. There's also a lot we could do with Fortran and Cobol. That's no bloody excuse. [0] in Self, prototypes are just the thing you clone to get a basic object, they're just a template. They're not a unit of code reuse or inheritance: that's the job of mixins[1] [1] which, again, are very different from what you get in JavaScript or Ruby (though Ruby is closer): in Self, a mixin is an object you link to your own via a "parent slot", a special type of slot used for message resolution. When a message is sent to an object, the runtime first checks all of the object's non-parent slots and if there's no match it follows the parent slots recursively to try and find a slot matching the message.
- yuchi 14y ago
  While you're generally right, you must not forget about Harmony Proxies and all that meta-programming fuzz. While the final result of a prototypal class hierarchy is in fact very similar to pseudo-classic inheritance, remember that it's just the result of an internal, manual, modifiable process.
  - masklinn 14y ago
    > While you're generally right, you must not forget about Harmony Proxies and all that meta-programming fuzz. All of which (and more) is available in class-based dynamically typed languages
- wwweston 14y ago
  > don't provide anything more than classes do in nice dynamic languages How would you do in-place method mutation in something like Python or Ruby?

pilif 14y ago

> the document.getElementById sort of operation which looks like it was designed in 10 days (all due respect to Brandon Eich) document.getElementById() isn't part of JavaScript but part of the DOM Level 2 spec that came out years after JS. JS was first seen in Netscape 2.0 in 1995 whereas DOM level 1 was specified in 1998 but didn't in fact yet contain document.getElementById. That one was added in DOM Level 2 in 2000, so five years after JS. As such it was not designed by Brendan Eich, nor was it created in 10 days. No. This is the work of a committee that was heavily influenced by the way Java does it which is understandable because when DOM1 came out it looked like Java is going to be the be all end all of Computer languages. The "library" that comes with JS is really small (methods on String, RegEx, Date and Array). Everything else we owe to the W3C which has created an API that was all but made for the language it was going to be used from most of the time. (edit: I got my dates and dom levels mixed up - fixed)

fruchtose 14y ago
Ah, my bad. Next time I will do more research before running my mouth.
yuhong 14y ago
Actually it was in DOM1 HTML and moved to Core in DOM2.

masklinn 14y ago

> Awesome: prototypes Meh. I still have to write that rant, but javascript's "prototypes" are a boondoggle, they've got nothing to do with Self's prototypes[0] and don't provide anything more than classes do in nice dynamic languages (you can, in fact, do more fucking around with Python's types than with Javascript's prototypes). For all intents and purposes, Javascript's so-called prototypes are shitty single-inheritance classes without the sugar. > dynamic function scope (not sure if there's a proper name for this) Not sure what you mean by "dynamic function scope", since you don't seem to like `this` (which is indeed complete garbage, but is sorta dynamically scoped) I'm guessing you mean lexical closures? The part where a nested function has read/write access to bindings created in its outer functions/scopes? > for now there is a lot we can do with it. There's also a lot we could do with Fortran and Cobol. That's no bloody excuse. [0] in Self, prototypes are just the thing you clone to get a basic object, they're just a template. They're not a unit of code reuse or inheritance: that's the job of mixins[1] [1] which, again, are very different from what you get in JavaScript or Ruby (though Ruby is closer): in Self, a mixin is an object you link to your own via a "parent slot", a special type of slot used for message resolution. When a message is sent to an object, the runtime first checks all of the object's non-parent slots and if there's no match it follows the parent slots recursively to try and find a slot matching the message.

yuchi 14y ago
While you're generally right, you must not forget about Harmony Proxies and all that meta-programming fuzz. While the final result of a prototypal class hierarchy is in fact very similar to pseudo-classic inheritance, remember that it's just the result of an internal, manual, modifiable process.
- masklinn 14y ago
  > While you're generally right, you must not forget about Harmony Proxies and all that meta-programming fuzz. All of which (and more) is available in class-based dynamically typed languages
wwweston 14y ago
> don't provide anything more than classes do in nice dynamic languages How would you do in-place method mutation in something like Python or Ruby?