| > > The city I live in now has many bike paths, completely separate from major roads. > Which wasn't the point of that at all. It was to point out that you[r] assessment of how much time is wasted working around problems in each case is irrelevant given your vastly different experience levels. That was almost my exact point, and it's odd you're repeating it back to me. I guess I could've laid it out more plainly. > [Metaphors] Driving it into irrelevancy through focusing on minutiae is a useful rhetorical trick. [...] at the extreme end if done purposefully is not acting in good faith Using a metaphor is a rhetorical trick. If you want to explain something to a non-technical audience, maybe analogies "get the hay down to the horses" so they can have at least a limited understanding. However, we both seem to understand programming languages so talking about roads obfuscates the discussion, leaving me to wonder whether there really is a parallel between the two topics. I know more about programming languages than I do about bike paths. > Depending on the segfault? I could. It would take me a lot of work, because it's been nearly 15 years since I paid much attention to that, but I have done it before. Even if I offer to run malicious data, it sounds to me like a low probability event - probably lower than my being in an airplane crash or shot by a cop. It's not something I should fear today. Over the last 25 years, I've had lots of segfaults, but I think I've done the most damage by accidentally overwriting files. I'm a little afraid of that. > No, you don't optimize your life around them, but you might also support checking of identities on international flights to prevent access to your nation from known terrorists. No, I definitely would not. It's very easy to get into this country, and an organized (dangerous) group would have no more difficulty than the drug dealers do smuggling cocaine. There is no benefit to harassing millions of citizens if you can't actually stop the problem. > Here's the thing. It's not about you. Are you suggesting the only people allowed to share their experiences in a thread like this are new programmers and the people pushing their language? I was new once, and I survived lots and lots of segfaults. Don't you think neophytes should hear that? They're definitely getting a large dose of doom and gloom about the bad old days. > Some percentage of C and C++ programmers are neophytes. [...] I think that reducing this has such a large impact, that this is of vast benefit to society at large (given the botnets we are currently seeing), and would total billions of dollars. In one of your other comments, you indicated you haven't tried Rust yet. You should - you sound interested. It definitely has its nice parts. However, I don't think you will find the safety features to be a big productivity gain, and you will have to use unsafe code to accomplish tasks from a freshman level computer science book. Think about that - you can't cleanly use the safe subset of Rust to teach computer science to beginners... (you could do it with a lot of compromises) |
Rhetorical tricks can be used to deepen the conversation, or to dismiss points out of hand. The first is useful to the discussion, the second is useful for winning, but at the detriment to the discussion.
> However, we both seem to understand programming languages so talking about roads obfuscates the discussion
I provided a example where it may provide value even if two people are experts in the area being discussed. Metaphors can help explain someone underlying reasoning and motivation in a way that is hard to express technically. People talk past each other enough in discussions by slightly misinterpreting what is trying to be expressed, that I find metaphors a valuable tool. I find many disagreements in text are rooted in people assuming a comment is countering a point of their or someone the agree with, and interpreting it in that light when often they are saying very close to the same thing. Thus I believe expressing a point in multiple ways, even if it's through metaphor, to have merit.
> Even if I offer to run malicious data, it sounds to me like a low probability event - probably lower than my being in an airplane crash or shot by a cop.
First, airplane crashes are extremely rare. Second, being shot by a cop is rare too, depending on your vocation and behavior. Third, remote code execution exploits are not rare, given the relatively small amount of public facing software compared to airplane flights an all police interactions.[1] Were you to author or contribute to any non-trivial size C or C++ project that was publicly available, I would put better than even money on there being an exploit findable in it. There's a vast difference in how much software is written to how much is public facing, but that doesn't mean things that were originally private don't sometimes make their way public years later, for example internal libraries that a company open sources or even just includes in another project that ends up being public facing.
> No, I definitely would not. It's very easy to get into this country, and an organized (dangerous) group would have no more difficulty than the drug dealers do smuggling cocaine. There is no benefit to harassing millions of citizens if you can't actually stop the problem.
So, again, because you can render a metaphor in more detail to make it irrelevant in context doesn't mean that's appropriate. So, in more generic terms, "do you support keeping known detrimental people out of a defined area to facilitate the usefulness of that area"? If can can do so, and it's not to cumbersome on those that are not detrimental, depending on the problems caused by the people in question, at some point it becomes worth it. There are parallels that can be drawn here, if you're willing to entertain the thought. It appears you aren't.
> Are you suggesting the only people allowed to share their experiences in a thread like this are new programmers and the people pushing their language?
No, I'm expressing that a single person't ability to avoid negative behavior has little bearing in an argument regarding community norms and herd behavior, which is what I'm getting at. Whether you are a perfect programmer and never make a single mistake in any language you use doesn't matter when discussing the merits of enforced safety in general as in this discussion regarding C and C++. What does matter is whether other programmers in general do, and what percentage of them, which you've also made a point of expressing. I think that is worth discussing, because I think we either disagree on the proportion of those programmers that can code with adequate safety, or some other facet of them that results in them yielding far more problematic code every year than you think they are producing.
> In one of your other comments, you indicated you haven't tried Rust yet.
I've tried it. I haven't done more than dabble though, while playing it futures-rs. I understand the borrow checker is cumbersome at my level of uncerstanding, and I fought with it. I don't think I have sufficient experience to make an assessment of the language personally based on my level of experience with it, and especially not with how it feels to write in comparison to C or C++, because I strive to avoid using those languages.
> However, I don't think you will find the safety features to be a big productivity gain, and you will have to use unsafe code to accomplish tasks from a freshman level computer science book.
I believe have the ability to define safe and unsafe portions of code is in itself laudable and useful. Allowing me to categorize possibly problematic portions of code is a benefit. In any case, I could essentially write the entire program in an unsafe block and have a C/C++ alike with a different syntax. I'm not sure how "unsafe" can be presented as a downside, when it's strictly a way to enforce separation of a feature that C and C++ don't have.
> Think about that - you can't cleanly use the safe subset of Rust to teach computer science to beginners... (you could do it a lot of compromises)
What, you can't use that explicit separation of what is known safe and known unsafe to point out computational problems and ways they can be solved? I find that hard to believe. Unless you think unsafe is Rust but "lesser, not really". It isn't. It's part of the language. It exists as a concession that sometimes things are needed that can't be proven safe by the compiler, but you may be able to prove to yourself it is.
1: https://www.exploit-db.com/remote/