4 ms·

> 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

by 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.
  - jstimpfle 4y ago
    Well some day we should meet for a beer :)
- pharmakom 4y ago
  > 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. I think this is the root of the disagreement. For my domain at least, I find it very hard to write robust software in some languages and fairly routine in others. Unfortunately the data on this topic is very limited - typically groups of college students implement something in various languages to compare. Hardly a realistic test. What I can point to are code constructs that I cannot make in certain languages where the work arounds are either more verbose or less precise.
  - jstimpfle 4y ago
    As I said I'd likely use a different language if working in a different domain (but then again I'm not). But you will be hard pressed to find a serious domain where there aren't solid mainstream tech choices. > What I can point to are code constructs that I cannot make in certain languages This is what I was alluding to, these examples are not very relevant. In a larger-scale codebase the important thing is the structure that you build, not the structure you get for free (or are being imposed) by the language. If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases. Functions and records (structs) are sufficient to cover you in almost all real world situations. I believe that the step up from assembly to higher-level languages is a very powerful step, because it frees you from doing a repetitive task again and again, that you can't even realistically do better than the compiler (because of time constraints), at least not on a large scale. Another reason that the step works is that what it automizes are quite local issues to solve. Barring extreme optimization requirements, we can simply come up with a function call ABI and have the compiler solve all register allocation for us. The tradeoffs and ramifications of this are quite clear - we can be confident by now that there are no unknown tradeoffs that will come haunt us later when the project has grown much bigger. The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Garbage collection is another big help automating the repetitive in some domains, but it gets in the way in other domains.

by Yoric 4y ago

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.
- jstimpfle 4y ago
  Well some day we should meet for a beer :)
pharmakom 4y ago
> 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. I think this is the root of the disagreement. For my domain at least, I find it very hard to write robust software in some languages and fairly routine in others. Unfortunately the data on this topic is very limited - typically groups of college students implement something in various languages to compare. Hardly a realistic test. What I can point to are code constructs that I cannot make in certain languages where the work arounds are either more verbose or less precise.
- jstimpfle 4y ago
  As I said I'd likely use a different language if working in a different domain (but then again I'm not). But you will be hard pressed to find a serious domain where there aren't solid mainstream tech choices. > What I can point to are code constructs that I cannot make in certain languages This is what I was alluding to, these examples are not very relevant. In a larger-scale codebase the important thing is the structure that you build, not the structure you get for free (or are being imposed) by the language. If you cannot say certain things easily, then write a function to factor the common stuff in a layer that you can then build upon. This is the basics of programming, and from what I've seen this is already where it fails in most real-world codebases. Functions and records (structs) are sufficient to cover you in almost all real world situations. I believe that the step up from assembly to higher-level languages is a very powerful step, because it frees you from doing a repetitive task again and again, that you can't even realistically do better than the compiler (because of time constraints), at least not on a large scale. Another reason that the step works is that what it automizes are quite local issues to solve. Barring extreme optimization requirements, we can simply come up with a function call ABI and have the compiler solve all register allocation for us. The tradeoffs and ramifications of this are quite clear - we can be confident by now that there are no unknown tradeoffs that will come haunt us later when the project has grown much bigger. The same step up will be hard to repeat, since functions and structs are so expressive already, it's rare to find a problem that can't be elegantly solved using them. Garbage collection is another big help automating the repetitive in some domains, but it gets in the way in other domains.