10 ms·

State of Elm 2017 Results

83 points by myth_drannon 9y ago

tarr11 9y ago
JSON Decoders were the killer for me. Just way too verbose.
- enalicho 9y ago
  Luckily there's a whole range of tools dedicated to making your life there a bit easier: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export And so on :) While it would be nice to solve Json Decoders in a better way, these solutions are very helpful for the time being.
shakna 9y ago
> JSON Decoders: This is one of those things that everyone has trouble with. I sure did! So I wrote a book about them. They’re not that bad once you get used to them! This is odd thinking. Everyone hates the current JSON Decoders. That suggests that there is something wrong with them, not that the audience should simply "get used to them".
- hellofunk 9y ago
  The "our way is the right way" mentality that is common in the Elm community is really the larger issue here, and it has been a bit of a turn off for me. There is a lot about Elm to really like, but it is a rather closed off development culture without a lot of appreciation for hearing ideas and experiences from others. If Elm could open up and allow developers to experiment with other architectures, like pretty much every other language, and not be so restrictive in forcing everyone into the exact same pattern, I think it would be very successful, because the language itself is nice. If someone wants to use Elm as it currently is, that should be one simple option available to everyone. But you should be able to easily discard that if you want to, and do other things, including making a choice on the trade-offs for JavaScript interaction. Languages that don't give developers much choice in how they are used are usually not going to be very successful.
  - tylerdiaz 9y ago
    I noticed a similar problem when I wanted elm-format's indentation set with 2 spaces instead of the un-configurable 4.
    - enalicho 9y ago
      Please see the discussion at https://github.com/avh4/elm-format/issues/210 https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.
      - allover 9y ago
        It might have been fine if elm-format had chosen better defaults. Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue. And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy. Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
        hellofunk 9y ago
        The interesting thing to me is that you highlight how priorities are different among different people/companies; to me, choice of indentation spacing is trivial. But to you and the sibling comment, it obviously is not. And that's the point: a developer should be respected to decide what is important for their work. In this case, we are talking about indentation flexibility. But this problem scales throughout on many other issues that I might find important but you do not. Most languages give developers more freedom, even if starting out with a consistent default that everyone can understand first.
- enalicho 9y ago
  I posted this lower down, but I'm posting it here again since it also applies to your comment: Luckily there's a whole range of tools dedicated to making your life there a bit easier: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export And so on :) While it would be nice to solve Json Decoders in a better way, these solutions are very helpful for the time being. Long term, I personally believe the right route is hard to decide on. We could go with json-decoders being part of the language and compiler itself. We could generate decoders from type aliases. Or some template solution like template Haskell. Or tagged unions like Go. The issue is that decoders are not a blocker to people who write a lot of Elm. They make me sad, but they're not a blocker. That means that the solution is not such a high priority.
- danneu 9y ago
  Elm's JSON combinators are great. I'm sure one reason so many people have particular trouble with them is because, according to the survey, the vast majority of them come from a dynamically-typed language where you'd just go `user = JSON.parse(string)`. I think a lot of people would be helped by tacking a bunch of real-world examples onto the actual Json.Decoder docs like how to decode `[1, [3, 5], 7, 9]` (nested range) into `[1, 3, 4, 5, 7, 9]`. One issue is that it's pretty hard to derive understanding from just function signatures, so a dozen quick-start / cookbook examples gives people something to chew on. Combinators are really good at forbidding runtime errors which is a central theme of Elm, but it comes at the expense of a steeper learning curve than the weaker alternatives that come to mind: reflection and manual descent.
  - shakna 9y ago
    > Elm's JSON combinators are great. > I'm sure one reason so many people have particular trouble Those two sentences don't really fit together. Elm isn't an academic experiment, which means people need to use it. If the vast majority of people find it overly difficult, then it probably is. > come from a dynamically-typed language where you'd just go `user = JSON.parse(string)` Not just dynamic languages. Haskell, one of Elm's inspirations, can handle it a hell of a lot easier. Define an interface, then use it on a string: data Coord = Coord { x :: Double, y :: Double } deriving (Show, Generic) let req = decode "{\"x\":3.0,\"y\":-1.0}" :: Maybe Coord I am cheating a bit, as that's the aeson package... But decoding the JSON is a lot simpler than the Elm equivalent, and Haskell doesn't even target web browsers, where JSON is so prevalent. But, here's another static example, this time, C++. auto j3 = json::parse("{ \"happy\": true, \"pi\": 3.141 }"); You can use auto to avoid writing a massive type definition, or you can write it ensure it's correct. Static typing has nothing to do with not being able to write JSON.parse(string), because it doesn't prevent that. At all.
    - PhineasRex 9y ago
      I've heard more than one person argue against automatically generated encoders/decoders since it's easy to accidentally introduce breaking changes to your API by renaming a record field / class method. If that's your view then Elm's approach is a plus for the language since it eliminates a potential pitfall.
- savanaly 9y ago
  I don't think that sentence you quoted suggest everyone should get used to them. It simply says they're not that bad once you get used to them.
  - shakna 9y ago
    > It simply says they're not that bad once you get used to them. Yes, and I was simply pointing out that, that is not helpful thinking. JSON is fundamental to working with the web, and Elm works on the web. A high learning curve on something fundamental is fine in languages that are academic in nature, intentionally obtuse, or designed to be difficult. It's not fine in a language intended for production use. This post was about a language survey. It says that JSON decoders are too hard for the audience. A helpful step forward, is seeing how to make them less obtuse. An unhelpful step backward, is tell everyone just deal with it. We'll see which step Elm takes in the coming months.
the_duke 9y ago
From looking at the repositories, I get the feeling that Elm devopment effort has been pretty low for quite a while. Many pull requests and issues are undiscussed and uprocessed.
- hellofunk 9y ago
  Elm's primary development largely operates on the whims of a single person. This can have both advantages and disadvantages, and in my opinion is a net negative.
  - steinuil 9y ago
    I think the advantages of depending on a single person only come out when that person has a clear vision of where they want to bring the project. I feels like Evan doesn't know what to do with the more advanced features that Elm, in my opinion, desperately needs, and I've been pretty unhappy with how he's taken a policy of removing stuff because nobody uses it.
    - hellofunk 9y ago
      The other problem is that no matter how many times different people bring up the same recommendations for Elm language features, if those opinions are not shared by Evan, they are seen as trivial and unnecessary. Also, for such a very tiny community, they make it hard to participate in some ways. Many of the github issues are locked for comments unless you are a core contributor. And the mailing list has a lengthy waiting period on the first several new messages sent to it (I've never seen such a tightly moderated list in any language). You would think they would want to embrace anyone who chooses to spend time with their language, but they don't really give average users much of a voice.
      - steinuil 9y ago
        Yep, there is very little discussion over taking the language in other directions, because ultimately Evan supposedly knows best. It's sad to see such a nice project being bogged down by such a mentality, but Evan really brought this upon himself.
dom96 9y ago
It's great to see so many programming language community surveys these days. I'm running a survey for the Nim programming language and I'd love to hear your responses: https://nim-lang.org/blog/2017/06/23/community-survey-2017.html https://nim-lang.org/blog/2017/06/23/community-survey-2017.h...
fnordsensei 9y ago
> Aside from the huge number of JavaScript programmers, the top 5 are Ruby, Python, Haskell and Java. > No functional language beside Haskell cracked the top 5. I’m a little surprised by this: I had expected to see more people with functional programming experience. Perhaps Elm provides less "news" to people who are already using one functional platform or another, and therefore lower incentive to try it out/switch?
- Tarean 9y ago
  For haskell programmers there is also purescript which is basically a somewhat cleaned up haskell that compiles to human readable javascript.
deleted 9y ago
[deleted]
crimsonalucard 9y ago
I was trying to build a tmux style svg based windowing system for elm. Guess what? this involves a tree. Trees don't go well with functional programming. Ever heard of a zipper? lol.
- hellofunk 9y ago
  I used to think that walking trees was a standard task in functional programming languages because the one I am used to (Clojure) contains gobs of functions in its library for all kinds of walking, zipping, combining, separating trees of different structures. But I've learned since studying other functional languages that it isn't as commonly done as I'd thought.
- gilmi 9y ago
  > Trees don't go well with functional programming What? Building trees is easy as pie in typed fp http://hackage.haskell.org/package/containers-0.5.10.2/docs/Data-Tree.html http://hackage.haskell.org/package/containers-0.5.10.2/docs/... > Ever heard of a zipper? https://github.com/soupi/purescript-list-zipper/blob/master/src/Data/List/Zipper.purs https://github.com/soupi/purescript-list-zipper/blob/master/...
- enalicho 9y ago
  Trees go extremely well with FP. In fact, a lot of Elm's core data structures are implemented with trees. Dicts, Arrays, Sets. Here's an example of a zipper package in Elm: http://package.elm-lang.org/packages/wernerdegroot/listzipper/latest http://package.elm-lang.org/packages/wernerdegroot/listzippe...
- deleted 9y ago
  [deleted]
op00to 9y ago
Before reading the article, I was really excited to read about people still using Elm (the email client) in 2017. There's enough people using Elm to justify a State of Elm in 2017? Awesome! I was disappointed.

83 points by myth_drannon 9y ago

tarr11 9y ago

JSON Decoders were the killer for me. Just way too verbose.

enalicho 9y ago
Luckily there's a whole range of tools dedicated to making your life there a bit easier: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export And so on :) While it would be nice to solve Json Decoders in a better way, these solutions are very helpful for the time being.

shakna 9y ago

> JSON Decoders: This is one of those things that everyone has trouble with. I sure did! So I wrote a book about them. They’re not that bad once you get used to them! This is odd thinking. Everyone hates the current JSON Decoders. That suggests that there is something wrong with them, not that the audience should simply "get used to them".

hellofunk 9y ago
The "our way is the right way" mentality that is common in the Elm community is really the larger issue here, and it has been a bit of a turn off for me. There is a lot about Elm to really like, but it is a rather closed off development culture without a lot of appreciation for hearing ideas and experiences from others. If Elm could open up and allow developers to experiment with other architectures, like pretty much every other language, and not be so restrictive in forcing everyone into the exact same pattern, I think it would be very successful, because the language itself is nice. If someone wants to use Elm as it currently is, that should be one simple option available to everyone. But you should be able to easily discard that if you want to, and do other things, including making a choice on the trade-offs for JavaScript interaction. Languages that don't give developers much choice in how they are used are usually not going to be very successful.
- tylerdiaz 9y ago
  I noticed a similar problem when I wanted elm-format's indentation set with 2 spaces instead of the un-configurable 4.
  - enalicho 9y ago
    Please see the discussion at https://github.com/avh4/elm-format/issues/210 https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.
    - allover 9y ago
      It might have been fine if elm-format had chosen better defaults. Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue. And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy. Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
      - hellofunk 9y ago
        The interesting thing to me is that you highlight how priorities are different among different people/companies; to me, choice of indentation spacing is trivial. But to you and the sibling comment, it obviously is not. And that's the point: a developer should be respected to decide what is important for their work. In this case, we are talking about indentation flexibility. But this problem scales throughout on many other issues that I might find important but you do not. Most languages give developers more freedom, even if starting out with a consistent default that everyone can understand first.
enalicho 9y ago
I posted this lower down, but I'm posting it here again since it also applies to your comment: Luckily there's a whole range of tools dedicated to making your life there a bit easier: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export And so on :) While it would be nice to solve Json Decoders in a better way, these solutions are very helpful for the time being. Long term, I personally believe the right route is hard to decide on. We could go with json-decoders being part of the language and compiler itself. We could generate decoders from type aliases. Or some template solution like template Haskell. Or tagged unions like Go. The issue is that decoders are not a blocker to people who write a lot of Elm. They make me sad, but they're not a blocker. That means that the solution is not such a high priority.
danneu 9y ago
Elm's JSON combinators are great. I'm sure one reason so many people have particular trouble with them is because, according to the survey, the vast majority of them come from a dynamically-typed language where you'd just go `user = JSON.parse(string)`. I think a lot of people would be helped by tacking a bunch of real-world examples onto the actual Json.Decoder docs like how to decode `[1, [3, 5], 7, 9]` (nested range) into `[1, 3, 4, 5, 7, 9]`. One issue is that it's pretty hard to derive understanding from just function signatures, so a dozen quick-start / cookbook examples gives people something to chew on. Combinators are really good at forbidding runtime errors which is a central theme of Elm, but it comes at the expense of a steeper learning curve than the weaker alternatives that come to mind: reflection and manual descent.
- shakna 9y ago
  > Elm's JSON combinators are great. > I'm sure one reason so many people have particular trouble Those two sentences don't really fit together. Elm isn't an academic experiment, which means people need to use it. If the vast majority of people find it overly difficult, then it probably is. > come from a dynamically-typed language where you'd just go `user = JSON.parse(string)` Not just dynamic languages. Haskell, one of Elm's inspirations, can handle it a hell of a lot easier. Define an interface, then use it on a string: data Coord = Coord { x :: Double, y :: Double } deriving (Show, Generic) let req = decode "{\"x\":3.0,\"y\":-1.0}" :: Maybe Coord I am cheating a bit, as that's the aeson package... But decoding the JSON is a lot simpler than the Elm equivalent, and Haskell doesn't even target web browsers, where JSON is so prevalent. But, here's another static example, this time, C++. auto j3 = json::parse("{ \"happy\": true, \"pi\": 3.141 }"); You can use auto to avoid writing a massive type definition, or you can write it ensure it's correct. Static typing has nothing to do with not being able to write JSON.parse(string), because it doesn't prevent that. At all.
  - PhineasRex 9y ago
    I've heard more than one person argue against automatically generated encoders/decoders since it's easy to accidentally introduce breaking changes to your API by renaming a record field / class method. If that's your view then Elm's approach is a plus for the language since it eliminates a potential pitfall.
savanaly 9y ago
I don't think that sentence you quoted suggest everyone should get used to them. It simply says they're not that bad once you get used to them.
- shakna 9y ago
  > It simply says they're not that bad once you get used to them. Yes, and I was simply pointing out that, that is not helpful thinking. JSON is fundamental to working with the web, and Elm works on the web. A high learning curve on something fundamental is fine in languages that are academic in nature, intentionally obtuse, or designed to be difficult. It's not fine in a language intended for production use. This post was about a language survey. It says that JSON decoders are too hard for the audience. A helpful step forward, is seeing how to make them less obtuse. An unhelpful step backward, is tell everyone just deal with it. We'll see which step Elm takes in the coming months.

the_duke 9y ago

From looking at the repositories, I get the feeling that Elm devopment effort has been pretty low for quite a while. Many pull requests and issues are undiscussed and uprocessed.

hellofunk 9y ago
Elm's primary development largely operates on the whims of a single person. This can have both advantages and disadvantages, and in my opinion is a net negative.
- steinuil 9y ago
  I think the advantages of depending on a single person only come out when that person has a clear vision of where they want to bring the project. I feels like Evan doesn't know what to do with the more advanced features that Elm, in my opinion, desperately needs, and I've been pretty unhappy with how he's taken a policy of removing stuff because nobody uses it.
  - hellofunk 9y ago
    The other problem is that no matter how many times different people bring up the same recommendations for Elm language features, if those opinions are not shared by Evan, they are seen as trivial and unnecessary. Also, for such a very tiny community, they make it hard to participate in some ways. Many of the github issues are locked for comments unless you are a core contributor. And the mailing list has a lengthy waiting period on the first several new messages sent to it (I've never seen such a tightly moderated list in any language). You would think they would want to embrace anyone who chooses to spend time with their language, but they don't really give average users much of a voice.
    - steinuil 9y ago
      Yep, there is very little discussion over taking the language in other directions, because ultimately Evan supposedly knows best. It's sad to see such a nice project being bogged down by such a mentality, but Evan really brought this upon himself.

dom96 9y ago

It's great to see so many programming language community surveys these days. I'm running a survey for the Nim programming language and I'd love to hear your responses: https://nim-lang.org/blog/2017/06/23/community-survey-2017.html https://nim-lang.org/blog/2017/06/23/community-survey-2017.h...

fnordsensei 9y ago

> Aside from the huge number of JavaScript programmers, the top 5 are Ruby, Python, Haskell and Java. > No functional language beside Haskell cracked the top 5. I’m a little surprised by this: I had expected to see more people with functional programming experience. Perhaps Elm provides less "news" to people who are already using one functional platform or another, and therefore lower incentive to try it out/switch?

Tarean 9y ago
For haskell programmers there is also purescript which is basically a somewhat cleaned up haskell that compiles to human readable javascript.

deleted 9y ago

[deleted]

crimsonalucard 9y ago

I was trying to build a tmux style svg based windowing system for elm. Guess what? this involves a tree. Trees don't go well with functional programming. Ever heard of a zipper? lol.

hellofunk 9y ago
I used to think that walking trees was a standard task in functional programming languages because the one I am used to (Clojure) contains gobs of functions in its library for all kinds of walking, zipping, combining, separating trees of different structures. But I've learned since studying other functional languages that it isn't as commonly done as I'd thought.
gilmi 9y ago
> Trees don't go well with functional programming What? Building trees is easy as pie in typed fp http://hackage.haskell.org/package/containers-0.5.10.2/docs/Data-Tree.html http://hackage.haskell.org/package/containers-0.5.10.2/docs/... > Ever heard of a zipper? https://github.com/soupi/purescript-list-zipper/blob/master/src/Data/List/Zipper.purs https://github.com/soupi/purescript-list-zipper/blob/master/...
enalicho 9y ago
Trees go extremely well with FP. In fact, a lot of Elm's core data structures are implemented with trees. Dicts, Arrays, Sets. Here's an example of a zipper package in Elm: http://package.elm-lang.org/packages/wernerdegroot/listzipper/latest http://package.elm-lang.org/packages/wernerdegroot/listzippe...
deleted 9y ago
[deleted]

op00to 9y ago

Before reading the article, I was really excited to read about people still using Elm (the email client) in 2017. There's enough people using Elm to justify a State of Elm in 2017? Awesome! I was disappointed.