3 ms·

> Most mature, high level ("easy") languages are relatively bug free for most use cases. Languages and their libraries - yes. That's because they were battle-t

by fiedzia 10y ago

> Most mature, high level ("easy") languages are relatively bug free for most use cases. Languages and their libraries - yes. That's because they were battle-tested by users for a long time (and failed them many times). New programs written in those languages do not inherit those properties. However I referred to C here. Consequences of mistakes there are serious, modern high level languages (probably most, if not of them) do not have such problem. > Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself? I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try.

tylerhou 10y ago
> I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try. What if those proofs have a mistake, or the program you use to verify those proofs has a bug in it? What if the machine you're using has a bug in its processor, or somewhere else? You said that you won't deal with anyone who relies on other people. Your criterion of "anyone" also implies "yourself". By your own argument, unless you yourself personally have verified that every single line of code in your program, every single assembly instruction in your machine code, every single molecule in your computer is correct, you cannot even "deal with" yourself. Have you verified those things yet? It's simply not feasible to trust nobody when nowadays there are so many layers of abstraction. (Not to mention that your original comment was somewhat pretentious.)

by fiedzia 10y ago

tylerhou 10y ago

> I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try. What if those proofs have a mistake, or the program you use to verify those proofs has a bug in it? What if the machine you're using has a bug in its processor, or somewhere else? You said that you won't deal with anyone who relies on other people. Your criterion of "anyone" also implies "yourself". By your own argument, unless you yourself personally have verified that every single line of code in your program, every single assembly instruction in your machine code, every single molecule in your computer is correct, you cannot even "deal with" yourself. Have you verified those things yet? It's simply not feasible to trust nobody when nowadays there are so many layers of abstraction. (Not to mention that your original comment was somewhat pretentious.)