5 ms·

And what are the credentials you have for backing up this claim? Because to me it seems like the majority of those who deliver value would beg to differ. And a

And what are the credentials you have for backing up this claim? Because to me it seems like the majority of those who deliver value would beg to differ. And a vocal minority is shouting "Stop wasting your time on programming languages". There are so many other easy ways to improving software quality. The xkcd linked in the article had me laugh out loud. I hadn't known that one, it's great, and what it says about languages rings true.

pharmakom 4y ago
I do not have a peer reviewed study to back up my claim. Sorry to disappoint. Which XKCD? I read the article but missed it.
- jstimpfle 4y ago
  Neither do I, but if I find the time I'll make one up to support my preferences. The XKCD: https://xkcd.com/568/ https://xkcd.com/568/
  - bmacho 4y ago
    Is copilot a programming language?
Yoric 4y ago
> There are so many other easy ways to improving software quality. Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it? Also, for some issues and metrics, software quality is in fact limited in practice by the language used. Getting guarantees of certain properties is trivial in garbage-collected languages, near impossible in languages with manual memory management. Similarly, the lack buffer overruns and underruns, XSS exploits, properly following protocol, etc. are going to be trivial to guarantee in some languages, near impossible in others. Now, I fully understand that following the hype wagon (or listening to fanbois singing praise about the latest tech, whether it's a language or anything else) is annoying. But let's not confuse hype and using the right tool. The intersection between those is often rather small :)
- jstimpfle 4y ago
  > Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it? The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English. Beyond the random internet post (or the rare one, like "Beating the Averages", which might well be exaggerated) I haven't seen any obvious competitive advantages from choosing a non-mainstream language. On the contrary, what you often see is that immature ecosystems are huge timesinks because a lot of stuff simply isn't "there" yet. That's not to say there aren't incremental improvements happening with new languages over time. But if your goal is to complete a project as opposed to evolving a language ecosystem I'd say that it's unwise to pick a non-mainstream language. Heck, I'm still using C for almost all of my projects (chances are I'd be using Java or C# if I was working in other domains). I've tried to switch - I have smaller and larger investments in a dozen languages. But no other language has stuck for me. A big reason for this inertia is that I simply know C well and I feel productive with it. But there are more objective qualities, some of which are related to it being mainstream and having a mature ecosystem. My language of choice has flaws, but they are well-known, with well-known workarounds. That lets me focus on the problem instead of the tools. Blog posts generally don't consider these qualities because they can't be discussed with toy examples that show you how you can neatly turn an isolated problem from 10 lines of C code into a 2-line fancy language solution. The problem with these examples is that they are not representative of longer-term and larger-scale software development.
  - pjmlp 4y ago
    Even with my typical C rants, I absolutely support the idea of a project going with C if that is what it makes sense on the market they operate on. The additional effort to add tooling and workflows that most of the teams aren't comfortable with, extra effort implementing integration layers, might slow down delivery to the point of diminishing returns, thus withdrawing any advantage. So while I personally might not like it, in some scenarios that is exactly the tool to use. Same applies to other domains and whatever language might be the "to go option" there.
mlatu 4y ago
and why should everyone plow their fields like everyone else does? > "Stop wasting your time on programming languages" "stop trying to fasc us out of having fun while being productive!" is my reply. there are already enough people trying to improve software quality using rusty shears, let me use my fusion powered laser cutter if i want to!
- jstimpfle 4y ago
  You are free to plow your field whichever way you like, of course. Just step back once in a while and check whether you've done enough plowing last month - or spent all your time upgrading your plowing technology. In the end you just have to plow, and it doesn't matter all that much how you do it (as long as you use my preferred brand of course). Plowing tech isn't all there is to growing crop and vegetables. There is an awful lot more that you have to understand and plan and take care of, and upgrading your plowing tech won't help you with any of that.
  - mlatu 4y ago
    i think you plowed the point into the ground
deleted 4y ago
[deleted]
dkarl 4y ago
The most productive people may program in mainstream languages like Java, but their programming is informed by exposure to a broader variety of languages than just the mainstream ones. To stick with Java as the example, Java was designed with a set of affordances for managing mutability, complex inheritance relationships, and objects with rich behavior, and the coding norms and "wisdom" surrounding Java in the early years was based on that. Appreciation for immutability, value objects, and transformation rather than mutation came from outside of Java. That's my experience and the experience of the people I've worked with: our understanding of the value of immutability and dumb data came from working in languages that demanded or at least strongly suggested it and had elegant affordances for it. If we worked exclusively in Java, we would have been much less likely to realize the value of an approach that seemed alien and awkward in our language of choice. (Eventually, due to popular demand, better language support was tacked onto Java, but I'm talking about 10+ years ago.) Every programmer should at least dabble in other languages and try to absorb the good big ideas from them, even if they ultimately put these ideas to work in "mainstream" languages.
- jstimpfle 4y ago
  Very much agree.

pharmakom 4y ago

I do not have a peer reviewed study to back up my claim. Sorry to disappoint. Which XKCD? I read the article but missed it.

jstimpfle 4y ago
Neither do I, but if I find the time I'll make one up to support my preferences. The XKCD: https://xkcd.com/568/ https://xkcd.com/568/
- bmacho 4y ago
  Is copilot a programming language?

Yoric 4y ago

> There are so many other easy ways to improving software quality. Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it? Also, for some issues and metrics, software quality is in fact limited in practice by the language used. Getting guarantees of certain properties is trivial in garbage-collected languages, near impossible in languages with manual memory management. Similarly, the lack buffer overruns and underruns, XSS exploits, properly following protocol, etc. are going to be trivial to guarantee in some languages, near impossible in others. Now, I fully understand that following the hype wagon (or listening to fanbois singing praise about the latest tech, whether it's a language or anything else) is annoying. But let's not confuse hype and using the right tool. The intersection between those is often rather small :)

jstimpfle 4y ago
> Well, yes, there are. But picking the right language for the task is one easy way to improve software quality, so why discard it? The language isn't all that important. The main problem is functional decisions that transcend the implementation language. It's not hugely important if I write this comment in English or French to get my point across, and that's why I'm writing it in English. Beyond the random internet post (or the rare one, like "Beating the Averages", which might well be exaggerated) I haven't seen any obvious competitive advantages from choosing a non-mainstream language. On the contrary, what you often see is that immature ecosystems are huge timesinks because a lot of stuff simply isn't "there" yet. That's not to say there aren't incremental improvements happening with new languages over time. But if your goal is to complete a project as opposed to evolving a language ecosystem I'd say that it's unwise to pick a non-mainstream language. Heck, I'm still using C for almost all of my projects (chances are I'd be using Java or C# if I was working in other domains). I've tried to switch - I have smaller and larger investments in a dozen languages. But no other language has stuck for me. A big reason for this inertia is that I simply know C well and I feel productive with it. But there are more objective qualities, some of which are related to it being mainstream and having a mature ecosystem. My language of choice has flaws, but they are well-known, with well-known workarounds. That lets me focus on the problem instead of the tools. Blog posts generally don't consider these qualities because they can't be discussed with toy examples that show you how you can neatly turn an isolated problem from 10 lines of C code into a 2-line fancy language solution. The problem with these examples is that they are not representative of longer-term and larger-scale software development.
- pjmlp 4y ago
  Even with my typical C rants, I absolutely support the idea of a project going with C if that is what it makes sense on the market they operate on. The additional effort to add tooling and workflows that most of the teams aren't comfortable with, extra effort implementing integration layers, might slow down delivery to the point of diminishing returns, thus withdrawing any advantage. So while I personally might not like it, in some scenarios that is exactly the tool to use. Same applies to other domains and whatever language might be the "to go option" there.

mlatu 4y ago

and why should everyone plow their fields like everyone else does? > "Stop wasting your time on programming languages" "stop trying to fasc us out of having fun while being productive!" is my reply. there are already enough people trying to improve software quality using rusty shears, let me use my fusion powered laser cutter if i want to!

jstimpfle 4y ago
You are free to plow your field whichever way you like, of course. Just step back once in a while and check whether you've done enough plowing last month - or spent all your time upgrading your plowing technology. In the end you just have to plow, and it doesn't matter all that much how you do it (as long as you use my preferred brand of course). Plowing tech isn't all there is to growing crop and vegetables. There is an awful lot more that you have to understand and plan and take care of, and upgrading your plowing tech won't help you with any of that.
- mlatu 4y ago
  i think you plowed the point into the ground

deleted 4y ago

[deleted]

dkarl 4y ago

The most productive people may program in mainstream languages like Java, but their programming is informed by exposure to a broader variety of languages than just the mainstream ones. To stick with Java as the example, Java was designed with a set of affordances for managing mutability, complex inheritance relationships, and objects with rich behavior, and the coding norms and "wisdom" surrounding Java in the early years was based on that. Appreciation for immutability, value objects, and transformation rather than mutation came from outside of Java. That's my experience and the experience of the people I've worked with: our understanding of the value of immutability and dumb data came from working in languages that demanded or at least strongly suggested it and had elegant affordances for it. If we worked exclusively in Java, we would have been much less likely to realize the value of an approach that seemed alien and awkward in our language of choice. (Eventually, due to popular demand, better language support was tacked onto Java, but I'm talking about 10+ years ago.) Every programmer should at least dabble in other languages and try to absorb the good big ideas from them, even if they ultimately put these ideas to work in "mainstream" languages.

jstimpfle 4y ago
Very much agree.