151–160 of 199 posts
Earlier quoted context omitted.
The core question is, "have you ever experienced a runtime error?" Have you ever spent time debugging a runtime error deployed to production? You can't get those in Elm.
https://medium.com/@eeue56/top-6-ways-to-make-your-elm-app-c...
It’s intellectually dishonest to point to implementation bugs as fundamental flaws.
Earlier quoted context omitted.
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…
The core question is, "have you ever experienced a runtime error?" Have you ever spent time debugging a runtime error deployed to production? You can't get those in Elm.
It might make sense for other people. It doesn’t add up for me.
Earlier quoted context omitted.
https://medium.com/@eeue56/top-6-ways-to-make-your-elm-app-c...
You’ve already posted this. It’s intellectually dishonest to point to implementation bugs as fundamental flaws.
Earlier quoted context omitted.
You’ve already posted this. It’s intellectually dishonest to point to implementation bugs as fundamental flaws.
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.
After a couple of years running in production, my opinion is that it is well-made generally.
Finding clever ways to break a technology isn’t a fair reflection of “real world” use, in my opinion.
Earlier quoted context omitted.
The problem with static typing confidence is it suggests no runtime errors, but really all it does is handle a certain class of runtime errors. To say that Elm has no runtime crashes is one thing, but it still suffers from all the runtime problems of any language when logic isn't written properly to account for different and unexpected values. Does your compiler guarantee that you don't have a "cents" value that is g…
This argument is essentially “the tool doesn’t protect me from everything, therefore it’s better to have no protection at all.” And I don’t agree with it. I’m aware Elm doesn’t have dependent types.
> "by default, number of runtime errors is zero"
And that's just a silly argument to make about any language and I hope Elm developers don't have false confidence about this.
Earlier quoted context omitted.
Hum... No. Abstractions can hide anything. Besides, your example get much of its gains by hiding the behavior of that 'if' statement than by hiding that 'buttonClicked' stores the button data.
> Hum... No. Abstractions can hide anything. Sure, I'm not going to argue the meaning of "state". You know what I mean. Hiding internal state is good for abstraction. > Besides, your example get much of its gains by hiding the behavior of that 'if' statement than by hiding that 'buttonClicked' stores the button data. The if statement is intrinsically linked to the boolean state. If your render function forgets its im…
The biggest drawback of the explicit state is that the separated GUI stages has to be named so the code can refer and match on them. This naming requires to spend mental energy when writing the code and is the reason behind complains about extra boilerplate in Elm.
In implicit state the stages are anonymous and hidden behind a semicolon (yield statements in your example). So it is faster to write code. Yet these nameless yet present states exist and makes much harder to grasp the code. One has to recover the states from the code, not from declarative description as with the explicit state.
I don't understand why this is noteworthy. I think maybe this is when you decide 'maybe our language has failed'. Or at least admit it's a toy language that hasn't been properly engineered to be effectively used commercially. When it's a 'worth mentioning' when a single app has been written in it by some dying company. I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Ja…
> Functional languages are great toys but nobody uses them to get work done, almost without exception. I run my own businesses on functional programming languages (Haskell and Elm) almost exclusively. 100% of my income comes from the three software products I own, all primarily written in Haskell. You're displaying a pretty amazing level of ignorance here.
Earlier quoted context omitted.
https://medium.com/@eeue56/top-6-ways-to-make-your-elm-app-c...
You’ve already posted this. It’s intellectually dishonest to point to implementation bugs as fundamental flaws.
Imagine my shock................
Earlier quoted context omitted.
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.
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/Ba...