fragbait65

I've been a technical advisor for several startups, I'd say that overall this advice is wrong.

Most startups stay in it way longer than they should.

I'm happy that things worked out in your example, but they generally don't. Mostly because founders reason with their feelings instead of applying logic, statistics and probabilities of success.

I don't agree. Deceiving and lying are two different things. You are describing somebody being deceptive.

You can deceive somebody and still be 100 % truthful.

Is that actually a good example of what you mean? There is no contradiction? The first statement does not say that Joe drove drunk?

Exactly!

I think I'll just write something similar and wrap Apache with a shell scrip, claim that it's a web server written in bash, post it here and see what reaction I get, just for shits and giggles.

It's not exactly the same though. Stolen cars does not have the potential to affect your daily day life as broken software can.

I agree that the blame does not lie on the engineers that created the cars or software though. In the end it's a problem of cost, you could write better software, but it would cost you time, money and shifted focus in the education of software developers and so on. Users are not willing to pay for that cost, they are very upset when reality bites them in the rear though...

I agree, Siberian cold due to changed flows of different currents seems more likely as the end result due to climate change for the Nordics rather than increased temperatures.

Increasing temperatures now does not equal increased temperatures later, when the system has stabilized again.

I'm not saying it will happen, just that it seems more likely with what the current data seems to imply, my current information is from some pop culture article though, so I'm the first one to agree that that information might be wrong.

My company that I work at actually closes bug reports that has been in "pending customer feedback" for more than 6 months automatically. The customer is free to re-open the issue at a later date if it's still an issue.

I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.

I think some incremental improvements could be done for C, question is if it's worth the time?

Maybe it's better to just use a better tool for new code bases?

I agree.

The difference is that engineering over all is mature enough that you can make incremental changes over time and it still does not invalidate what you did previously. If you built a bridge 10 years ago its probably safe enough to leave standing even if you can build a safer bridge today.

The same cannot be said for programming yet. It's hard to improve the safety of the tool, the C compiler, without breaking your past bridges or having to redo the work again, i.e rebuilding the bridge.

Well, I agree that you can wish that the tool was better designed, that's a whole different thing though.

What I meant to say, in a rather roundabout way to be fair, is that the problem is both the language and the programmers. C is a tool that is too hard to use correctly, but the programmers who write crappy C code are to blame for their crappy code. It's another thing if an expert fails to use the tool safely, then one might blame the design of the tool used.

There seems to be 2 camps, one camp blames C and one camp blame it on poor programmers. Poor programmers have given C a reputation and the tool itself is too hard to use correctly, even for experts, so both camps are right and also wrong...

I think some of the decisions made for C back in the day where fine, C was designed to be lightning fast and close to the metal, but I think it's time to pivot. I don't think it's necessary to sacrifice security to squeeze out the last percent of "speed" today. C has a lot of legacy code still in use though, so I don't think it will ever happen, that's why I use other languages for production code today and only write C when needed for C code bases still in use.

Well, I do think a programming language is a tool and it is kind of wrong to blame the tool for the mistakes made by the one wielding it.

The problem with C is that it's a tool where you have no safety and I don't think there's a programmer alive that can actually use it in a safe manner. I guess some are close, but they will still end up with the occasional wound here and there on their bodies...

I would probably avoid using C for anything I put in production today, I still love the language though. It still feels special, sitting down with all that power at your fingertips knowing that you'll have a built in buffer overflow if you lose focus for a second, gets (no pun intended) my blood flowing! :-)

Sounds a bit weird? Who signs an NDA at a job interview?

I agree, especially since a portion of the "new" movies are regurgitation of old classics anyway and more often than not weaker than the original movies.

Well, I can agree with that!

Chances are that your code base will be untestable, at least for unit testing, if unit testing where not considered at all when writing it.