3 ms·

I do Python daily, but I also am familiar with Java and C++. In my experience with these languages I would argue that static type checking does not really help

I do Python daily, but I also am familiar with Java and C++. In my experience with these languages I would argue that static type checking does not really help catching bugs other than the most trivial ones. Don't get me wrong, I like these languages, because they yield fast code, but being less error-prone to bugs is a myth. Without a good unit test suite you are doomed in any language. I actually think that writing bug-free code (ahem!) is most easily done in Python, because it is just much easier and faster to debug, test and fix. Java is pretty okay too and the code fast. I would choose Java for any large project that does not have deal with string processing. Although it is still much slower to develop than Python, it has the best technology stack ever! Well, when you get your C++ program to compile, it is still probably wrong. Only after running with Valgrind to check for problems during runtime I could have some confidence that it is working. I would choose C++ only for specific algorithms and data structures that I need to be very efficient. One major advantage for C++ is that it is very convenient to interface it from any other language. That said, note that I only compared fairly unfraily these three languages and based my opinions on my skills and experience. Still, I could bet on it that if you were write any program in Python vs C++, the Python program not only gets completed much faster, but it also has less bugs.

pmoriarty 9y ago
"I do Python daily, but I also am familiar with Java and C++. In my experience with these languages I would argue that static type checking does not really help catching bugs other than the most trivial ones." Guido Van Rossum seems to be more enthusiastic about static type checking. He's put in a lot of effort recently in to mypy[1], a static type checker for Python. Dropbox, the company that Guido works for, has committed to adding static type annotations to their entire 4,000,000 line codebase and checking it with mypy. As of 2016 they had done 400,000 lines[2], and 700,000 lines as of 2017 (after 18 months total).[3] Guido also mentioned that Dropbox's desktop client team, one of the most important teams at Dropbox, has mandated that all new code have static type annotations and be checked with mypy.[2] [1] - http://www.mypy-lang.org/ http://www.mypy-lang.org/ [2] - https://www.youtube.com/watch?v=ZP_QV4ccFHQ https://www.youtube.com/watch?v=ZP_QV4ccFHQ [3] - https://www.youtube.com/watch?v=7ZbwZgrXnwY https://www.youtube.com/watch?v=7ZbwZgrXnwY
- neemetamm 9y ago
  Thanks for the links! I am watching [2] at the moment and I would just like to give my perspective on how I would approach this problem. To rehash, the question in the video is that just by looking at the following code: for entry in entries: entry.data.validate() What does it do? Without context it is hard to know and one would have to search for all functions named validate(), which is hard. Or to rewrite it in statically typed language, which is impossible. The way I've been solving these situations is that I look into the unit test of the relevant function to understand what is going on. Unit tests also act as concise examples on how to use the code with example data. Also, if necessary, I can just debug the relevant unit test and step through the function and see in real-time what is going on. But I am not trying to claim that type annotations are a bad idea, I just haven't used them myself yet.
jerf 9y ago
"I do Python daily, but I also am familiar with Java and C++." I think if you really want to participate in the "strong vs. dynamic type" conversation, you need to pick something like Rust or Haskell for your strong typing. Mere "manifest" typing is a very weak type of strong typing. It can be coerced into giving some nicer guarantees via some trickery with things like constructors setting private fields and validating them at the time. For people who advocate proactively preventing bugs via type systems, the type system that C++ or Java has is not very good at it. Even Go v. Python is a more interesting comparison than you might initially think. I prototype things in Go pretty much as quickly as I could in Python now, but the prototypes are way easier to transform into production code after the first couple of thousand lines. In fact, given how much time I spend with network servers and concurrency I am probably prototyping more quickly than I could in Python, and still having an easier time converting to production services. Go also has a terribly weak type system from the point of view of those who wish to proactively prevent bugs with them (weaker than C++ and Java), but since it has GC and array bound checks it grabs a lot of the low hanging fruit. (See https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... , under the heading "Automatic Transmissions Win The Day".)
MaulingMonkey 9y ago
I make enough "trivial" errors that I find static typing useful on larger projects. Static vs dynamic typing in this context is mostly about when you catch the bug, not "if" you'll catch it per se, so you're right that static doesn't necessarily mean fewer bugs. But it might still mean they're caught faster! Individual type errors have occasionally eaten a distressing amount of my time in dynamically typed languages - in terms of debug time and context switching, when I make the mistake of, say, trusting Javascript docs, in a way that mostly doesn't happen in statically typed languages IME. They help keep these trivial bugs trivial. Sadly most types systems (static or dynamic) aren't leveraged well enough to catch, say, SQL data being passed to things expecting SQL commands, so some issues still slip through. > Without a good unit test suite you are doomed in any language. I write a lot of code that is difficult to meaningfully unit test. How do I properly unit test a platform agnostic wrapper for gamepads - hook up a raspberry pi to some servos? How do I share that with our build server cluster? When is it a bug if nVidia and Intel GPUs render my scene slightly differently - what specific fuzzy conditions qualify as "bug" vs "expected variation"? How do I catch a missing memory barrier in multi-threaded code with unit tests? Sometimes an ARM processor with it's weaker memory semantics can help, but that still won't catch cases where triggering the bug requires the optimizer to do something specific. > Well, when you get your C++ program to compile, it is still probably wrong. While I agree in general, there are counterexamples. Even in the tire fire that is C++, static typing and compile time checks mean that if it still compiles, my rename refactoring in a large project was probably successful. If I rename something in Python, I have no such assurance, and probably updated the name where it was actually referencing something else, or failed to update the name where I thought it was referencing something else and it wasn't. So I have to test "everything". If I'm lucky, my manual audit of the codebase will show that this thing was only used by things that I know are well covered by unit tests. But let's be honest, I'm not that lucky.

pmoriarty 9y ago

"I do Python daily, but I also am familiar with Java and C++. In my experience with these languages I would argue that static type checking does not really help catching bugs other than the most trivial ones." Guido Van Rossum seems to be more enthusiastic about static type checking. He's put in a lot of effort recently in to mypy[1], a static type checker for Python. Dropbox, the company that Guido works for, has committed to adding static type annotations to their entire 4,000,000 line codebase and checking it with mypy. As of 2016 they had done 400,000 lines[2], and 700,000 lines as of 2017 (after 18 months total).[3] Guido also mentioned that Dropbox's desktop client team, one of the most important teams at Dropbox, has mandated that all new code have static type annotations and be checked with mypy.[2] [1] - http://www.mypy-lang.org/ http://www.mypy-lang.org/ [2] - https://www.youtube.com/watch?v=ZP_QV4ccFHQ https://www.youtube.com/watch?v=ZP_QV4ccFHQ [3] - https://www.youtube.com/watch?v=7ZbwZgrXnwY https://www.youtube.com/watch?v=7ZbwZgrXnwY

neemetamm 9y ago
Thanks for the links! I am watching [2] at the moment and I would just like to give my perspective on how I would approach this problem. To rehash, the question in the video is that just by looking at the following code: for entry in entries: entry.data.validate() What does it do? Without context it is hard to know and one would have to search for all functions named validate(), which is hard. Or to rewrite it in statically typed language, which is impossible. The way I've been solving these situations is that I look into the unit test of the relevant function to understand what is going on. Unit tests also act as concise examples on how to use the code with example data. Also, if necessary, I can just debug the relevant unit test and step through the function and see in real-time what is going on. But I am not trying to claim that type annotations are a bad idea, I just haven't used them myself yet.

jerf 9y ago

"I do Python daily, but I also am familiar with Java and C++." I think if you really want to participate in the "strong vs. dynamic type" conversation, you need to pick something like Rust or Haskell for your strong typing. Mere "manifest" typing is a very weak type of strong typing. It can be coerced into giving some nicer guarantees via some trickery with things like constructors setting private fields and validating them at the time. For people who advocate proactively preventing bugs via type systems, the type system that C++ or Java has is not very good at it. Even Go v. Python is a more interesting comparison than you might initially think. I prototype things in Go pretty much as quickly as I could in Python now, but the prototypes are way easier to transform into production code after the first couple of thousand lines. In fact, given how much time I spend with network servers and concurrency I am probably prototyping more quickly than I could in Python, and still having an easier time converting to production services. Go also has a terribly weak type system from the point of view of those who wish to proactively prevent bugs with them (weaker than C++ and Java), but since it has GC and array bound checks it grabs a lot of the low hanging fruit. (See https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... , under the heading "Automatic Transmissions Win The Day".)

MaulingMonkey 9y ago

I make enough "trivial" errors that I find static typing useful on larger projects. Static vs dynamic typing in this context is mostly about when you catch the bug, not "if" you'll catch it per se, so you're right that static doesn't necessarily mean fewer bugs. But it might still mean they're caught faster! Individual type errors have occasionally eaten a distressing amount of my time in dynamically typed languages - in terms of debug time and context switching, when I make the mistake of, say, trusting Javascript docs, in a way that mostly doesn't happen in statically typed languages IME. They help keep these trivial bugs trivial. Sadly most types systems (static or dynamic) aren't leveraged well enough to catch, say, SQL data being passed to things expecting SQL commands, so some issues still slip through. > Without a good unit test suite you are doomed in any language. I write a lot of code that is difficult to meaningfully unit test. How do I properly unit test a platform agnostic wrapper for gamepads - hook up a raspberry pi to some servos? How do I share that with our build server cluster? When is it a bug if nVidia and Intel GPUs render my scene slightly differently - what specific fuzzy conditions qualify as "bug" vs "expected variation"? How do I catch a missing memory barrier in multi-threaded code with unit tests? Sometimes an ARM processor with it's weaker memory semantics can help, but that still won't catch cases where triggering the bug requires the optimizer to do something specific. > Well, when you get your C++ program to compile, it is still probably wrong. While I agree in general, there are counterexamples. Even in the tire fire that is C++, static typing and compile time checks mean that if it still compiles, my rename refactoring in a large project was probably successful. If I rename something in Python, I have no such assurance, and probably updated the name where it was actually referencing something else, or failed to update the name where I thought it was referencing something else and it wasn't. So I have to test "everything". If I'm lucky, my manual audit of the codebase will show that this thing was only used by things that I know are well covered by unit tests. But let's be honest, I'm not that lucky.