5 ms·

The point is to write bug-free code. Dynamic typing makes that harder (makes proving that harder). If you just focus on off-by-one array reads then you're focus

by kreetx 8y ago

The point is to write bug-free code. Dynamic typing makes that harder (makes proving that harder). If you just focus on off-by-one array reads then you're focusing on something that is already solved either by languages themselves, or tools around it that prove that the access is always ok. And there are also libraries that do bounds checking for you. But you still maintain memory access should you need it. (And, depending on the operating system, you can't actually read and write any memory - you get a segfault instead, which is perhaps the js explosion equivalent, no?) On the point about inconsistent state: if your JavaScript program is doing something important but then dies because of a bug then maybe the interpreter was left in a consistent state, yes, but what it was doing was not. This is safe how?

z3t4 8y ago
About inconsistent state, take an altitude meter for example, in an airplane setting, it's better if the altimeter restarts, then having it show the wrong value. For bug prevention I like defensive programming, checking for "impossible" conditions that should never happen. And always exit if the unforeseeable occurs. The most effective way to prevent bugs though is probably to keep that program small and comprehensible, and that's easier with a high level language. The static type checking is just one of many ways to prevent bugs. Personally I rather want the dynamic features. And I add checks at critical intersections, with human friendly errors. And do other automatic tests.
- 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 ago
    Actually, 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.

by kreetx 8y ago

z3t4 8y ago

About inconsistent state, take an altitude meter for example, in an airplane setting, it's better if the altimeter restarts, then having it show the wrong value. For bug prevention I like defensive programming, checking for "impossible" conditions that should never happen. And always exit if the unforeseeable occurs. The most effective way to prevent bugs though is probably to keep that program small and comprehensible, and that's easier with a high level language. The static type checking is just one of many ways to prevent bugs. Personally I rather want the dynamic features. And I add checks at critical intersections, with human friendly errors. And do other automatic tests.

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 ago
  Actually, 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.