5 ms·

> Programming languages should be safe by default I disagree. Programming languages should teach you how to program safely. It's the same with construction, h

> Programming languages should be safe by default I disagree. Programming languages should teach you how to program safely. It's the same with construction, here's your brick. You can either use cement or not. Both will build a tower but one will topple and one will not. Programming is the same. Here's your compiler, program your tower without garbage collection and watch it topple. If you don't wish to learn how to program safely then choose a language that does it for you. But don't moan because you refuse to learn how to program safely. Most languages are derived from C anyway so your coding in C but just in the way how the developer wants you to code in C.

kazinator 2y ago
You can't program safely in an unsafe language. You can program correctly so nothing bad happens, but it's still unsafe code. Just like a tightrope walk between two buildings without a safety net is unsafe even if you're very good at it and never fall down. A programming language has multiple safety modes and is safe by default could be used as a tool for teaching a range of concepts.
- doublerabbit 2y ago
  If nothing bad happens when something unsafe happens then code is safe. If you don't use the feature set that declares the code as unsafe then it's safe. A knife is unsafe, but when a chef uses it correctly it's safe. As is code. It's only when you use syntax incorrectly does it become unsafe. A tightrope is still unsafe and now you're relying on the safety net to catch your fall. What declares the safety of the safety net? However both standards should apply. But as programming is now more rapid rather than a dedicated skill, prototyping of new code landing in production. We are tend to rapidly program ignoring the correct way to program and now relying on the language to do the checkup. That itself is still just as unsafe and now passing the buck of lousy code on to as a fault of the language itself. Safety doesn't come from the language. It can, mainly it comes from the code. Use syntax incorrectly and you have unsafe code in any language.
  - kstrauser 2y ago
    We need to accept that humans are not capable of writing safe code in unsafe languages. Brilliant, dedicated, diligent programmers still write busted C code all the time. If the OpenBSD team still makes critical mistakes today, what hope do the rest of us have?
    - kazinator 2y ago
      It is selection bias at work. Only programs in which an issue is found are the targets of reports like CVE.
  - kazinator 2y ago
    Almost all code in an unsafe language will misbehave on bad inputs. The program is put together in a way such that it avoids stepping on those cases. For instance, by validating and diagnosing inputs so as to avoiding executing that code. You would think that a program which has been deemed "correct" cannot misuse any of its own code with undefined results. Alas, that is not the case. Such a program is called a "robust" program. A correct program is one that meets all of its functional requirements; does eveything right with correct inputs. Whether robustness is required for correctness depends entirely on how the program is specified: does the specification explicitly call for robustness (grace on bad inputs) or not? For instance, the memcpy() function in your C library is a correct program (hopefully). When you use it correctly, it does its specified job. Most implementations of it are not robust, though. Most memcpy functions cheerfully accept overlapping objects and do something, and are easily crashed by bad pointers. Robustness is related to security. It is often in the areas of the software that lack robustness that attackers find exploitable surfaces! Safe languages contribute robustness to programs. It's as if the requirements were added to the spec of every program. The programmers working with these languages, and their users, get accustomed to this and then expect robustness out of programs as a tacit requirement. Note that an incorrect program can be robust! A program that due to some coding mistake or misunderstanding calculates the wrong thing for correct inputs (not meeting a functional requirement) can still be impervious to misuse. So in a nutshell, safety is more concerned with robustness than correctness. That's why we can talk about languages and libraries being safe, in the absence of a program being specified. Those tools are still safe when they are used to put together a program that doesn't meet its functional requirements. The safety mechanisms in safe languages may not be enoguh for some desirable level of robustness. Users don't want programs to stop with a diagnostic message because they gave bad inputs. Modern safe languages have tools like exception handling. Some wrongheaded programmers think that just because the default robustness provided by safe languages is not always good enough for many kinds of professional or industrial applications, those robustness features are therefore not worth it. ("If I'm going to have to check for bad inputs and take special action, what's the use of the language doing the checking robust.") The safe language can make it much easier to do that, though. For instance, we can often let an entire module execute freely and just catch an exception in one place. Say, inside a CAD program, some calculation over a model could divide by zero. We just catch that somewhere, put up a dialog (or log something in a log window) and the CAD program keeps running.
- Jensson 2y ago
  > You can't program safely in an unsafe language Of course you can, Rust is an unsafe language but people tend to use the safe subset of it. Are you telling me that is impossible and they are writing unsafe code?
  - kazinator 2y ago
    I'm telling you you've not read the entire thread, which I started with: "Programming languages should be safe by default, except in clearly delimited sections of code (as small as a single expression) where the programmer requests less safety." In terms of the word semantics of the situation, people writing in a safe subset of a language are writing safe code. Once they use the unsafe bits, then they aren't.
nicoburns 2y ago
> > Programming languages should be safe by default > I disagree. Programming languages should teach you how to program safely. One of the best things about safe-by-default languages is that they do teach you to program safely! If your program fails to compile you then have to go and find out why, and that's a fantastic learning opportunity. In languages where there are no guard rails, it's much more difficult to work out what you don't know that you don't know.
- doublerabbit 2y ago
  > In languages where there are no guard rails, it's much more difficult to work out what you don't know that you don't know. I don't disagree. But the above is what's not taught anymore. Which what Computer Science taught you about; a subject that has now been watered down. It's great to have languages that have guard rails. And sure helps you learn shaving time off your project/life. However if you're using syntax you have no idea about that can cause system damage than the fault is on the programmer not the language. It exists to be used, but use it wrong it becomes unsafe. I know i'm not right, but i'm not wrong either. It's a double edged sword.
  - kstrauser 2y ago
    Has computer science ever been primarily about programming? I don’t think that’s the case.
  - nicoburns 2y ago
    > It's great to have languages that have guard rails. And sure helps you learn shaving time off your project/life. It also means that beginners can reasonably use the language for production projects. Including those who have never had the opportunity to study computer science. To me, it reflects poorly on a language if pretty much the only reasonable way to learn it such that you can use it safely is via computer science course (or another similarly structured environment - perhaps a work place with senior mentors). Of commonly used languages, that's pretty much true only of C and C++.
  - kazinator 2y ago
CJefferson 2y ago
Let's compare to building (this is in the UK, but I think most countries have similar rules). If someone asks you to build a house, you need to make a plan, and get it signed off. There are lots of rules on what you can, and can't do. If you build a house without cement, by just piling bricks up, you will get fined and be told to take it down and build it again. If that house you badly built falls down and kills someone, you go to jail.
- rikroots 2y ago
  In theory. We're still waiting to see if anyone will be prosecuted for the Grenfell Tower fire ... https://www.bbc.co.uk/news/articles/c6pp46z93k6o https://www.bbc.co.uk/news/articles/c6pp46z93k6o On the software front - there may finally be some progress on prosecuting the people responsible for the Horizon system, whose faults directly led to the Post Office scandal? https://www.bbc.co.uk/news/articles/cvgr19lwgv0o https://www.bbc.co.uk/news/articles/cvgr19lwgv0o
  - CJefferson 2y ago
    You are right that there are terrible issues in building (Grenfell being an obvious, terrible example). But I'd say, in general, building is in a much better state. There are fairly standard rules, which are mostly followed, and most building stay standing, year after year, without the need for constant maintence. On the other hand, software is still really pre-fire of london (at best) in terms of quality and standards.

kazinator 2y ago

You can't program safely in an unsafe language. You can program correctly so nothing bad happens, but it's still unsafe code. Just like a tightrope walk between two buildings without a safety net is unsafe even if you're very good at it and never fall down. A programming language has multiple safety modes and is safe by default could be used as a tool for teaching a range of concepts.

doublerabbit 2y ago
If nothing bad happens when something unsafe happens then code is safe. If you don't use the feature set that declares the code as unsafe then it's safe. A knife is unsafe, but when a chef uses it correctly it's safe. As is code. It's only when you use syntax incorrectly does it become unsafe. A tightrope is still unsafe and now you're relying on the safety net to catch your fall. What declares the safety of the safety net? However both standards should apply. But as programming is now more rapid rather than a dedicated skill, prototyping of new code landing in production. We are tend to rapidly program ignoring the correct way to program and now relying on the language to do the checkup. That itself is still just as unsafe and now passing the buck of lousy code on to as a fault of the language itself. Safety doesn't come from the language. It can, mainly it comes from the code. Use syntax incorrectly and you have unsafe code in any language.
- kstrauser 2y ago
  We need to accept that humans are not capable of writing safe code in unsafe languages. Brilliant, dedicated, diligent programmers still write busted C code all the time. If the OpenBSD team still makes critical mistakes today, what hope do the rest of us have?
  - kazinator 2y ago
    It is selection bias at work. Only programs in which an issue is found are the targets of reports like CVE.
- kazinator 2y ago
  Almost all code in an unsafe language will misbehave on bad inputs. The program is put together in a way such that it avoids stepping on those cases. For instance, by validating and diagnosing inputs so as to avoiding executing that code. You would think that a program which has been deemed "correct" cannot misuse any of its own code with undefined results. Alas, that is not the case. Such a program is called a "robust" program. A correct program is one that meets all of its functional requirements; does eveything right with correct inputs. Whether robustness is required for correctness depends entirely on how the program is specified: does the specification explicitly call for robustness (grace on bad inputs) or not? For instance, the memcpy() function in your C library is a correct program (hopefully). When you use it correctly, it does its specified job. Most implementations of it are not robust, though. Most memcpy functions cheerfully accept overlapping objects and do something, and are easily crashed by bad pointers. Robustness is related to security. It is often in the areas of the software that lack robustness that attackers find exploitable surfaces! Safe languages contribute robustness to programs. It's as if the requirements were added to the spec of every program. The programmers working with these languages, and their users, get accustomed to this and then expect robustness out of programs as a tacit requirement. Note that an incorrect program can be robust! A program that due to some coding mistake or misunderstanding calculates the wrong thing for correct inputs (not meeting a functional requirement) can still be impervious to misuse. So in a nutshell, safety is more concerned with robustness than correctness. That's why we can talk about languages and libraries being safe, in the absence of a program being specified. Those tools are still safe when they are used to put together a program that doesn't meet its functional requirements. The safety mechanisms in safe languages may not be enoguh for some desirable level of robustness. Users don't want programs to stop with a diagnostic message because they gave bad inputs. Modern safe languages have tools like exception handling. Some wrongheaded programmers think that just because the default robustness provided by safe languages is not always good enough for many kinds of professional or industrial applications, those robustness features are therefore not worth it. ("If I'm going to have to check for bad inputs and take special action, what's the use of the language doing the checking robust.") The safe language can make it much easier to do that, though. For instance, we can often let an entire module execute freely and just catch an exception in one place. Say, inside a CAD program, some calculation over a model could divide by zero. We just catch that somewhere, put up a dialog (or log something in a log window) and the CAD program keeps running.
Jensson 2y ago
> You can't program safely in an unsafe language Of course you can, Rust is an unsafe language but people tend to use the safe subset of it. Are you telling me that is impossible and they are writing unsafe code?
- kazinator 2y ago
  I'm telling you you've not read the entire thread, which I started with: "Programming languages should be safe by default, except in clearly delimited sections of code (as small as a single expression) where the programmer requests less safety." In terms of the word semantics of the situation, people writing in a safe subset of a language are writing safe code. Once they use the unsafe bits, then they aren't.

nicoburns 2y ago

> > Programming languages should be safe by default > I disagree. Programming languages should teach you how to program safely. One of the best things about safe-by-default languages is that they do teach you to program safely! If your program fails to compile you then have to go and find out why, and that's a fantastic learning opportunity. In languages where there are no guard rails, it's much more difficult to work out what you don't know that you don't know.

doublerabbit 2y ago
> In languages where there are no guard rails, it's much more difficult to work out what you don't know that you don't know. I don't disagree. But the above is what's not taught anymore. Which what Computer Science taught you about; a subject that has now been watered down. It's great to have languages that have guard rails. And sure helps you learn shaving time off your project/life. However if you're using syntax you have no idea about that can cause system damage than the fault is on the programmer not the language. It exists to be used, but use it wrong it becomes unsafe. I know i'm not right, but i'm not wrong either. It's a double edged sword.
- kstrauser 2y ago
  Has computer science ever been primarily about programming? I don’t think that’s the case.
- nicoburns 2y ago
  > It's great to have languages that have guard rails. And sure helps you learn shaving time off your project/life. It also means that beginners can reasonably use the language for production projects. Including those who have never had the opportunity to study computer science. To me, it reflects poorly on a language if pretty much the only reasonable way to learn it such that you can use it safely is via computer science course (or another similarly structured environment - perhaps a work place with senior mentors). Of commonly used languages, that's pretty much true only of C and C++.
- kazinator 2y ago

CJefferson 2y ago

Let's compare to building (this is in the UK, but I think most countries have similar rules). If someone asks you to build a house, you need to make a plan, and get it signed off. There are lots of rules on what you can, and can't do. If you build a house without cement, by just piling bricks up, you will get fined and be told to take it down and build it again. If that house you badly built falls down and kills someone, you go to jail.

rikroots 2y ago
In theory. We're still waiting to see if anyone will be prosecuted for the Grenfell Tower fire ... https://www.bbc.co.uk/news/articles/c6pp46z93k6o https://www.bbc.co.uk/news/articles/c6pp46z93k6o On the software front - there may finally be some progress on prosecuting the people responsible for the Horizon system, whose faults directly led to the Post Office scandal? https://www.bbc.co.uk/news/articles/cvgr19lwgv0o https://www.bbc.co.uk/news/articles/cvgr19lwgv0o
- CJefferson 2y ago
  You are right that there are terrible issues in building (Grenfell being an obvious, terrible example). But I'd say, in general, building is in a much better state. There are fairly standard rules, which are mostly followed, and most building stay standing, year after year, without the need for constant maintence. On the other hand, software is still really pre-fire of london (at best) in terms of quality and standards.