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 the…
Elm at Pacific Health Dynamics
41–50 of 57 posts
Re: Elm at Pacific Health Dynamics
#42I'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.
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.
Re: Elm at Pacific Health Dynamics
#43Earlier quoted context omitted.
ReasonML could be a good middle ground there.
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?
Re: Elm at Pacific Health Dynamics
#44Earlier quoted context omitted.
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?
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.
Re: Elm at Pacific Health Dynamics
#45Serious question: What's the business value case for not using Elm?
Re: Elm at Pacific Health Dynamics
#46A 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 kno…
You might check out ReasonML. There is even a blessed ReasonReact
Re: Elm at Pacific Health Dynamics
#47Re: Elm at Pacific Health Dynamics
#48Re: Elm at Pacific Health Dynamics
#49All 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 the…
> 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…
Re: Elm at Pacific Health Dynamics
#50Serious 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
I definitely move faster in decent statically typed languages, but I did invest time in learning.