61–70 of 84 posts
I like Elm as a language, but the community is extremely toxic, and it's not production-ready yet (version < 1.0, one-person project). Too bad, because it's a great project.
Earlier quoted context omitted.
Why exactly? Elm 0.19 is out on August 2018, and the only thing that's expected is 0.19.1 which barely changes anything (doesn't break any api). Seems like 0.19 is quite settled at this point.
Will my Elm code written today still be maintainable with an up-to-date elm environment in 3 years? It certainly isn't the case with code written 3 years ago.
The next upgrade, 0.19.1, will be completely backwards compatible.
For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Having said that, the article is well written and thorough for anyone wanting to take a look into Elm. But there are massive problems with Elm itself which make it impossible to consider seriously. I have and still do use Elm in production, and went through the ni…
This is the only Elm I know: https://en.wikipedia.org/wiki/Elm_(email_client)
If I have time off to learn a new language in order to get a new Job, would Elm be a good choice? I wonder if picking a niche language would give me an advantage or there would be too few jobs.
For anyone new trying to get into Elm (as a language/tool), I would look elsewhere. ReasonML, PureScript, TypeScipt, etc are all better featured solutions. Having said that, the article is well written and thorough for anyone wanting to take a look into Elm. But there are massive problems with Elm itself which make it impossible to consider seriously. I have and still do use Elm in production, and went through the ni…
Regarding #3, would you mind pointing out some good resources/examples that illustrate this pattern?
Earlier quoted context omitted.
That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?
Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shap…
I’m curious about this comment on statically typed OO languages. I work mainly with C# and don’t have much FP experience. Are you referring to exhaustive matching?
Edit: To clarify, I understand that C# compiler won’t prevent you from trying to access an element in an empty collection. What prevents you, in a typed FP language, from accessing head of an empty list?
Earlier quoted context omitted.
Why exactly? Elm 0.19 is out on August 2018, and the only thing that's expected is 0.19.1 which barely changes anything (doesn't break any api). Seems like 0.19 is quite settled at this point.
Will my Elm code written today still be maintainable with an up-to-date elm environment in 3 years? It certainly isn't the case with code written 3 years ago.
Earlier quoted context omitted.
Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shap…
> These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. I’m curious about this comment on statically typed OO languages. I work mainly with C# and don’t have much FP experience. Are you referring to exhaustive matching? Edit: To clarify, I understand that C# compiler won’t prevent you from trying to access an element in an empty collection. What prevent…
In OCaml, (List.hd []) throws an exception, which is not a desirably behaviour, so we mostly use a safer version of List.hd which would return an option type. This could be either "None" or "Some(value)". To operate on option types, we have to pattern match and handle both cases where the value could be either None or Some)
Exhaustive pattern matching is useful here, so is the very notion of variants. Without variants (or sum type / union type) we tend to leave domain concepts implicit in the codebase. While we can simulate variants with classes, it is too unwieldy to be used except for core domain concepts.
Earlier quoted context omitted.
> These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. I’m curious about this comment on statically typed OO languages. I work mainly with C# and don’t have much FP experience. Are you referring to exhaustive matching? Edit: To clarify, I understand that C# compiler won’t prevent you from trying to access an element in an empty collection. What prevent…
Yes I was thinking of a couple of things, but most importantly the existence of null in the language. So functions either receive exactly the type they were looking for (which is better than dynamically typed), or a null (which never happens in a Typed FP language). In OCaml, (List.hd []) throws an exception, which is not a desirably behaviour, so we mostly use a safer version of List.hd which would return an option…