No one write fail-safe code because "it's hard".

It actually is hard. No need for quotes.

A former colleague of mine always asked me why I wrote code that failed so eagerly. Why didn't I write code that handled errors like him? Well, I found his manner of error handling likely to cause more problems in the long run. Often, it could allow code to continue running after recovering from an error. But I always worried that the internal state of the program would be changed in unexpected ways, causing unexpected results. I prefer to bring the whole system down than catch() an unknown exception and just keep running, potentially hiding a real problem.

That guy was in the habit of writing SafeSomething() methods that did the same as Something(), but he claimed they would never cause a system to fail. In fact, he was so confident, that he bet me a free lunch for every way I could find to make an application crash originate inside of those functions.

I got a few lunches out of it. There are a lot of ways to crash an application beyond regular out of bounds and null reference exceptions. Heap overflows, stack overflows, and all manner of other nastiness can strike too. It's seriously difficult to write a system that continues to operate under any circumstances. That's the domain of NASA and pacemakers.

Yawn? Have some coffee.

HTML isn't the only language without a compiler. I didn't say all languages without compilers are programming languages. I said a language doesn't need a compiler to be a programming language.

I'm not seeing a connection between your argument and anything I said. By your argument, ruby is not a programming language, and that's a pretty unusual point of view.

afaik, that's never been part of the commonly understood definition. I got my degree at about the same time.

https://en.wikipedia.org/wiki/Programming_language#Definitions

https://en.wikipedia.org/wiki/Interpreter_(computing)

Compilation is not a necessary criteria for programming languages.

This page doesn't have anything to do with github. Put away your pitchforks.

I'd put these methods inside the associated classes. There are arguments both ways, but my primary reason is simple: They're more easy to find there.

Without COBOL you wouldn't have the finance industry.

No. Without taking away anything from the achievements of COBOL, this is a blatant exaggeration. Without COBOL, the finance industry would have maybe been delayed slightly, and might have used a different language.