codr4

I'm far from wizard on the topic, but from my experience it's not that simple since the relative magnitudes of the operands and the operator affect the size of the error in non obvious ways.

I spent 13 years maintaining a 2mloc reservation and accounting system that used floats for everything. By the time I got there and understood enough it was simply too late to do anything about it.

Just say no, really; that road leads to madness.

If you need precision; and many do; consider fixnums, rationals or bignums, in order of increasing complexity and flexibility.

If I remember correctly at least Alan Kay openly admits being very inspired by Lisp. Unfortunately the limitations/walled gardens they chose to impose in the name of simplification, everything is an object etc, had us running in circles for a long long time. My guess is it was picked up by managements for the same reasons as Cobol, Java, Go etc.

Mostly agree...

The reason it's not all about power/competition is that corruption is very easy to get into your system; be that individual, corporate or otherwise; and tricky as hell to weed out. Once you've been there and done that, the bar is set lower for relapse.

Do you know what the best predictor of future behavior is? They're acting all nice and friendly right now, wasn't always like that and there's no reason to assume it always will be. Even the catholic church is pretty chill these days, but give them enough power and they'll have people burning at stakes in no time.

I've been practicing Ving Tsun for around 25 years. Many aren't aware, but the most of the system is based on blades. The issue I've been having is finding good enough knives to train with. Most of the stuff out there is ornamental crap that will teach you the wrong thing best case and break and hurt someone if you're unlucky. I ended up getting two big, well balanced hunting knives that I've blunted for training.

I'm pretty sure I'll end up making my own sooner or later...

I didn't say that, I said that exceptions are used for exceptional problems. Expected errors like missing values are better handled using optional types. I find the one ring to rule them all attitude less than constructive.

Yep yep, sounds good.

Problem is you're not handling errors, you're wasting precious energy shuffling errors to code that knows how to handle it; which is exactly what exceptions could do for you. The end result is the same, except it takes more effort and the code looks like crap.

They are used for exceptional problems, expecting one doesn't really make any sense.

Of course you do, that's the point; to unwind the stack until you reach code that knows how to handle the error.

Cancer, really; is that you Gordon?

The standard library uses panic/recover to sort of implement exceptions here and there. It's a pretty serious case of do as I say, not as I do.

Do you see any problems with optimizing everything we do for junior developers? I mean, most of us aren't, and it would be really nice if someone gave a crap about wasting our lives as well.

They are not overlooked, they are better handled further up the call stack. And not having the option to forward them implicitly is a step back, not forward. There's no way to make a programming language better by forcing users to do anything, in many cases the user will have more experience than the person implementing the language. A programming language is a tool, predicting and dictating how the tool is to be used is missing the point.

Go's resistance to exceptions looks like Steve Jobs and his one button mouse from here. It's not like renaming them to panic/recover fooled anyone outside of the Pike reality distortion field. Sometimes unwinding the stack is exactly what you want. Optional types are nice too, but that's more for things that are intentionally missing. I have yet to see anything here that's an improvement over just doing the obvious thing.

Exactly like that.

Blindly trusting authority and walking over dead bodies to defend our ignorance hasn't been working for thousands of years, it's about time.