14 ms·

Elm at Pacific Health Dynamics

165 points by mordrax 8y ago

Patrick_Devine 8y ago
Took me a while to realize this wasn't about the Elm email client https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)
- GavinMcG 8y ago
  I'm curious how you interpreted the very first sentence on the page: > the technical trials and tribulations he faced, the euphoric and … not so euphoric bits of writing a SPA in Elm What trials and tribulations did you picture that came with writing a single page application in an email client?
  - Patrick_Devine 8y ago
    Honestly, it took digging through multiple pages to figure out what (this) Elm was about. If you come in with a preconceived notion of what something is supposed to be about, and there is nothing which even gives a short blurb on project goals, it can be a little bewildering. Clearly it wasn't about the email client (that was a bit tongue-in-cheek), but I was curious about what the project actually was for, and had to really hunt to find any information.
    - always_good 8y ago
      It's interesting how everyone thinks they're the first person to make the joke. Not much different than going "haha, I thought it was about the Elm tree for a while!" I'm starting to think it's just a way to signal to others that you know of an email client that last had a stable release 12 years ago that most people haven't heard of. Maybe there should be a way to wear this badge of honor in your profile instead of making the same joke, though.
- spraak 8y ago
  https://hn.algolia.com/?query=elm%20email&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=elm%20email&sort=byPopularity&... Seems like at least a few others have over time as well
  - always_good 8y ago
    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.
    - Patrick_Devine 8y ago
      Sure, but I used Elm for email for probably close to 15 years. It, and Pine, were pretty much the only two dedicated email clients for as long as I can remember. I don't have a problem with people repurposing the name, just be somewhat sympathetic that not everyone is going to know about your web framework. Onboarding is a thing.
    - spraak 8y ago
      Yep, I wasn't so clear with what I'd posted, but I agree
- gumby 8y ago
  I was confused about this too and thought perhaps it was about the security issues and how a command line client worked for them.
lolc 8y ago
I've only used Elm for a hobby project. Given how much I enjoyed the experience of web app programming for once, it's nice to read how well it scales to a large application.
- mordrax 8y ago
  It definitely scales. There is an 'adjustment period' where I went from a nested to a flat, decoupled architecture. But as most things are one to two levels deep (state), complexity also grows fairly linearly. This is really great from a developer's pov when trying to grapple with how to add new features.
  - freekh 8y ago
    This is also my experience in both elm and (type|Java)script/react/redux apps as well: flat decoupled architectures seem to scale better in terms of development/maintenance in addition to reducing (bad) churn. If styling is properly handled, feature progression is also linear-ish.
woolvalley 8y ago
Thanks for warning about compile times.
- mordrax 8y ago
  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.
  - woolvalley 8y ago
    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.
sridca 8y ago
I never enjoyed frontend programming until I came across Elm. Not only that Elm turned out to be a gateway drug to Haskell. Now I write frontend and mobile apps in Haskell using Functional Reactive programming (FRP).
- ghayes 8y ago
  Yeah, we've had a great time writing Elm for a fairly complex single-page Ethereum dApp. It's conceptually a lot simpler than Haskell, which made it easy for the team to pick up. I only wish it had a better system (Tasks) for JavaScript interop instead of ports.
  - kureikain 8y ago
    This is so true. I liked and used Elm when I have the right to make final decision. But it's hard to convince others use Elm when coming to integrate with JS. That's the reason TypeScript won. It intergrate with existing JavaScript seamlessly.
  - spraak 8y ago
    ReasonML could be a good middle ground there.
    - byw 8y ago
      One of the biggest complaints of Elm is the lack of typeclass. I'm not aware of a similar abstraction in OCaml. Does Reason have similar limitations, or are there ways to get around it?
      - rs86 8y ago
        First class modules. And yes, not having typeclasses is a bit of a turn off too...
      - orbifold 8y ago
        OCaml has parametrized modules, confusingly called functors, a very nice feature along with first class modules that Haskell doesn’t have. It is roughly speaking used wherever one would use a Typeclass in Haskell http://ocamlgraph.lri.fr/index.en.html http://ocamlgraph.lri.fr/index.en.html is one good example.
fwip 8y ago
The lead paragraph is a bit worrying. > Since July 2017, I’ve been leading the frontend rewrite of their flagship product. The codebase was at 16k LoC when I started. Since then, I’ve rewritten the various subsystems at least once (I'm looking at you generic form component). Now we hover around 45k LoC with most of the common SPA structures stabilizing. We are about a third of the way to completion. I don't know if it's common for rewrites to triple the amount of code while being only 1/3rd complete, but it certainly doesn't feel like "these are the facts I should lead with." Edit: I read more of the prologue, and it turns out that the initial 16kloc application was not complete.
- georgeam 8y ago
  It may be relevant that he applied elm-format to the codebase, apparently for the first time. elm-format puts very little code on each line and puts a lot of meaning into indentation, so that alone could inflate the LoC instantly without changing any semantics.
- mordrax 8y ago
  Correct, the initial 16k LoC was not complete. In fact ( no metrics ), I deleted large portions of redundant files/code and at one stage we were back at about 11k LoC. The comment about 16k -> 45k LoC was to give an idea of how much we had added to the product over the last 10 months.
callahanrts 8y ago
Thanks for writing this. It's encouraging to read about others' experiences using Elm in production. After a couple small side projects in Elm, I'm finally using it in a few low-risk areas at work.
kuon 8y ago
I also shared my elm experience a few days ago: https://news.ycombinator.com/item?id=16750842 https://news.ycombinator.com/item?id=16750842
- mordrax 8y ago
  That was also a good read, thanks for sharing it!
Tehnix 8y ago
A bit of a side-track, but I feel like I'm in a weird waiting phase with Pure FP JS. With Elm, I don't really feel like introducing it to my team before 0.19 hits, because it "feels" like it's around the corner, but it has felt like that for a while. With Haskell, I'm not entirely happy with GHCJS and the tooling surrounding it. I'm dreaming of the WebGHC[0]/WASM being nicer, if it ever gets done. I don't exactly know what keeps me off PureScript, perhaps that most frameworks just seem to compile to React, and that the community still hasn't settled on one (at least it seems so from the outside). Honestly, Miso[1] is the one I feel the most optimistic about atm. [0] https://github.com/WebGHC https://github.com/WebGHC [1] https://haskell-miso.org https://haskell-miso.org
- spraak 8y ago
  You might check out ReasonML. There is even a blessed ReasonReact
  - thoradam 8y ago
    ReasonML isn't pure FP.
    - jasim 8y ago
      Purity is not an end unto itself.
      - Tehnix 8y ago
        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.
sulam 8y ago
All the ML inspired languages seem to fall over on compile time. This post is a good example, where it describes design choices driven specifically by compile time, which is not a dimension I usually want interacting with the way I structure my code. I love the rest of the story (full disclosure: I have years of experience with Scala and Swift, which are no better) but until sufficiently advanced compilers arrive these languages are going to continue to be a hard sell for a substantial group of developers.
- scns 8y ago
  OCaml has a fast compiler
- hibikir 8y ago
  The strange bit with Elm is that it limits its type system just enough that compile times should be reasonable: The performance pits that Scala has are skirted altogether by Elm. If Elm isn't faster at compilation time, it's because that's not where the focus has been. I might be missing something though, and I'd be happy if Evan corrected me on this one. As far as Scala goes, Grzegorz Kossakowski has done work trying to get major performance improvements out of Scala type checking, and his numbers look very promising. Barring some Shapeless-style type level computations, Scala could compile quite fast.
- mordrax 8y ago
  > where it describes design choices driven specifically by compile time I'd like to point out two things here: 1. There are common library functions that we put in single files. These are imported by a lot of other files. The fact that these incur a large recompile cost is unfortunate and I think it doesn't have to be this way if dependencies were calculated at a more granular level. 2. The far larger implication to compile time becoming exponential is coupling of concerns. This is solely in the developer's responsibility. For a type system that guarantees correctness of code, there is no way around the fact that all affected modules must recompile. eg, if a fundamental law of physics were to change, the whole universe would have to recompute. So I think for a 'substantial group of developers', the focus should be on helping people to recognise what is coupling and how to design de-coupled systems.
binora 8y ago
that's a good read. can anyone point me to similar stories but for clojurescript ??
carapace 8y ago
Serious question: What's the business value case for not using Elm?
- Guthur 8y ago
  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
  - kod 8y ago
    If static compilation was a free lunch AND people were rational, which they are not, there would be no question. I definitely move faster in decent statically typed languages, but I did invest time in learning.
  - jxxcarlson 8y ago
    Yes, move faster, then pay the price later when stuff is broken and hard to fix.
- vogre 8y ago
  If you doubt that it will persist in 5 years, and want you app to be supported in this timespan. Nothing is worse than abandoned technology in the core of your application
- vages 8y ago
  Network effects: The sufficiently large pool of competent programmers who already know Javascript makes it easier to hire people. The many people you don't hire often make some of their work available for reuse for free.
- boubiyeah 8y ago
  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.

165 points by mordrax 8y ago

Took me a while to realize this wasn't about the Elm email client https://en.wikipedia.org/wiki/Elm_(email_client) https://en.wikipedia.org/wiki/Elm_(email_client)

GavinMcG 8y ago
I'm curious how you interpreted the very first sentence on the page: > the technical trials and tribulations he faced, the euphoric and … not so euphoric bits of writing a SPA in Elm What trials and tribulations did you picture that came with writing a single page application in an email client?
- Patrick_Devine 8y ago
  Honestly, it took digging through multiple pages to figure out what (this) Elm was about. If you come in with a preconceived notion of what something is supposed to be about, and there is nothing which even gives a short blurb on project goals, it can be a little bewildering. Clearly it wasn't about the email client (that was a bit tongue-in-cheek), but I was curious about what the project actually was for, and had to really hunt to find any information.
  - always_good 8y ago
    It's interesting how everyone thinks they're the first person to make the joke. Not much different than going "haha, I thought it was about the Elm tree for a while!" I'm starting to think it's just a way to signal to others that you know of an email client that last had a stable release 12 years ago that most people haven't heard of. Maybe there should be a way to wear this badge of honor in your profile instead of making the same joke, though.
spraak 8y ago
https://hn.algolia.com/?query=elm%20email&sort=byPopularity&prefix=false&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=elm%20email&sort=byPopularity&... Seems like at least a few others have over time as well
- always_good 8y ago
  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.
  - Patrick_Devine 8y ago
    Sure, but I used Elm for email for probably close to 15 years. It, and Pine, were pretty much the only two dedicated email clients for as long as I can remember. I don't have a problem with people repurposing the name, just be somewhat sympathetic that not everyone is going to know about your web framework. Onboarding is a thing.
  - spraak 8y ago
    Yep, I wasn't so clear with what I'd posted, but I agree
gumby 8y ago
I was confused about this too and thought perhaps it was about the security issues and how a command line client worked for them.

lolc 8y ago

I've only used Elm for a hobby project. Given how much I enjoyed the experience of web app programming for once, it's nice to read how well it scales to a large application.

mordrax 8y ago
It definitely scales. There is an 'adjustment period' where I went from a nested to a flat, decoupled architecture. But as most things are one to two levels deep (state), complexity also grows fairly linearly. This is really great from a developer's pov when trying to grapple with how to add new features.
- freekh 8y ago
  This is also my experience in both elm and (type|Java)script/react/redux apps as well: flat decoupled architectures seem to scale better in terms of development/maintenance in addition to reducing (bad) churn. If styling is properly handled, feature progression is also linear-ish.

woolvalley 8y ago

Thanks for warning about compile times.

mordrax 8y ago
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.
- woolvalley 8y ago
  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.

sridca 8y ago

I never enjoyed frontend programming until I came across Elm. Not only that Elm turned out to be a gateway drug to Haskell. Now I write frontend and mobile apps in Haskell using Functional Reactive programming (FRP).

ghayes 8y ago
Yeah, we've had a great time writing Elm for a fairly complex single-page Ethereum dApp. It's conceptually a lot simpler than Haskell, which made it easy for the team to pick up. I only wish it had a better system (Tasks) for JavaScript interop instead of ports.
- kureikain 8y ago
  This is so true. I liked and used Elm when I have the right to make final decision. But it's hard to convince others use Elm when coming to integrate with JS. That's the reason TypeScript won. It intergrate with existing JavaScript seamlessly.
- spraak 8y ago
  ReasonML could be a good middle ground there.
  - byw 8y ago
    One of the biggest complaints of Elm is the lack of typeclass. I'm not aware of a similar abstraction in OCaml. Does Reason have similar limitations, or are there ways to get around it?
    - rs86 8y ago
      First class modules. And yes, not having typeclasses is a bit of a turn off too...
    - orbifold 8y ago
      OCaml has parametrized modules, confusingly called functors, a very nice feature along with first class modules that Haskell doesn’t have. It is roughly speaking used wherever one would use a Typeclass in Haskell http://ocamlgraph.lri.fr/index.en.html http://ocamlgraph.lri.fr/index.en.html is one good example.

fwip 8y ago

The lead paragraph is a bit worrying. > Since July 2017, I’ve been leading the frontend rewrite of their flagship product. The codebase was at 16k LoC when I started. Since then, I’ve rewritten the various subsystems at least once (I'm looking at you generic form component). Now we hover around 45k LoC with most of the common SPA structures stabilizing. We are about a third of the way to completion. I don't know if it's common for rewrites to triple the amount of code while being only 1/3rd complete, but it certainly doesn't feel like "these are the facts I should lead with." Edit: I read more of the prologue, and it turns out that the initial 16kloc application was not complete.

georgeam 8y ago
It may be relevant that he applied elm-format to the codebase, apparently for the first time. elm-format puts very little code on each line and puts a lot of meaning into indentation, so that alone could inflate the LoC instantly without changing any semantics.
mordrax 8y ago
Correct, the initial 16k LoC was not complete. In fact ( no metrics ), I deleted large portions of redundant files/code and at one stage we were back at about 11k LoC. The comment about 16k -> 45k LoC was to give an idea of how much we had added to the product over the last 10 months.

callahanrts 8y ago

Thanks for writing this. It's encouraging to read about others' experiences using Elm in production. After a couple small side projects in Elm, I'm finally using it in a few low-risk areas at work.

kuon 8y ago

I also shared my elm experience a few days ago: https://news.ycombinator.com/item?id=16750842 https://news.ycombinator.com/item?id=16750842

mordrax 8y ago
That was also a good read, thanks for sharing it!

Tehnix 8y ago

A bit of a side-track, but I feel like I'm in a weird waiting phase with Pure FP JS. With Elm, I don't really feel like introducing it to my team before 0.19 hits, because it "feels" like it's around the corner, but it has felt like that for a while. With Haskell, I'm not entirely happy with GHCJS and the tooling surrounding it. I'm dreaming of the WebGHC[0]/WASM being nicer, if it ever gets done. I don't exactly know what keeps me off PureScript, perhaps that most frameworks just seem to compile to React, and that the community still hasn't settled on one (at least it seems so from the outside). Honestly, Miso[1] is the one I feel the most optimistic about atm. [0] https://github.com/WebGHC https://github.com/WebGHC [1] https://haskell-miso.org https://haskell-miso.org

spraak 8y ago
You might check out ReasonML. There is even a blessed ReasonReact
- thoradam 8y ago
  ReasonML isn't pure FP.
  - jasim 8y ago
    Purity is not an end unto itself.
    - Tehnix 8y ago
      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.

sulam 8y ago

All the ML inspired languages seem to fall over on compile time. This post is a good example, where it describes design choices driven specifically by compile time, which is not a dimension I usually want interacting with the way I structure my code. I love the rest of the story (full disclosure: I have years of experience with Scala and Swift, which are no better) but until sufficiently advanced compilers arrive these languages are going to continue to be a hard sell for a substantial group of developers.

scns 8y ago
OCaml has a fast compiler
hibikir 8y ago
The strange bit with Elm is that it limits its type system just enough that compile times should be reasonable: The performance pits that Scala has are skirted altogether by Elm. If Elm isn't faster at compilation time, it's because that's not where the focus has been. I might be missing something though, and I'd be happy if Evan corrected me on this one. As far as Scala goes, Grzegorz Kossakowski has done work trying to get major performance improvements out of Scala type checking, and his numbers look very promising. Barring some Shapeless-style type level computations, Scala could compile quite fast.
mordrax 8y ago
> where it describes design choices driven specifically by compile time I'd like to point out two things here: 1. There are common library functions that we put in single files. These are imported by a lot of other files. The fact that these incur a large recompile cost is unfortunate and I think it doesn't have to be this way if dependencies were calculated at a more granular level. 2. The far larger implication to compile time becoming exponential is coupling of concerns. This is solely in the developer's responsibility. For a type system that guarantees correctness of code, there is no way around the fact that all affected modules must recompile. eg, if a fundamental law of physics were to change, the whole universe would have to recompute. So I think for a 'substantial group of developers', the focus should be on helping people to recognise what is coupling and how to design de-coupled systems.

binora 8y ago

that's a good read. can anyone point me to similar stories but for clojurescript ??

carapace 8y ago

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

Guthur 8y ago
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
- kod 8y ago
  If static compilation was a free lunch AND people were rational, which they are not, there would be no question. I definitely move faster in decent statically typed languages, but I did invest time in learning.
- jxxcarlson 8y ago
  Yes, move faster, then pay the price later when stuff is broken and hard to fix.
vogre 8y ago
If you doubt that it will persist in 5 years, and want you app to be supported in this timespan. Nothing is worse than abandoned technology in the core of your application
vages 8y ago
Network effects: The sufficiently large pool of competent programmers who already know Javascript makes it easier to hire people. The many people you don't hire often make some of their work available for reuse for free.
boubiyeah 8y ago
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.