There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm. I also like the debugger. It allows you to easily capture your st…
> It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where 1 + "1" "1" + 1 1 + 1 "1" + "1" are all 2, and 1 . "1" "1" . 1 "1" . "1" 1 . 1 are all 11. Letting you specify the result you want by the function you call basically solves that whole problem.
Elm changed my mind about unpopular languages
61–70 of 321 posts
Re: Elm changed my mind about unpopular languages
#62My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…
Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading…
Re: Elm changed my mind about unpopular languages
#63> First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case. I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Re: Elm changed my mind about unpopular languages
#64Earlier quoted context omitted.
> > First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case. > I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language? Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely…
> Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). Neither is even remotely as robust — let alone friendly — as Elm's type system.
Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time.
I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")
Re: Elm changed my mind about unpopular languages
#65My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…
Re: Elm changed my mind about unpopular languages
#66Earlier quoted context omitted.
Not to the same extent, Elm: * sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0]) * has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience) * and which you use as bottom by hand-rolling pattern matches * at which point you might as well…
GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.
Re: Elm changed my mind about unpopular languages
#67Earlier quoted context omitted.
The communities for languages like Elm are definitely smaller, but they're also "passion languages", if that makes sense. Nobody is learning elm because they've been or feel forced to (like you might with React, eg) or because they needed to maintain a legacy codebase at an old job or something. They're learning it because they're interested/like it, etc. So when it comes time to hire you have a small(er) pool of can…
But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.
Re: Elm changed my mind about unpopular languages
#68Earlier quoted context omitted.
Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading…
Don't you want people that care about your product instead of the technology behind it? I do. Because there may come a time when another technology is a better fit for your product and ultimately your customer's experiences. Then what? Now your not using elm and your team leaves or is disgruntled. I hire on passion for what we are trying to accomplish, not the technology stack.
Re: Elm changed my mind about unpopular languages
#69My first thought: The author would probably be equally satisfied if they had used JavaScript with flowtype and react. It sounds like they're comparing JQuery + Bootstrap (and similar "old" frontend frameworks) to Elm. I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.
Re: Elm changed my mind about unpopular languages
#70What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to achieve the same result? Just seems like added complexity for no reason, even if the code looks simple with the first pass.