Live data from Hacker News

Elm at Pacific Health Dynamics

mordrax.gitbooks.io

51–57 of 57 posts

Re: Elm at Pacific Health Dynamics

#51
post #40

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

Yes, move faster, then pay the price later when stuff is broken and hard to fix.

Re: Elm at Pacific Health Dynamics

#52
post #44
post #39

Earlier 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)

typescript has both :D

Re: Elm at Pacific Health Dynamics

#53

Serious question: What's the business value case for not using Elm?

You would have to bet on Elm being maintained in the future. It's quite a lot of buy in, especially considering it's just one guy.

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

#54
post #20

Earlier 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.

Yep, I wasn't so clear with what I'd posted, but I agree

Re: Elm at Pacific Health Dynamics

#55
post #44

Earlier 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

Well, in my professional life, there is a lot of untyped Python on the horizon :P

And for side-projects I think I prefer PureScript anyway?

Re: Elm at Pacific Health Dynamics

#56
post #47

Earlier quoted context omitted.

ReasonML isn't pure FP.

Purity is not an end unto itself.

Immutability and purity by default goes a long way to remove a lot of headaches. I could settle for immutability, but it seems ReasonML mixes things a bit.

Re: Elm at Pacific Health Dynamics

#57
post #28

Thanks 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 fact I have to do that shouldn't be necessary. I've been scarred by too many long compile time projects to know eventually entropy takes over despite the best of optimization efforts.

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.

Post reply on HN