Reply to post: Re: Is it just me ...

Re: Is it just me ...

I'll grant you all of that. The problem, then, is that most of the core stuff, on which we rely, which is developed by many people who have experience, but evidently not enough, is not "well written".

Has bugs is not the same as not well written, now you are misrepresenting the point.

How well or how bad the average bit of code is is not really a language issue, it's more to do with experience and tooling. Chronically underesource projects don't have the resource to spend on release engineering, is a little closer.

We can't fix this problem by telling all the developers of libcrypt that they're rubbish and need retraining. They will ignore us.

As well they should, the answer is to simply run tests including AFL. valgrind etc as part of the build. Not switch language to the still unnamed bug free future that awaits us, once we free ourselves from the shackles of being tied to a standardized portable language and use ?

The electricity analogy is continuing to make my point for me. I made a point about safe or unsafe plug sockets. You countered that a different part of the system can also be risky, changing the subject.

In point of fact I made the analogy that you need to know what you are doing.

I said

"My electricity supply is sufficient to kill me, it's not the fault of the installation if I defeat the safety interlocks.

. You decided that "safety interlocks" meant plugs, I'm guessing not being that aware that a Ring Final Circuits are a little nutty and that the UK is the only user of them, it's special as your contention that the "plug socket" helps is exactly what's wrong with the debate about rust.

The socket protects your appliance, the wires protect your house. It's not a different part of the system, if your wires endup burning the house down, the socket is hosed anyway, but I countered by proving that safer sockets didn't absolve you from the consequences of failure to understand the correct method of safe usage, or mean that your professional is still 100% responsible for detecting your dangerous solution by means of appropriate testing.

Similarly, you have successfully pointed out that you can get vulnerabilities in languages other than C, which nobody argued against.

Implicit in the thread and the article, that using another language, rather than using professional practises and test equipment, is the way to go.

It's hard to see that the premise is not being argued.

Security requires good practice in coding, and it especially requires it in C because bad practice in C leads more often to security vulnerabilities whereas bad practice in other languages leads more often to crashes.

And you've decided this is better because? It seems like bad practise is statically detectable in C and C++ and not detectable in "other languages".

You can still get security vulnerabilities in those languages. If we removed C tomorrow, we wouldn't solve security. However, that point is not in itself a cogent argument for keeping C

Again, we don't need an argument for keeping it, you need an argument for removing it, you've yet to make one, that stands up to minor examination.

Java, Ruby, Perl, Python, Erlang, Haskell written in C. Seems like managed to get working code out the door..

Such arguments exist, and they're convincing, but you're not making one. You are not defending C. You are not really even attacking anything else.

I don't need to defend it, as you have no case. A it's the alternative to assembler, you've not addressed this at all.

B for higher level code you should be using C++ with scripting languages.

So the use case for C is between Assembler and C++, and neither you nor anyone else has said a word about how the meaningful usecases are met in that arena.

I've posted code in C, what exactly makes that code so hard to write, or maintain?

It's fairly pythonic and frankly it could be ported to a scripting language easily enough.

You're just trying to change the subject to point out that I can't get perfection and hard work is required to approach it. Which is correct and beside the point.

It's not about perfection, but pragmatism. There a lot of shit code out there, if people insist in doing application programming in system programming languages, I don't see why I have to care.

I know a wide community of C and C++ users, they don't have these problems, perhaps it's that they know what they are doing, or maybe they are just lucky.

I don't see how tab and space swapping round which breaks my python is an advance.

Or really what you are advocating other than don't use C, but all and any other issue with any other language is just fine, because the bar is lower.

C and C++ are going nowhere, the last time this discussion came up, it was Java, then it was Golang, now it's rust. I wonder what we'll be ignoring next..