Hacker News Reader

Comment by hasbroslasher | Hacker News Reader

I'm not really following. If it works then why not use a control loop on top of Python? We are engineers, after all.

View on HN

Because by "works" you mean "I tried it out a bunch of times and nothing bad happened, so must be production ready", because that's what you do when you build websites and desktop CRUD apps and nobody ever died cause the web server choked under load or the web page rendered a bit funny or the request took a full quarter second because the GC kicked off as a wave of requests came in.

And then one day a one-in-ten-million event that never would've surfaced during testing does happen and the OS crashes or the interpreter hangs or some non-determinism causes a period of non-responsiveness or a bit gets mangled because you don't have any redundancies and solar rays are thing or ... and someone dies. And of course that didn't happen in testing, because all of those things are rare possibilities.

And then it happens again.

And again.

And then you're in court being sued for millions. And a bunch of industry experts who do build their systems with redundancies and do design their systems with a safety-first mindset come to the stand and rip you apart for not taking even the most basic precautions. And when it comes out just how many best practices you completely ignored, you're mostly just hoping beyond hope that all of the legal problems stay on the civil side of the civil/criminal divide.

Or, to say it in a sentence, "because the sort of exceptional circumstances that safety-critical software needs to handle with grace are very difficult or impossible to account for with a desktop machine running interpreted code on top of Linux."

I like that you reduced that to a one-liner, and I understand your point. I sure as hell wouldn't hook my car up to this software.

But I also feel like you're being a bit hasty. Obviously a Python script isn't going to turn into a Tesla overnight. But maybe it'll help you find a few bugs before you throw all that time and effort into building the real deal. When I look at a Github repo that claims to be a self-driving car I don't say to myself "yep, looks production ready," I say "Cool prototype, now let's break it." To me it seems entirely reasonable to get a working Python prototype 90% of the way there and then send it off to the OS programmers to design something that actually meets the concept of "production ready".

Yes, I absolutely agree with you on that. Nothing wrong with prototyping in whatever setting is most convenient.

I think w/ self-driving cars there is an interesting ethical question. The full auto cars on the roads today definitely aren't production ready, but they also have constant safety drivers. Probably even ACC systems are tested in the wild with a safety driver before production.

Basically, "is the safety driver sufficient to justify running prototype software in the real world?"

Yeah, that's a tough question that we as a society will have to wrestle with. Knowing that humans are imperfect drivers as well doesn't make it any easier. Even cars today have crippling safety flaws -- remember that one Lexus model that had a sticky gas pedal? Or worse yet, the Ford Pinto. I'm genuinely interested to see how the governments of the world weigh in on this, if at all.

Intuitively, though, I think that buying/using the software is tantamount to accepting its imperfections, so long as they are adequately (factually) presented to you beforehand. You're signing off your ability to make your own decisions, but are still responsible for them.

You have a lot of solid points, but note that Linux is currently being used by SpaceX in an even more safety-critical aerospace setting.

Also note that interpreters have their place in safety-critical aerospace as well: some satellites run Forth.

> You have a lot of solid points, but note that Linux is currently being used by SpaceX in an even more safety-critical aerospace setting

I disagree with the 'more' - how many lives are at risk with a SpaceX failure vs. a self-driving car failure? This is even without multiplying by number of users.

There are few things more destructive than a serious spacecraft crash.

You are really going to freak out when you learn how deep neural networks work.

I know how DNNs work -- I've even designed my own.

The existence of a component that is difficult to analyze for safety doesn't justify ignoring well-established safety engineering techniques throughout the rest of the system. That attitude would have us throw out seat belts and snow tires just because the ACC system might be buggy sometimes.

The thing that distinguishes an engineer from a bodger is not just observing what works but understanding why, how, and to what margin of safety it works.

The reason the "realtime" designation exists at all is that, in a realtime system, it is possible to say what the worst-case timing is for any operation, and to guarantee by design what failure conditions can and cannot happen.

You cannot guarantee in a python program the timing of your GC. You can't even guarantee that the whole thing won't fall over with an exception.

And we've already had this problem with the Toyota "unintended acceleration" bug, in the (far simpler) electronic throttle system: https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... - and that was using C, but not in an appropriate style (MISRA or similar).

(89 dead, cost Toyota billions)

Believe it or not - many folks coding out there don't even understand the meaning "real time" in this designation. I recall asking some colleagues in a conversation, "So when you say 'real time' do you mean hard or soft?" To which they replied, "Just, real time, like in real time." I gave up pressing the point when I realized they simply meant "interactive" and didn't know such a designation existed.

Hard real time is really only applicable when designing critical systems. Unless your anecdotal conversation was about one of those systems, it's pedantic to not simply infer soft/firm real time.

I agree. And yes though that is inferrable from my anecdote, in fact I wasn't being pedantic. I actually probably used the terminology wrong myself, but all I really meant was, "what are your latency requirements in this system? How real time?" It was a conversational confusion because they kept using the term and I thought they were using it technically. When I realized they weren't, I didn't bother trying to correct them...

[edit] I'll add this conversation stuck out in my mind simply because I was a bit surprised that no one knew what I was talking about, that's all.

Python uses reference counting. The garbage collector is only required for cyclic references and can be disabled.

The C code was a byproduct of some higher end framework isn't it ? (Still doesn't forgive the stupid errors that went into but..)

This comment shield should not have been downvoted. Downvoting should be reserved for off topic comments. Someone who is confused and brave enough to ask a question should not be discouraged through downvoting.

The question is naive and has a dangerously ignorant view of what "engineering" means. But it has been properly and usefully answered by others.

(sorry for a meta comment rather than a substantive response, but I feel strongly about this).

This is research code, not product code. I wouldn't recommend shipping a consumer product with your PID loops in Python.

you could easily starve a process or thread whose purpose is to stop your car in an emergency over a long enough period of time to cause the occupants harm. I haven't dug into the code so I don't know exactly how this software uses processes and threads (you could have one process no threads and crank down nice on the process) but considering this and GC in python I would not feel confident that this system will always respond quickly enough to emergency scenarios.

Reply on news.ycombinator.com