5 ms·

I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" Thanks for the article th

I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" Thanks for the article though, if I ever need to write some JS this will help keep me a little more sane.

ufo 14y ago
The first time I saw something like IIFEs was in one of the SICP lectures, where they show that variable definitions with let or define can be seen as syntactic sugar over immediately invoked lambdas. And even those Scheme uber-nerds considered it big hack, more useful in theory then in practice.
- silentbicycle 14y ago
  It's useful as a de-sugaring step during compilation, not something people generally do by hand.
  - ufo 14y ago
    Continuation Passing Style is also supposed to be used as part of acompilation step but look at how everyone does in by hand in Javascript-land :(
    - silentbicycle 14y ago
      For real. I tried to find a way to point that out without sounding snarky, gave up.
azakai 14y ago
> I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" I don't deride PHP (I don't know it), but I see nothing wrong with IIFE. Yes, it could benefit from some syntactic sugar, but otherwise it is just using one of the best features of JavaScript, function support (first-class functions, anonymous functions, etc.). It makes perfect sense to use a pattern like IIFE in order to encapsulate code, often using closures to allow access in a controlled manner from the outside, etc. I suppose perhaps you don't like closures and so forth, and that's fine, but many people including me love them.
- ufo 14y ago
  IIFEs are cumbersome and non-intuitive. Better languages have block scope or a "let" statement instead.
  - TazeTSchnitzel 14y ago
    `let` is drafted for ECMAScript 6.
    - georgemcbay 14y ago
      ...and ECMAScript 4 had block scope. Language design by committee is seriously flawed and until a feature is shipping in all the major browsers it isn't real.
      - TazeTSchnitzel 14y ago
        ECMAScript 4 was cancelled.
        georgemcbay 14y ago
        That was exactly my point.
  - grannyg00se 14y ago
    Javascript [does/will]* have a "let" statement. *depending on which version of ECMAscript is being used.
DivisibleByZero 14y ago
Exactly my thoughts. There really needs to be some healthy competition in client side languages.
- tomjen3 14y ago
  Oh definitely. Or rather we need a vm designed to write code that can be optimized to run fast (personal dream, allow me to optionally include typing information. I already type my JS, might as well make it run better). This means that the vm would be lowlevel enough that performance would start to approach that of native code, with complete freedom for the programmer to write the code for it in any language he desired. The browser would then be able to execute this code instead of the corresponding Javascript file (e.g you compiler outputs two different object codes, one minified javascript for legacy browsers, one modern vm file for modern browsers).
  - TazeTSchnitzel 14y ago
    You'll be disappointed to know that Dart doesn't use bytecode.
    - kmontrose 14y ago
      There's a wholly unconvincing argument as to why Dart isn't pushing a VM as well, http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/ . Might as well be titled "Why not the JVM?" in my opinion.
      - TazeTSchnitzel 14y ago
        It isn't unconvincing. They make the case that bytecode is not assembly in reality, and constrains what you can do in languages compiled to it.
        kmontrose 14y ago
        Nonsense, a VM is what it's defined to be. If you wanted the x86 (or ARM, or PPC, etc.) instruction set to be your bytecode, you've got it. That article starts from the assumption that any in browser VM will resemble the JVM; which is a faulty assumption. In fact, any in browser VM would have to be very different from the JVM since Rule 0 for any such VM would be "acceptable Javascript performance". From that article: > Meanwhile, JVMs don't do these optimizations. Since all types are statically > known, the compiler knows exactly how much storage they need and what > operations they support. It can then generate appropriate tight code for those > types. This is fast if your language is statically typed, but if you're trying to > compile a dynamically typed language to the JVM, it won't be able to run as fast as a > VM that can assume dynamic typing all the way down and optimize specifically > for that. A whole wasted paragraph. Of course a browser VM wouldn't be statically typed, that'd make compiling/running Javascript a bear. One would hope there'd be some system of type-hinting, because eliminating dynamic dispatch is really low hanging fruit in terms of optimization, but JVM/CLR-style static typing? Madness.

ufo 14y ago

The first time I saw something like IIFEs was in one of the SICP lectures, where they show that variable definitions with let or define can be seen as syntactic sugar over immediately invoked lambdas. And even those Scheme uber-nerds considered it big hack, more useful in theory then in practice.

silentbicycle 14y ago
It's useful as a de-sugaring step during compilation, not something people generally do by hand.
- ufo 14y ago
  Continuation Passing Style is also supposed to be used as part of acompilation step but look at how everyone does in by hand in Javascript-land :(
  - silentbicycle 14y ago
    For real. I tried to find a way to point that out without sounding snarky, gave up.

azakai 14y ago

> I always find it odd that the same developers who deride PHP look at things like IIFE and think "wow, JS is a cool, modern language!" I don't deride PHP (I don't know it), but I see nothing wrong with IIFE. Yes, it could benefit from some syntactic sugar, but otherwise it is just using one of the best features of JavaScript, function support (first-class functions, anonymous functions, etc.). It makes perfect sense to use a pattern like IIFE in order to encapsulate code, often using closures to allow access in a controlled manner from the outside, etc. I suppose perhaps you don't like closures and so forth, and that's fine, but many people including me love them.

ufo 14y ago
IIFEs are cumbersome and non-intuitive. Better languages have block scope or a "let" statement instead.
- TazeTSchnitzel 14y ago
  `let` is drafted for ECMAScript 6.
  - georgemcbay 14y ago
    ...and ECMAScript 4 had block scope. Language design by committee is seriously flawed and until a feature is shipping in all the major browsers it isn't real.
    - TazeTSchnitzel 14y ago
      ECMAScript 4 was cancelled.
      - georgemcbay 14y ago
        That was exactly my point.
- grannyg00se 14y ago
  Javascript [does/will]* have a "let" statement. *depending on which version of ECMAscript is being used.

DivisibleByZero 14y ago

Exactly my thoughts. There really needs to be some healthy competition in client side languages.

tomjen3 14y ago
Oh definitely. Or rather we need a vm designed to write code that can be optimized to run fast (personal dream, allow me to optionally include typing information. I already type my JS, might as well make it run better). This means that the vm would be lowlevel enough that performance would start to approach that of native code, with complete freedom for the programmer to write the code for it in any language he desired. The browser would then be able to execute this code instead of the corresponding Javascript file (e.g you compiler outputs two different object codes, one minified javascript for legacy browsers, one modern vm file for modern browsers).
- TazeTSchnitzel 14y ago
  You'll be disappointed to know that Dart doesn't use bytecode.
  - kmontrose 14y ago
    There's a wholly unconvincing argument as to why Dart isn't pushing a VM as well, http://www.dartlang.org/articles/why-not-bytecode/ http://www.dartlang.org/articles/why-not-bytecode/ . Might as well be titled "Why not the JVM?" in my opinion.
    - TazeTSchnitzel 14y ago
      It isn't unconvincing. They make the case that bytecode is not assembly in reality, and constrains what you can do in languages compiled to it.
      - kmontrose 14y ago
        Nonsense, a VM is what it's defined to be. If you wanted the x86 (or ARM, or PPC, etc.) instruction set to be your bytecode, you've got it. That article starts from the assumption that any in browser VM will resemble the JVM; which is a faulty assumption. In fact, any in browser VM would have to be very different from the JVM since Rule 0 for any such VM would be "acceptable Javascript performance". From that article: > Meanwhile, JVMs don't do these optimizations. Since all types are statically > known, the compiler knows exactly how much storage they need and what > operations they support. It can then generate appropriate tight code for those > types. This is fast if your language is statically typed, but if you're trying to > compile a dynamically typed language to the JVM, it won't be able to run as fast as a > VM that can assume dynamic typing all the way down and optimize specifically > for that. A whole wasted paragraph. Of course a browser VM wouldn't be statically typed, that'd make compiling/running Javascript a bear. One would hope there'd be some system of type-hinting, because eliminating dynamic dispatch is really low hanging fruit in terms of optimization, but JVM/CLR-style static typing? Madness.