3 ms·

There are languages (sometimes a subset of an existing language, like C) where you can prove for a program that it has no bugs, or that it can function in a rea

by kreetx 8y ago

There are languages (sometimes a subset of an existing language, like C) where you can prove for a program that it has no bugs, or that it can function in a real-time context (i.e stays reactive to some frame rate at all situations). This is useful for very expensive hardware that you can't go and service later on. JavaScript can easily explode at run time, while these other languages won't even compile. JavaScript is small, but then again - you need to ship the interpreter. Not sure about maintainability either - static typing really helps with that. The safety you mention is that js runs in a sandbox (and e.g can't wipe your hard drive), but this is a feature of browsers, not the language itself. All in all I find it hard to believe they wrote any critical parts in js, and I'd also guess it's possible to replace the currently deployed scripts should they fail.

z3t4 8y ago
JavaScript types are very strict, and are checked at runtime, compared to at compile time. So you are less likely to get some random off by one bug in JavaScript then say C, which causes a bit flip somewhere and makes the rocket engines turn on, or what not. JavaScript "exploding" at runtime is great, it's much better then to continuing poisoning the state making weird stuff happen. JavaScript is however paying the price in performance, where a statically typed language can have 10x better performance.
- 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.
      - 8y ago

by kreetx 8y ago

z3t4 8y ago

JavaScript types are very strict, and are checked at runtime, compared to at compile time. So you are less likely to get some random off by one bug in JavaScript then say C, which causes a bit flip somewhere and makes the rocket engines turn on, or what not. JavaScript "exploding" at runtime is great, it's much better then to continuing poisoning the state making weird stuff happen. JavaScript is however paying the price in performance, where a statically typed language can have 10x better performance.

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.
    - 8y ago