Live data from Hacker News

Elm changed my mind about unpopular languages

blog.realkinetic.com

61–70 of 321 posts

Re: Elm changed my mind about unpopular languages

#61

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.

I think this was only to demonstrate the point. Elm's string concatenation operator is ++, so you never run into a case where this would happen.

Re: Elm changed my mind about unpopular languages

#62
post #2

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

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

#63
post #17

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

"Functional language" has come to tend to mean a language with an ML-style type system, possibly because almost all serious languages these days have first-class functions and map/reduce/filter. But ultimately the term means different things to different people.

Re: Elm changed my mind about unpopular languages

#64

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

It's not so black and white :)

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

#65
post #2

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

I think the hiring woes problem for languages like this is a reasonable hypothesis, but I've never seen any actual evidence for it. I constantly hear from folks who are worried that they will have this problem, and frequently hear folks saying they tried it and it wasn't a problem (see sibling comments, for example). I'm not sure I've ever heard from someone who has actually had this problem.

Re: Elm changed my mind about unpopular languages

#66

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

Pattern matching on GADTs will get you there, I believe.

Re: Elm changed my mind about unpopular languages

#67
post #38

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

That's what a good manager is for, they're there to turn a powerful engine into a productive one.

Re: Elm changed my mind about unpopular languages

#68
post #62

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

I fail to see how your argument makes Elm a worse option than any other language?

Re: Elm changed my mind about unpopular languages

#69

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

Perhaps, but with Elm you get a much better experience revolving about the tooling(Inspired from Golang I believe). This would be one of my top arguments for picking Elm over a giant mess of react+infinite choices of libraries and configurations.

Re: Elm changed my mind about unpopular languages

#70
I feel unpopular languages are best relegated for niche use cases the language is well suited for. If you are going to build something mundane like a CRUD App or a game, or an ERP, why wouldn't you just use some mundane blue-collar language like Javascript or its equivalent?

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

Post reply on HN