Hacker News new | past | comments | ask | show | jobs | submit login

> There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off.

A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are. For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose?

Modern JavaScript undoubtedly towers over Elm in terms of go-to-market time for arbitrary apps.

> you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code.

This is a big problem with 2007 JavaScript and jQuery. React/Vue and other declarative VDOM frameworks bring the Elm philosophy to the masses.




> For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose?

IMO this is an advantage of the smaller/smarter/niche (whatever you want to call them) programming communities. When they congregate around a couple libraries for common problems, those libraries tend to be very good. Speaking from experience in the Elm and Clojure ecosystems.

It’s much better in terms of developer time to evaluate 2 good libraries than 50 libraries where the quality ranges from abysmal to good.


> This is a big problem with 2007 JavaScript and jQuery. React/Vue and other declarative VDOM frameworks bring the Elm philosophy to the masses.

But ... in addition to npm/babel etc. you need a wetware constraint checker. React says "human: make sure your data is immutable - please don't forget or something might break later in production". Elm says "I guarantee immutability"


> A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are

That seems more of a metric for an ecosystem than a community.


It's presumptuous to assume "community A is smarter than community B". It's just not even the right question to ask. Better questions to ask are "what are third party libs like?", "how active are people in this community?", "how active is the SO and other forums?". These are actionable questions.

"People who use Elm are smarter" is simply not actionable information. What does it even mean? It's meaningless.


> It's presumptuous to assume "community A is smarter than community B"

You can e.g. Rocket scientists VS. Janitors.

Note what I am not saying (which people might take offense to) is "you use Vue not Elm, so you are dumb". Nope of course that isn't true!. I am saying in aggregate, due to selection biases etc, Elm attracts smart people. A lot of really smart people will stick to popular frameworks and not use Elm. Some bad programmers might use Elm for some reason. Aggregates are what I am talking about.

> "what are third party libs like?", "how active are people in this community?", "how active is the SO and other forums?". These are actionable questions.

These are good questions.

Another question though is: how much do I trust another library to not have bugs? Given Elm's design vs. vanilla JS, I'd go for Elm. That confidence extends to "How much do I trust a Library I knocked up over the weekend to solve an previously unsolved problem in Elm".


> It's presumptuous to assume "community A is smarter than community B".

To assume with no basis, sure; to conclude it may or may not be.

> It's just not even the right question to ask.

It's not inherently operationalized, sure, though (as seen elsewhere in this thread), “advertising jobs for platform A results in us needing to filter out fewer candidates with no real programming ability than when we advertise jobs for platform B” I'd pretty much an operationalization of it, and quite (to address your later point) actionable.


You're saying the "simpler" route will attract newer devs and dilute the skill pool.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: