Hacker News Comments (commented so it is not a refer link, just copy/paste it): “https://news.ycombinator.com/item?id=12906119”
Direct Article Link: http://reasonablypolymorphic.com/blog/elm-is-wrong
Basically someone is iterating a couple of the big issues I’ve had with Elm, though he is much more… loud with his language than I’d be, so fair warning. 
Skimmed over the article and I would agree with some of the comments on HN saying it is needlessly harsh. Evan should be commended for what he has done. Having said that, sometimes stark (even rude) negativity like this can drive people to prove their critics wrong on a mammoth scale - let’s hope this happens here 
Something good to come out of the link, the author of the blog is writing an introduction to computer science Preface :: Reasonably Polymorphic 
With regards to Elm, I was at one point really rooting for it, willing to forgo my dislike of white space significance. However, as is the case in the land of JS, new stuff keeps cropping up demanding attention. I need to put some time aside to look at all the options before deciding on something to go with (I will naturally be averse to anything created by Facebook).
Oh I do so hope so! ^.[1]
Something good to come out of the link, the author of the blog is writing an introduction to computer science Preface :: Reasonably Polymorphic
[/quote]
Huh, that looks quite interesting, might have to hold on to it to pass it around.
Come to Bucklescript, just normal OCaml but to JS. ^.^
quote=“AstonJ, post:2, topic:2317” ↩︎
Hmm. Bucklescript sounds very interesting. I really like ML family languages.
Saw that article and it seemed sort of like click bait to me.
Thanks for linking the article, was an interesting read for me!
The two pieces that stick out to me are:
There is no map function, but there are List.map, Dict.map, Array.map among others, and none of them are related to one another. This is not only annoying, but also breaks the abstract data-type guarantee: our call-sites are now tightly coupled to our implementation details. If I decide to change from a List a to an Array a for efficiency reasons, my whole codebase needs to know about it.
That seems really bad. 
The other thing I highly dislike is that part about packages with native bindings needing approval, that truly does not scale and it inhibits the community. What I love about Ruby and Elixir (and probably other languages just haven’t done it) is how easy it is to publish a package and share code with others. Love to do that. Any inhibitors to that greatly inhibit eco system growth and overall programmer happiness imo.
A long time ago Elm decided it’d be a language aimed at beginners and JavaScript programmers—not for ML or functional programming experts. This post’s complaints are the result of that. In general I do agree the way packages have to be “vetted” by Evan is ridiculous.
I’d tell the author to check out PureScript, GHC.js, and the various OCaml to JS technologies.
It was a rant for sure, bit more language then I’d recommend, and some of his points shows he is a bit biased (typeclasses are not the be-all-end-all of typing and are in fact highly restricting compared to the alternatives, in fact the ‘Witness’ way he proposed is the way OCaml does it, though more succinctly, and imparts more power as well).
Not really, most functional languages have ‘map’ based per-type instead of global (even Erlang, technically Elixir too but the Enum module tests the types and dispatches to the type-specific module). The reasoning is that you already know what the type is so make it a fast static dispatch. Typeclasses like in Haskell or Implicit Modules like in (the soon-coming version of) OCaml basically have compile-time dictionaries that do a lookup of a type to find the proper dispatch statically at runtime are just a simplification. Honestly he focused on that issue too much and is definitely not something I’d fault Elm on.
This I highly agree with. At the very least native/port modules should be accepted but behind a “I know what I’m doing” flag when used as a dependency, that way libraries and tests can still grow without being hampered.
Which is a great goal, however it entirely makes many classes of code categorically either impossible or significantly large. It really is a great library on a trivial language. Elm is even less complex than the little functional languages we make in compiler classes in college. The language gives us nothing. Like I’ve shown, the Elm code you can copy/paste into OCaml and make just a couple of syntactical differences that take second and then you suddenly have the same code but in a substantially more powerful language that does not take thousands of lines to emulate a simple idea.
There are plenty of options, he should go to them, he was ‘too’ noisy about Elm.
I work for NoRedInk, with Evan, but my thoughts are my own.
Keep in mind that Elm is still pre 1.0. Evan spends a ton of time trying to find the right solutions to problems and he’s totally fine with waiting until he has that.
Almost all Elm code is side effect free! This is huge. It cannot be overstated. Elm doesn’t have runtime errors, under normal circumstances. Let that sink in. Also, compare that with JavaScript.
Native code throws away all of those guarantees. If there are native libraries side by side with pure Elm code and a user doesn’t yet understand the difference, they are selecting a massive tradeoff without knowing it. We need to make sure we educate around this choice. One way to do that, in these early days, is to tightly manage native libraries.
Obviously, this isn’t the final plan for the language.
Based on what I have seen, I believe the plan is to expand elm package to be aware of catalogs or different sources you can fetch libraries from. This opens up the possibility for “Untrusted” catalogs, your company’s own internal catalogs, etc. This is kind of what I mean about Evan waiting until he’s sure he addressed all the needed concerns.
Again, I’m not promising this feature. The above is my best guess at where things are heading.
For what it’s worth, I really like Elm as a language and I think it’s very worth checking out.
Thanks for dropping by and clarifying James!
I can only imagine what it’s like to design a language… so I can see that tradeoffs have to be made. Still something like an “unsafe” flag with a warning making the user aware of the dangers or something like that would be better than prohibiting it.
I also might have come a across a bit wrong - I played a bit with Elm, liked it very much and am still looking forward to put more time into it to extend my knowledge as what I’ve seen so far was truly impressive.
So, one could say that I was a bit upset reading the article that my little pet interest had some flaws Still want to invest time and learn!
Languages should be judged on their lack of features, or their principles.
OCaml has the kitchen sink.
Elm wins : )
The last ‘feature’ I would like Evan to add before 1.0 is removing recursion, and therefore Turing Completeness.
A little tongue in cheek, but I do seriously believe that Turing Completeness is over-rated, for most real world applications.
Wait a second…this article is way outdated. It’s from version 0.16 (its from april) in may Elm introduced new look of elm with new architecture (0.17). Lots of issues from article was closed.
Issues on Elm are closed immediately upon being reported and they are combined into single mega-issues. And nothing he mentioned has been fixed.
Seems that Evan Czaplicki had at least at one time (2014) his eye on OCaml’s polymorphic variants:
OCaml has a cool feature to make this more light-weight [than Haskell type classes], but Elm does not have that yet.
He has used OCaml as inspiration for a lot of Elm, however I do not think polymorphic variants belong in Elm, they are too specific in usages for the simplicity that Elm is going for, though they are amazingly useful for plugins I could see…
© Copyright Elixir Forum | Terms | Privacy & Cookies
