If you're interested in Elm but don't really know what it's about, I highly recommend Evan's Strange Loop talk, "Controlling Time and Space: understanding the many formulations of FRP."
It will help to already have a bit of background in functional programming.
The Elm website is blank without JavaScript enabled. Here's a script to extract the Markdown in the given page and optionally format it without having to enable JavaScript in the browser:
The benefits are actually much deeper though. Now that we know exactly how the API has changed, it is possible to automatically enforce strict versioning rules. If there are breaking changes, the new release must be a major version bump.
This is very interesting to me. It demands consideration: do we need a person to manually bump the version anymore at all? If you can statically verify that a change meets the criteria, couldn't the package publishing process autoincrement the appropriate version segment and be done with it?
there are probably cases in which you want to change the version independently of API changes, i.e. "going stable" (0.x to 1.0), major internal changes, new interfaces with deprecations of the old ones etc.
It seems doable to differentiate additions from (breaking) changes if all the API is statically defined. It would be nice to even have the feedback on larger changes.
That being said it's possible to change a library's behaviour without touching the API. Consider the following diff:
-add a b = a + b
+add a b = a - b
Granted the example is simplistic. With the API versioning system in place the author should have renamed the method and would have gotten the right result. It's just to show that it wouldn't be a silver bullet.
What is the point of changes like [] to List, mod to %, . to << and >>?
Is it just aesthetics?
When I looked at Elm it was really similar to Haskell. After I learned a bit of Elm I dove into Haskell. Now that I'm coming back to Elm I'm having problems because I confuse this different syntaxes many times.
I hoped they could maintain the language more similar to it to make the switch between them easier.
Personally, I am overjoyed that Elm is taking steps to make it's aesthetics more approachable to the non-Haskell crowd. Haskell is wonderful, but it has a learning curve that is steep enough to ward off the vast majority of programmers. A big part of the curve is that Haskell has a vocabulary that presumes a familiarity with decades of research that frankly only a very small population is familiar with. In that context, I'm sure "lift" made sense for the Elm thesis. But, without that context, "map" makes a lot more sense to me and to a lot more people.
I'm hopeful that Elm will help bring Haskell's ideas to a wider audience. After those ideas become familiar, I fully expect a large crowd of them to find Haskell's highly efficient syntax for expressing them to be very enticing. But, getting people to that point is going to require a lot of considerations to ease the JavaScripter -> Elmer -> Haskeller transformation.
I personally find all the changes really nice. (<|), (|>), (<<), (>>), are far more intuitive compared to the Haskell operators for example. Yes, it's just syntax, but usability is important. As an aside, Idris uses (:) in type signatures, and doesn't have a lift function in its standard library (it just leans on a genereralised map function).
They have no intention of making them more similar- in fact I was told there is going to be more subtle diverging happening.
Elm was really cool for me too at first, but these subtleties are just a pain. I am now using haste (haste-lang.org), which seems to have really come a long way over the course of its 3 year life span. I highly recommend it to those wanting to use Haskell as a front-end web development language.
Have there been any performance improvements under Firefox? Almost every Elm demo that I've seen so far has been basically unusable under that browser. I've been told that the issue is some difference between Chrome and FF with canvas drawing... but regardless of where the fault lies, Elm is pretty much a Chrome-only technology until that gets worked out.
Awesome. I like the name change from 'lift' to 'map'. Also, the public API diffs that the packaging tool provides looks very neat. Congrats to the Elm team!
It's nice to see that they have replaced Either with Result[0]. I wonder if Rust's Result type[1] was the inspiration? (not sure if there is prior art)
I started looking into Rust again while picking the term "union type" because of their choice to use the term "enum". I ran into the Result type in some code I was reading and it just made so much more sense to me as a new person learning the language. Basically, it made it self-evident to me that "a library for error handling should be named with error handling in mind." You will also see a Result type in some Haskell libraries so it's not unprecedented there.
I also got tired of explaining "the good result goes in Right, because it's 'Right'" like I'm endlessly telling a bad dad-joke.
It's possible, but it's really just a name change. And the `Either` monad is used almost entirely for error handling anyway, so Result is a name that many Haskell/Elm users could come up with on their own.
"Result" is a pretty opaque name: any value or type can be called a "Result", really. "Either" at least hints to the fact that it is either-this-or-that.
"Either" is IMO a nice counterpart to tuple types: one is a generic sum, the other is a generic product. People could complain that a tuple of ints are less descriptive than just using a constructor with a more descriptive name - like "Pair" or "Coordinate", depending on its intended application.
Having a specialized type for error handling makes sense, though.
Elm really is fascinating... Am I the only one who thinks FRP is just a reincarnation of dataflow programming?
I'm learning Verilog in my spare time, because I want to implement a dataflow/FRP language in hardware. (People tried to build massively parallel hardware in the past to run dataflow languages... I'm pretty sure it's a good idea.) Should be interesting!
That's like saying Rust is "just a reincarnation of imperative programming". Dataflow is an extremely general category, there's a lot of room for important differences; describing something as "dataflow" doesn't really tell you much about it.
I used Elm for my Ludum Dare entry. As a first attempt using a functional language I definitely did many things wrong, but I found it very easy to iterate. Great language and I'm going to look into going further with it for game development.
Eh, that's a tagged union, but I think "union type" usually refers to untagged unions like you see in more dynamic languages such as TypeScript and Facebook's Flow. Tagged unions are typically called sum types. That is, searching for "union type" is gonna give you results about untagged unions or C style unions. I'm not sure this new terminology helps.
We discussed this to death on the mailing list, and this was definitely a consideration!
People searching for it online will very likely be searching for "elm union type" where they'll quickly find examples and docs. Furthermore, you can prefix the term "union type" with stuff like "closed/open" and "tagged/untagged" to start making finer grained distinctions as need higher degrees of precision. In Elm it is always tagged and closed, so in discussions within the community, adding those prefixes is redundant. Finally, if you start with the term "union type" it becomes easier to think about what an "anonymous union type" might look like (like OCaml's polymorphic variants or open variants) ;)
More broadly, if people do run into the term "union type" in other languages they will be building intuition in exactly the way I'd like: it's a way to use different types in the same place. Things happen to have this extra tag thing in Elm, but it's not so different than anything people do in JS or Clojure or Racket or TypeScript or C or whatever else. I think bringing that connection out is a major benefit of this naming choice. The goal is to feel really welcoming and friendly, and my personal preference is to build on people's existing intuition as much as possible. If someone comes from JS and does not see all the subtleties of this discussion immediately on day one, they are actually having a better experience because they can learn the info as it becomes relevant to their daily usage. Hopefully a much nicer learning curve!
I realize I am making a somewhat controversial choice, but the idea is that statically typed FP people are building artificial barriers by being sticklers about this, rather than just prefixing for precision. You may not agree with all this, but we thought it through pretty extensively, and that is the reasoning!
Depending on who you ask, there's another established meaning of "union type" when contrasting it against "sum type" in a safe context. Sum types are discriminated unions in which each constructor tag in the union is disjoint from each other member and all other types. In contrast, "union type" tends to imply that you can share constructors/tags between types.
For the record, I voted for enum, like in rust-lang ;-)
This was going to be contentious no matter what. For what it's worth, Wikipedia (top Google result) seems to have a compatible story.
Luckily, it's just a conversation change. I think it will be fine, and net more helpful than damaging. The overall goals are intuition and accessibility.
We've been using it to render schematic symbols and PCB footprints at CircuitHub.com (this has been going on for a couple of months). I'm testing it out in other areas of the product at the moment, so if all goes well additional Elm widgets might land on our site very soon.
For a second I had thought that someone had released an update for the Elm mail client. Color me disappointed (although I am more of a Pine guy myself, up to ~2006 at least).
That's pretty ridiculous. Literally the day after I start working on my Elm project in a couple months...
Anyway, the changes here do look pretty nice. Looking at the docs, it seems that they've added more examples, which is always appreciated! I still don't like the impurity that comes with the Signal.Channel, though... not that I have a better idea.
[+] [-] dcre|11 years ago|reply
It will help to already have a bit of background in functional programming.
https://www.youtube.com/watch?v=Agu6jipKfYw
[+] [-] musername|11 years ago|reply
[+] [-] pflanze|11 years ago|reply
https://github.com/pflanze/de-elm
(Edit: here's a copy of the content of the linked page: https://github.com/pflanze/de-elm/blob/master/examples/annou... . Tell me if you don't like this and I'll remove it again.)
[+] [-] jmite|11 years ago|reply
[+] [-] 3rd3|11 years ago|reply
[+] [-] couchand|11 years ago|reply
This is very interesting to me. It demands consideration: do we need a person to manually bump the version anymore at all? If you can statically verify that a change meets the criteria, couldn't the package publishing process autoincrement the appropriate version segment and be done with it?
[+] [-] riffraff|11 years ago|reply
[+] [-] zimbatm|11 years ago|reply
That being said it's possible to change a library's behaviour without touching the API. Consider the following diff:
Granted the example is simplistic. With the API versioning system in place the author should have renamed the method and would have gotten the right result. It's just to show that it wouldn't be a silver bullet.[+] [-] rnhmjoj|11 years ago|reply
When I looked at Elm it was really similar to Haskell. After I learned a bit of Elm I dove into Haskell. Now that I'm coming back to Elm I'm having problems because I confuse this different syntaxes many times.
I hoped they could maintain the language more similar to it to make the switch between them easier.
[+] [-] corysama|11 years ago|reply
I'm hopeful that Elm will help bring Haskell's ideas to a wider audience. After those ideas become familiar, I fully expect a large crowd of them to find Haskell's highly efficient syntax for expressing them to be very enticing. But, getting people to that point is going to require a lot of considerations to ease the JavaScripter -> Elmer -> Haskeller transformation.
[+] [-] bjz_|11 years ago|reply
[+] [-] fallat|11 years ago|reply
: and :: are reversed.
They have no intention of making them more similar- in fact I was told there is going to be more subtle diverging happening.
Elm was really cool for me too at first, but these subtleties are just a pain. I am now using haste (haste-lang.org), which seems to have really come a long way over the course of its 3 year life span. I highly recommend it to those wanting to use Haskell as a front-end web development language.
[+] [-] sbergot|11 years ago|reply
[+] [-] StevePerkins|11 years ago|reply
[+] [-] jcollard|11 years ago|reply
https://github.com/elm-lang/core/pull/25
I believe the original improvements were done here: https://github.com/jwmerrill/elm-animation-frame
I modified a game I wrote to use the modified run time. I can see a huge difference between the two in Firefox.
Unmodified: http://jcollard.github.io/elm-flyer-old/
Modified: http://jcollard.github.io/elm-flyer/
[+] [-] davexunit|11 years ago|reply
[+] [-] bjz_|11 years ago|reply
[0]: http://elm-lang.org/blog/announce/0.14.elm#making-error-hand...
[1]: http://static.rust-lang.org/doc/master/std/result/index.html
[+] [-] wheatBread|11 years ago|reply
I also got tired of explaining "the good result goes in Right, because it's 'Right'" like I'm endlessly telling a bad dad-joke.
[+] [-] rjayatilleka|11 years ago|reply
[+] [-] Dewie|11 years ago|reply
"Either" is IMO a nice counterpart to tuple types: one is a generic sum, the other is a generic product. People could complain that a tuple of ints are less descriptive than just using a constructor with a more descriptive name - like "Pair" or "Coordinate", depending on its intended application.
Having a specialized type for error handling makes sense, though.
[+] [-] AlexanderDhoore|11 years ago|reply
I'm learning Verilog in my spare time, because I want to implement a dataflow/FRP language in hardware. (People tried to build massively parallel hardware in the past to run dataflow languages... I'm pretty sure it's a good idea.) Should be interesting!
[+] [-] tree_of_item|11 years ago|reply
[+] [-] lsjroberts|11 years ago|reply
[+] [-] tree_of_item|11 years ago|reply
[+] [-] wheatBread|11 years ago|reply
People searching for it online will very likely be searching for "elm union type" where they'll quickly find examples and docs. Furthermore, you can prefix the term "union type" with stuff like "closed/open" and "tagged/untagged" to start making finer grained distinctions as need higher degrees of precision. In Elm it is always tagged and closed, so in discussions within the community, adding those prefixes is redundant. Finally, if you start with the term "union type" it becomes easier to think about what an "anonymous union type" might look like (like OCaml's polymorphic variants or open variants) ;)
More broadly, if people do run into the term "union type" in other languages they will be building intuition in exactly the way I'd like: it's a way to use different types in the same place. Things happen to have this extra tag thing in Elm, but it's not so different than anything people do in JS or Clojure or Racket or TypeScript or C or whatever else. I think bringing that connection out is a major benefit of this naming choice. The goal is to feel really welcoming and friendly, and my personal preference is to build on people's existing intuition as much as possible. If someone comes from JS and does not see all the subtleties of this discussion immediately on day one, they are actually having a better experience because they can learn the info as it becomes relevant to their daily usage. Hopefully a much nicer learning curve!
I realize I am making a somewhat controversial choice, but the idea is that statically typed FP people are building artificial barriers by being sticklers about this, rather than just prefixing for precision. You may not agree with all this, but we thought it through pretty extensively, and that is the reasoning!
[+] [-] brandonbloom|11 years ago|reply
For example Julia: http://docs.julialang.org/en/release-0.3/manual/types/#type-...
Typed Racket: http://docs.racket-lang.org/ts-guide/beginning.html#%28part....
Haskell: http://okmij.org/ftp/Haskell/extensible/#open-union
And many more.
[+] [-] johnpmayer|11 years ago|reply
This was going to be contentious no matter what. For what it's worth, Wikipedia (top Google result) seems to have a compatible story.
Luckily, it's just a conversation change. I think it will be fine, and net more helpful than damaging. The overall goals are intuition and accessibility.
[+] [-] thewarrior|11 years ago|reply
[+] [-] RehnoLindeque|11 years ago|reply
[+] [-] rtfeldman|11 years ago|reply
https://github.com/rtfeldman/dreamwriter
[+] [-] etaque|11 years ago|reply
Nothing serious though...
[+] [-] shard|11 years ago|reply
[+] [-] jmgrosen|11 years ago|reply
Anyway, the changes here do look pretty nice. Looking at the docs, it seems that they've added more examples, which is always appreciated! I still don't like the impurity that comes with the Signal.Channel, though... not that I have a better idea.
[+] [-] lucian1900|11 years ago|reply
Interestingly enough, the dice is loaded. If you click long enough, you'll get an upside down V shape.
[+] [-] flebron|11 years ago|reply
[1] http://en.wikipedia.org/wiki/Binomial_distribution [2] http://hyperphysics.phy-astr.gsu.edu/hbase/math/dice.html#c2
[+] [-] davidrusu|11 years ago|reply
7 = 1+6, 2+5, 3+4, 4+3, 5+2, 6+1
2 = 1+1, 1+1
[+] [-] peapicker|11 years ago|reply