[@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.
> 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.
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.
> 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.
> 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.
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.
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?
This confirms my belief that most criticisms of Elm are emotional responses, not rational ones.
Allowing arbitrary JS functions to be called from wherever would indeed break everything. Want to use `Math.random()`? Whoops! There goes referential transparency. Want to use `document.querySelector()`? Hello runtime errors my old friend. Want to use `function(x) { return x / 0; }`?
Yeah, have fun with that. I'll stay in North Korea ¯\_(ツ)_/¯
I literally have never experienced a bug because of the existence of Math.random(). I don’t think I’ve ever used it outside of a coding interview. Similarly, I don’t spend time debugging runtime errors caused by document.querySelector()? If I do it’s usually only once when I write the initial query. I don’t understand your last argument: why would I divide by 0?
Everyone’s relationship to their tools of choice has an emotional component. Check out this talk, you might find it interesting:
No the core question is “does the time and effort spent on those cases justify the cost of switching to elm?” I have to weigh the benefit of no runtime exceptions against things like having to write interop code for libraries that I may have to integrate with.
It might make sense for other people. It doesn’t add up for me.
This matters in the real world question of “should I use elm” even if it doesn’t matter to the theoretical question of “is the elm language sound?”. Especially since there is only one implementation of elm that updates very infrequently.
What are you talking about? You said no runtime errors because you have pure functions and now it turns out that actually implementation also matters?????
>>> I literally have never experienced a bug because of the existence of Math.random().
You must be doing something wrong than. :)
The world is impure. Pretending it is not is just laughable. I am saying this and I am actually writing only functional code for living, but I understand when I cannot solve the problem with functional concepts.
Few example:
- now()
- random()
- runSqlQuery()
- open a file
My code might be 90% pure functions but the rest is mutations, handling non-idempotent things, dealing with state, as the world is.
Uhh… What? I’m confused. Did you think this would be a smoking gun to your argument?
Of course Time.now() is an effectful routine.
This is not a strange idea to “FP purist zealots” either.
How is it defined in Elm?
Time.now : Task x Posix
How is it defined in Haskell?
Data.Time.Clock.getCurrentTime :: IO UTCTime
And no, you have not given any examples of using JavaScript in a type-safe way. If you think you have, it means you don’t adequately understand type-safety.
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. :)
