5 ms·

Have you seen ReasonML? [@bs.val] external pi : float = "Math.PI"; let tau = pi *. 2.0; [@bs.val] external alert : string => unit = "alert"; alert("hel

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
    Of course you can't hang yourself with `Math.PI` or `window.alert`. Try `Math.random()` and `window.confirm` instead, or much more relevant: `document.getElementById`.
    - StreamBright 8y ago
      I am not saying that everything is going to be super easy to do this way but taking away my ability of using Math.PI because of document.getElementById is silly.
      - yakshaving_jgt 8y ago
        No, it is not silly. It is referential transparency.
      - the_gipsy 8y ago
        If you absolutely must run unsafe JS interop inline then maybe Elm is not for you, but it doesn't make its approach "silly". You can run absolutely any JS code, just through the ports API. Trivial things like Math.PI are in the core[1] or some package. [1] https://package.elm-lang.org/packages/elm-lang/core/5.1.1/Basics#pi https://package.elm-lang.org/packages/elm-lang/core/5.1.1/Ba...
        StreamBright 8y ago
        Again, I could not care less what is in core (which might not be there anymore without a deprecation warning) but I want to use JS functions if I need to. How hard is to understand these requirements?
        the_gipsy 8y ago
        As I said, yoy can use any JS function with Elm. It’s just through ports, not inline.
  - yakshaving_jgt 8y ago
- gothy 8y ago
  I was(am? will be again?) a fan of Elm. Constraints can be helpful and even liberating(in some sense). But that's something that should be balanced carefully with other things, like rules\laws that are clear, universal and follow the common sense. Unfortunately, during my Elm journey, I've found that's not the case for Elm. > Freedom is the rope with which I can hang myself. If you'd like to, why not? It's up to you. You're not forced to do, though. On the other side, being a hostage of some secret plans in "people in power" minds, you might be forced to do any kind of staff. New constraints are here and they're enforced on anyone. That's a catch with constraints, you can be OK with existing, but you'll never know what comes tomorrow.
  - yakshaving_jgt 8y ago
    > If you'd like to, why not? It's up to you. You're not forced to do, though. Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.
    - gothy 8y ago
      > Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project. Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want. All browsers are the same, their behavior is consistent, mobile web is pure joy and all of our users know their plugins might cause an issue to our app, therefore they're disabling them when they launch our app". Anybody who does webdev knows that. Different projects, different requirements(sometimes very, very strange), brand new requirements right before the release, deadlines, etc. There're lots of things you have to deal with to end up with a good website\app. Picking a language with nice "correctness guarantees", is not going to help you much. There were times, long time before 0.19, when there were at least discussions on effect managers, extending the type system, native modules were a nice escape hatch to fix your problem at hand with nasty browser bug or even Elm runtime issue. Those were times when I was so excited to use Elm, did some tiny (sub)projects in it, did a workshop at the office. Since then, many things have changed to the worse, imho. Some features were removed, not even deprecated. No public discussions, no roadmap, no bugfix releases, no escape hatches for special cases. But who cares what some random guy on the internets thinks :) Don't get me wrong, I think Elm is a great experiment in the land of static languages, lots of great stuff is getting into mainstream languages(like Elm architecture, error msgs). I still hope we'll see the 1.0 version and things might get better in terms of feature stability, feedback and building things a little bit more complex than counter apps without hitting even more pain points than we have with modern JS\TS.
k_bx 8y ago
> 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. Your code will produce runtime errors which will be rendered into console with ReasonML runtime guts in it. I would disagree that this is in any way superior to Elm's promise of no runtime errors, and JS via ports having no runtime in its errors.

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
  Of course you can't hang yourself with `Math.PI` or `window.alert`. Try `Math.random()` and `window.confirm` instead, or much more relevant: `document.getElementById`.
  - StreamBright 8y ago
    I am not saying that everything is going to be super easy to do this way but taking away my ability of using Math.PI because of document.getElementById is silly.
    - yakshaving_jgt 8y ago
      No, it is not silly. It is referential transparency.
    - the_gipsy 8y ago
      If you absolutely must run unsafe JS interop inline then maybe Elm is not for you, but it doesn't make its approach "silly". You can run absolutely any JS code, just through the ports API. Trivial things like Math.PI are in the core[1] or some package. [1] https://package.elm-lang.org/packages/elm-lang/core/5.1.1/Basics#pi https://package.elm-lang.org/packages/elm-lang/core/5.1.1/Ba...
      - StreamBright 8y ago
        Again, I could not care less what is in core (which might not be there anymore without a deprecation warning) but I want to use JS functions if I need to. How hard is to understand these requirements?
        the_gipsy 8y ago
        As I said, yoy can use any JS function with Elm. It’s just through ports, not inline.
- yakshaving_jgt 8y ago
gothy 8y ago
I was(am? will be again?) a fan of Elm. Constraints can be helpful and even liberating(in some sense). But that's something that should be balanced carefully with other things, like rules\laws that are clear, universal and follow the common sense. Unfortunately, during my Elm journey, I've found that's not the case for Elm. > Freedom is the rope with which I can hang myself. If you'd like to, why not? It's up to you. You're not forced to do, though. On the other side, being a hostage of some secret plans in "people in power" minds, you might be forced to do any kind of staff. New constraints are here and they're enforced on anyone. That's a catch with constraints, you can be OK with existing, but you'll never know what comes tomorrow.
- yakshaving_jgt 8y ago
  > If you'd like to, why not? It's up to you. You're not forced to do, though. Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.
  - gothy 8y ago
    > Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident. That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project. Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want. All browsers are the same, their behavior is consistent, mobile web is pure joy and all of our users know their plugins might cause an issue to our app, therefore they're disabling them when they launch our app". Anybody who does webdev knows that. Different projects, different requirements(sometimes very, very strange), brand new requirements right before the release, deadlines, etc. There're lots of things you have to deal with to end up with a good website\app. Picking a language with nice "correctness guarantees", is not going to help you much. There were times, long time before 0.19, when there were at least discussions on effect managers, extending the type system, native modules were a nice escape hatch to fix your problem at hand with nasty browser bug or even Elm runtime issue. Those were times when I was so excited to use Elm, did some tiny (sub)projects in it, did a workshop at the office. Since then, many things have changed to the worse, imho. Some features were removed, not even deprecated. No public discussions, no roadmap, no bugfix releases, no escape hatches for special cases. But who cares what some random guy on the internets thinks :) Don't get me wrong, I think Elm is a great experiment in the land of static languages, lots of great stuff is getting into mainstream languages(like Elm architecture, error msgs). I still hope we'll see the 1.0 version and things might get better in terms of feature stability, feedback and building things a little bit more complex than counter apps without hitting even more pain points than we have with modern JS\TS.

k_bx 8y ago

> 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. Your code will produce runtime errors which will be rendered into console with ReasonML runtime guts in it. I would disagree that this is in any way superior to Elm's promise of no runtime errors, and JS via ports having no runtime in its errors.