4 ms·

Because a framework can't bring new language primitives, such as types?

krapp 9y ago
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
- jstanley 9y ago
  Well then do you think no language that "compiles to machine code" really creates new language primitives, either? The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
  - krapp 9y ago
    > Well then do you think no language that "compiles to machine code" really creates new language primitives, either? No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. >The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead. Fair enough, but it doesn't actually change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
    - nothrabannosir 9y ago
      > No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people programmed in machine code (punch cards) and assembly was a programming language! Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js. This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
      - z3t4 9y ago
        It's funny when languages like C where you have to baby-sit the memory handler "compiles" to JavaScript, where all memory handling is completely abstracted.
      - krapp 9y ago
        Ten hours later and it's obvious from the all but unanimous negativity that I'm wrong about something. But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer. It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter. I should probably stop tilting at this particular windmill, though.
    - jstanley 9y ago
      > it doesn't actually change the grammar of the language Yes it does! That's the entire point. It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.
      - krapp 9y ago
        >It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language. But that's the grammar I was talking about, so no it doesn't.
    - wehere111 9y ago
      relevant username!
- wereHamster 9y ago
  Just like no language that compiles to machine code can create new x86 assembler instructions. So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
- cube2222 9y ago
  No, you wouldn't get the required compile time checks. (Transpile time checks in exact)
  - reificator 9y ago
    A compiler takes input in one language and converts it to another language. That the web community has a fundamental misunderstanding of this and created a derivative word with the same meaning is unfortunate. That it is now being used in misguided pedantic arguments reflects poorly on our community.
    - cube2222 9y ago
      The transpiler add-on in the comment wasn't meant to be meaningful anyhow. The main point were the compile time checks, which aren't to be achieved when using a library. Thanks for the correction though!
- z5h 9y ago
  You don't know what you're talking about.
kevmo314 9y ago
But why does that need to be tied to the framework? It seems that Elm provides two things that work together well: new language primitives and a functional framework. Tying the success of each component to the other doesn't seem like a great choice.
- mixedCase 9y ago
  The Elm experience simply cannot work on JavaScript. It demands a pure, strongly typed functional language that guides developers from any background into the right direction.
  - kevmo314 9y ago
    I disagree, after all it's compiled to js. As I mentioned, cycle.js is a good example of a functional js framework. Perhaps the experience is much better with a typed, functional language, but saying it can't work without it is disingenuous and haughty. After all, this is how Angular works: the experience is much superior with Typescript, but you can use it with JavaScript if you really want.
    - mixedCase 9y ago
      It doesn't work like that in the case of Elm. You can implement the Elm architecture with React, Redux and Redux-saga, but that's just a poor imitation of the API. The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language. "Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
      - kevmo314 9y ago
        You're still arguing features of the language, not why the framework requires them.

No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.

jstanley 9y ago
Well then do you think no language that "compiles to machine code" really creates new language primitives, either? The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
- krapp 9y ago
  > Well then do you think no language that "compiles to machine code" really creates new language primitives, either? No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. >The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead. Fair enough, but it doesn't actually change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
  - nothrabannosir 9y ago
    > No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor. This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people programmed in machine code (punch cards) and assembly was a programming language! Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js. This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
    - z3t4 9y ago
      It's funny when languages like C where you have to baby-sit the memory handler "compiles" to JavaScript, where all memory handling is completely abstracted.
    - krapp 9y ago
      Ten hours later and it's obvious from the all but unanimous negativity that I'm wrong about something. But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer. It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter. I should probably stop tilting at this particular windmill, though.
  - jstanley 9y ago
    > it doesn't actually change the grammar of the language Yes it does! That's the entire point. It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language.
    - krapp 9y ago
      >It doesn't change the grammar of the language that the generated code is using, but you don't care, because you're not writing in that language. But that's the grammar I was talking about, so no it doesn't.
  - wehere111 9y ago
    relevant username!
wereHamster 9y ago
Just like no language that compiles to machine code can create new x86 assembler instructions. So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
cube2222 9y ago
No, you wouldn't get the required compile time checks. (Transpile time checks in exact)
- reificator 9y ago
  A compiler takes input in one language and converts it to another language. That the web community has a fundamental misunderstanding of this and created a derivative word with the same meaning is unfortunate. That it is now being used in misguided pedantic arguments reflects poorly on our community.
  - cube2222 9y ago
    The transpiler add-on in the comment wasn't meant to be meaningful anyhow. The main point were the compile time checks, which aren't to be achieved when using a library. Thanks for the correction though!
z5h 9y ago
You don't know what you're talking about.

kevmo314 9y ago

But why does that need to be tied to the framework? It seems that Elm provides two things that work together well: new language primitives and a functional framework. Tying the success of each component to the other doesn't seem like a great choice.

mixedCase 9y ago
The Elm experience simply cannot work on JavaScript. It demands a pure, strongly typed functional language that guides developers from any background into the right direction.
- kevmo314 9y ago
  I disagree, after all it's compiled to js. As I mentioned, cycle.js is a good example of a functional js framework. Perhaps the experience is much better with a typed, functional language, but saying it can't work without it is disingenuous and haughty. After all, this is how Angular works: the experience is much superior with Typescript, but you can use it with JavaScript if you really want.
  - mixedCase 9y ago
    It doesn't work like that in the case of Elm. You can implement the Elm architecture with React, Redux and Redux-saga, but that's just a poor imitation of the API. The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language. "Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
    - kevmo314 9y ago
      You're still arguing features of the language, not why the framework requires them.