7 ms·

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 (quicke

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. :)

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. :)