>I think it's better to catch errors sooner than later. This is where type checking helps.
Agreed. It is better. But it's not that much better. That's why python is able to beat out C++ by leagues in terms of usability and ease of debugging and safety. This is my entire point. That type checking is not the deal breaker here. Type checking is just some extra seasoning on top of good fundamentals, but it is NOT fundamental in itself.
>As for C++ "non-determinism": If you write buggy code that overwrites memory, then of course you're going to get segfaults. This isn't C++'s fault.
This doesn't happen in python. You can't segfault in python. No language is at "fault" but in terms of safety python is safer.
This language of "which language is at fault" is the wrong angle. There is nothing at "fault" here. There is only what is and what isn't.
Also my point was that when you write outside of memory bounds, anything could happen. You can even NOT get a segfault. That's the problem with what makes C++ so not user friendly.
>I've seen plenty of code in all languages (including Python) that appears to exhibit chaotic run time behavior. At a previous company, we had apps that Python would bloat to gigabytes in size and eventually OOM. Is this "non-determinism"? No, it's buggy code or dependencies.
This is literally one of the few things that are non-deterministic in python or dynamic languages. Memory leaks. But these are Very very very hard to trigger in python. But another thing you should realize is that this error has nothing to do with type checking. Type checking is completely orthogonal to this type of error.
>I think it's better to catch errors sooner than later. This is where type checking helps. I've seen plenty of Python code that takes a poorly named argument (say "data").. is it a dict? list? something from a third party library like boto3? If it's a dict, what's in the dict? What if someone suddenly starts passing in 'None' values for the dict? Does the function still work? Almost nobody documents this stuff. Unless you read the code, you have no idea. "Determinism" of code is determined based on inputs. Type checking helps constrain those inputs.
When you get a lot of experience, you realize that "sooner" rather then "later" is better but not that much. Again the paradox reels it's head here. Python forwards ALL type errors to "later" while C++ makes all type errors happen sooner and Python is STILL FAR EASIER to program in. This is evidence for the fact that type checking does not improve things by too much. Other aspects of programming have FAR more weight on the the safety and ease of use of the language. <-- That's my thesis.
Well, we do agree on something! I too much prefer programming in Python over C++. I honestly hope I never have to touch C++ code again. It's been about 5 years.
I try to add typing in Python where it makes sense (especially external interfaces), mostly as documentation, but am not overly zealous about them like some others I know. Mostly I look at them as better comments.
>I try to add typing in Python where it makes sense (especially external interfaces), mostly as documentation, but am not overly zealous about them like some others I know. Mostly I look at them as better comments.
See you don't type everything because it doesn't improve things from a practical standpoint. You view it as better comments rather then additional type safety. You leave holes in your program where certain random parts aren't type checked. It's like if only half of C++ was type checked, one would think that it'd be a nightmare to program in given that we can't assume type correctness everywhere in the code. but this is not the case.
Your practical usage of types actually proves my point. You don't type everything. You have type holes everywhere and things still function just fine.
I type everything for that extra 1% in safety. But I'm not biased. I know 1% isn't a practical number. I do it partly out of habit from my days programming in haskell.
Agreed. It is better. But it's not that much better. That's why python is able to beat out C++ by leagues in terms of usability and ease of debugging and safety. This is my entire point. That type checking is not the deal breaker here. Type checking is just some extra seasoning on top of good fundamentals, but it is NOT fundamental in itself.
>As for C++ "non-determinism": If you write buggy code that overwrites memory, then of course you're going to get segfaults. This isn't C++'s fault.
This doesn't happen in python. You can't segfault in python. No language is at "fault" but in terms of safety python is safer.
This language of "which language is at fault" is the wrong angle. There is nothing at "fault" here. There is only what is and what isn't.
Also my point was that when you write outside of memory bounds, anything could happen. You can even NOT get a segfault. That's the problem with what makes C++ so not user friendly.
>I've seen plenty of code in all languages (including Python) that appears to exhibit chaotic run time behavior. At a previous company, we had apps that Python would bloat to gigabytes in size and eventually OOM. Is this "non-determinism"? No, it's buggy code or dependencies.
This is literally one of the few things that are non-deterministic in python or dynamic languages. Memory leaks. But these are Very very very hard to trigger in python. But another thing you should realize is that this error has nothing to do with type checking. Type checking is completely orthogonal to this type of error.
>I think it's better to catch errors sooner than later. This is where type checking helps. I've seen plenty of Python code that takes a poorly named argument (say "data").. is it a dict? list? something from a third party library like boto3? If it's a dict, what's in the dict? What if someone suddenly starts passing in 'None' values for the dict? Does the function still work? Almost nobody documents this stuff. Unless you read the code, you have no idea. "Determinism" of code is determined based on inputs. Type checking helps constrain those inputs.
When you get a lot of experience, you realize that "sooner" rather then "later" is better but not that much. Again the paradox reels it's head here. Python forwards ALL type errors to "later" while C++ makes all type errors happen sooner and Python is STILL FAR EASIER to program in. This is evidence for the fact that type checking does not improve things by too much. Other aspects of programming have FAR more weight on the the safety and ease of use of the language. <-- That's my thesis.