Hacker News .hnnew | past | comments | ask | show | jobs | submit | Mawr's commentslogin

Says you, while sitting comfortably on a couch sipping coffee, with zero risk of death, able to take as much time as you'd like to analyze the situation, with perfect information available and a fresh, unstressed mind.

Everybody's got a plan until they get punched in the face. Bravado and macho mindset are explicitly frowned upon in aviation for a reason.

Reminds me of "aviation experts" claiming Sulley didn't have to ditch in the Hudson at all, since some pilots in the simulator were later able to turn around and land back at the airport.

Sure they were! I'd be able to do so too, and I'm no pilot — I'm safe in a simulator, I already know I'm going to have a double engine failure x seconds after takeoff, and I get to try to land an infinite amount of times until I get it right. Easy peasy.

Things look a bit different when it's your ass in the seat and you lose both engines on a random takeoff.

They also look different when you're subjected to massive G forces, your plane isn't listening to your inputs, the computer is shouting erratic warnings at you, you're rapidly losing altitude, and your training didn't cover this scenario.


Other than writing a lot about obvious things, what is your actual point?

If you want to have something or someone to blame then all of it. However, you want future flights to become safer, then none. Make your pick.

Your response is very human, but also deeply irrational. In practical terms of safety it is irrelevant if the pilot is to blame or not or to what degree.

All we should want to do is analyze the reasons why the crash happened and adjust the aviation safety system such that it never happens again.

If pilot actions contributed, then we must ask why and how exactly, then fix those factors through better airplane design and pilot training.

Just blaming someone, then moving on may make you feel good inside, but does nothing to improve safety.

> This is flying 101.

>

> How poorly trained in basic airmanship were they and how were they allowed to be pilots?

Thoughts like these about three experienced professional pilots should make you do at least a double take. It is far more likely that you're dead wrong than that those pilots were so incompetent they didn't even know the basics.


> It baffles me again and again how people can just dismiss these things.

Because risk is relative, and not as you seem to think, absolute and binary.

The risks are being dismissed because they're so tiny, that they're irrelevant. You may as well start planning your life around the assumption you'll win the lottery.

That's why nuclear waste storage is such a common fear mongering tactic, it exploits the human liability of not understanding long-term statistics very well.

Even solar power is more dangerous due to people falling off roofs and such. Same with wind power. And don't get me started on dams. When those fail, people die.

And that's renewables. We're stil mostly burning fossil fuels and dumping the waste products into the atmosphere we all breathe.

Yes, we are literally, as we speak, doing that.

And you're talking about the massive problem of storing some barrels of solid waste.

You're off base in your perception of risk by several orders of magnitude.


First of all I never said these things you claim. I literally said "ignoring these risks is BAD", not that they are absolutely too great or whatever. That must be evaluated per case.

However there are numerous nuclear disasters in recent history that show, that we were not so good at estimating the risk.

Yes other things can also be dangerous or deadly. But when a dam breaks people die. What doesn't happen is that the region is unusable for eternity afterwards. So nuclear disasters are a very special case.


> However there are numerous nuclear disasters in recent history that show, that we were not so good at estimating the risk.

The only "recent" one I can think of is Fukushima Daiichi, a little more than fifteen years ago. That one definitely had a couple-dozen injuries at and around the time of the disaster and maybe one death four years later. Compare that to the tens of thousands killed and many thousands injured because of the tsunami and earthquake that damaged the fission plant.

What other ones do you consider to be recent? Do make sure to mention the year in which they happened as well as reasonable guesses at the death and injury numbers for each incident.

(I'll refrain from more than a brief mention of the century+-long ongoing disaster that is fossil-fuel-fired [0] power generation.)


> I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me.

Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling.

Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software.

The tradeoffs are super simple here - exceptions require very little of your input but lead to terrible spaghetti due to hidden control flow. Explicit error returns are seemingly the opposite, but their verbosity issues have mostly gone away thanks to modern language improvements, so they're just better, unless you're writing short scripts and the like.

The situation is very similar to static vs dynamic typing - dynamic typing used to make a lot of sense in the days of extremely verbose Java type declarations, but modern static type systems with inference have made dynamic typing basically obsolete.

> That said, the typical performance complaints made against the most common implementations of exceptions are valid.

This also sounds off and outdated to me. If anything, exceptions typically have better performance, so long as errors aren't common. Indeed, if optimized correctly, exceptions have zero cost if not thrown, which can get you better perf than error returns, which have a low, but constant cost.


Can you point me to a language that encodes the handling of errors in a less verbose way than C++/Java/C# exception handling?

I used a hard drive for a few applications several years ago. One time, the drive got corrupted and all the data was lost. That was the day I stopped using hard drives.


This isn't the same and you know it.


Cool collection of self driving edge cases, thanks. How are any of them related to Waymo using or not using a particular sensor, LIDAR or otherwise?


You're arguing based on pure hypotheticals.

> Nuclear reactors are inherently a very risky business,

Well, let me introduce you to airplanes — flying is inherently risky, and so many people have died on commercial flights. We should abolish it immediately!

> The fact that a Fukushima-scale nuclear disaster can happen at all is a major cause for concern.

Maybe. I'm more concerned about coal plants that are, as we speak, dumping metric tons of harmful materials, including radioactive ones, into the atmosphere we all breathe, which causes approximately 100_000 people to die each year.

These are real things happening right now, not some hypothetical problems that may happen, but haven't in the last 60 years of commercial nuclear reactor operations.

Seriously, all you can cling to are what, 2-3 major accidents in all this time? With negligible death tolls? Please. This is just concern trolling.


Hmm well, we have some "smart traffic lights" where I live that are always red unless a vehicle goes over a metal detecting loop under the road in front of them. Guess how well that works for any vehicle that's not a car.

Rules of the road are generally designed in the same way — for cars. Nobody cares about carving out obvious exceptions for bikes, like the Idaho stop.


Well, if you genuinely find it interesting, I can explain why they don't:

1. Cyclists live and die by inertia. Getting up to speed on a bike requires a lot of effort and every application of brakes erases that spent effort, which feels really bad.

In a car, it doesn't matter — you stop and accelerate with exactly the same trivial effort of pressing a pedal.

So all the grandstanding that cars stop at stop signs (since when, but ok), and cyclists don't is like bragging that you beat a disabled person in a 100m sprint. Good job, I guess.

2. Stop signs and traffic lights are made for cars, because of their speed, how dangerous they are, and how bad their visibility is. Cyclists are like pedestrians in that they do not need traffic lights, they can navigate just fine with just body language.

Telling whether running a red light would be safe in a car is essentially impossible, you're going too fast and can't see much, can't hear anything either. But on a bike you have perfect visibility, there's no box of metal all around you. You can hear quite well too.

Stop signs are an even better example. Literally the only reason for their use instead of yield signs is that the visibility at the intersection is bad enough that you need to stop to be able to yield. But that is only the case because your visibility is so bad in the first place.

Stop signs literally never make sense for bikes — there's no "hood", so your head is basically where the vehicle starts and you can lean forward to make that literally true if really needed, and you've got perfect visibility all around, no blind spots.

Hence why in a lot of places cyclists can legally treat red lights like stop signs and stop signs like yield signs.


As a general rule, the the frequency illusion[1] and the negativity bias[2] are a thing and combined make shallow, single-datapoint arguments like yours instantly invalid.

[1]: "The frequency illusion is a cognitive bias in which a person notices a specific concept, word, or product more frequently after recently becoming aware of it."

[2]: "The negativity bias, is a cognitive bias that human cognition is relatively more affected by a negative affect than an equally potent positive affect."


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: