4 ms·

It may be less awful, but I have a quite long list of languages that I would use rather than JavaScript. Luckily nowadays it is not that essential, thanks to al

It may be less awful, but I have a quite long list of languages that I would use rather than JavaScript. Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Ages ago the only alternative was GWT with all his problems.

krapp 10y ago
>Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Except at the end of the day, you're not actually using those languages to do anything besides generating javascript. So you're still using javascript, which means it remains just as essential as it ever was. You could just as well write the javascript being "compiled to" after learning whatever idioms make it "safe" versus vanilla js, and cut out the middleman. Javascript-as-bytecode is an antipattern.
- tigershark 10y ago
  How you would make invalid state unrepresentable at compile time in vanilla JavaScript? How you would have an HM type systems? How you would not kill yourself in a simple app less than 100k LOC working alone? If you have an answer to all this questions then maybe I missed A LOT in the recent JavaScript evolution, but I really doubt it. And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code. So you're still using machine code, which means it remains just as essential as it ever was. You could just as well write the machine code being "compiled to" after learning whatever idioms make it "safe" versus a normal language, and cut out the middleman. Machine code-as-another language is an antipattern.'
  - krapp 10y ago
    >How you would make invalid state unrepresentable at compile time in vanilla JavaScript? >How you would have an HM type systems? Let me ask you this - how do languages which compile to javascript manage to implement these features in javascript? The answer is they don't. The javascript they generate may behave as if it were safe, but it's no more safe than any other javascript anywhere else, and no different. Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to javascript itself. >How you would not kill yourself in a simple app less than 100k LOC working alone? I don't see how this is relevant to my point, and I don't think 100 KLOC apps represent the common use case for compile-to-js languages. I never argued that compiling to javascript wasn't useful in some way, only that it's still an abstract way to write plain old every day javascript. It's simply incorrect that compile to js language have rendered javascript less relevant because they compile to javascript. >"And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code Except at the end of the day, you're not actually using those languages to do anything besides generating machine code (...) Well, no, and obviously not. Because javascript isn't machine code. It's not bytecode. It's not assembly. It's a high level, loosely typed programming language. However, if we were to accept your facile equivalence as true for the sake of argument, that javascript is no different than machine language, and that, therefore, compiling to javascript is no different than compiling to machine language, then it must also follow that writing javascript by hand is no different than compiling to machine language, and further that translating from any high level language to any other is the same as compiling to machine language. If I were to transpile from any high-level language a to any other high level language b, would it make sense to then declare b equivalent to machine code? Of course not. If you took javascript and translated it to Python, is Python then equivalent to machine language? Of course not. It's the model of treating javascript as a compile target that's absurd. If you're going to try to construct a strawman out of my reasoning and knock it down, at least try a sturdier one.
    - tigershark 10y ago
      how do languages which compile to machine code manage to implement these features in machine code? The answer is they don't. The machine code they generate may behave as if it were safe, but it's no more safe than any other machine code anywhere else, and no different. At the end everything you write on a machine is translated to machine code and executed. Or do you really believe that the CPU executes directly JavaScript? Powerful type systems, HM inferences and all the other abstractions obviously don't exist at machine code level. It's the resulting machine code that behave producing the behaviour of these abstractions. Borrowing again your words: Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to machine code itself. I would say that it is obvious that you can write them directly in machine code and have the same effects. Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code? I don't think you can find anyone outside a mental institution.
      - krapp 10y ago
        >how do languages which compile to machine code manage to implement these features in machine code? The answer is they don't. The machine code they generate may behave as if it were safe, but it's no more safe than any other machine code anywhere else, and no different. Merely replacing "javascript" with "machine code" and pasting my comment back doesn't constitute a rational argument or an effective refutation of anything i've actually stated, it's the intellectual equivalent of a small bird mimicking human speech. >Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code? Except... writing machine code does not describe writing javascript in any meaningful way. Machine code is low level, concrete, and not easily human readable. Javascript is high level and abstract. How sane is it to manually write a complex application that uses powerful type systems directly in machine code using C++? Why would you bother writing Java bytecode directly in Java source code? The metaphor of javascript as machine language breaks down so readily that, yes, I will question its utility, and whether fixating on it is pathological. If you don't like javascript as a language, fair enough - plenty of people don't, for valid reasons. I understand perfectly well why developers generate javascript from other languages and why they might find it useful to do so. But to hearken back to my original point, doing so doesn't affect javascript's relevance or discredit its quality as a language. You're still developing in javascript by proxy.

krapp 10y ago

>Luckily nowadays it is not that essential, thanks to all the languages that compile to JavaScript. Except at the end of the day, you're not actually using those languages to do anything besides generating javascript. So you're still using javascript, which means it remains just as essential as it ever was. You could just as well write the javascript being "compiled to" after learning whatever idioms make it "safe" versus vanilla js, and cut out the middleman. Javascript-as-bytecode is an antipattern.

tigershark 10y ago
How you would make invalid state unrepresentable at compile time in vanilla JavaScript? How you would have an HM type systems? How you would not kill yourself in a simple app less than 100k LOC working alone? If you have an answer to all this questions then maybe I missed A LOT in the recent JavaScript evolution, but I really doubt it. And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code. So you're still using machine code, which means it remains just as essential as it ever was. You could just as well write the machine code being "compiled to" after learning whatever idioms make it "safe" versus a normal language, and cut out the middleman. Machine code-as-another language is an antipattern.'
- krapp 10y ago
  >How you would make invalid state unrepresentable at compile time in vanilla JavaScript? >How you would have an HM type systems? Let me ask you this - how do languages which compile to javascript manage to implement these features in javascript? The answer is they don't. The javascript they generate may behave as if it were safe, but it's no more safe than any other javascript anywhere else, and no different. Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to javascript itself. >How you would not kill yourself in a simple app less than 100k LOC working alone? I don't see how this is relevant to my point, and I don't think 100 KLOC apps represent the common use case for compile-to-js languages. I never argued that compiling to javascript wasn't useful in some way, only that it's still an abstract way to write plain old every day javascript. It's simply incorrect that compile to js language have rendered javascript less relevant because they compile to javascript. >"And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code Except at the end of the day, you're not actually using those languages to do anything besides generating machine code (...) Well, no, and obviously not. Because javascript isn't machine code. It's not bytecode. It's not assembly. It's a high level, loosely typed programming language. However, if we were to accept your facile equivalence as true for the sake of argument, that javascript is no different than machine language, and that, therefore, compiling to javascript is no different than compiling to machine language, then it must also follow that writing javascript by hand is no different than compiling to machine language, and further that translating from any high level language to any other is the same as compiling to machine language. If I were to transpile from any high-level language a to any other high level language b, would it make sense to then declare b equivalent to machine code? Of course not. If you took javascript and translated it to Python, is Python then equivalent to machine language? Of course not. It's the model of treating javascript as a compile target that's absurd. If you're going to try to construct a strawman out of my reasoning and knock it down, at least try a sturdier one.
  - tigershark 10y ago
    how do languages which compile to machine code manage to implement these features in machine code? The answer is they don't. The machine code they generate may behave as if it were safe, but it's no more safe than any other machine code anywhere else, and no different. At the end everything you write on a machine is translated to machine code and executed. Or do you really believe that the CPU executes directly JavaScript? Powerful type systems, HM inferences and all the other abstractions obviously don't exist at machine code level. It's the resulting machine code that behave producing the behaviour of these abstractions. Borrowing again your words: Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to machine code itself. I would say that it is obvious that you can write them directly in machine code and have the same effects. Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code? I don't think you can find anyone outside a mental institution.
    - krapp 10y ago
      >how do languages which compile to machine code manage to implement these features in machine code? The answer is they don't. The machine code they generate may behave as if it were safe, but it's no more safe than any other machine code anywhere else, and no different. Merely replacing "javascript" with "machine code" and pasting my comment back doesn't constitute a rational argument or an effective refutation of anything i've actually stated, it's the intellectual equivalent of a small bird mimicking human speech. >Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code? Except... writing machine code does not describe writing javascript in any meaningful way. Machine code is low level, concrete, and not easily human readable. Javascript is high level and abstract. How sane is it to manually write a complex application that uses powerful type systems directly in machine code using C++? Why would you bother writing Java bytecode directly in Java source code? The metaphor of javascript as machine language breaks down so readily that, yes, I will question its utility, and whether fixating on it is pathological. If you don't like javascript as a language, fair enough - plenty of people don't, for valid reasons. I understand perfectly well why developers generate javascript from other languages and why they might find it useful to do so. But to hearken back to my original point, doing so doesn't affect javascript's relevance or discredit its quality as a language. You're still developing in javascript by proxy.