3 ms·
I think I see what you mean. I think it's the Erlang way of software developments: acknowledge that bugs are bound to happen, and if so then recover by restarti
by kreetx 8y ago
I think I see what you mean. I think it's the Erlang way of software developments: acknowledge that bugs are bound to happen, and if so then recover by restarting quickly, and have the other party (in a network setting) retry. If the restarter thing has no bugs, then I guess it's ok that way.
What I was pointing at more is that there are ways to prove for a program (even for C I've heard) that your program has no bugs, and also that whatever loop it has it always runs at some "Hz" level at most - which makes this a good fit for controlling something efficient in real-time. As far as JavaScript goes it seems it's mostly meant to run at the edge where it's fine to fail mid-way and where you have time to wait for a restart. How much time is enough time is, I guess, very dependent on what is being controlled, and perhaps for a telescope restarting is tolerable.
I write haskell these days and I can say that for the most part of the code I don't check anything since the type checker does it for me (once, at compile time). And if it compiles I can be fairly sure that there are no bugs. It's only at the edges where I talk to external APIs and/or parse json where I get errors and need to handle them in some way. There are of course bug sources left after types, but a huge part of it simply doesn't exist.
But I do understand how JavaScript can be a good choice if errors are tolerable, since it's fast to prototype in, and also, as a language it's easy to pick up, tons of resources online, plenty of developers who already know it etc. But I'd still maintain that safety isn't a property of the language itself, but more of the infrastructure it runs on.
- mikhanoid 8y agoActually, there are research on what percentage of bugs type system can catch. http://ttendency.cs.ucl.ac.uk/projects/type_study/ http://ttendency.cs.ucl.ac.uk/projects/type_study/ So, i don't think, that Haskell really helps not to introduce logical bugs. And, as to my experience with Haskell, such bugs really hard to detect (somebody else's code is hard to read; especially, if the code is based on categorical abstractions, not widely known, or on well known abstractions, but in pervasive ways), and harder to fix, because of the amount of code that should be rewritten. And of course, with Haskell there are always undetectable system errors, like consuming all of the system RAM by quite simple loops. There are no internal tools in the Haskell's semantics, to detect such situations, catch them and treat sanely. And usually strict type systems are bad in providing such a system reflection semantics to the languages. You always should fallback to some kind of external interpreter, like IO, which may be integrated in the language with extremely hard to detect errors. See, for instance, the bugs in FSCQ http://css.csail.mit.edu/fscq/ http://css.csail.mit.edu/fscq/ So, Haskell, i think, is not the best choice for spacecraft programming. And one should not rely only on the type systems and verification (remember Arian 4 or Deep Space One stories). You always need to test exhaustively. But if so, why not to use simpler language? At least it might have less bugs in its interpreter/compiler.