6 ms·

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

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
        Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.
    - enalicho 9y ago
      > It might have been fine if elm-format had chosen better defaults. Subjective. This is a time old discussion. Please read the linked issue. > 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. When I come to an Elm project, I am able to read the code instantly. In fact, the majority (91%) of the Elm community who use elm-format enjoy it because of this. See here: https://www.brianthicks.com/post/2017/07/27/state-of-elm-2017-results/#do-you-format-your-code-with-elm-format https://www.brianthicks.com/post/2017/07/27/state-of-elm-201... What you say might be true for you, but for people who are actually writing and using Elm, it does not apply.
      - deleted 9y ago
        [deleted]
      - hellofunk 9y ago
        > for people who are actually writing and using Elm, it does not apply You assume the OP is not actually using the language.
leshow 9y ago
This has also been my experience. Elm programmers don't tolerate dissent. The community is welcoming so long as you toe the line.
- rtfeldman 9y ago
  I'm not sure what the last sentence is supposed to mean. Can you link to an example of what you're referring to?
  - barrkel 9y ago
    Have a look at this thread right here: https://news.ycombinator.com/item?id=14873351 https://news.ycombinator.com/item?id=14873351
    - dyeje 9y ago
      Dang you beat me to it. Pretty funny that sibling comment spawned a perfect example.
      - abiox 9y ago
        i'm not sure i understand how that is a 'perfect example' of 'don't tolerate dissent'. could you elaborate?
      - enalicho 9y ago
        I don't think that is a fair evaluation of that comment thread. I explained with links and resources _why_ elm-format is how it is, and _why_ it is considered a feature to not have flags. I also backed this up by showing how many of the users enjoy elm-format. This is not saying "don't dissent". This is saying "this argument is a strawman"
    - rtfeldman 9y ago
      This links to a thread where an Elm community member politely explains design decisions. What am I missing?
- 9y ago
rtfeldman 9y ago
> it is a rather closed off development culture without a lot of appreciation for hearing ideas and experiences from others. I've had the opposite experience. From what I've seen, Elm's development culture requires hearing outside ideas and experiences, to a greater degree than I've seen in any other programming language community. Many design discussions get blocked on Evan saying "We need to research what's out there more before we can proceed. What do other languages do? Which approaches have people liked and disliked? What are the trade-offs of each approach?" It slows down development, for sure, but I think it's worth it. :)
abiox 9y ago
> ...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. javascript already lets you do whatever you want, whenever you want. evan's goal isn't to be 'javascript with different keywords'; he wants to create something with a specific set of properties. a language doesn't need to be all things to all people. runtime guarantees are a core part of elm's identity. if you want to introduce null and undefined, there are plenty of other options.
sridca 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. This is exactly how I felt as well. I really enjoyed Elm in the beginning but soon hit the abstraction wall as the complexity of my apps grew. I never got the impression that the Elm community was going to fix those problems any time soon. I now use PureScript which is far more pleasant to use, albeit it took a while to get up to speed with the language. Also I'm not the only one who went to PureScript from Elm: https://youtu.be/ngWo5e-294o?t=19m14s https://youtu.be/ngWo5e-294o?t=19m14s
- rtfeldman 9y ago
  We're over 150,000 lines of Elm code in production and are loving it. Wouldn't trade Elm for anything! It's natural for people to have language preferences, but let's not pretend there's some spooky "abstraction wall" prohibiting a nice experience at scale. ;)
  - hellofunk 9y ago
    That's great that you are having a good time. But a few points: 1) The experiences you've personally had do not capture all problems that everyone has, and to assume you've seen it all is pretentious at best. You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture, without even knowing the details of the myriad other projects out there; sorry, that is just naive or arrogant. 2) I've noticed that on nearly any forum, you like to brag about the size of your... codebase. The quality of a project and the problems it has solved are not revealed in quantity of lines. It doesn't matter if you have 100K or now you say 150K lines of code. I have no idea what problems you are solving, nor you us; so stop hiding behind a nice round number and claiming it gives you all manner of authority on what developers need. > let's not pretend there's some spooky "abstraction wall" Honestly, it's comments like this that underscore what many others here have said about the general stance in the Elm community. How about actually listening to people's experiences rather than dismissing them? You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting.

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
      Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.
  - enalicho 9y ago
    > It might have been fine if elm-format had chosen better defaults. Subjective. This is a time old discussion. Please read the linked issue. > 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. When I come to an Elm project, I am able to read the code instantly. In fact, the majority (91%) of the Elm community who use elm-format enjoy it because of this. See here: https://www.brianthicks.com/post/2017/07/27/state-of-elm-2017-results/#do-you-format-your-code-with-elm-format https://www.brianthicks.com/post/2017/07/27/state-of-elm-201... What you say might be true for you, but for people who are actually writing and using Elm, it does not apply.
    - deleted 9y ago
      [deleted]
    - hellofunk 9y ago
      > for people who are actually writing and using Elm, it does not apply You assume the OP is not actually using the language.

leshow 9y ago

This has also been my experience. Elm programmers don't tolerate dissent. The community is welcoming so long as you toe the line.

rtfeldman 9y ago
I'm not sure what the last sentence is supposed to mean. Can you link to an example of what you're referring to?
- barrkel 9y ago
  Have a look at this thread right here: https://news.ycombinator.com/item?id=14873351 https://news.ycombinator.com/item?id=14873351
  - dyeje 9y ago
    Dang you beat me to it. Pretty funny that sibling comment spawned a perfect example.
    - abiox 9y ago
      i'm not sure i understand how that is a 'perfect example' of 'don't tolerate dissent'. could you elaborate?
    - enalicho 9y ago
      I don't think that is a fair evaluation of that comment thread. I explained with links and resources _why_ elm-format is how it is, and _why_ it is considered a feature to not have flags. I also backed this up by showing how many of the users enjoy elm-format. This is not saying "don't dissent". This is saying "this argument is a strawman"
  - rtfeldman 9y ago
    This links to a thread where an Elm community member politely explains design decisions. What am I missing?
9y ago

rtfeldman 9y ago

> it is a rather closed off development culture without a lot of appreciation for hearing ideas and experiences from others. I've had the opposite experience. From what I've seen, Elm's development culture requires hearing outside ideas and experiences, to a greater degree than I've seen in any other programming language community. Many design discussions get blocked on Evan saying "We need to research what's out there more before we can proceed. What do other languages do? Which approaches have people liked and disliked? What are the trade-offs of each approach?" It slows down development, for sure, but I think it's worth it. :)

abiox 9y ago

> ...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. javascript already lets you do whatever you want, whenever you want. evan's goal isn't to be 'javascript with different keywords'; he wants to create something with a specific set of properties. a language doesn't need to be all things to all people. runtime guarantees are a core part of elm's identity. if you want to introduce null and undefined, there are plenty of other options.

sridca 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. This is exactly how I felt as well. I really enjoyed Elm in the beginning but soon hit the abstraction wall as the complexity of my apps grew. I never got the impression that the Elm community was going to fix those problems any time soon. I now use PureScript which is far more pleasant to use, albeit it took a while to get up to speed with the language. Also I'm not the only one who went to PureScript from Elm: https://youtu.be/ngWo5e-294o?t=19m14s https://youtu.be/ngWo5e-294o?t=19m14s

rtfeldman 9y ago
We're over 150,000 lines of Elm code in production and are loving it. Wouldn't trade Elm for anything! It's natural for people to have language preferences, but let's not pretend there's some spooky "abstraction wall" prohibiting a nice experience at scale. ;)
- hellofunk 9y ago
  That's great that you are having a good time. But a few points: 1) The experiences you've personally had do not capture all problems that everyone has, and to assume you've seen it all is pretentious at best. You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture, without even knowing the details of the myriad other projects out there; sorry, that is just naive or arrogant. 2) I've noticed that on nearly any forum, you like to brag about the size of your... codebase. The quality of a project and the problems it has solved are not revealed in quantity of lines. It doesn't matter if you have 100K or now you say 150K lines of code. I have no idea what problems you are solving, nor you us; so stop hiding behind a nice round number and claiming it gives you all manner of authority on what developers need. > let's not pretend there's some spooky "abstraction wall" Honestly, it's comments like this that underscore what many others here have said about the general stance in the Elm community. How about actually listening to people's experiences rather than dismissing them? You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting.