4 ms·

But can you write "consistently safe" (whatever that may mean) programs in any other language?

by zabzonk 6y ago

oytis 6y ago
Should be a bit easier with Rust or Ada I think.
deleted 6y ago
[deleted]
jerf 6y ago
Obviously, this depends on your definition of "safe". But there's a fairly large set of "safety" issues that, in 2021, effectively only C and C++ have. Other than straight assembler, which by its nature will always be with us in some sense, there aren't any other languages in common use anymore with similar memory safety issues. I'm not sure I can think of any other languages with "pointer arithmetic". Almost nobody else is using NULL-terminated strings. And so on and so on. (Please read that carefully. I'm not saying every language other than C and C++ are completely safe by any definition. I'm saying there are significant weaknesses that only C and C++ have nowadays. Threads unsafety, mutable state management issues, bad/unhelpful type systems, plenty of common unsafety out there today, but C/C++ have their own nearly-unique entries on that list.) C++ nominally has solutions to any given weakness, but in practice they're at the very least difficult to use in isolation, and very, very complicated to completely correctly use in combination with each other, to say nothing of code bases that inevitably end up having to deal with multiple solutions intersecting in the same code base because of two important libraries that have to do things differently or whatever.
- zabzonk 6y ago
  There are lots of languages that are not "safe" in your terms. I'll limit them to ones I am fairly expert in - assembler, FORTH, Object Pascal, but there are many, many others.
  - jerf 6y ago
    FORTH and Object Pascal are not in common use. Languages actually 100% dying are rare. I'm very, very confident that there are people out there working in them full time, and making a good living. But they are not even remotely in the same tier as Java, Python, Go, C++, C, Objective C, etc. Again, this depends on your definition of "common", but... can anyone tell me with a straight face that Java and FORTH are in the same class of usage? Also, I already called out assembler as an exception. By its nature it will always be unsafe. This is fine by me, because any restriction that it lays down will be something that no language above it can possibly get around, no matter how good an idea that may become in a future, which is dangerously restrictive over the long term. I don't look to assembler to provide language-level safety. I don't want assembler to, say, rigidly protect the "private" fields of objects from exterior access, because then my debuggers and state viewers and other tools become impossible.
  - pjmlp 6y ago
    Object Pascal is definitly safer. - bounds checking - proper strings - strong typed enumerations - parameter references cannot be forced to nil (C++ ones can be tricked into null and C doesn't have them anyway)
    - yakubin 6y ago
      Is there a spec for Object Pascal? I'm wondering what document I should follow, if I wanted to write a compiler for it. UPDATE: From what I see[1], there is a proposed standard, but no finalized one. [1]: <http://pascal-central.com/standards.html http://pascal-central.com/standards.html>
- bluetomcat 6y ago
  C is assembly on steroids which gives you just the essential features of an HLL, without any of the fancy stuff which would complicate the translation and would potentially require a runtime environment. Any C construct/operation has a canonical representation as a short series of instructions found on most machines. Essentially, what you get is expression-oriented syntax (operations are expressions yielding a result), support for structured programming (loops, conditionals), automatic register allocation and stack frame management through named local variables, abstraction for calling conventions and a rudimentary type system around integers and pointers.
- userulluipeste 6y ago
  "issues that, in 2021, effectively only C and C++ have" "I'm not sure I can think of any other languages with «pointer arithmetic». Almost nobody else is using NULL-terminated strings. And so on and so on." The thing is, at least a while ago, these were features that got C and C++ chosen for, precisely because they enable someone to go do things quick and dirty (mostly for "quick", with "dirty" only as an assumed consequence, but I've also seen both C and C++ for "dirty" alone plenty of times). We had safer languages (the one named after lovely Mrs. Lovelace, for instance), yet those options simply could not persuade the people that like it raw. Now we clearly have a stronger techno-political pressure lobbying for wearing straighter jackets, so at least it's interesting to watch.

But can you write "consistently safe" (whatever that may mean) programs in any other language?

oytis 6y ago

Should be a bit easier with Rust or Ada I think.

deleted 6y ago

[deleted]

jerf 6y ago

Obviously, this depends on your definition of "safe". But there's a fairly large set of "safety" issues that, in 2021, effectively only C and C++ have. Other than straight assembler, which by its nature will always be with us in some sense, there aren't any other languages in common use anymore with similar memory safety issues. I'm not sure I can think of any other languages with "pointer arithmetic". Almost nobody else is using NULL-terminated strings. And so on and so on. (Please read that carefully. I'm not saying every language other than C and C++ are completely safe by any definition. I'm saying there are significant weaknesses that only C and C++ have nowadays. Threads unsafety, mutable state management issues, bad/unhelpful type systems, plenty of common unsafety out there today, but C/C++ have their own nearly-unique entries on that list.) C++ nominally has solutions to any given weakness, but in practice they're at the very least difficult to use in isolation, and very, very complicated to completely correctly use in combination with each other, to say nothing of code bases that inevitably end up having to deal with multiple solutions intersecting in the same code base because of two important libraries that have to do things differently or whatever.

zabzonk 6y ago
There are lots of languages that are not "safe" in your terms. I'll limit them to ones I am fairly expert in - assembler, FORTH, Object Pascal, but there are many, many others.
- jerf 6y ago
  FORTH and Object Pascal are not in common use. Languages actually 100% dying are rare. I'm very, very confident that there are people out there working in them full time, and making a good living. But they are not even remotely in the same tier as Java, Python, Go, C++, C, Objective C, etc. Again, this depends on your definition of "common", but... can anyone tell me with a straight face that Java and FORTH are in the same class of usage? Also, I already called out assembler as an exception. By its nature it will always be unsafe. This is fine by me, because any restriction that it lays down will be something that no language above it can possibly get around, no matter how good an idea that may become in a future, which is dangerously restrictive over the long term. I don't look to assembler to provide language-level safety. I don't want assembler to, say, rigidly protect the "private" fields of objects from exterior access, because then my debuggers and state viewers and other tools become impossible.
- pjmlp 6y ago
  Object Pascal is definitly safer. - bounds checking - proper strings - strong typed enumerations - parameter references cannot be forced to nil (C++ ones can be tricked into null and C doesn't have them anyway)
  - yakubin 6y ago
    Is there a spec for Object Pascal? I'm wondering what document I should follow, if I wanted to write a compiler for it. UPDATE: From what I see[1], there is a proposed standard, but no finalized one. [1]: <http://pascal-central.com/standards.html http://pascal-central.com/standards.html>
bluetomcat 6y ago
C is assembly on steroids which gives you just the essential features of an HLL, without any of the fancy stuff which would complicate the translation and would potentially require a runtime environment. Any C construct/operation has a canonical representation as a short series of instructions found on most machines. Essentially, what you get is expression-oriented syntax (operations are expressions yielding a result), support for structured programming (loops, conditionals), automatic register allocation and stack frame management through named local variables, abstraction for calling conventions and a rudimentary type system around integers and pointers.
userulluipeste 6y ago
"issues that, in 2021, effectively only C and C++ have" "I'm not sure I can think of any other languages with «pointer arithmetic». Almost nobody else is using NULL-terminated strings. And so on and so on." The thing is, at least a while ago, these were features that got C and C++ chosen for, precisely because they enable someone to go do things quick and dirty (mostly for "quick", with "dirty" only as an assumed consequence, but I've also seen both C and C++ for "dirty" alone plenty of times). We had safer languages (the one named after lovely Mrs. Lovelace, for instance), yet those options simply could not persuade the people that like it raw. Now we clearly have a stronger techno-political pressure lobbying for wearing straighter jackets, so at least it's interesting to watch.