Serious question: What's the business value case for not using Elm?
It's also possible that you can move faster with a dynamically type checked language. I would be of the opinion that it is faster because if static compilation was a free lunch there would be no question
Elm at Pacific Health Dynamics
51–57 of 57 posts
Re: Elm at Pacific Health Dynamics
#52Earlier quoted context omitted.
From an OO perspective, Elm lacks interfaces. Typeclasses are probably the best way to handle the idea of interfaces in the functional programming model. Since functions are first class, you can bodge this with an object that has functions in it, but since those don't serialize they don't play well with a lot of Elm idioms if you put them in your model.
I thought about this, and kinda came to a conclusion, than I would take a language that has generics, and doesn't have interfaces (i.e. Elm) over a language that has interfaces and doesn't have generics (i.e. Go)
Re: Elm at Pacific Health Dynamics
#53Serious question: What's the business value case for not using Elm?
Also, some apps are just very difficult to code in Elm (interactive, lots of DOM manipulations, video, etc) and it's just not worth it.
Re: Elm at Pacific Health Dynamics
#54Earlier quoted context omitted.
https://hn.algolia.com/?query=elm%20email&sort=byPopularity&... Seems like at least a few others have over time as well
Notice how there isn't a single submission about the Elm email client. I think I'm dead-on with my signaling hypothesis. It died 12 years ago.
Re: Elm at Pacific Health Dynamics
#55Earlier quoted context omitted.
I thought about this, and kinda came to a conclusion, than I would take a language that has generics, and doesn't have interfaces (i.e. Elm) over a language that has interfaces and doesn't have generics (i.e. Go)
typescript has both :D
And for side-projects I think I prefer PureScript anyway?
Re: Elm at Pacific Health Dynamics
#56Re: Elm at Pacific Health Dynamics
#57Thanks for warning about compile times.
It's definitely an issue for larger, coupled projects in 0.18 but don't let it scare you. The trick is to decouple your modules by focusing them on a single responsibility. Then the compile time is a non-issue.
The fixes need to be in the compiler & dev tools itself, or it needs to be a very obscure feature or obviously surfaced build time problem highlighted by the compiler.