7 ms·
Because it's a business risk. - It's very easy to find JS programmers. There's a _lot_ of them. But programmers proficient with pure functional programming lan
by kolme 7y ago
Because it's a business risk.
- It's very easy to find JS programmers. There's a _lot_ of them. But programmers proficient with pure functional programming languages are harder to come by.
- JS is natively supported by browsers and it is pretty much guaranteed that the code you write is going to work for ever. Elm on the other side, who knows? It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet.
- Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa.
That being said, it's only a risk. Maybe your team is more comfortable with Elm and they get more productive. Maybe the language design makes easier writing code with less defects. Maybe it actually gives you an edge.
It is hard to say if Elm brings value to your business. It most likely depends on what kind of a business that is (web agency than cranks 3 visit-card websites a day? Or is it one developing a complex app?)
In any case, managers get very nervous about languages that are not mainstream. And they do have good reasons.
- carapace 7y agoThanks for replying. > But programmers proficient with pure functional programming languages are harder to come by. I used to get a similar argument when pushing Python over Java, and my counterargument is the same: I wouldn't hire a JS programmer who was afraid or unwilling or unable to learn Elm. I would bet that any normal person smart enough to solve Sudoku problems could learn Elm, I wouldn't make that bet with JS/CSS/HTML. > It might lose steam and go into support mode, or drop support, or maybe they introduce breaking changes in a future version. JS is a much safer bet. But who is using just JS these days? Frameworks and transpiling are the order of the day, no? Same argument applies to them. And JS is a moving target too. As for "breaking changes", well, it is just version 0.19 so far. Once they hit 1.0 I would bet on Elm being more stable than JS+Whatever. Weigh this against zero front end bugs. That's a staggering (if hard-to-quantify) cost savings. > Writing Elm does not guarantee a good polished product. You can write bad software in good languages and vice-versa. Yeah but that's not an argument in favor or against any particular language, and in the specific case of JS vs Elm I think it's clear Elm wins. If your developers are truly crap then, yeah, Elm won't save them. But then you also have bigger problems than what tech stack to use, eh?
- wolco 7y agoIf you gave people the chance to learn you would find plenty of candidates. If you look for developers with elm experience you run into supply issues.
- 0_gravitas 7y agoIf you're open to remote hiring, I highly doubt it, I dont know much about elm (except that the people using it really like it) but the argument is one I've heard before with elixir. Hang out in the elixir slack or a FP discord for a day/week and you'll notice a massive amount of people taking about how much they like the language and wish there was somewhere hiring that used it. The people are definately willing.
- orange8 7y ago> I wouldn't hire a JS programmer who was afraid or unwilling or unable to learn Elm. Would you hire an Elm programmer who was afraid or unwilling to learn proper JS?
- busfahrer 7y agoAlso I want to throw in that learning a new paradigm (Elm) is something else entirely than going from one imperative language to another one.
- 0_gravitas 7y agoIn all fairness the functional paradigm isnt exactly all too hard to grasp (when it comes to what you need to be effective at least, you dont need to understand what a monad is, I still dont!). I started learning Clojure completely cold going through Exercism and it took me maybe 2 weeks of doing a problem a day (not much work at all) before I felt like I started to "get" FP. In fact, I would say it's even easier in a lot of cases because FP is a much "purer" skill set- any imperative language still uses functions, and arrays, and switch statements, and overloading. In FP, you have all of those familiar concepts (just presented in a possibly different way) but you dont need to worry about how classes work at all, or even loops in some cases!