
Elm at Pacific Health Dynamics - mordrax
https://mordrax.gitbooks.io/elm-at-phd/content/
======
sridca
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
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.

~~~
spraak
ReasonML could be a good middle ground there.

~~~
byw
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?

~~~
yomly
Noon question: what is a typeclass in the sense of the feature Elm lacks?

Does it mean the equivalent to `class` keyword in the OO sense?

~~~
hawkice
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.

~~~
a-saleh
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)

~~~
boubiyeah
typescript has both :D

~~~
a-saleh
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?

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

~~~
mordrax
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.

------
Tehnix
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
You might check out ReasonML. There is even a blessed ReasonReact

~~~
thoradam
ReasonML isn't pure FP.

~~~
jasim
Purity is not an end unto itself.

~~~
Tehnix
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
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.

~~~
mordrax
> 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.

~~~
seanmcdirmid
Beyond separate compilation, incremental compilation can go a far way here in
minimizing what has to be recompiled on a change. You can even be incremental
at tree level for really aggressive change latency reductions (though batch
becomes lower because of memoization overhead, not to mention memory
consumption concerns).

------
kuon
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
That was also a good read, thanks for sharing it!

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

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

------
carapace
Serious question: What's the _business value_ case for _not_ using Elm?

~~~
Guthur
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
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.

------
woolvalley
Thanks for warning about compile times.

~~~
mordrax
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
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.

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

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

