I'm torn between "The record for bug-free C or Java code are not exactly inspiring" and "Wait wait wait in a system with Bitcoin and Javascript you think Javascript is the probable source of problems?"
My question implicitly defined the scope of the conversation to be programming languages. I like how you broke out of that, and pointed out that Bitcoin might have bigger problems that need to be tackled first. Every time I try to think about how to solve Bitcoin's problems, I return to the traditional banking paradigm: you pay someone else to take the risks of managing the money, and they will thus reimburse you if something bad happens.
That depends. If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability.
Consider that, in strongly types languages, things go wrong anyway. Once an officer aboard a U.S. Navy capital ship entered a zero into a program, the zero caused a divide-by-zero error, and the error propagated through the ship's network and disabled the entire system. The ship had to be towed back to port. So much for strong typing.
Quote: "On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing an attempted division by zero in the ship's Remote Data Base Manager, resulting in a buffer overflow which brought down all the machines on the network, causing the ship's propulsion system to fail."
> That depends. If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability.
How did you arrive at that conclusion? How, exactly, is it "fully understood by its creators"? How do you know that it's "thoroughly tested"?
Type systems allow one to assert these ideas declaratively and provably, and depending on the type system, more or less of the design can be asserted.
> Consider that, in strongly types languages, things go wrong anyway ...
That's not an argument against strong typing, that's an argument against your understanding of type systems.
On top of which, you've deployed an illogical assertion: that because things anecdotally CAN go wrong with what you presume was a type-safe language, the failure rate is EQUIVALENT to a non-typesafe language.
> How, exactly, is it "fully understood by its creators"? How do you know that it's "thoroughly tested"?
Here's what I said: "If the software is fully understood by its creators, and if it has been thoroughly tested, there's no reason to doubt its reliability."
Read it again. Note the word "if" repeated twice.
> On top of which, you've deployed an illogical assertion: that because things anecdotally CAN go wrong with what you presume was a type-safe language, the failure rate is EQUIVALENT to a non-typesafe language.
As is often the case in Internet debates, you have invented a position I have never taken to argue with (a "straw man"). I don't have to defend a position I've never taken.
> That doesn't make any sense.
So? It's your opinion, not mine. You defend it.
> That's not an argument against strong typing, that's an argument against your understanding of type systems.
"My understanding?" Was I present on the Navy capital ship that lost its way after a zero was entered into a strongly typed software system? Did I write the code? No to both.
I understand typed systems perfectly well, and they're sometimes helpful in avoiding problems. But the reliability difference between typed and untyped schemes is overrated.