5 ms·

In some cases we don't want safety. C can be safe or unsafe depending on how you approach a problem.

userbinator 13y ago
In some cases, we want freedom... and that's something that has been neglected a bit too much with new programming languages IMHO. Safety/security feels like it's the latest of the dumbing-down "let's treat programmers like idiots" fad.
- Allan_Smithee 13y ago
  I submit as evidence 99.44% of software that has been released that programmers are, in fact, idiots.
- scott_s 13y ago
  I think the approach of languages like Rust, which enforce strict safety by default, but allow "unsafe" regions of code, is the correct way to go. See http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety
  - Allan_Smithee 13y ago
    Or if you have any sense of history, languages like Modula-2/2+/3. (And undoubtedly a few (dozen?) others I'm unaware of.) Nothing new in software development. All the "new" shinies are decades (!) old.
    - pjmlp 13y ago
      Somehow young developers seem to think only C and C++ offer native features. I wonder how we got sidetracked like that.
deletes 13y ago
Can you give an example where you don't want safety and you aren't trying to hack? //curious
- csmithuk 13y ago
  Few of the top of my head: 1. Performance reasons. For example: zero copy data structures, mutable data structures, controlling data locality. 2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers. 3. Bitwise and machine specific conversions. For example: endianess conversions. 4. Structure type coercion. For example: object systems, tagged data structures etc.
  - pjmlp 13y ago
    All of those examples are possible in safe systems programming languages like Modula-2 and Ada, with the difference that only the tiny spot where it matters is marked explicitly unsafe. Whereas in C there is no way to distinguish between unsafe and safe code.
  - numeromancer 13y ago
    2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers. Of course doing this usually means your code isn't portable, sometimes not even to other versions of the same compiler. I often wish C had a defined order for bitfields, for example. One of the things I do to help debug & test embedded code is to factor out code which isn't dependent on the hardware platform (eg communication protocols) into a library, and compile it for, and write test programs to test them on, the host. So even embedded code is often best written to be as portable as possible.
  - fanf2 13y ago
    If you are doing unsafe or machine-dependent endurance conversion code, you are almost certainly doing it wrong. http://commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html http://commandcenter.blogspot.co.uk/2012/04/byte-order-falla...

In some cases, we want freedom... and that's something that has been neglected a bit too much with new programming languages IMHO. Safety/security feels like it's the latest of the dumbing-down "let's treat programmers like idiots" fad.

Allan_Smithee 13y ago
I submit as evidence 99.44% of software that has been released that programmers are, in fact, idiots.
scott_s 13y ago
I think the approach of languages like Rust, which enforce strict safety by default, but allow "unsafe" regions of code, is the correct way to go. See http://static.rust-lang.org/doc/master/rust.html#unsafety http://static.rust-lang.org/doc/master/rust.html#unsafety
- Allan_Smithee 13y ago
  Or if you have any sense of history, languages like Modula-2/2+/3. (And undoubtedly a few (dozen?) others I'm unaware of.) Nothing new in software development. All the "new" shinies are decades (!) old.
  - pjmlp 13y ago
    Somehow young developers seem to think only C and C++ offer native features. I wonder how we got sidetracked like that.

deletes 13y ago

Can you give an example where you don't want safety and you aren't trying to hack? //curious

csmithuk 13y ago
Few of the top of my head: 1. Performance reasons. For example: zero copy data structures, mutable data structures, controlling data locality. 2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers. 3. Bitwise and machine specific conversions. For example: endianess conversions. 4. Structure type coercion. For example: object systems, tagged data structures etc.
- pjmlp 13y ago
  All of those examples are possible in safe systems programming languages like Modula-2 and Ada, with the difference that only the tiny spot where it matters is marked explicitly unsafe. Whereas in C there is no way to distinguish between unsafe and safe code.
- numeromancer 13y ago
  2. Direct memory mapped hardware access. For example: device drivers, kernel, embedded systems, microcontrollers. Of course doing this usually means your code isn't portable, sometimes not even to other versions of the same compiler. I often wish C had a defined order for bitfields, for example. One of the things I do to help debug & test embedded code is to factor out code which isn't dependent on the hardware platform (eg communication protocols) into a library, and compile it for, and write test programs to test them on, the host. So even embedded code is often best written to be as portable as possible.
- fanf2 13y ago
  If you are doing unsafe or machine-dependent endurance conversion code, you are almost certainly doing it wrong. http://commandcenter.blogspot.co.uk/2012/04/byte-order-fallacy.html http://commandcenter.blogspot.co.uk/2012/04/byte-order-falla...