"JSON-based RESTful API as its back end" what language do you use for the backend, Haskell?
You can use anything that can expose an HTTP port. It doesn't have to be Haskell.
Elm in Production: 25K Lines Later
11–20 of 278 posts
Re: Elm in Production: 25K Lines Later
#12I'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…
> writing a fresh map function for each data type
You have to do that in Haskell as well (where »you« can be you or the compiler via DeriveFunctor); the key difference is at the use site: there is one map function (called fmap) that does the mapping, whereas in Elm (and pretty much all other languages that don’t have higher kinds while we’re at it) you have to use the specific map function for that type.
Re: Elm in Production: 25K Lines Later
#13First: > 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,…
That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.
Re: Elm in Production: 25K Lines Later
#14Great 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: http://reasonablypolymorphic.com/blog/elm-is-wrong
The core complaint is the lack of typeclasses. If your coding style relies heavily on generics, maybe Elm isn't for you.
Re: Elm in Production: 25K Lines Later
#15First: > 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,…
That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.
For custom JSON schemas nothing tops F#'s type providers [0] IMO.
Re: Elm in Production: 25K Lines Later
#16Earlier quoted context omitted.
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…
Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?
Re: Elm in Production: 25K Lines Later
#17First: > 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,…
If you want a powerful type system (i.e. Haskell), but the benefits of Elm, Miso is a project that implements the Elm Architecture in Haskell. It obviously has typeclasses, and can encode / decode JSON on the frontend using GHC.Generics quite well. https://github.com/dmjio/miso
Re: Elm in Production: 25K Lines Later
#18They're using a decades-old E-mail client in production today?
Impressive.
Re: Elm in Production: 25K Lines Later
#19First: > 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,…
That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.
One could use a generics library to emulate something like Go's struct field tags, which decouple "external" fields names from the actual field names. Something like this is explained from 48:50 in this talk: https://skillsmatter.com/skillscasts/10181-fun-with-sum-and-...
But perhaps it wouldn't save much code compared to custom-made parsers.
Re: Elm in Production: 25K Lines Later
#20Earlier quoted context omitted.
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…
Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?
That's exactly what I mean: A type like a -> a -> Bool says that it will work for _any_ a, but we can easily find counter examples. We could pass in functions (say) and write something like (\x -> x * 2) == (\x -> x + 1). The type signature for (==) as written says it _should_ work, but it doesn't because there's no general way to compute function equality.
Instead, there's this temporary hack[0]:
> Note: Equality (in the Elm sense) is not possible for certain types. For example, the functions (\n -> n + 1) and (\n -> 1 + n) are “the same” but detecting this in general is undecidable. In a future release, the compiler will detect when (==) is used with problematic types and provide a helpful error message. This will require quite serious infrastructure work that makes sense to batch with another big project, so the stopgap is to crash as quickly as possible. Problematic types include functions and JavaScript values like Json.Encode.Value which could contain functions if passed through a port.
As you say, Haskell's version of (==) has the type Eq a => a -> a -> Bool, and function types do not belong to Eq.
[0]: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Bas...