5 ms·

It's extremely simple - basically everything is a hash. It has full lambda, not just crippled lambda like Python. It's very fast (I think it is the fastest scri

• dkuntz2 13y ago
  I personally don't like that everything's a hash. It's nifty, and it means you don't really need objects, but I kinda like objects, even if I don't use them frequently in Python. Your preference makes sense, it's just not the same one I have. More on topic for this thread, I'm still not convinced that it's a good thing for an embedded system.
  • Tichy 13y ago
    You can use objects in JS if you want to - but fair enough, different tastes and preferences.
    • dkuntz2 13y ago
      I didn't say you couldn't, I just skimmed over them. The prototype stuff is funky to me, I'd rather just have a straightforward syntax with objects.
      • DonPellegrino 13y ago
        It takes less than an hour to learn and get used to it if you know the standard Java-style OOP already. It's worth it and it'll give you a whole new opinion on what OOP means. I made this a while ago, see if you can figure out how it works: http://jsfiddle.net/AXTdj/ http://jsfiddle.net/AXTdj/
        • dkuntz2 13y ago
          I know how it works, I just find it worse, by far. There's a whole lot more overhead to getting it working, specifically all of the foo.prototype stuff, and it doesn't require that everything be together. Sure, it's kinda nice that you're able to extends objects later on, but I'd rather have everything neatly declared in one place. It definitely does not "give me a whole new opinion on what OOP means", it furthers my opinion that I'm not a fan of JavaScript.
          • Tichy 13y ago
            You know that you can just do foo.prototype = { dothis: function(){}, dothat: function(){} } In the beginning I wrote it more like foo.prototype.dothat = function(){} foo.prototype.dothis = function(){} Which was a lot more ugly.
          • PommeDeTerre 13y ago
            It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't practical. For far too long now we've had to hear JavaScript advocates go on and on about how good JavaScript's approach is. Yet over and over we see developers being forced to fake a limited subset of class-based OO one way or another, just to get their work done effectively. Of course, there are multiple ways of faking class-based OO in JavaScript, with varying degrees of compatibility with one another. In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly. This is one of the things that the JavaScript community should have addressed years ago.
            • nilliams 13y ago
              >> In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly. Whether you use constructor functions, object literals, or the module pattern to structure your code in an OO-like manner, they all result in 'functions hung off objects' which can be called in the same way: object.foo(), I don't see the very real compatibility issue you're talking about. >> It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't practical. It's plenty practical, I will welcome ES6's class keyword for the clearer semantics, but this is simply vague FUD.
• anonymoushn 13y ago
  Non-string values are not valid hash keys. Operations that should be type errors fail silently and return nonsense. The prototype system is less powerful than the OO system of basically every other scripting language. The language will never have continuations, so people who want real control flow are stuck using preprocessors to generate callback spaghetti. Encoding a particularly rigid mix of dynamic and lexical scope into the language specification, such that everyone must be exposed to dynamic scoping much of the time, is one of the worst ideas I can imagine.
  • jeswin 13y ago
    Non-string values are not valid hash keys. - ES6 Maps The prototype system is less powerful .. - No. Just different. The language will never have continuations.. - Generators help here. We use them with node --harmony Scoping. - Fat arrows and block scoping coming in ES6. These features can be used today in node, by enabling the harmony flag. Otherwise wait until next year.
    • anonymoushn 13y ago
      > Non-string values are not valid hash keys. - ES6 Maps Yes, this is a good thing :) > The prototype system is less powerful .. - No. Just different Javascript let you use prototypes to cause map lookups for absent keys to fall back to a different map. Lua lets you use prototypes to override every operator, make the object callable, override map lookups for absent keys, and override assignment of new keys. All of these operations can be made to call into arbitrary functions the user provides. Python, an OO scripting language, provides all of the same features. It seems to me that among these three languages there is a greater difference between the more powerful systems and the less powerful system than between the prototypal systems and the OO system. > The language will never have continuations.. - Generators help here. We use them with node --harmony Python also has generators, but you still need greenlet or stackless if you want to use coroutines. The inability to suspend from a subroutine is a deal breaker. Generators are probably nice for writing generators. For writing control flow, Continuation.js seems like a better choice. > Scoping. - Fat arrows and block scoping coming in ES6. => lets you use a lexically scoped this, which is likely a dynamically scoped this from an enclosing lexical scope. This sounds useful, but it doesn't really make things less messy.