5 ms·

One thing I don't see addressed here is the biggest "Why Not Elm": you have to learn Elm. Elm is a beautiful language and in the last year or two the ecosystem

by ng12 10y ago

One thing I don't see addressed here is the biggest "Why Not Elm": you have to learn Elm. Elm is a beautiful language and in the last year or two the ecosystem has gotten much better. However I don't think I'll ever make progress adopting it at my day job. For all of it's flaws JavaScript is still quick, scrappy, and easy to pick up. Convincing a curmudgeonly back-end developer that React and webpack will make his life easier is hard enough. Convincing him to learn a seemingly esoteric functional language too is basically a non-starter.

splintercell 10y ago
I have learned ELM and I have done React + Redux development, and I can say that I found learning and using former a lot easier than doing the latter. Probably because react redux were trying to make me learn a new concept over existing knowledge of JS was, while Elm was easier to pick up because I entered with a mindset of learning a new language. For those who are new to any kind of development, learning Elm would be no more different/difficult than learning react redux.
- ng12 10y ago
  I think that's only true if you're already familiar with Haskell-like languages. Elm-html is conceptually close to React/Redux so you basically have to learn it either way. Even knowing a few functional languages already it took a while for me achieve a basic level of competency with Elm. On the other hand someone who knows Java can pick up JS in an afternoon.
  - Risord 10y ago
    I don't know. I felt sameway that elm was easier when I was learning Vue with all modern shiny stuff. I had done mostly C#/Java and some old school JS programming but none Haskell likes. It's hard to say which ones was easier since learning experiences were so different. Maybe learning took approximately same time but time was used with JS for googling and brute forcing things. On the other side Elm compiler just said "You probably did this common error ####. Try do ###" so learning was much more efficient since you know instantly what was wrong and why. I can certainly say that learning Elm was much more pleasant one for me.
cel1ne 10y ago
Why not Elm on google turns up this: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong I think the basic gist was that it's type-system is far from complete.
- commandertso 10y ago
  FWIW, when this was new it got a lot of pushback in a related Reddit thread. Might be worth digging in if you're seriously thinking about it.
- AlexCoventry 10y ago
  This was definitely a pain point for me when I experimented with Elm.
- 0xCMP 10y ago
  It's not that it is not complete, but not entirely as powerful as Haskell which inspires a lot of how Elm works and looks like. The creator/maintainer of elm doesn't believe they're required.
- zeptomu 10y ago
  The main critics is that it does not support type classes, but maybe that is actually not a bad thing. The discussion is similar to the never ending Go discussion about generics and people do amazing stuff with Go (now I guess critics would say they would do even more amazing stuff with generics). Not that I say type classes (or generics) are useless, but keeping a language simple (in the sense of keeping the feature list small) has benefits on its own. I did not to complicated projects in Elm, but I watch the language closely and really like what I have seen so far, so I hope Evan keeps up the good work, as I think he has pretty good taste for language design.
allochthon 10y ago
Wrapping my head around Elm took a little while. I was enjoying my progress until I attempted to abstract out some view render code into a separate module. I fought with the type system for a long time and had difficulty getting beyond an obscure compiler complaint.
danyx 10y ago
I'm actually surprised that so many teams have this view. We are a very small dev team working on scientific apps and I feel that the time it took us all to get comfortable with Elm was easily recouped by the constant development speed we had even as the app got bigger. In Javascript, projects just become harder and harder to refactor and so they accumulate cruft and development speed drops as the project ages. In Elm, with the help of a really decent type system and a helpful compile, we were able to keep going and just add features at a constant pace. I think it's worth taking a close look at Elm for this reason alone (or Purescript for that matter but there it is possible to get lost in rabbit holes of type complexity :) ).
- ng12 10y ago
  > We are a very small dev team That's the secret though, right? When you have teams of dozens of developers in a company of thousands the cost of adoption and the resistance you encounter increases exponentially. At least I can evangelize React/Redux/Typescript and get a sane development experience that's still just JavaScript.
  - firethief 10y ago
    That's an interesting claim. Can you elaborate on the superlinear factors of the cost increase?
    - mikekchar 10y ago
      I'm not entirely sure that the cost is exponential as the parent stated, but it certainly is superlinear above a certain threshold in my experience. There are a few issues you have to deal with. The first is how adoption happens. This is generally based on power structures and reputation. If you are in a position to mandate a change, the cost is potentially lower (see below, though), but if you are not then you have to influence enough people to make a change. There are many ways to do this, but I will split it into 2 for simplicity. First, you can try to influence the rest of the group directly. As the group size grows, this becomes progressively more difficult because your message is lost in the noise of other people pressing their own agendas. Once you get above certain point (say about 8-10 people), your odds of success drops to near zero. The other main way is to pilot a project and use its success to influence others. Setting up the pilot requires influencing a smaller group and therefore you have higher chances of success. The problem is that when you pilot a new way of doing things, you are intentionally breaking consensus. You now have a small group of individuals who have experience that nobody else in the group has. Whether the adoption of the new technique is successful or not, this leads to increased cost as attitudes change. The bigger the group, growing out a pilot into a larger project becomes more expensive. This is essentially the same problem as before -- you may be in a position now to mandate a way of working, but if you are not, then you have to create another round of pilots to move the idea around the group. But now you have another problem -- the implementors of the new pilots are different than the implementors of the original pilot. So you will now have more than one message coming out. You now have to harmonise that message in order to drive adoption. At every step, there is a chance of failure (sometimes quite high). The chance of failure grows as size of the group increases, because the external pressures to not change are higher. Again, there are several possible outcomes, but I will pick 2 for simplicity. You may find that your idea is rejected. You have now spent resources on your pilot that you will have to reimplement in another way. Another outcome is that your adoption is simply stalled -- you split your group permanently. This has cost implications ranging from staffing, to training, to tooling, to management, etc. Now, assuming you don't fail, you may have organically grown the adoption in your group (which is ideal), but as your group size grows, the possibility of that decreases (because the risk of failure increases based on the size of the group). More likely is that you have gotten enough reputation to be able to mandate a change. Mandating changes has costs as well. The first is that some people will be uncomfortable with the change and will quit. You now have to replace those individuals - which costs you both lost productivity, referral fees, and training costs. This is more likely as the group size increases because you are more likely to have diverse, strongly held opinions. The next biggest cost would appear to be training, retooling, etc. However, there is a hidden cost -- compliance. Very good people who dislike the change will leave. Very poor people will not leave -- they will simply refuse to follow the new strategy competently. This may be because they are depressed over the change, scared of how the change affects their influence, and many other things. These people can often end up sabotaging your projects (mostly unintentionally, but as they are usually quite upset they also don't care if they do). As the size of the group increases, the chances of building an unshiftable group of discontents grows. If you want to make a lot of money, become a consultant introducing new development techniques into large organisations like banks. It's a bit like siphoning all their operating capital into your pocket because you have no hope of success and can blame all your failure on other people.
napsterbr 10y ago
Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), learning elm was quite simple. There's a lot of help from the compiler and the community as well. After two weeks I was quite confident on my work, and in one month I managed to create the entire architecture of our production app. Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). I've made the decision to use elm and put my two frontend devs to learn it. They managed to start contributing to the app in less than a week. So if you have the chance, I think it's worth a shot. I thought I'd never learn elm, but so far my experience proved that it's much easier than it seems.
- KurtMueller 10y ago
  > Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error. Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.
boubiyeah 10y ago
In my company, whenever a backend dev has to do frontend dev, it never ends well :(

by ng12 10y ago

splintercell 10y ago

I have learned ELM and I have done React + Redux development, and I can say that I found learning and using former a lot easier than doing the latter. Probably because react redux were trying to make me learn a new concept over existing knowledge of JS was, while Elm was easier to pick up because I entered with a mindset of learning a new language. For those who are new to any kind of development, learning Elm would be no more different/difficult than learning react redux.

ng12 10y ago
I think that's only true if you're already familiar with Haskell-like languages. Elm-html is conceptually close to React/Redux so you basically have to learn it either way. Even knowing a few functional languages already it took a while for me achieve a basic level of competency with Elm. On the other hand someone who knows Java can pick up JS in an afternoon.
- Risord 10y ago
  I don't know. I felt sameway that elm was easier when I was learning Vue with all modern shiny stuff. I had done mostly C#/Java and some old school JS programming but none Haskell likes. It's hard to say which ones was easier since learning experiences were so different. Maybe learning took approximately same time but time was used with JS for googling and brute forcing things. On the other side Elm compiler just said "You probably did this common error ####. Try do ###" so learning was much more efficient since you know instantly what was wrong and why. I can certainly say that learning Elm was much more pleasant one for me.

cel1ne 10y ago

Why not Elm on google turns up this: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong I think the basic gist was that it's type-system is far from complete.

commandertso 10y ago
FWIW, when this was new it got a lot of pushback in a related Reddit thread. Might be worth digging in if you're seriously thinking about it.
AlexCoventry 10y ago
This was definitely a pain point for me when I experimented with Elm.
0xCMP 10y ago
It's not that it is not complete, but not entirely as powerful as Haskell which inspires a lot of how Elm works and looks like. The creator/maintainer of elm doesn't believe they're required.
zeptomu 10y ago
The main critics is that it does not support type classes, but maybe that is actually not a bad thing. The discussion is similar to the never ending Go discussion about generics and people do amazing stuff with Go (now I guess critics would say they would do even more amazing stuff with generics). Not that I say type classes (or generics) are useless, but keeping a language simple (in the sense of keeping the feature list small) has benefits on its own. I did not to complicated projects in Elm, but I watch the language closely and really like what I have seen so far, so I hope Evan keeps up the good work, as I think he has pretty good taste for language design.

allochthon 10y ago

Wrapping my head around Elm took a little while. I was enjoying my progress until I attempted to abstract out some view render code into a separate module. I fought with the type system for a long time and had difficulty getting beyond an obscure compiler complaint.

danyx 10y ago

I'm actually surprised that so many teams have this view. We are a very small dev team working on scientific apps and I feel that the time it took us all to get comfortable with Elm was easily recouped by the constant development speed we had even as the app got bigger. In Javascript, projects just become harder and harder to refactor and so they accumulate cruft and development speed drops as the project ages. In Elm, with the help of a really decent type system and a helpful compile, we were able to keep going and just add features at a constant pace. I think it's worth taking a close look at Elm for this reason alone (or Purescript for that matter but there it is possible to get lost in rabbit holes of type complexity :) ).

ng12 10y ago
> We are a very small dev team That's the secret though, right? When you have teams of dozens of developers in a company of thousands the cost of adoption and the resistance you encounter increases exponentially. At least I can evangelize React/Redux/Typescript and get a sane development experience that's still just JavaScript.
- firethief 10y ago
  That's an interesting claim. Can you elaborate on the superlinear factors of the cost increase?
  - mikekchar 10y ago
    I'm not entirely sure that the cost is exponential as the parent stated, but it certainly is superlinear above a certain threshold in my experience. There are a few issues you have to deal with. The first is how adoption happens. This is generally based on power structures and reputation. If you are in a position to mandate a change, the cost is potentially lower (see below, though), but if you are not then you have to influence enough people to make a change. There are many ways to do this, but I will split it into 2 for simplicity. First, you can try to influence the rest of the group directly. As the group size grows, this becomes progressively more difficult because your message is lost in the noise of other people pressing their own agendas. Once you get above certain point (say about 8-10 people), your odds of success drops to near zero. The other main way is to pilot a project and use its success to influence others. Setting up the pilot requires influencing a smaller group and therefore you have higher chances of success. The problem is that when you pilot a new way of doing things, you are intentionally breaking consensus. You now have a small group of individuals who have experience that nobody else in the group has. Whether the adoption of the new technique is successful or not, this leads to increased cost as attitudes change. The bigger the group, growing out a pilot into a larger project becomes more expensive. This is essentially the same problem as before -- you may be in a position now to mandate a way of working, but if you are not, then you have to create another round of pilots to move the idea around the group. But now you have another problem -- the implementors of the new pilots are different than the implementors of the original pilot. So you will now have more than one message coming out. You now have to harmonise that message in order to drive adoption. At every step, there is a chance of failure (sometimes quite high). The chance of failure grows as size of the group increases, because the external pressures to not change are higher. Again, there are several possible outcomes, but I will pick 2 for simplicity. You may find that your idea is rejected. You have now spent resources on your pilot that you will have to reimplement in another way. Another outcome is that your adoption is simply stalled -- you split your group permanently. This has cost implications ranging from staffing, to training, to tooling, to management, etc. Now, assuming you don't fail, you may have organically grown the adoption in your group (which is ideal), but as your group size grows, the possibility of that decreases (because the risk of failure increases based on the size of the group). More likely is that you have gotten enough reputation to be able to mandate a change. Mandating changes has costs as well. The first is that some people will be uncomfortable with the change and will quit. You now have to replace those individuals - which costs you both lost productivity, referral fees, and training costs. This is more likely as the group size increases because you are more likely to have diverse, strongly held opinions. The next biggest cost would appear to be training, retooling, etc. However, there is a hidden cost -- compliance. Very good people who dislike the change will leave. Very poor people will not leave -- they will simply refuse to follow the new strategy competently. This may be because they are depressed over the change, scared of how the change affects their influence, and many other things. These people can often end up sabotaging your projects (mostly unintentionally, but as they are usually quite upset they also don't care if they do). As the size of the group increases, the chances of building an unshiftable group of discontents grows. If you want to make a lot of money, become a consultant introducing new development techniques into large organisations like banks. It's a bit like siphoning all their operating capital into your pocket because you have no hope of success and can blame all your failure on other people.

napsterbr 10y ago

Before diving into elm, I had this fear too. But speaking from someone who never used haskell before (hell, I never used a statically typed language before), learning elm was quite simple. There's a lot of help from the compiler and the community as well. After two weeks I was quite confident on my work, and in one month I managed to create the entire architecture of our production app. Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). I've made the decision to use elm and put my two frontend devs to learn it. They managed to start contributing to the app in less than a week. So if you have the chance, I think it's worth a shot. I thought I'd never learn elm, but so far my experience proved that it's much easier than it seems.

KurtMueller 10y ago
> Through the months I got a better grasp of elm and refactored the entire app several times (not nearly as painful as it sounds). Refactoring Elm code isn't as painful for me as Javascript or Ruby - because it's statically compiled, it gets rid of a whole class of errors. The compiler does an excellent job at where compilation fails and suggestions to fix the error. Additionally, I find in Elm (and other ML-typed languages) that it's easy to model states of your app (e.g. like a state machine) and events that change the state of your app. Adding/modifying states and events in Elm is one of its strong suits and it really forces you to logically think through how your app transitions from one state to another. Scott Wlaschin has an excellent talk on Domain Driven Design in F# that articulates this point quite well.

boubiyeah 10y ago

In my company, whenever a backend dev has to do frontend dev, it never ends well :(