5 ms·

> It actually makes python safer then C++ even though python is dynamically typed. Yes, Python is safer than C++. C++ makes no pretence of being a safe languag

> It actually makes python safer then C++ even though python is dynamically typed. Yes, Python is safer than C++. C++ makes no pretence of being a safe language. Static typing is not the same thing as safety. > It is far easier to debug a error caused by out of bounds memory writing/reading in python then it is in a strictly typed language like C++. This is because C++ doesn't actually fail hard and fast when you do this. Out-of-bounds array access is undefined behaviour in C++, but that isn't a result of C++ being statically typed. If you want a statically typed language with bounds-checked arrays, look at Java, Ada, or Rust. More broadly, languages with static type systems aren't precluded from using runtime checks. > python is by far less error prone then C++ despite being untyped. Again this doesn't generalise to all statically typed languages. Also, Python isn't untyped, it's dynamically typed. An untyped language is a language with no concept of type, such as assembly or Forth. [0] > Javascript is actually the same, though a little worse then python because how an undefined can get propagated deep into a program. How is JavaScript different from Python here? > I would argue that it doesn't depend on whether the language is dynamically typed, but more on the traceability of crashes. I'm not sure I follow, what doesn't depend? I agree that for a language to score highly on debugging, there's more to it than being statically typed. [0] https://en.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages https://en.wikipedia.org/wiki/Programming_language#Typed_ver...

kazinator 5y ago
> C++ makes no pretence of being a safe language Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified. For instance, std::string is a heck of a lot safer than manipulating character arrays. You can do str1 = str2 + str3 without worrying about memory allocation. Not to mention "return str1" as if it were a scalar value. There are ways of using C++ that are entirely safe, along those lines. Not just modern C++ either, but old C++98. You carefully develop some classes that are nicely behaved, and then use only those classes. No C arrays, no C pointers.
- MaxBarraclough 5y ago
  > Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified. You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language. Whether it's safer than C isn't the point, but this causes undefined behaviour in both C and C++: int i; int j = i; as does this statement: int i = 1 / 0; as does: int i = INT_MIN * -1; as does: int i = INT_MAX + 1; > There are ways of using C++ that are entirely safe, along those lines. [...] No C arrays, no C pointers. Practically speaking, no, there are not. As I showed above, it's not just arrays and pointers that have safety issues in C and C++. I've rambled before about how there's no practical way to entirely avoid the unsafety pitfalls of C and C++ (short of formal verification). [0][1] Compare this against the Safe Rust subset of Rust. Safe Rust really is a safe language, at least by their (very strong) definition of the term as guaranteed to be free of undefined behaviour. [2] It's not possible to define a practical subset of C or C++ with this property. [0] https://news.ycombinator.com/item?id=26307709 https://news.ycombinator.com/item?id=26307709 [1] https://news.ycombinator.com/item?id=30597750 https://news.ycombinator.com/item?id=30597750 [2] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
  - deltaonefour 5y ago
    > You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language. The topic at hand is not what your purporting it to be either. You seem to be thinking that the topic at hand is C++ is a language that touts itself to be safer then python. And you are responding to me as if I made that claim. I never did. Obviously the person you're responding to is making the claim that C++ does tout itself as "safer" then C but not necessarily "safer" then python. But he is responding to an Actual claim you made saying that C++ doesn't tout itself as safe.
  - kazinator 5y ago
    > Practically speaking, no, there are not. Yes, there are. C++ has constructors which ensure that uninitialized objects don't happen. mynumber i; // i is initialized by constructor mynumber j = i; mynumber x = mynumber(1) / 0; // reliable exception is thrown i * INT_MAX; // exception or bignum support in mynum
deltaonefour 5y ago
>Yes, Python is safer than C++. C++ makes no pretence of being a safe language. Static typing is not the same thing as safety. I'm just addressing the posters comment on statically typed langauges. Not saying anything about "pretenses". >Out-of-bounds array access is undefined behaviour in C++, but that isn't a result of C++ being statically typed. If you want a statically typed language with bounds-checked arrays, look at Java, Ada, or Rust. Yeah I know. >Again this doesn't generalise to all statically typed languages. I never said this. I am just commenting on the opposite generalization the poster I'm replying to made. In general statically typed is safer the dynamically typed but this doesn't apply to all actual languages with these properties. There are actual statically typed languages like C++ that are less safe then a dynamically typed language like python. >Also, Python isn't untyped, it's dynamically typed. This is just a semantic mistake. Clearly I meant dynamically typed. Not untyped. But I hope people get the meaning. >How is JavaScript different from Python here? Javascript doesn't crash as much as python. For example Calling someHashTable[nonexistentKey] in javascript returns a value that can actually be propagated far along into the datapath before throwing an error. IN python that's an instant crash. This makes python much easier to debug then js. I use the words less error prone, because python in the long run ends up having less errors due to creators implementing failures that happen quickly and early. >I'm not sure I follow, what doesn't depend? Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable. What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error. The existence of errors that are hard to trace in C++ actually makes it much much less safe then python despite the extensive type system. It indicates that type safety is much less important.
- MaxBarraclough 5y ago
  > Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable. I don't think I agree, it's very beneficial to catch a bug at compile time (or at least 'type-check time') rather than at runtime. It's particularly valuable for refactoring. Even if it's easy to trace a runtime error, it's still a win to transform it into a compile-time error, or a bright red line in an IDE. > Statically typed languages prevent run time errors related to types. The upper-limit on what can be done with type-systems isn't terribly clear, as sophisticated type systems (of the kind we don't see in today's mainstream languages) can prevent errors which aren't simply passing the wrong kind of data. An old Rust example: [0]. > What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error. An error might be very rare or might only occur when a malicious action is taken, so it's important for a language to be helpful in writing correct code. Consider a buffer-overflow in a C codebase that only happens when a malicious packet is received. Of course, type systems aren't the only way for a language to help the programmer write correct/safe/secure code. For example GCC has a flag to have the compiler insert code to explode noisily if the program tries to dereference NULL. That's an improvement in safety when compared to what standard C gives you (undefined behaviour of course), but doesn't relate at all to type systems. [0] https://yoric.github.io/post/rust-typestate/ https://yoric.github.io/post/rust-typestate/ (although typestates were since removed from the Rust language)

kazinator 5y ago

> C++ makes no pretence of being a safe language Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified. For instance, std::string is a heck of a lot safer than manipulating character arrays. You can do str1 = str2 + str3 without worrying about memory allocation. Not to mention "return str1" as if it were a scalar value. There are ways of using C++ that are entirely safe, along those lines. Not just modern C++ either, but old C++98. You carefully develop some classes that are nicely behaved, and then use only those classes. No C arrays, no C pointers.

MaxBarraclough 5y ago
> Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified. You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language. Whether it's safer than C isn't the point, but this causes undefined behaviour in both C and C++: int i; int j = i; as does this statement: int i = 1 / 0; as does: int i = INT_MIN * -1; as does: int i = INT_MAX + 1; > There are ways of using C++ that are entirely safe, along those lines. [...] No C arrays, no C pointers. Practically speaking, no, there are not. As I showed above, it's not just arrays and pointers that have safety issues in C and C++. I've rambled before about how there's no practical way to entirely avoid the unsafety pitfalls of C and C++ (short of formal verification). [0][1] Compare this against the Safe Rust subset of Rust. Safe Rust really is a safe language, at least by their (very strong) definition of the term as guaranteed to be free of undefined behaviour. [2] It's not possible to define a practical subset of C or C++ with this property. [0] https://news.ycombinator.com/item?id=26307709 https://news.ycombinator.com/item?id=26307709 [1] https://news.ycombinator.com/item?id=30597750 https://news.ycombinator.com/item?id=30597750 [2] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
- deltaonefour 5y ago
  > You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language. The topic at hand is not what your purporting it to be either. You seem to be thinking that the topic at hand is C++ is a language that touts itself to be safer then python. And you are responding to me as if I made that claim. I never did. Obviously the person you're responding to is making the claim that C++ does tout itself as "safer" then C but not necessarily "safer" then python. But he is responding to an Actual claim you made saying that C++ doesn't tout itself as safe.
- kazinator 5y ago
  > Practically speaking, no, there are not. Yes, there are. C++ has constructors which ensure that uninitialized objects don't happen. mynumber i; // i is initialized by constructor mynumber j = i; mynumber x = mynumber(1) / 0; // reliable exception is thrown i * INT_MAX; // exception or bignum support in mynum

deltaonefour 5y ago

>Yes, Python is safer than C++. C++ makes no pretence of being a safe language. Static typing is not the same thing as safety. I'm just addressing the posters comment on statically typed langauges. Not saying anything about "pretenses". >Out-of-bounds array access is undefined behaviour in C++, but that isn't a result of C++ being statically typed. If you want a statically typed language with bounds-checked arrays, look at Java, Ada, or Rust. Yeah I know. >Again this doesn't generalise to all statically typed languages. I never said this. I am just commenting on the opposite generalization the poster I'm replying to made. In general statically typed is safer the dynamically typed but this doesn't apply to all actual languages with these properties. There are actual statically typed languages like C++ that are less safe then a dynamically typed language like python. >Also, Python isn't untyped, it's dynamically typed. This is just a semantic mistake. Clearly I meant dynamically typed. Not untyped. But I hope people get the meaning. >How is JavaScript different from Python here? Javascript doesn't crash as much as python. For example Calling someHashTable[nonexistentKey] in javascript returns a value that can actually be propagated far along into the datapath before throwing an error. IN python that's an instant crash. This makes python much easier to debug then js. I use the words less error prone, because python in the long run ends up having less errors due to creators implementing failures that happen quickly and early. >I'm not sure I follow, what doesn't depend? Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable. What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error. The existence of errors that are hard to trace in C++ actually makes it much much less safe then python despite the extensive type system. It indicates that type safety is much less important.

MaxBarraclough 5y ago
> Statically typed languages prevent run time errors related to types. I am saying that while this is great this property isn't that important then errors that are easily traceable. I don't think I agree, it's very beneficial to catch a bug at compile time (or at least 'type-check time') rather than at runtime. It's particularly valuable for refactoring. Even if it's easy to trace a runtime error, it's still a win to transform it into a compile-time error, or a bright red line in an IDE. > Statically typed languages prevent run time errors related to types. The upper-limit on what can be done with type-systems isn't terribly clear, as sophisticated type systems (of the kind we don't see in today's mainstream languages) can prevent errors which aren't simply passing the wrong kind of data. An old Rust example: [0]. > What's by far more important is that even if the programming language has many holes where run time errors can occur it is better just to have those runtime errors easily traceable to the source of the error. An error might be very rare or might only occur when a malicious action is taken, so it's important for a language to be helpful in writing correct code. Consider a buffer-overflow in a C codebase that only happens when a malicious packet is received. Of course, type systems aren't the only way for a language to help the programmer write correct/safe/secure code. For example GCC has a flag to have the compiler insert code to explode noisily if the program tries to dereference NULL. That's an improvement in safety when compared to what standard C gives you (undefined behaviour of course), but doesn't relate at all to type systems. [0] https://yoric.github.io/post/rust-typestate/ https://yoric.github.io/post/rust-typestate/ (although typestates were since removed from the Rust language)