4 ms·

> what would be called a modern statically typed system? Now we are splitting hairs and looking for the one true scotsman. You asked for quantitative evidence,

by srean 12y ago

> what would be called a modern statically typed system? Now we are splitting hairs and looking for the one true scotsman. You asked for quantitative evidence, but the problem is that you have already made up your mind (perhaps only subconciously) and you will find a way to lookaway from the evidence or logic (which you term just an appeal). Lookup birthers for instance. I for one have'nt heard of any flight control or life support software written in a dynamically typed language, whereas have heard of plenty written in what would qualify more as a statically typed than dynamically typed language. ADA in particular comes to mind. I dont discount that there might exist some written in a dynamic languages. Lets agree that they are quite hard to find. I wont be surprised with prototypes written in dynamic languages though. > I wouldn't be surprised to find some lisp in there, [...] I'm open to being proven wrong. Now that would be the Russel's teapot fallacy. I am not ruling it out, but for such assertions, the burden, I think, lies on the one making the assertion. You handed out an epistemic sucker punch there. The proof that you desire requires presenting the entire set of Lisp programs, or the entire set of flight control programs, both are quite ridiculous. BTW I do love lisp a whole freaking lot. Curious about this: Say you have to be (god forbid) irradiated. There are two pieces of software written by two groups, one that uses statically typed, another that uses dynamically typed and this is all the information you have. Which one would you pick ? There is no right or wrong answer. I will pick the one written by the group that uses statically typed language because of their cultural obsession with correctness. That is just a Bayesian prior, there are exceptions of course. Sqlite is indeed afflicted by the same obsession. EDIT: @taeric > If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done. Ah! then lookup ADA's resume > I'd pick the one that has the better track record and has been proven with more tests. You are dodging the (silly) question sir :) I said thats the only thing you know. Anyways wasnt an important question and here's wishing that you never need to get irradiated with any such thing, seriously.

taeric 12y ago
I'm not trying to play the scotsman's game. Though, I can confess that that is the direction I am somewhat steering this. Not my main goal. My aim is more against the claims of the parent post. Note that there is a big difference between static tooling and statically typed languages. I have high regard for the both. And I've seen more evidence of the former in older, less statically typed, languages than I have the latter. So, part of my point is I haven't ever "heard" what language those systems are written in, period. It isn't that I have heard they are in dynamic or static languages. I flat out never hear. If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done. I do know that the older languaged programs I have seen are typically not in what one would call a statically typed language. There is plenty of static tooling on them, but to pretend that there is statically "typed" tooling around any software that ran something such as the space program feels like it is reaching. Heavily. So, to your silly question. I'd pick the one that has the better track record and has been proven with more tests. I don't care if they are dynamic tests, statically typed assertions, statically analyzed assertions on a dynamically typed codebase, whatever. There are too many tools to care. Because I can hazard a guess that all of the things that have irradiated me in my years have not been by the strongest statically typed languages out there. :)
taeric 12y ago
:( Why are we replying without going down the chain? I almost didn't even see you put more of a response to me. Regardless, I'm familiar with Ada. I'm also familiar with some fun disasters using software by Ada.[1] Now, do I blame that it was in Ada? No. However, the attitude you are displaying of "if all you know is it was in Ada, then it is safer than the alternatives" seems to be the exact problem that led to that disaster. If the only thing I know of two irradiation devices is one was statically typed and the other wasn't, I'd likely pass on both. Or I'd like to know how much radiation each is capable of outputting. Consider, x-ray machines far predate what we realize as programmable computers. And much more goes into the safety of the devices than just the language used. [1] http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=328 http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&...
- srean 12y ago
  > :( Why are we replying without going down the chain? I dislike deeply nested, indentation cramped and tangential threads, so sometimes if I dont have anything that important to say I inline it. More so when everyone has left the building. > I'm also familiar with some fun disasters using software by Ada. I dont think we were ever discussing whether using Ada or some other statically type checked language immunizes a project against all other peripheral errors. That would be a supremely ridiculous and stupid claim to make. Typechecking proves either that the code is type error free or that the typechecker has a bug. In the case of the latter, you try and fix it and the benefit percolates to every software verified by it. Testing proves that it passes only those specific test cases and only if the programmer tested it at all. BTW the very first line says the fault had nothing to do with Ada. The source of the error was beyond the scope of typechecking. To backtrack, our discussion was on whether there are notable examples of software written in dynamically typed languages where the cost of error is high. Runtime error while spaceshuttle descends backs to earth, no thank you, on a fly-by-wire unit, when the pilot is breaking out of a loop, again no thank you. There are times when, no pun intended, you just cannot bail out and wash your hands off the situation, without terrible consequences. In such cases I would rather have the error surfaced in an environment where I can control the consequences, meaning early, and as exhaustively as possible. Most importantly typechecking does not preclude/replace testing, it complements it. Everything cannot be statically verified or insured against, but that does not mean that just because we cannot verify everything statically, we should verify nothing statically. BTW Typical x-ray machines do not have the power to kill you in a single exposure, radiotherapy units absolutely can, example Therac. The accidents occurred when the high-power electron beam was activated instead of the intended low power beam, and without the beam spreader plate rotated into place. Previous models had hardware interlocks in place to prevent this, but Therac-25 had removed them, depending instead on software interlocks for safety. The software interlock could fail due to a race condition. I would rather have it proved (exhaustively, rather than with typical tests which would be anecdotaly) that such errors cannot happen.

by srean 12y ago

taeric 12y ago

I'm not trying to play the scotsman's game. Though, I can confess that that is the direction I am somewhat steering this. Not my main goal. My aim is more against the claims of the parent post. Note that there is a big difference between static tooling and statically typed languages. I have high regard for the both. And I've seen more evidence of the former in older, less statically typed, languages than I have the latter. So, part of my point is I haven't ever "heard" what language those systems are written in, period. It isn't that I have heard they are in dynamic or static languages. I flat out never hear. If they are in a static language, then this should be an easy debate for you. Merely give me some evidence and we are done. I do know that the older languaged programs I have seen are typically not in what one would call a statically typed language. There is plenty of static tooling on them, but to pretend that there is statically "typed" tooling around any software that ran something such as the space program feels like it is reaching. Heavily. So, to your silly question. I'd pick the one that has the better track record and has been proven with more tests. I don't care if they are dynamic tests, statically typed assertions, statically analyzed assertions on a dynamically typed codebase, whatever. There are too many tools to care. Because I can hazard a guess that all of the things that have irradiated me in my years have not been by the strongest statically typed languages out there. :)

taeric 12y ago

:( Why are we replying without going down the chain? I almost didn't even see you put more of a response to me. Regardless, I'm familiar with Ada. I'm also familiar with some fun disasters using software by Ada.[1] Now, do I blame that it was in Ada? No. However, the attitude you are displaying of "if all you know is it was in Ada, then it is safer than the alternatives" seems to be the exact problem that led to that disaster. If the only thing I know of two irradiation devices is one was statically typed and the other wasn't, I'd likely pass on both. Or I'd like to know how much radiation each is capable of outputting. Consider, x-ray machines far predate what we realize as programmable computers. And much more goes into the safety of the devices than just the language used. [1] http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=328 http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&...

srean 12y ago
> :( Why are we replying without going down the chain? I dislike deeply nested, indentation cramped and tangential threads, so sometimes if I dont have anything that important to say I inline it. More so when everyone has left the building. > I'm also familiar with some fun disasters using software by Ada. I dont think we were ever discussing whether using Ada or some other statically type checked language immunizes a project against all other peripheral errors. That would be a supremely ridiculous and stupid claim to make. Typechecking proves either that the code is type error free or that the typechecker has a bug. In the case of the latter, you try and fix it and the benefit percolates to every software verified by it. Testing proves that it passes only those specific test cases and only if the programmer tested it at all. BTW the very first line says the fault had nothing to do with Ada. The source of the error was beyond the scope of typechecking. To backtrack, our discussion was on whether there are notable examples of software written in dynamically typed languages where the cost of error is high. Runtime error while spaceshuttle descends backs to earth, no thank you, on a fly-by-wire unit, when the pilot is breaking out of a loop, again no thank you. There are times when, no pun intended, you just cannot bail out and wash your hands off the situation, without terrible consequences. In such cases I would rather have the error surfaced in an environment where I can control the consequences, meaning early, and as exhaustively as possible. Most importantly typechecking does not preclude/replace testing, it complements it. Everything cannot be statically verified or insured against, but that does not mean that just because we cannot verify everything statically, we should verify nothing statically. BTW Typical x-ray machines do not have the power to kill you in a single exposure, radiotherapy units absolutely can, example Therac. The accidents occurred when the high-power electron beam was activated instead of the intended low power beam, and without the beam spreader plate rotated into place. Previous models had hardware interlocks in place to prevent this, but Therac-25 had removed them, depending instead on software interlocks for safety. The software interlock could fail due to a race condition. I would rather have it proved (exhaustively, rather than with typical tests which would be anecdotaly) that such errors cannot happen.