> more burden is placed on me, the developer. Which means I have to work more slowly, cautiously, and remember things that a good type system could have been checking for me.
Very interesting. You cite these as drawbacks, and I consider them all to be advantages.
Which just proves the point!
> I suspect these preferences are irreconcilable.
I think you're right. Fortunately, they are only preferences and so aren't incredibly meaningful. I prefer C, but most of my professional work isn't in C. And I don't always choose C for any given project.
Every language has its own advantages and disadvantages, so I select the language for a project keeping in mind which one mesh best with the project at hand.
> You cite these as drawbacks, and I consider them all to be advantages.
Why would they be advantages? Working more slowly and cautiously might be advantageous in some cases, but being forced to do so because otherwise your program might die a horrible death seems hard to justify as advantageous. Unless you're treating it as a sort of extreme sport, like rock climbing without a rope.
It may not be stressful for you, but it ends up being stressful for anyone who has to rely on the resulting programs. When they have a security issue due to a buffer overflow, or a crash due to a null pointer error, etc.
The "just trust me bro" school of programming is not suitable for delivering serious systems.
if you can't write code without buffer overflows, how are you going to write code that is accurate on any of a number of other dimensions? You need to do things the right number of times, if you don't, you get the wrong answer. I agree that security vulns are bad bad, but correctness is also a good thing, and getting things right is not a "nice to have" skill.
> The idea that it's impossible to write good, solid programs in any given language is ridiculous.
The data disagrees. There's plenty of evidence that the severity of bugs and the number and severity of security bugs is far higher in languages like C or C++ than in memory-safe languages.
> Only if you're writing bad programs.
This is precisely the "just trust me bro" mentality I was referring to.
"I write good programs, I swear!"
But you're human, and you really don't. You make mistakes. Empirically, you make roughly as many mistakes per line as
programmers in other languages, but the consequences of those mistakes are worse.
You can argue with me all you want, but you're essentially arguing with reality. C has survived for legacy reasons, but almost everyone is desperate for a better, more robust alternative.
Just so you know where I'm coming from - I learned C in the early 80s, not long after learning Fortran. I later started using C++ because it seemed to offer some benefits. But now - more than forty years later, when there are so many better alternatives for any given problem except one which requires legacy integration - it's astonishing to me that people are still staunchly defending C.
It reminds me of what Max Planck said about physics:
> “A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents die, and a new generation grows up that is familiar with it.”
Because working slowly and rewriting code typically leads to better code. By taking it slowly you grow more familiar with what you want, it gives you more time to think, and its generally more enjoyable.
This culture of “fast coding” is a major reason software ends up so flawed. People are so enamored with quantity they completely forget quality along the way. And that means everyone suffers.
You didn’t actually address the point I raised about why C is hard to justify for that reason.
Besides, a strong type system also forces you to think about the design of your code, and demonstrably leads to more reliable results, on an industry-wide basis.
Except the forcing function in C occurs because if you make a mistake, you can have serious problems at runtime. With a strong type system, if you make a mistake, your program won't compile. It's a big difference, and it's hard to justify the C approach for reliable systems development in a modern context. No-one in this thread even seems to be trying.
If you want to use it for hobby projects because you enjoy it, knock yourself out. But advocating its use for anything important hasn't been viable for decades except for legacy reasons.
It is! And there is absolutely a role for strongly typed languages.
> But advocating its use for anything important hasn't been viable for decades except for legacy reasons.
We entirely disagree here.
The big benefit of more stringent languages is that they require less effort on the part of the programmer to ensure safety and correctness. This is of great value -- perhaps even indispensable -- in certain contexts. For instance, if the programming team is large, or if the company wants to hire less experienced developers, or if the company wants to keep up a very high velocity.
But those are economic arguments. It's different than asserting that a given language is simple too dangerous to use under any circumstance. I think that assertion is entirely unsupportable.
Very interesting. You cite these as drawbacks, and I consider them all to be advantages.
Which just proves the point!
> I suspect these preferences are irreconcilable.
I think you're right. Fortunately, they are only preferences and so aren't incredibly meaningful. I prefer C, but most of my professional work isn't in C. And I don't always choose C for any given project.
Every language has its own advantages and disadvantages, so I select the language for a project keeping in mind which one mesh best with the project at hand.