Elm in Production: 25K Lines Later
charukiewi.cz
Elm in Production: 25K Lines Later
1–10 of 278 posts
Re: Elm in Production: 25K Lines Later
#2What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.
Re: Elm in Production: 25K Lines Later
#3"JSON-based RESTful API as its back end" what language do you use for the backend, Haskell?
Re: Elm in Production: 25K Lines Later
#4I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the power of FP, convincing people to try FP won't be the difficult step any more, and Elm won't need to try so hard to be un-intimidating.
Re: Elm in Production: 25K Lines Later
#5What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.
Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.
Re: Elm in Production: 25K Lines Later
#6I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…
Every added feature also adds complexity (and to be fair, in some cases, removes complexity). I love type classes, but I discovered in playing with Elm and specifically, TEA (The Elm Architecture) that the simplicity is also really nice even if you're comfortable doing type-level programming. There's something about Elm's simplicity that really works.
Re: Elm in Production: 25K Lines Later
#7I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…
Every added feature also adds complexity (and to be fair, in some cases, removes complexity). I love type classes, but I discovered in playing with Elm and specifically, TEA (The Elm Architecture) that the simplicity is also really nice even if you're comfortable doing type-level programming. There's something about Elm's simplicity that really works.
Agreed, but Elm is hurting for some way to deal with this stuff. Currently, the API reference lies by claiming things like (==) : a -> a -> Bool, because it lacks a generic mechanism to let the programmer think the necessary thoughts. (The story for comparison functions like (>) is similar.)
Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
Re: Elm in Production: 25K Lines Later
#8First:
> Elm has an incredibly powerful type system
Near the end of the article:
>Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application.
IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e.
{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics
data Person = Person {
name :: Text
, age :: Int
} deriving (Generic, Show)
instance ToJSON Person
instance FromJSON Person
Re: Elm in Production: 25K Lines Later
#9Great article! I have no experience with Elm but I'm much more likely to try it out now. I'm curious to hear your thoughts on this though:
Re: Elm in Production: 25K Lines Later
#10Having started using Elm for side projects over 3 years ago, the article is pretty much spot on.
Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before.
Where I really disliked about Elm is when I had to encode or decode JSON. It's a giant royal pain in the ass. Also, when you find you have to break out to JS often for libraries you don't want to write yourself, it's not a good fit--as I found out when write a toy interactive notebook to render markdown in Elm.
But for most SPA that just manipulate form data and communicate with the server, it's a pretty great fit.