If you started with Elm then JS/CSS/HTML+Frameworks|Transpiled-langs et. al. would, I imagine, seem like a massive amount of stuff to learn, eh?
I think the Elm-first programmer would be right to ask, "What's the payoff? What awesome new powers do I gain, impossible with Elm, as reward for all this blood sweat and tears?"
(Elm is wildly easier to debug than the status quo stuff. The compiler is awesome for that. So the hypothetical Elm-first programmer has to learn not just the status quo stack but also how to debug it!)
So, again, it seems to me like it behooves the cost-conscious programmer to carefully examine the cost/benefit ratio of non-Elm-implementable features in light of the availability of Elm.
I am presupposing, like I said above, that you can take pretty much any member of the Sudoku-solving public and train them up in Elm in a few weeks. Even paying them at parity with JS devs, the time and effort savings of Elm vs. JS et. al. would be substantial, I believe.
(Personally, I would want at least two or three people on the team who knew what was going on under the hood.)
So you're ok with an elm programmer not willing to learn JS, but not ok with the reverse. That just sounds like good old fashioned tribalism; and personally I'd never hire a tribal programmer, whether that tribalism is about a great language, or the latest coolest JS framework.
What I'd look for is an open, sharp mind. Willing and happy to learn new things and paradigms, even those that go beyond their comfort zones, whether it is JS, Elm or Java. Someone to whom programming languages, frameworks and libraries are just TOOLS to accomplish a certain goal, and not part of their identity.
I'm not sure where you're coming from, but when I'm looking for a job, I pay attention to the tools that companies have picked, and if I get the chance to ask them, why. A company that picks good tools is a lot more attractive to me. All other thigns being equal, if I had to choose between a company that used JS, and one that used JS and one that used Elm, I would prefer the Elm one. I've never written a line of Elm before.
I'm willing and happy to learn new tools. I'm happy with hiking in flip-flops if that's all that's available, but I'd certainly choose hiking boots if given the choice. I suspect most "good" developers have the same attitude.
> So you're ok with an elm programmer not willing to learn JS, but not ok with the reverse.
That's not exactly the spirit of what I meant, but, yes.
> That just sounds like good old fashioned tribalism
I can't really control what it sounds like to you, can I?
My whole point is that Elm is (or one day soon will be) much superior to JS et. al. This is a cost/benefit analysis, not tribalism. (I'm not an Elm fanboy. I don't actually like it that much, in fact.)
It's puzzling that more JS programmers don't adopt Elm.
It's reasonable for an Elm developer to ignore JS to the extent possible.
That's the point of Elm, eh?
> What I'd look for is an open, sharp mind. Willing and happy to learn new things and paradigms, even those that go beyond their comfort zones, whether it is JS, Elm or Java. Someone to whom programming languages, frameworks and libraries are just TOOLS to accomplish a certain goal, and not part of their identity.
Sure! Me too. But now I can make the scarcity argument, no? And you've got to pay those folks well, eh?
I'm postulating that you can take normal people (smart enough to solve Sudoku) and have them productive in Elm within a month or so. You probably would not have to pay them as much as an equivalently-productive JS programmer, and certainly not as much as the kind of person you described.
Again, I'm talking about the business value of a given software production tool not the entertainment value or the personal-growth value for the devs.
> My whole point is that Elm is (or one day soon will be) much superior to JS et. al. This is a cost/benefit analysis, not tribalism.
I'm sorry, but your enthusiasm for Elm might be blinding your reasoning. JS is an EXTREMELY flexible languange. Open and malleble to both experts and newbies alike. Open to all styles and paradgims of programming including object and functional, which is what makes it possible to be the worlds most compiled to languange (https://github.com/jashkenas/coffeescript/wiki/List-of-langu...). Elm comes nowhere close to beating the JS cost benefit analysis.
In the end, the business value always wins out. Elm, started in 2012 is even older than react, and would've took of long ago if it had any business value.
> It's puzzling that more JS programmers don't adopt Elm.
JS developers come from diverse backgrounds (expert, newbie, functional, object, procedural etc). The ones that like elms approach will adopt it, those that don't will use a different style/compiler/transpiler; and it all ends up as JS. That's flexibility at work.
> which is what makes it possible to be the worlds most compiled to languange
Okay now that's just ridiculous.
There are no other native scripting languages that the browsers understand. Of course it's going to be the most compiled to language, doh.
Your statement is along the lines of "all Earth life breathes oxygen, this has to mean something".
Well of course it means something. It means that our planet doesn't offer alternative biomes. It doesn't mean that oxygen-based life is ideal (which it isn't).
JS is a legacy everybody is stuck with. That doesn't make it good. It only makes it a safe choice because it's widely used and has a larger pool of programmers as you said.
Most businesses are followers. If an universally better technology makes strides you can be damn sure a lot of those follower businesses will be all over it after Facebook or Google adopts it. Nothing new, businesses always seemed to operate like so.
Not sure what value do your comments bring except for stubbornly reasserting the state of our currently (and highly suboptimal) reality. Practically almost every non-junior programmer knows how we arrived here.
And finally, the better business value of JS [devs] is far from given. It's a local maximum and nothing else. I've seen teams replace 5 average programmers with 1 senior, save 40% expense in doing so, and have much more maintenable code with much less support costs. These things do happen even if they are not the majority. And they will keep happening until one day somebody like you will lecture people how "JS was never bound to succeed".
You should realise you are only reasserting current reality and are doing post-hoc rationalisations in an attempt to understand the said reality. This is completely fine; we all try to make sense of the world. Reality however is always in flux. Keep an eye out. ;)
As I said, I'm not an Elm fanboy. I don't actually like it that much.
> JS is an EXTREMELY flexible languange. Open and malleble to both experts and newbies alike. Open to all styles and paradgims of programming including object and functional
Sure. So what? So is LISP. I'm talking about "business value", meaning: if you don't care about how shiny and flexible and open your programmers' languages are, you care about the hard $$$ cost of development and maintainence per unit of webapp functionality delivered, then Elm makes a heck of a lot more sense than JS+etc.
The compiler and the fact that you get zero front-end errors just blows away the typical JS dev cycle with a buggy front-end. I can't quantify it because you can't quantify the hypothetical lost business due to hypothetical bugs that don't happen because you're not using JS.
To me it seems clear that it is much cheaper to develop and maintain Elm apps.
> what makes it possible to be the worlds most compiled to languange
Nah. That's because it's the only language in the browser and people would rather use something else.
> Elm, started in 2012 is even older than react, and would've took of long ago if it had any business value.
You're begging the question I think, my whole puzzlement is that the business value seems very clear yet Elm hasn't taken off.
To date, the only serious objection I've heard here and elsewhere is that they removed older docs when they bumped a minor version number. That sucks.
> you care about the hard $$$ cost of development and maintainence per unit of webapp functionality delivered, then Elm makes a heck of a lot more sense than JS+etc.
It doesn't, sorry. JS resources, developers and libraries are atleast x1000 more than Elm. business is about supply and demand, more supply == cheaper cost. That's business 101. That's why there are hardly any Elm jobs advertised if compared to JS. You keep talking about how Elm makes better business sense, but the reality of it is completely different. Maybe all those employees are just making the wrong business decision, right? Wishful fanboy thinking. You are even in denial about liking Elm, which is pretty obvious to anyone reading your comments about it.
> Nah. That's because it's the only language in the browser and people would rather use something else.
Something else like dart, flash, VB, Java... oh wait! They've all been used in the browser before, none passed the test of time. And Elms approach (transpiling to JS, CSS, HTML) is not unique either, e.g. TypeScript and its not exactly shinning against competition in its league either. Once it beats competition there, then maybe it can start taking aim at JS, CSS and HTML.
> You're begging the question I think, my whole puzzlement is that the business value seems very clear yet Elm hasn't taken off.
It seems very clear to you, because you like and have invested in the language so much. A less invested "business person" will have a more objective view of which of the two (JS vs Elm) makes more business sense.
In 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!
What most people do not realize, is JavaScript was designed as a functional language, with a C-like syntax. When I talk about learning proper JS, I mean getting back to its functional roots, because that where it really shines.
If you started with Elm then JS/CSS/HTML+Frameworks|Transpiled-langs et. al. would, I imagine, seem like a massive amount of stuff to learn, eh?
I think the Elm-first programmer would be right to ask, "What's the payoff? What awesome new powers do I gain, impossible with Elm, as reward for all this blood sweat and tears?"
(Elm is wildly easier to debug than the status quo stuff. The compiler is awesome for that. So the hypothetical Elm-first programmer has to learn not just the status quo stack but also how to debug it!)
So, again, it seems to me like it behooves the cost-conscious programmer to carefully examine the cost/benefit ratio of non-Elm-implementable features in light of the availability of Elm.
I am presupposing, like I said above, that you can take pretty much any member of the Sudoku-solving public and train them up in Elm in a few weeks. Even paying them at parity with JS devs, the time and effort savings of Elm vs. JS et. al. would be substantial, I believe.
(Personally, I would want at least two or three people on the team who knew what was going on under the hood.)