Slashdot Mirror

← Back to Stories (view on slashdot.org)

Guido van Rossum On Strong vs. Weak Typing

Posted by timothy on from the hey-baby-what's-your-type-strength-preference dept.

Bill Venners writes "In this interview, Java creator James Gosling says, 'There's a folk theorem out there that systems with very loose typing are very easy to build prototypes with. That may be true. But the leap from a prototype built that way to a real industrial strength system is pretty vast.' In this interview, Python creator Guido van Rossum responds with 'That attitude sounds like the classic thing I've always heard from strong-typing proponents. The one thing that troubles me is that all the focus is on the strong typing, as if once your program is type correct, it has no bugs left. Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct.'"

9 of 100 comments (clear)

  1. Guns don't kill people by KDan · · Score: 4, Insightful

    "Strong or Weak Typing doesn't make good programs. Good programmers make good programs."

    Daniel

    --
    Carpe Diem
  2. Strong Typing is a Must by the+eric+conspiracy · · Score: 4, Insightful

    I think that this argument is exactly backwards. Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process. Strong typing takes a lot of the load off a human developer, and puts it on mechanical systems that can be made much more reliable than humans. The important thing is to take maximum advantage of strong typing - use an IDE that does incremental compilation, etc.

    On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system. The result is many more bugs, and bugs caught much later in the development process when they are more expensive to correct.

    1. Re:Strong Typing is a Must by Jerf · · Score: 5, Insightful

      Sorry, but that's spoken like someone parroting the party line, not someone with experience in both.

      Strong typing allows mechanical type checking via compilers and incremental type checkers during the development process.

      OK, but A: it only allows type checking and B: it enforces type checking.

      A: Type consistency is not a guarentee of correctness. It's not even close to a guarentee of correctness. It's not even more then loosely related to guarentee of correctness. Type 'errors' are only one class of error, and they are detectable in both paradigms, just at different times. Don't skip the focus on "unit-test based testing"; the point of unit-based testing is that it tests for any kind of error you can program a test case for, including type errors, wrong-output for input, environment interaction, and all the other kinds of non-type errors that happen in real life. Unit-test based programming says why pay so much for such a weak guarentee of correctness when you can spend that time writing unit tests and test for useful properties?

      Note that XP calls for unit testing in all languages, not just dynamic ones. You need to be writing them anyhow; why not lean on them and keep your program flexible and tested correct, rather then "proven type correct"?

      B: It enforces type consistency. How many times have you wanted to jump out of the type cage? When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style. If you implement an object that has all the necessary methods, and it'll work right, why shouldn't you be able to use it just because it's not the right "type"? Many, many things in Python present a file-like interface, or a string-like interface, or a sequence-like interface, without having to inherit from the official implementations which may be very wrong for their purposes. And many other parts of the language do that too.

      And guess what? Even in large programs, the world does not come to an end. See unit-testing, although even without that it's still usually OK.

      Because the interface style pervades the whole language, you get to easily write programs that can handle certain types of "type" violations without blowing themselves to smithereens like you might expect if you've never tried it before.

      On the other hand, since it is not possible to mechanically check weak typed code, weak typing places much more load on the programmer to make sure the types are correct than a strongly typed system.

      Two more things:

      One, my experience and the experience of a lot of others says the opposite. You spend an unbelievable amount of time jumping through compiler hoops in a static typed language, and sometimes the smallest change cascades down your entire static hierarchy. You spend a lot of time worrying about things that really aren't importent in the grand scheme of things. Half the time if you're trying to write with any sort of flexible pattern like Iterator or something you end up with a superclass called "Iterable" or "Object" (sound familiar?) or some equivalent, which isn't that far from dynamic typing anyhow.

      The other thing is again, "mechanically checking" code isn't possible for anything but type-correctness. No other goodness properties can be checked that way; in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically. (This implies type correctness is not an interesting property ;-) )

      If type safety could give me something above and beyond type safety, I might be interested. But all it does is "prevent" a class of problems that don't exactly plague most coders anyhow. It's an incredibly steep price to pay for something that doesn't do much for you.

      I've experienced both sides of this. Sure, in theory type checking is great, but in practice, the dangers of type errors are incredibly exaggerated. It's just not a problem. It's too late to convince me with theory that has completely failed to play out the way the the type-safety advocates said it would.

    2. Re:Strong Typing is a Must by jbester1 · · Score: 3, Insightful

      Ever tried an ML derivative?
      They are statically typed, yet typed-inferred so you save quite a lot of time and any change cascades itself down. Saves a whole lot of time, especially nice since the type system is flexible enough to do symbolic computing.

    3. Re:Strong Typing is a Must by shaper · · Score: 3, Insightful

      Unit-test based programming says why pay so much for such a weak guarentee of correctness when you can spend that time writing unit tests and test for useful properties?

      Maybe it's just me, but I've found that much (most?) non-trivial systems that I write are not easily unit-testable. They are usually part of or dependent on large libraries and infrastructure. Most of that infrastructure I did not write nor do I have access to its source. Much of it is often poorly documented, so that one does not have any clear spec upon which to build tests.

      Instead, I tend to rely on the tools to do as much as possible for me, type checking being just one tool in one phase. I expect and plan for unexpected behavior and design for graceful error handling and degradation at every level of code. I know that the developer that wrote that library is at least as lazy as me, probably even more, so I cannot depend on documentation and correct behavior and I definitely do not have the time to write test cases for every interface in every external library that I use.

      Maybe its my early background in military systems. I just got used to disciplined development and I don't really have to think too much about type correctness. I just tend to be careful about it out of habit.

      And finally there is the one iron-clad fundamental rule of software development: a defect found earlier is much easier to fix. I prefer to catch as many errors as I can by compile time. Everything after that starts getting much more expensive really fast.

  3. -1 Flamebait by clem.dickey · · Score: 4, Insightful

    So what other imperfect things should we do away with? Roads with median strips? Safety locks on guns? Metal detectors?

    I would argue that strict typing reduces one class of bugs so that I can concentrate on other less tractable classes. Who gave Guido the idea that strong-typing programmers are satisifed with clean compiles. I will be satisfied with clean compiles when the compiler can detect *all* bugs. Until then we (some of us, at least) need to work on improving languages and language tools toward that goal.

    1. Re:-1 Flamebait by DannyBoy · · Score: 5, Insightful

      I completely agree with you. Any software developer who doesn't have their head up their ass knows that a clean compile only means that you've made it past the simplest bugs. The good ones have unit and regression tests, the others just run a few testcases by hand. Who ships as soon as it cleanly compiles???

      The main thing that scares me about languages with run-time time checking is that the types can change at run time. If you have unit tests where a variable is a integral/scalar value, and then somehow at runtime it has a string value (cause someone called your function incorrectly), you're screwed because you didn't test that. And if your response is that you should have had a unit test for that, then you'd have to have a unit test for every type (incl user defined) types in the language. This isn't really a problem if it is a small program or you are scripting something, because you can have more control over the inputs, but in a large system, especially with a large development team, compile time type checking has an incredible value!!!

      dan

  4. the majority are not good programmers... by LinuxXPHybrid · · Score: 3, Insightful

    > "Strong or Weak Typing doesn't make good programs. Good programmers make good programs."

    That's probably true, but my wild guess is that the majority of so called programmers are not good programmers. Knowing that, what tool (programming language) should be provided to programmers to write a better (not necessarily good) programs? I think that's the question to be asked.

  5. Here's my vote for static typing! by Tom7 · · Score: 4, Insightful

    Strong typing catches many bugs, but it also makes you focus too much on getting the types right and not enough on getting the rest of the program correct.

    (Does anyone else find it a little scary that Guido confuses "strong" and "static" typing?)

    There's not much substance in this article to actually refute, but I would like to share my experience on this. I have had a lot of experience with static and dynamic, strong and weakly-typed languages, though not much with Python.

    I'm a fan of statically-typed functional languages, especially SML and O'Caml. I agree that static typing catches many bugs; ones that would not be caught at compile-time in a dynamic language. However, in my experience, spending time getting the types right is not a distraction but actually a guide in the design of the program. Static typing encourages . Even if I considered all of that time (which amounts to very little once you become good at the languages) a burden, I think static typing would still be worth it. The reason is that compile-time errors are much, much easier to track down and fix than ones that occur only dynamically (or only once you've shipped your program!).

    By the way, "strong" typing does not mean writing down a lot of types. (ML and Haskell have type-inference systems where you end up writing less than you would in C or Java, and maybe even less than in Python!) By the time you become an expert in a language like ML, you are hardly encountering type errors (except when you make a typo or actual mistake), and hardly writing down anything having to do with types -- the best of both worlds!