Earlier quoted context omitted.
It has something, but not what you'd call modern type checking: #include int main(void) { unsigned int positive_number = -1; printf("%d", positive_number); return 0; } Prints -1.
I must be missing something here. Wouldn't an unsigned int be unable to represent -1 since the sign bit is part of the value?
Python types have an expectations problem
81–90 of 115 posts
Re: Python types have an expectations problem
#82Earlier quoted context omitted.
There is nothing bold about the claims, knowing the differences between the various typing systems and their advantages and disadvantages is standard stuff. I mean you could always try to find some sources to try and prove me wrong if you want?
I don't have a dog in your fight regarding the original point you made related to the number of bugs increasing but the logic in your comment is flawed though. "I mean you could always try to find some sources to try and prove me wrong if you want? " That's not really how it works though. If you make a claim, either you back-it up or it's irrelevant. Case and point: I believe that a flying tea pot created the univers…
If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct but that is their choice.
Re: Python types have an expectations problem
#83Earlier quoted context omitted.
There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount. Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.
> There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount. i've read some of these studies, they don't prove much. it's typically languages with inexpressive type systems like java. >Type checking mostly shows that code can be compiled successfully. The thing it was designed to do. what languages are you thinking of when you say th…
Re: Python types have an expectations problem
#84Earlier quoted context omitted.
You can annotate OR types in python so in this case you could do def fooify(x: int | list[int])
But if x is an int, the result is an int If x is a list, the result is a list I don’t think that the type system can describe this.
Re: Python types have an expectations problem
#85Earlier quoted context omitted.
> There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount. i've read some of these studies, they don't prove much. it's typically languages with inexpressive type systems like java. >Type checking mostly shows that code can be compiled successfully. The thing it was designed to do. what languages are you thinking of when you say th…
Over the years, plenty of people have wanted to show that static typing gives code correctness benefits over dynamic typing. Everyone who tries just falls flat on their faces.
I don't see how e.g. [1] or [2] are "falling flat on their faces".
[1] https://fsharpforfunandprofit.com/posts/designing-with-types...
[2] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
or even something as basic as non-nullable types, enforced at compile time. a clear, obvious win.
Re: Python types have an expectations problem
#86Earlier quoted context omitted.
The -1 here is hiding the fact that -1 is really just 0xffffffff due to two's complement (architecture dependant of course) And printing it as %d is technically a misuse of printf, since %d means print as a signed integer. If you did %u (print as unsigned integer) instead you'd see the value is really 4,294,967,295 (again, platform dependant)
I knew someone would say this :) But my point is that how can I assign a negative number to an unsigned int in the first place?
Re: Python types have an expectations problem
#87Earlier quoted context omitted.
Python's type hints are great as machine-checkable statements about constraints on the behavior of your code. It's not strictly true that they're unavailable at runtime. > Don't count on them at runtime here either If you're adventurous enough, you can reflect on the type hints and check things yourself at runtime, but you have to understand that the type hints aren't meant for this and they could well blow up in you…
> It's not strictly true that they're unavailable at runtime. So is it possible for me to enforce type hints at runtime, so my program crashes if a type is ever wrong? How do I turn this checking on?
See for example https://pypi.org/project/py-strict-typing/
Re: Python types have an expectations problem
#88Earlier quoted context omitted.
I don't have a dog in your fight regarding the original point you made related to the number of bugs increasing but the logic in your comment is flawed though. "I mean you could always try to find some sources to try and prove me wrong if you want? " That's not really how it works though. If you make a claim, either you back-it up or it's irrelevant. Case and point: I believe that a flying tea pot created the univers…
We assume in good faith that statements made in comments on social media are true. If this was an academic paper, then perhaps you would be correct. But on social meda, asking for sources for what is basically common programming knowledge is borderline trolling. If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct…
I use python add my day job, and I hate writing and dealing with typing. I do admit it makes it easier to reason about other people's code though, especially when faced with libraries that don't have any hints.
Re: Python types have an expectations problem
#89Earlier quoted context omitted.
I don't have a dog in your fight regarding the original point you made related to the number of bugs increasing but the logic in your comment is flawed though. "I mean you could always try to find some sources to try and prove me wrong if you want? " That's not really how it works though. If you make a claim, either you back-it up or it's irrelevant. Case and point: I believe that a flying tea pot created the univers…
We assume in good faith that statements made in comments on social media are true. If this was an academic paper, then perhaps you would be correct. But on social meda, asking for sources for what is basically common programming knowledge is borderline trolling. If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct…
I could write "Humans have actually always had blue skin and hair, but due to a cosmic ray warping our ocular nervous response systems 1000 years ago, we now see humans the way we see them today". And I'd damn well hope someone would ask me to back this absurdity up with evidence.
... and thus: "lalalala I can't hear youuuuuuuuu over the sound of being right!" doesn't make for a good look, is basically what I'm telling you, and asking you to please either cite some sources, or stop doubling down on having to be right because you said so. This is such a ridiculous exchange I'd swear I was having it as an elementary school teacher.
Re: Python types have an expectations problem
#90Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler. Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature. It addi…
The error won't exactly point me to the source of bug and I was getting vague message that some data was missing .
And there were many instances of same throughout my project experience.
With typescript you will know instantly. The javascript being weakly typed compared to python necessitates use of typescript.