Live data from Hacker News

Elm at Pacific Health Dynamics

mordrax.gitbooks.io

41–50 of 57 posts

Re: Elm at Pacific Health Dynamics

#41
post #31

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…

OCaml has a fast compiler

Re: Elm at Pacific Health Dynamics

#42
post #27
post #4

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.

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.

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.

Re: Elm at Pacific Health Dynamics

#43
post #21
post #18

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

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 is one good example.

Re: Elm at Pacific Health Dynamics

#44
post #39
post #37

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

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

#45

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

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

Re: Elm at Pacific Health Dynamics

#46
post #19
post #13

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 kno…

You might check out ReasonML. There is even a blessed ReasonReact

ReasonML isn't pure FP.

Re: Elm at Pacific Health Dynamics

#49
post #34
post #31

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…

> 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…

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

Re: Elm at Pacific Health Dynamics

#50
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

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.

Post reply on HN