5 ms·

It’s a bit unfortunate that Elm will always be left out of lists like this. Yes it’s a different language that compiles to JavaScript, but unlike other languag

It’s a bit unfortunate that Elm will always be left out of lists like this. Yes it’s a different language that compiles to JavaScript, but unlike other languages that do this, Elm exists solely to excel at front-end web development. Ironically, that Redux and React equivalents are some of the “batteries included” in Elm can make it harder to pitch because at first it seems like you’d have to add that stuff in.

kevmo314 9y ago
Reading over the Elm documentation, I respect the ideals a lot, it looks like a fantastic language, but why does it need to be a completely new language instead of a framework in js? It's not particularly convincing to my co-workers if I have to convince them to try a completely new syntax instead of just a new framework. Actually, I think this is why something like cycle.js is more tractable.
- codecurve 9y ago
  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.
    - 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.
- zachrose 9y ago
  It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable. Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system. “Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
  - BatFastard 9y ago
    Trying to understand, I am still looking for my next front end language. Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?
  - kevmo314 9y ago
    > It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable. Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.
    - zachrose 9y ago
      Yes, but using Elm has convinced me of the significant difference between runtime checks and compile time checks. In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.) By contrast, you get that much certainty every time an Elm program compiles. Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.
Girlang 9y ago
I never did any web stuff—-considered it beneath me—-before Elm. Now I will do web front ends myself.
platz 9y ago
They included purescript (compilers), so why not elm, which has orders of magnitude more users?
- dom96 9y ago
  Similarly, I wonder if they included Nim[1]. While it's use as a compile-to-js language is more niche I think it deserves to be among the likes of ClojureScript. 1 - https://nim-lang.org https://nim-lang.org
- phillipcarter 9y ago
  Do you have anything to back up the assertion that it has orders of magnitude more users? I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.
sjrd 9y ago
If I recall correctly, the state-of-JS survey did not even have an "Other: ____" field for the Flavors category [1]. Which means that people going to the survey had no way to even mention alternative languages. The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks. [1] https://stateofjs.com/2017/flavors/results https://stateofjs.com/2017/flavors/results
indexerror 9y ago
> Elm exists solely to excel at front-end web development. Except that it unfortunately falls short of that.
- worble 9y ago
  In what ways? Bearing in mind it's still in development and doesn't claim to be production ready by any means.
  - erezsh 9y ago
    Umm.. That's pretty damning. Why would a technology that isn't production ready yet be featured in a "most popular" list?
    - zachrose 9y ago
      In my experience there’s a difference between being production ready and claiming to be production ready. Quite a few projects (Node.js and Backbone) achieved wide adoption before 1.0.0. For the record I’m not sure the Elm project has any claim one way or another, apart from the current version of 0.18 and the main contributors having large code bases in production at private companies. So maybe it’s not that damning, and we still haven’t heard the GPs thoughts on how Elm has fallen short for them.

kevmo314 9y ago

Reading over the Elm documentation, I respect the ideals a lot, it looks like a fantastic language, but why does it need to be a completely new language instead of a framework in js? It's not particularly convincing to my co-workers if I have to convince them to try a completely new syntax instead of just a new framework. Actually, I think this is why something like cycle.js is more tractable.

codecurve 9y ago
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.
  - 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.
zachrose 9y ago
It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable. Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system. “Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”
- BatFastard 9y ago
  Trying to understand, I am still looking for my next front end language. Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?
- kevmo314 9y ago
  > It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable. Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.
  - zachrose 9y ago
    Yes, but using Elm has convinced me of the significant difference between runtime checks and compile time checks. In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.) By contrast, you get that much certainty every time an Elm program compiles. Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.

Girlang 9y ago

I never did any web stuff—-considered it beneath me—-before Elm. Now I will do web front ends myself.

platz 9y ago

They included purescript (compilers), so why not elm, which has orders of magnitude more users?

dom96 9y ago
Similarly, I wonder if they included Nim[1]. While it's use as a compile-to-js language is more niche I think it deserves to be among the likes of ClojureScript. 1 - https://nim-lang.org https://nim-lang.org
phillipcarter 9y ago
Do you have anything to back up the assertion that it has orders of magnitude more users? I'm a fan of elm, but but overall population of functional programmers is quite small, so I wouldn't be shocked of Elm, PureScript, and Reason had similar populations of developers.

sjrd 9y ago

If I recall correctly, the state-of-JS survey did not even have an "Other: ____" field for the Flavors category [1]. Which means that people going to the survey had no way to even mention alternative languages. The set of languages on state-of-JS is therefore artificially constrained to what the creators of the survey think deserves a place there, rather than the actual community thinks. [1] https://stateofjs.com/2017/flavors/results https://stateofjs.com/2017/flavors/results

indexerror 9y ago

> Elm exists solely to excel at front-end web development. Except that it unfortunately falls short of that.

worble 9y ago
In what ways? Bearing in mind it's still in development and doesn't claim to be production ready by any means.
- erezsh 9y ago
  Umm.. That's pretty damning. Why would a technology that isn't production ready yet be featured in a "most popular" list?
  - zachrose 9y ago
    In my experience there’s a difference between being production ready and claiming to be production ready. Quite a few projects (Node.js and Backbone) achieved wide adoption before 1.0.0. For the record I’m not sure the Elm project has any claim one way or another, apart from the current version of 0.18 and the main contributors having large code bases in production at private companies. So maybe it’s not that damning, and we still haven’t heard the GPs thoughts on how Elm has fallen short for them.