4 ms·

Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway. Mistakes they would quickly realize if someone po

by runeks 9y ago

Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway. Mistakes they would quickly realize if someone pointed it out to them. Seems to me like safe languages is the real solution to this: make the compiler memorize this document, and have it tell the programmer when he’s made a mistake. If you’re in the business of writing safety-critical code, relying on humans not making mistakes seems naive at best.

Lev1a 9y ago
So something like linting for known bad-practice patterns at compile time and failing compilation if at least one is found? Although it only warns by default IIRC, there is clippy [1] for Rust. And the current lints: https://rust-lang-nursery.github.io/rust-clippy/current/index.html https://rust-lang-nursery.github.io/rust-clippy/current/inde... [1]: https://github.com/rust-lang-nursery/rust-clippy https://github.com/rust-lang-nursery/rust-clippy edit: damn formatting...
catnaroek 9y ago
> Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway. There's some dose of truth to this, but the statement requires further elaboration to illustrate the complete picture. Programmers understand informally and intuitively what to avoid, yet we make serious mistakes when writing code anyway, because we are all stuck at the prerigorous[0] stage of understanding programming languages. Unfortunately, so long as our languages don't have a formal semantics, there is no way to reach the rigorous stage, let alone the postrigorous stage. (There is no path connecting the prerigorous and postrigorous stages that doesn't pass through the rigorous stage.) [0] https://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathematics-than-rigour-and-proofs/ https://terrytao.wordpress.com/career-advice/there%E2%80%99s... . > Seems to me like safe languages is the real solution to this Safe languages are one solution, perhaps the most useful one in the vast majority of cases. However, legitimate use cases for unsafe languages do exist, and we need workable solutions for those cases. That being said, I don't think an informal English document could be such a solution.
Someone 9y ago
Section 5.4, “Top avoidance mechanisms” (paraphrased): 1. Validate input 2. Check error values 3. Enable compiler static analysis 4. Run a static analysis tool So, tooling is high on the list. For #1 and #2 tooling may help, but I do not see how it can avoid them. Lower down that list there are items where tooling will be of limited, if any use, such as “make error handling an integral part of system design”, “use clear and consistent names” and “do not use floating point where integers would suffice”.

by runeks 9y ago

Lev1a 9y ago

So something like linting for known bad-practice patterns at compile time and failing compilation if at least one is found? Although it only warns by default IIRC, there is clippy [1] for Rust. And the current lints: https://rust-lang-nursery.github.io/rust-clippy/current/index.html https://rust-lang-nursery.github.io/rust-clippy/current/inde... [1]: https://github.com/rust-lang-nursery/rust-clippy https://github.com/rust-lang-nursery/rust-clippy edit: damn formatting...

catnaroek 9y ago

> Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway. There's some dose of truth to this, but the statement requires further elaboration to illustrate the complete picture. Programmers understand informally and intuitively what to avoid, yet we make serious mistakes when writing code anyway, because we are all stuck at the prerigorous[0] stage of understanding programming languages. Unfortunately, so long as our languages don't have a formal semantics, there is no way to reach the rigorous stage, let alone the postrigorous stage. (There is no path connecting the prerigorous and postrigorous stages that doesn't pass through the rigorous stage.) [0] https://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathematics-than-rigour-and-proofs/ https://terrytao.wordpress.com/career-advice/there%E2%80%99s... . > Seems to me like safe languages is the real solution to this Safe languages are one solution, perhaps the most useful one in the vast majority of cases. However, legitimate use cases for unsafe languages do exist, and we need workable solutions for those cases. That being said, I don't think an informal English document could be such a solution.

Someone 9y ago

Section 5.4, “Top avoidance mechanisms” (paraphrased): 1. Validate input 2. Check error values 3. Enable compiler static analysis 4. Run a static analysis tool So, tooling is high on the list. For #1 and #2 tooling may help, but I do not see how it can avoid them. Lower down that list there are items where tooling will be of limited, if any use, such as “make error handling an integral part of system design”, “use clear and consistent names” and “do not use floating point where integers would suffice”.