18 ms·

Elm from a Business Perspective

166 points by amitaibu 10y ago

the_duke 10y ago
Well. Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money." It's nice to hear that a company is able to utilize Elm effectively. It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judge whether Elm in it's current form is a good fit for larger apps. Especially since the Elm library ecosystem is still very immature, so experience with building good, reusable libraries is not that great. Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. In terms of maintainability (refactoring, etc) you can't get much worse than Javascript, so Elm will probably be a win there, regardless of a limited type system. As long as you don't have to build and maintain lot of required libraries yourself, that is.
- tomtheelder 10y ago
  > Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. Elm certainly has a lot of boilerplate compared to Haskell, but that might not be a fair comparison as they don't really have a shared use case. Elm ends up with considerably less, in my opinion, than something like React/Redux.
  - rtfeldman 10y ago
    > Elm certainly has a lot of boilerplate compared to Haskell This is not true based on my experiences with Elm and my knowledge of Haskell. Could you elaborate on why you are certain of this?
    - wyager 10y ago
      Haskell has much more powerful polymorphism as provided by typeclasses and various extensions like Multi-parameter typeclasses. Haskell, more than any other production-ready language, is able to encapsulate the essence of "doing the same thing in a different context", which means you can easily write code that is reusable to a degree not imaginable in most languages. For example, the expression "fold", from Data.Foldable, is capable of doing anything from concatenating all the strings in a set to adding up all the probability distributions in a sequence. This is a contrived example, but it's super useful in practice. It's hard to imagine all the code reuse you can get, especially as a library author, without using Haskell for a while. The most obvious cases are Ord and Eq, where things like maps and sets can contain any orderable type, rather than just a few types like String and Int.
    - pka 10y ago
      Instead of abstractly arguing over "writing generic code", here are some concrete examples I came up with when running down a random Haskell file: * Thing.map :: (a -> b) -> Thing a -> Thing b instead of deriving Functor (or Applicative, Monad, Generic, ...) * showThing :: Thing -> String, readThing :: String -> Maybe Thing instead of deriving Show/Read * decodeThing :: Json.Value -> Maybe Thing, encodeThing :: Thing -> Json.Value instead of deriving From/ToJSON * lenses definitions instead of makeLenses ''Type * things like update (Event childEvent) model -> let (m, fx) = Child.update childEvent model.child in ({ model | child = m }, Fx.map Event fx) instead of using lenses * append :: (a -> a -> a) -> (b -> b -> b) -> (a, b) -> (a, b) -> (a, b) instead of reusing the Monoid instance on tuples * toDyn :: (a -> TypeName) -> a -> Dynamic, fromDyn :: (a -> TypeName) -> Dynamic -> Maybe a instead of deriving Typeable * things like type StateLogger st = { log :: [st], current :: st } and then writing StateLogger.map, StateLogger.return, StateLogger.andThen, StateLogger.modify, StateLogger.tell instead of just type StateLogger = WriterT [st] (State st) and getting all of that for free... not only that, but now you can use lenses for manipulating a deeply nested state as well, because guess what, Control.Lens.Zoom is written generically And those are just the possible, but cumbersome things. There's stuff that's impossible to do: * free monad custom DSLs * GADT datatypes for typesafe request/response communication * existential quantification in ADTs Now this is very down-to-earth get-things-done Haskell code. All these things are there because they make the code simpler, easier to understand and eliminate repetition.
- rtfeldman 10y ago
  > Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project." ;) Our Elm code is about as DRY as our JavaScript code, and adding language features to squeeze even more DRYness out of it is way down my priority list. When I think about ways I want Elm to improve, I'm thinking about better support for server-side rendering and asset management (e.g. code splitting), not wanting to add type system features. I'm always a bit confused by "I tried Elm and disliked how it wasn't enough like Haskell" posts. PureScript is a fine language that's already on board with this design philosophy. Instead of lobbying for Elm to change, why not use PureScript? There's plenty enough room in the programming world for both languages to coexist!
  - renlo 10y ago
    The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point. [1] https://twitter.com/czaplic https://twitter.com/czaplic
    - sotojuan 10y ago
      Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.
      - rtfeldman 10y ago
        That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)
dkarapetyan 10y ago
The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.
- sotojuan 10y ago
  This is interesting because Elm has been removing features that Evan considers "too hard" and confusing for the average developer. I'd argue it's not "academic" any more (though it might be interesting for an academic who wants to do UI).
  - dkarapetyan 10y ago
    Yes, that is my point. I don't think Elm is "too academic". I think it strives for pragmatism in real world engineering scenarios and that is why it gets flak from a certain segment of the programming community. Similar to how golang does.
  - busterarm 10y ago
    Is it truly because they are "too hard" or is it because their current implementation in the language falls short? I was pretty sure in at least one of the cases Evan mentioned the possibility of revisiting it later. Other languages don't make these choices and end up with things like Python's async/await.
- vvanders 10y ago
  Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.
- projektfu 10y ago
  I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.
sotojuan 10y ago
I'm guessing pragmatism and practicality is why they went with Elm over PureScript? If their backend is in Haskell then it seems like they have devs who know it well enough to use PS.
- bbcbasic 10y ago
  From my limited experience, I would say PureScript sounds more practical. You can choose your own UI engine, and has additional language features that are useful like typeclasses. It also compiles without needing a runtime baked in to the output. When you hit a wall you can probably work around it in Purescript whereas I feel you are too sandboxed in with Elm and you'd have to start patching your Elm source to get around it.
- gilmi 10y ago
  It's more likely that they tried Elm first and liked it so they thought they might be able to use Haskell as well. I actually find PureScript quite practical by design and goals (for example the ffi and readable generated code).
petetnt 10y ago
> But than again, Elm is not too easy. This means that almost every developer I see that is already involved in Elm is a seasoned developer. Getting experienced developers on board means that they are immediately productive, which means we gain more per hour. Not really seeing this as a strong point. It feels like the same mindset that drove me away from Scala (and many others [0]!). Sure, it might be good for the company in short term, but what happens when you run out of experienced Elm developers? At least Elm fairs fairly better with having usable samples on their own (clean) site. [0] https://groups.google.com/forum/#!topic/scala-internals/r2GnzCFc3TY https://groups.google.com/forum/#!topic/scala-internals/r2Gn...
- skybrian 10y ago
  I don't think he's saying that Elm is actually hard to learn (like Scala or Haskell).
  - kod 10y ago
    Yup, Elm isn't actually hard to learn. Nor is Scala (I had a team of people productive with it in under 2 weeks, with no significant prior FP experience).
- jlarocco 10y ago
  My interpretation of that sentence was that it's easy for developers familiar with other languages to pick up Elm, but less easy for people with little or no experience what-so-ever. I think he was contrasting with languages like Haskell and Scala, where even people very experienced with other languages have a hard time picking them up.
- swsieber 10y ago
  You hire experienced developers. Then you teach them Elm.
- bcheung 10y ago
  I looked around at Elm a little bit recently. I use React/Redux daily at work and have been learning Haskell on the side. When I took another pass at Elm it was extremely easy to pick up. I was able to skim through the docs super fast and start writing real code in about 15 minutes. I noticed myself typing Haskell code a bunch of the time and wondering why it didn't work though. For me, the hardest part in Elm, and Haskell as well, is figuring out how to structure data that is composition in nature or that involve Union types that are records. I can never quite seem to get the dereferencing right.
chocolatebunny 10y ago
I thought this was going to be about the email client: https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)
- lgas 10y ago
  You were wrong.
mrkgnao 10y ago
I don't get how having type classes makes the learning curve steeper. It's not like the mere existence of type classes means you have to start writing your own and doing functional dependencies and all that. For a beginner, it just means being able to write filter instead of List.filter or whatever.
desireco42 10y ago
I really love this Elm drama. We get to discuss Elm a lot, talk about it, think about it, keep it in out minds. I don't like negativity, but it is good to popularize language, to let people know about it.
_Codemonkeyism 10y ago
There is no business perspective to programming languages. Stop kidding yourself to explain your favorite tool of the week as good for business. Successful companies have used plain st* languages like PHP and Java, thousands of companies that use the tool of the week go bust. There is no correlation (perhaps you should not use Assembler or COBOL for web development) If there is any then companies that use the tool of the week do too many rewrites instead of focusing on delivering business value, the correlation is negative if any.
- yakshaving_jgt 10y ago
  As someone who worked at a large software company that suffered huge losses because of 1) client data loss caused by using unsophisticated tools and strategies and 2) accounting errors caused by a lack of type-safety: I disagree.
amencarini 10y ago
This typeclasses discussion reminds me a lot of complaints about Go's lack of generics. Even without this "glaring shortcoming" Go became the de facto winner in the ops space, by staying a simple language with a smaller learning surface. Elm could be walking down the same route. Personally I find composability under The Elm Architecture more of an issue than pure language abstractions.
- pitaj 10y ago
  > Go became the de facto winner in the ops space Can you explain what you mean by this and possibly provide a source? I'd like to know how the different languages / platforms compare.
bloomca 10y ago
I always think that usage of such technologies can be only in some cases – mostly for small companies, which are not sure that this product will be maintained more than few years. Like, it is not that bad to use it in startups, in some small projects, or if you have pretty strong and enthusiastic team with a lot passion, which are ready to dive into new cool technology. Moreover, in the short term it can be even more beneficial, because you can attract even better developers, who like cutting edge stuff. But the problem is what if this product will be maintained throughout years? Then to support it, you have definitely hire much more skilled engineer than for the same in stable JS framework. I completely understand about types, strict rules how to write Elm code, etc, but there are literally no guarantees that it will be the same after some time, that new developers will pick it up quickly, and, if you decide to rewrite it much later, there is a big chance that you'd have to rewrite it completely (this applies for JS too, but there are quite a lot of success stories of gradual integration of new framework). To summarize, I don't think it is bad, it just doesn't scale and creates big technical debt, so you'd pay for it later; though it is a great chance to attract very skillfull and passionate developers – so, it is all about risk.

166 points by amitaibu 10y ago

Well. Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money." It's nice to hear that a company is able to utilize Elm effectively. It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judge whether Elm in it's current form is a good fit for larger apps. Especially since the Elm library ecosystem is still very immature, so experience with building good, reusable libraries is not that great. Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. In terms of maintainability (refactoring, etc) you can't get much worse than Javascript, so Elm will probably be a win there, regardless of a limited type system. As long as you don't have to build and maintain lot of required libraries yourself, that is.

tomtheelder 10y ago
> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. Elm certainly has a lot of boilerplate compared to Haskell, but that might not be a fair comparison as they don't really have a shared use case. Elm ends up with considerably less, in my opinion, than something like React/Redux.
- rtfeldman 10y ago
  > Elm certainly has a lot of boilerplate compared to Haskell This is not true based on my experiences with Elm and my knowledge of Haskell. Could you elaborate on why you are certain of this?
  - wyager 10y ago
    Haskell has much more powerful polymorphism as provided by typeclasses and various extensions like Multi-parameter typeclasses. Haskell, more than any other production-ready language, is able to encapsulate the essence of "doing the same thing in a different context", which means you can easily write code that is reusable to a degree not imaginable in most languages. For example, the expression "fold", from Data.Foldable, is capable of doing anything from concatenating all the strings in a set to adding up all the probability distributions in a sequence. This is a contrived example, but it's super useful in practice. It's hard to imagine all the code reuse you can get, especially as a library author, without using Haskell for a while. The most obvious cases are Ord and Eq, where things like maps and sets can contain any orderable type, rather than just a few types like String and Int.
  - pka 10y ago
    Instead of abstractly arguing over "writing generic code", here are some concrete examples I came up with when running down a random Haskell file: * Thing.map :: (a -> b) -> Thing a -> Thing b instead of deriving Functor (or Applicative, Monad, Generic, ...) * showThing :: Thing -> String, readThing :: String -> Maybe Thing instead of deriving Show/Read * decodeThing :: Json.Value -> Maybe Thing, encodeThing :: Thing -> Json.Value instead of deriving From/ToJSON * lenses definitions instead of makeLenses ''Type * things like update (Event childEvent) model -> let (m, fx) = Child.update childEvent model.child in ({ model | child = m }, Fx.map Event fx) instead of using lenses * append :: (a -> a -> a) -> (b -> b -> b) -> (a, b) -> (a, b) -> (a, b) instead of reusing the Monoid instance on tuples * toDyn :: (a -> TypeName) -> a -> Dynamic, fromDyn :: (a -> TypeName) -> Dynamic -> Maybe a instead of deriving Typeable * things like type StateLogger st = { log :: [st], current :: st } and then writing StateLogger.map, StateLogger.return, StateLogger.andThen, StateLogger.modify, StateLogger.tell instead of just type StateLogger = WriterT [st] (State st) and getting all of that for free... not only that, but now you can use lenses for manipulating a deeply nested state as well, because guess what, Control.Lens.Zoom is written generically And those are just the possible, but cumbersome things. There's stuff that's impossible to do: * free monad custom DSLs * GADT datatypes for typesafe request/response communication * existential quantification in ADTs Now this is very down-to-earth get-things-done Haskell code. All these things are there because they make the code simpler, easier to understand and eliminate repetition.
rtfeldman 10y ago
> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell. We have over 55,000 lines of Elm code in production at http://noredink.com http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project." ;) Our Elm code is about as DRY as our JavaScript code, and adding language features to squeeze even more DRYness out of it is way down my priority list. When I think about ways I want Elm to improve, I'm thinking about better support for server-side rendering and asset management (e.g. code splitting), not wanting to add type system features. I'm always a bit confused by "I tried Elm and disliked how it wasn't enough like Haskell" posts. PureScript is a fine language that's already on board with this design philosophy. Instead of lobbying for Elm to change, why not use PureScript? There's plenty enough room in the programming world for both languages to coexist!
- renlo 10y ago
  The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point. [1] https://twitter.com/czaplic https://twitter.com/czaplic
  - sotojuan 10y ago
    Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.
    - rtfeldman 10y ago
      That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)

dkarapetyan 10y ago

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

sotojuan 10y ago
This is interesting because Elm has been removing features that Evan considers "too hard" and confusing for the average developer. I'd argue it's not "academic" any more (though it might be interesting for an academic who wants to do UI).
- dkarapetyan 10y ago
  Yes, that is my point. I don't think Elm is "too academic". I think it strives for pragmatism in real world engineering scenarios and that is why it gets flak from a certain segment of the programming community. Similar to how golang does.
- busterarm 10y ago
  Is it truly because they are "too hard" or is it because their current implementation in the language falls short? I was pretty sure in at least one of the cases Evan mentioned the possibility of revisiting it later. Other languages don't make these choices and end up with things like Python's async/await.
vvanders 10y ago
Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.
projektfu 10y ago
I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.

sotojuan 10y ago

I'm guessing pragmatism and practicality is why they went with Elm over PureScript? If their backend is in Haskell then it seems like they have devs who know it well enough to use PS.

bbcbasic 10y ago
From my limited experience, I would say PureScript sounds more practical. You can choose your own UI engine, and has additional language features that are useful like typeclasses. It also compiles without needing a runtime baked in to the output. When you hit a wall you can probably work around it in Purescript whereas I feel you are too sandboxed in with Elm and you'd have to start patching your Elm source to get around it.
gilmi 10y ago
It's more likely that they tried Elm first and liked it so they thought they might be able to use Haskell as well. I actually find PureScript quite practical by design and goals (for example the ffi and readable generated code).

petetnt 10y ago

> But than again, Elm is not too easy. This means that almost every developer I see that is already involved in Elm is a seasoned developer. Getting experienced developers on board means that they are immediately productive, which means we gain more per hour. Not really seeing this as a strong point. It feels like the same mindset that drove me away from Scala (and many others [0]!). Sure, it might be good for the company in short term, but what happens when you run out of experienced Elm developers? At least Elm fairs fairly better with having usable samples on their own (clean) site. [0] https://groups.google.com/forum/#!topic/scala-internals/r2GnzCFc3TY https://groups.google.com/forum/#!topic/scala-internals/r2Gn...

skybrian 10y ago
I don't think he's saying that Elm is actually hard to learn (like Scala or Haskell).
- kod 10y ago
  Yup, Elm isn't actually hard to learn. Nor is Scala (I had a team of people productive with it in under 2 weeks, with no significant prior FP experience).
jlarocco 10y ago
My interpretation of that sentence was that it's easy for developers familiar with other languages to pick up Elm, but less easy for people with little or no experience what-so-ever. I think he was contrasting with languages like Haskell and Scala, where even people very experienced with other languages have a hard time picking them up.
swsieber 10y ago
You hire experienced developers. Then you teach them Elm.
bcheung 10y ago
I looked around at Elm a little bit recently. I use React/Redux daily at work and have been learning Haskell on the side. When I took another pass at Elm it was extremely easy to pick up. I was able to skim through the docs super fast and start writing real code in about 15 minutes. I noticed myself typing Haskell code a bunch of the time and wondering why it didn't work though. For me, the hardest part in Elm, and Haskell as well, is figuring out how to structure data that is composition in nature or that involve Union types that are records. I can never quite seem to get the dereferencing right.

chocolatebunny 10y ago

I thought this was going to be about the email client: https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)

lgas 10y ago
You were wrong.

mrkgnao 10y ago

I don't get how having type classes makes the learning curve steeper. It's not like the mere existence of type classes means you have to start writing your own and doing functional dependencies and all that. For a beginner, it just means being able to write filter instead of List.filter or whatever.

desireco42 10y ago

I really love this Elm drama. We get to discuss Elm a lot, talk about it, think about it, keep it in out minds. I don't like negativity, but it is good to popularize language, to let people know about it.

_Codemonkeyism 10y ago

There is no business perspective to programming languages. Stop kidding yourself to explain your favorite tool of the week as good for business. Successful companies have used plain st* languages like PHP and Java, thousands of companies that use the tool of the week go bust. There is no correlation (perhaps you should not use Assembler or COBOL for web development) If there is any then companies that use the tool of the week do too many rewrites instead of focusing on delivering business value, the correlation is negative if any.

yakshaving_jgt 10y ago
As someone who worked at a large software company that suffered huge losses because of 1) client data loss caused by using unsophisticated tools and strategies and 2) accounting errors caused by a lack of type-safety: I disagree.

amencarini 10y ago

This typeclasses discussion reminds me a lot of complaints about Go's lack of generics. Even without this "glaring shortcoming" Go became the de facto winner in the ops space, by staying a simple language with a smaller learning surface. Elm could be walking down the same route. Personally I find composability under The Elm Architecture more of an issue than pure language abstractions.

pitaj 10y ago
> Go became the de facto winner in the ops space Can you explain what you mean by this and possibly provide a source? I'd like to know how the different languages / platforms compare.

bloomca 10y ago

I always think that usage of such technologies can be only in some cases – mostly for small companies, which are not sure that this product will be maintained more than few years. Like, it is not that bad to use it in startups, in some small projects, or if you have pretty strong and enthusiastic team with a lot passion, which are ready to dive into new cool technology. Moreover, in the short term it can be even more beneficial, because you can attract even better developers, who like cutting edge stuff. But the problem is what if this product will be maintained throughout years? Then to support it, you have definitely hire much more skilled engineer than for the same in stable JS framework. I completely understand about types, strict rules how to write Elm code, etc, but there are literally no guarantees that it will be the same after some time, that new developers will pick it up quickly, and, if you decide to rewrite it much later, there is a big chance that you'd have to rewrite it completely (this applies for JS too, but there are quite a lot of success stories of gradual integration of new framework). To summarize, I don't think it is bad, it just doesn't scale and creates big technical debt, so you'd pay for it later; though it is a great chance to attract very skillfull and passionate developers – so, it is all about risk.