5 ms·

> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad

> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous." Like, what's the alternative? More JavaScript?

haskman 8y ago
Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.
- yakshaving_jgt 8y ago
  Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
  - haskman 8y ago
    > Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
    - yakshaving_jgt 8y ago
      > I find that Monads become intractable for new devs without do-notation. That's a fair point, and I agree, however this somewhat negates your previous point: > Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project. I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.
      - haskman 8y ago
        > I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.
StreamBright 8y ago
Have you seen ReasonML? [@bs.val] external pi : float = "Math.PI"; let tau = pi *. 2.0; [@bs.val] external alert : string => unit = "alert"; alert("hello"); Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language. Clojure is so popular because you have access to most of Java and the libraries written in Java. ReasonML makes super easy to use JS (or other languages, same FFI interface) while being an ML family language just like Elm. For me ReasonML is clearly the winner of type safe JS for these reasons.
- fmap 8y ago
  Elm is different to ML in that it is explicitly designed to be a pure language. Purity is important for the Elm architecture and allowing arbitrary side effects in your apps would break everything. That said, you could add effects and a JavaScript FFI using monads or algebraic effects. You could also get rid of a lot of boilerplate in the Elm architecture using existential types. It's a safe bet that the Elm developers know this. But all of these extensions would make the language less approachable. I think one of the reasons why Elm is doing so well is because it's not Haskell. :)
- yakshaving_jgt 8y ago
  I do not agree that it is "always a bad idea". That is why I use Elm, and not some other compile-to-JS language that allows me more freedom. I don't want freedom. I want constraints. Freedom is the rope with which I can hang myself. Constraints keep my bug tracker silent.
  - StreamBright 8y ago
    Most of the people want freedom and not some North Korean style crap. The example I gave was explicitly displaying how it is possible to use something from JS on a type safe way. Not sure how could you hang yourself with that. I guess you are just very creative.
    - the_gipsy 8y ago
cttet 8y ago
The alternative is less Javascript logic written by the app developer (and instead use packages and APIs directly). Elm disguised as a beginner friendly language for web front-end, which is not true with the case of ports. Where you need to be fairly familiar with Javascript. The Elm community also advertise a lot on the advantage of development happiness of Elm over Javascript, and mention the Javascript fatigue a lot. But the truth for a beginner is that you can't escape the Javascript ecosystem when using Elm, and sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided. If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.
- yakshaving_jgt 8y ago
  > sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided. I don't understand. You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript. This seems self-evidently false. > If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm. Seems like the argument is Elm isn't ideal if you're not a programmer, because you can't cargo-cult it. I think I'm ok with that.
  - cttet 8y ago
    > You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript. A codebase of 100% Javascript does not usually mean 100% written by the app developer. If you are coding in react for some basic app, like some basic crud with react using existing backend with Firebase, it almost only require you to learn the some basics of react and Javascript syntax, and fill in the template. You can also use other modules by just follow their documentation when you need some extra functionality. However in Elm Ports we are required to pass async messages for everything which is much harder. I am OK with the boilerplate for the JSON encoder and stuff, but I have to wrap around my head for how to write a port for lots of basic web APIs. Port is hard even for people that familiar with Javascript. There are plenty of experienced Javascript programmers willing to dive into the source code of Elm to write native modules to avoid ports even. https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/ https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_m... In addition, even the 5% of Javascript will eventually leads to the full Javascript stack, where Elm, without an official recommend JS stack, feels more like additional choice as a part of the JS fatigue. Beginners ends up looking up on browserfy/gulp/webpack etc and figuring out a way to integrate Elm in. > Seems like the argument is Elm isn't ideal if you're not a programmer I program daily for machine learning, and I have used many programming languages. But Javascript is not the language that I want to dive in too much, which it is the main reason I learn Elm. If your requirement of being a programmer is having a job as a software developer, then I am not. But I think a language with an aim of going into education and scientific computing shouldn't limit itself to that. https://www.youtube.com/watch?v=uGlzRt-FYto https://www.youtube.com/watch?v=uGlzRt-FYto I enjoy Elm. It is one of my favourite programming language. But I have not gotten anything done with it mainly because of ports. If I am pursuing a career in front-end related development, I would dive into Javascript and build stuff. I understand the decisions from Evan and friends and I am just thankful for Elm as it is, there is no right for me to demand anything anyway. [edit: formatting]

haskman 8y ago

Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.

yakshaving_jgt 8y ago
Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
- haskman 8y ago
  > Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. > Also a little surprised you mentioned do notation; it's just syntax sugar after all :) Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
  - yakshaving_jgt 8y ago
    > I find that Monads become intractable for new devs without do-notation. That's a fair point, and I agree, however this somewhat negates your previous point: > Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill. I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. They might feel intimidated by that, and discouraged from working with the technology at all. I'm using "team" in a more abstract sense here too; it could be all the collaborators (existing or potential) of an open source project. I'm not arguing the anti-intellectual position that everything should be dumbed-down. I just believe — as you said — there is some middle ground, which also isn't universally applicable.
    - haskman 8y ago
      > I can't say definitively, but you could argue that on a team, a more experienced developer might use more advanced features of a technology, which less experienced developers then have to just deal with. Actually in practice that's much less of an issue when using typed FP. I've found that it's easy to modify parts of code which you do understand the implementation of, while still being able to use the interface of other potentially more complex parts. Of course YMMV.

StreamBright 8y ago

Have you seen ReasonML? [@bs.val] external pi : float = "Math.PI"; let tau = pi *. 2.0; [@bs.val] external alert : string => unit = "alert"; alert("hello"); Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language. Clojure is so popular because you have access to most of Java and the libraries written in Java. ReasonML makes super easy to use JS (or other languages, same FFI interface) while being an ML family language just like Elm. For me ReasonML is clearly the winner of type safe JS for these reasons.

fmap 8y ago
Elm is different to ML in that it is explicitly designed to be a pure language. Purity is important for the Elm architecture and allowing arbitrary side effects in your apps would break everything. That said, you could add effects and a JavaScript FFI using monads or algebraic effects. You could also get rid of a lot of boilerplate in the Elm architecture using existential types. It's a safe bet that the Elm developers know this. But all of these extensions would make the language less approachable. I think one of the reasons why Elm is doing so well is because it's not Haskell. :)
yakshaving_jgt 8y ago
I do not agree that it is "always a bad idea". That is why I use Elm, and not some other compile-to-JS language that allows me more freedom. I don't want freedom. I want constraints. Freedom is the rope with which I can hang myself. Constraints keep my bug tracker silent.
- StreamBright 8y ago
  Most of the people want freedom and not some North Korean style crap. The example I gave was explicitly displaying how it is possible to use something from JS on a type safe way. Not sure how could you hang yourself with that. I guess you are just very creative.
  - the_gipsy 8y ago

cttet 8y ago

The alternative is less Javascript logic written by the app developer (and instead use packages and APIs directly). Elm disguised as a beginner friendly language for web front-end, which is not true with the case of ports. Where you need to be fairly familiar with Javascript. The Elm community also advertise a lot on the advantage of development happiness of Elm over Javascript, and mention the Javascript fatigue a lot. But the truth for a beginner is that you can't escape the Javascript ecosystem when using Elm, and sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided. If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm.

yakshaving_jgt 8y ago
> sometimes it requires even more Javascript experience than using just Javascript framework like React to build something that require a web api that's not in the tiny list that Elm provided. I don't understand. You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript. This seems self-evidently false. > If web development is not someone's main job and they are just finding a tool with better dev experience to build some side projects, the fact that they need to design an interface for almost every external package is not aligned with their original reason to use Elm. Seems like the argument is Elm isn't ideal if you're not a programmer, because you can't cargo-cult it. I think I'm ok with that.
- cttet 8y ago
  > You're saying a codebase of 5% JavaScript demands more JavaScript experience than a codebase of 100% JavaScript. A codebase of 100% Javascript does not usually mean 100% written by the app developer. If you are coding in react for some basic app, like some basic crud with react using existing backend with Firebase, it almost only require you to learn the some basics of react and Javascript syntax, and fill in the template. You can also use other modules by just follow their documentation when you need some extra functionality. However in Elm Ports we are required to pass async messages for everything which is much harder. I am OK with the boilerplate for the JSON encoder and stuff, but I have to wrap around my head for how to write a port for lots of basic web APIs. Port is hard even for people that familiar with Javascript. There are plenty of experienced Javascript programmers willing to dive into the source code of Elm to write native modules to avoid ports even. https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_move_away_from_elm/ https://www.reddit.com/r/elm/comments/81bo14/do_we_need_to_m... In addition, even the 5% of Javascript will eventually leads to the full Javascript stack, where Elm, without an official recommend JS stack, feels more like additional choice as a part of the JS fatigue. Beginners ends up looking up on browserfy/gulp/webpack etc and figuring out a way to integrate Elm in. > Seems like the argument is Elm isn't ideal if you're not a programmer I program daily for machine learning, and I have used many programming languages. But Javascript is not the language that I want to dive in too much, which it is the main reason I learn Elm. If your requirement of being a programmer is having a job as a software developer, then I am not. But I think a language with an aim of going into education and scientific computing shouldn't limit itself to that. https://www.youtube.com/watch?v=uGlzRt-FYto https://www.youtube.com/watch?v=uGlzRt-FYto I enjoy Elm. It is one of my favourite programming language. But I have not gotten anything done with it mainly because of ports. If I am pursuing a career in front-end related development, I would dive into Javascript and build stuff. I understand the decisions from Evan and friends and I am just thankful for Elm as it is, there is no right for me to demand anything anyway. [edit: formatting]