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
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).
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.
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.
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.
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!
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…