8 ms·

Actually python fails hard and fast. This is very different from javascript. It actually makes python safer then C++ even though python is dynamically typed. I

Actually python fails hard and fast. This is very different from javascript. It actually makes python safer then C++ even though python is dynamically typed. 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. If you ever programmed extensively in both languages you will actually see that python is by far less error prone then C++ despite being untyped. Javascript is actually the same, though a little worse then python because how an undefined can get propagated deep into a program. Still even though an undefined is hard to debug in javascript, it's still traceable through a step by step methodology. A C++ seg fault is not always so straight forward. I would argue that it doesn't depend on whether the language is dynamically typed, but more on the traceability of crashes.

olliej 4y ago
What? No it doesn’t? Python doesn’t stop until you attempt to use Nil, no different from JS or any other lazy bound language. You might be conflating null/undefined handling with type coercion, which is very different, and much worse.
- deltaonefour 4y ago
  That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on the other hand doesn't fail. It has 3 things equivalent to nil or Null. Called undefined and NaN and NULL. It lets you do some nutty things with undefined. undefined + 1 = NaN. NaN + 1 = NaN. NULL + 1 = 1. In python None + 1 is an instant hard crash. Still these types of errors are traceable by following the code path and even easier with a debugger. For C++ a seg fault could trigger an error anywhere and there's no direct path to the source of the error. For nullptr it triggers a runtime error but this is the same problem as javascript... not a huge deal. In terms of safety the order is: Python, Javascript, C++. C++ alone with the segfaults is what causes it to be on the bottom of the list despite the extensive type system. One seg fault alone is worse then a python program with 20 type errors due to the fact about how hard it is to trace seg faults. There are C++ production code bases where known segfaults exist but no one has ever been able to find the offending line.
  - _gabe_ 4y ago
    I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.
    - deltaonefour 4y ago
      >I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.
deleted 4y ago
[deleted]
MaxBarraclough 4y ago
> 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 4y 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 4y ago

olliej 4y ago

What? No it doesn’t? Python doesn’t stop until you attempt to use Nil, no different from JS or any other lazy bound language. You might be conflating null/undefined handling with type coercion, which is very different, and much worse.

deltaonefour 4y ago
That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on the other hand doesn't fail. It has 3 things equivalent to nil or Null. Called undefined and NaN and NULL. It lets you do some nutty things with undefined. undefined + 1 = NaN. NaN + 1 = NaN. NULL + 1 = 1. In python None + 1 is an instant hard crash. Still these types of errors are traceable by following the code path and even easier with a debugger. For C++ a seg fault could trigger an error anywhere and there's no direct path to the source of the error. For nullptr it triggers a runtime error but this is the same problem as javascript... not a huge deal. In terms of safety the order is: Python, Javascript, C++. C++ alone with the segfaults is what causes it to be on the bottom of the list despite the extensive type system. One seg fault alone is worse then a python program with 20 type errors due to the fact about how hard it is to trace seg faults. There are C++ production code bases where known segfaults exist but no one has ever been able to find the offending line.
- _gabe_ 4y ago
  I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.
  - deltaonefour 4y ago
    >I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.

deleted 4y ago

[deleted]

MaxBarraclough 4y ago

> 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 4y 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 4y ago