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.
Elm at Pacific Health Dynamics
31–40 of 57 posts
Re: Elm at Pacific Health Dynamics
#32Earlier 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.
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.
Re: Elm at Pacific Health Dynamics
#33All 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…
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.
Re: Elm at Pacific Health Dynamics
#34All 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 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.
Re: Elm at Pacific Health Dynamics
#35that's a good read. can anyone point me to similar stories but for clojurescript ??
Re: Elm at Pacific Health Dynamics
#36Serious question: What's the business value case for not using Elm?
Re: Elm at Pacific Health Dynamics
#37Earlier 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?
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?
Re: Elm at Pacific Health Dynamics
#38Serious question: What's the business value case for not using Elm?
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.
Re: Elm at Pacific Health Dynamics
#39Earlier quoted context omitted.
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?
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
#40Serious 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