quasit1

I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway.

If it's too slow, then you probably have an issue with which algorithm/data structure you chose and would have had the same issue in another language.

The biggest issue I have with C today is that you can't trust that your compiler actually generates code that is 1:1 with what you wrote. I'm not talking about UB here, your compiler can actually remove code/checks even though you don't invoke UB.

Then we have UB, I think UB should be removed from the spec completely. There probably was a point in time when leaving stuff as UB was the best option, but today speed is seldom the problem, correctness is.

I no longer work as a C programmer, but I still love the language and I really enjoy writing C code, but I really would like to get rid of UB and have a compiler I can trust to generate code even when I turn on optimizations, and having optimizations off is not an option either, since it can generate broken code as well, so...

I agree, I have worked at 3 different places that implemented demo-driven development. It always looks good the first couple of weeks or even months, but then it goes down hill, just as you describe.

So much important work is not really possible to demo in a way that most people understand or see the gain it gives either.

I think, from previous experience, that demo-driven development sort of works if you are a company or project in the start up phase, because there are a lot of stuff to demo and the development goup(s) can get quite a boost from the excitement it generates.

I've worked in such places. The reason it is that way is because you will receive a broken description/specification/story of what you are supposed to implement. You have a choice to make when that happens, you either implement it as specified or you reject it because it is broken. The problem is that if you do reject it then it will take about 6 months to get back a specification that is broken in another way and then you have to make the same choice...

So after a few iterations you just say "fuck it" and implement it as specified and then hope that you get a chance to fix it before shipping it (or that it doesn't become your headache later on...).

I feel as if it depends a lot on the code.

I sometimes read code for fun. Some code read like an essay, some like a book and other code read like a collection of poetry. So I feel as if all 3 can apply, sometimes some of them at the same time.