161–170 of 199 posts
Earlier quoted context omitted.
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.
What happens if you call in your ReasonML code a JS function that throws an exception?
Earlier quoted context omitted.
I think you should read this as being an otherwise 150kloc project in Java. Seriously, at this point IBM should fork a couple hundred thousand dollars just to know how anyone on their staff can recreate this in idiomatic java (or whatever OO language they want) and have you do it in idiomatic clojure/script. I'd be surprised if you managed less than 30k and very surprised if the OO implementation managed less than 10…
In this comparison of a minimal "real world" app comparison, Elm version has around 3 times as much code as ClojureScript. https://medium.freecodecamp.org/a-real-world-comparison-of-f...
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.
Here's a concrete real world example of what I'm talking about:
>When I first wrote the core.async go macro I based it on the state monad. It seemed like a good idea; keep everything purely functional. However, over time I've realized that this actually introduces a lot of incidental complexity. And let me explain that thought.
>What are we concerned about when we use the state monad, we are shunning mutability. Where do the problems surface with mutability? Mostly around backtracking (getting old data or getting back to an old state), and concurrency.
>In the go macro transformation, I never need old state, and the transformer isn't concurrent. So what's the point? Recently I did an experiment that ripped out the state monad and replaced it with mutable lists and lots of atoms. The end result was code that was about 1/3rd the size of the original code, and much more readable.
>So more and more, I'm trying to see mutability through those eyes: I should reach for immutable data first, but if that makes the code less readable and harder to reason about, why am I using it?
https://groups.google.com/forum/#!topic/clojure/wccacRJIXvg
Another example of something that's trivial in a dynamic language, but difficult to do in a static one would be Ring middleware: https://github.com/ring-clojure/ring/wiki/Middleware-Pattern...
So really what you're doing with static typing is trading one set of problems for another. This is perfectly fine if those are the kinds of problems you prefer to deal with, but it's important to recognize that you are making a trade off as opposed to getting something for free here.
Earlier quoted context omitted.
tail : List a -> Maybe (List a) Nice try though. https://github.com/elm/core/blob/master/src/List.elm#L548
Haha, sorry. You know what I mean, a partial function.
You're thinking of the partial functions from Haskell's Prelude.
Earlier quoted context omitted.
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...
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?
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…
You've used an example similar to a continuation, what is explicitly about flow control. Unless you are suggesting appropriating flow control into data (because you will need an interpreter) means that everything is "state".
I don't think that 'buttonClicked' value will make into the page state of an Elm program.
Earlier quoted context omitted.
Aren't those few lines missing all of async/IO/runtime stuff? Is all that supposed to happen inside `render`?
Edit: I changed my response after I took the time to understand what you meant. Concur has a very uniform programming model where you do everything by composing widgets. `elm` is a widget. `render` also is a widget. As such both can perform arbitrary async effects, and they take place inside event handlers, or inside lifecycle methods like componentWillMount. Concur takes care of managing that for you. So to log all…
I think Elm isolates its “views” much more, but concur might be easier (less boilerplate). I will definitely give it a try now, sometime.
Earlier quoted context omitted.
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.
Only insofar as you would check any technology for how well it’s made generally. 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.
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.
Well, you wrote: > "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.
Now that we have ReasonML, which has a more predictable and sustainable release cycle, and large support, as well as functional programming from OCaml and smoother JS interop when that's desired, what does Elm still bring to the table? When Elm was originally developed, there wasn't a viable alternative for those who wanted good statically-typed FP in the browser, but it would seem now that new apps in this style of…
Also, Elm has terrible communication (yearly posts) and official docs
And to be fair it's the best documented platform for web development I have worked with. Have you looked at documentations of random npm packages lately? No, fun.