Ask HN: Should we coordinate to switch to more productive languages?
It seems that some programming languages are simply better (i.e. overall safer, faster to read/write/compile/run, more expressive and efficient to develop in) than others. Overall worse languages often stick around though due to what often seems to essentially be community momentum--what could also be thought of as coordination failure.
Many individuals think "X lang clearly seems better, but Y is where the community momentum already is, so I am going with Y", and there isn't a clear way for developers and employers to commit to developing in language X instead of Y if "N quantity Y lang developers publicly commit to changing their next project that would otherwise be in Y lang to be in X lang."
While a public promise with public git repos may be enough, we may be able to even utilize smart contracts in the near future to help foster community-wide switches.
Also, while I'm not familiar enough with the languages to confidently say the dev community would be better if we could make the switch, I had: Python → Julia C → D C++ → D or Rust in mind, but whether or not you'd agree about these, I'm confident there are at least other switches worth making.
Would you pledge to switch to programming languages if enough of the industry agreed to do the same? If so, for which languages might you?
Is this worth thinking about more? > Would you pledge to switch to programming languages if enough of the industry agreed to do the same? If so, for which languages might you? Is this worth thinking about more? What research have you done on this matter other than this post? Is there a written record of you thinking about the trade offs in a longer format? > Is this worth thinking about more? No one can tell you what's worth thinking about. You'll have to decide that for yourself by doing the actual research and then presenting your results for discussion. Other than your questions I didn't see any actual research or summaries of research that would be useful for a discussion. I didn't realize this was Nature, my bad. And of course I am the one who decides for myself if anything is worth thinking about more. I was simply trying to elicit the sort of information which would be relevant to this decision such as, "Here's a bit of evidence you might not be aware of that suggest this is more intractable than you may think. Also, considering the existentially pressing X and Y risks on the horizon, which better programmer productivity presumably wouldn't help, you may want to consider that your comparative advantage may be A or B." Sounds like you already know what questions you want answers to but didn't actually put them in your prompt and made it much more open ended than necessary. Personally I think language wars are silly. I enjoy learning new languages and the more of them there are the better so I will not be making any pledges that involve standardizing on a specific language or set of languages. If my company's software is built with 10 million lines of C++, and the software works, how would you convince the stakeholders that a rewrite is worthwhile? Convincing people to switch because "it's better" is not very compelling if I have working code that is making money. If you like another programming language, use it. I will continue using what works for my needs, especially when I already have working code. I am not really interested in having people switch who don't want to and are perfectly happy with their language. I am proposing the r&d of a way to coordinate people switching who would like to switch languages, but only under certain conditions, such as if their would be jobs in it and sufficient expected growth in attention to the language's development. No. Use the language that fits best for the project/team. Why is Julia better than Python? These are entirely subjective questions. Many programming languages would fit a project\team better if they had more community support. It's often worth putting up with worse-designed languages due to the existing libraries and documentation. Also, the whole 'subjective\objective' distinction is tiresome and doesn't really help here. If we held a RCT where half of people started learning and developing in Julia, and the other half in Python, and they both only had the standard library and documentation, and we measured productivity, code performance, dev satisfaction, etc. and pehaps even had the developers eventually switch, we'd likely see data supporting the idea that one of the languages is overall favored by developers more than the other. I have a working situation where I need to work with Python and Julia. I'd like to say that there are great interoperability between these runtimes, so you can easily call a Python function from Julia and vice versa. Clearly, if you find Julia more productive and think that's the future, then that's great! There is no reason to hold back given that you can call out to legacy Python code as needed. The downside, obviously, is that you have two languages to work with, which is not ideal. Depending on the size of your project and how much appetite you want to migrate code in your longer term roadmap, you can make a good judgment how to proceed. I would have to say the world needs to move forward no matter what. COBOL used to be the best language for business applications and it clearly went out of favor. The recent events with COVID-19 brought up a clear technical debt issue. What I' trying to say is, sooner or later, the code will need to be rewritten. Google tends to rewrite their software every few years to keep it fresh. That's not a bad model to have for any technology-centric company.