5 ms·

Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type c

Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". The solution -- introducing a new type which explicitly is not to be used in string-like fashion and does not expose the same interface as 'str' -- was implemented in Python 3, and does not require static typing. Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance.

seanwilson 9y ago
> Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". You'd have to change type definitions then...if you define the type to allow those operations then obviously a static type checker isn't going to help. From the article they have this Python 2 -> 3 example which seems like static typing would catch: self.streams = zip(sizes, page_lists) and # zip return a generator on Py3 self.streams = list(zip(sizes, page_lists)) > Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance. Why would you not want assistance from the computer to automatically check things for you given the choice? Why would you not want ways to automatically refactor your code? Those are good reasons, not memes or ignorance... Basic refactorings like changing an ID field between being a number and a string type are just horrible with languages that have dynamic types and implicit conversions for example.
- ubernostrum 9y ago
  Did you know that automated refactoring was first invented and implemented in a dynamically-typed language?
  - seanwilson 9y ago
    Yes, but they're usually unsound. If you rename a field in thousands of lines of JavaScript code for example, you've no guarantee it's still going to work because of JavaScript's dynamic nature. I'm not saying refactoring dynamically typed code it impossible, it just makes life harder and I don't understand why you'd want that if you had a choice.
    - ubernostrum 9y ago
      Because everything has a cost, and the cost of static typing, as it stands right now, is far higher than any hypothetical you can propose about more difficult refactoring or unsuitability for "large" codebases.
      - tigershark 9y ago
        What is the "far higher" cost of static typing? In F# you don't even need to specify the types, they are (almost) all inferred. And you can be sure that you won't ever multiply feet with meters and crash some space probe on Mars for example. I think that the cost of the lost space probe is far higher than whatever advantage you find in dynamic typing. From my point of view I can see no advantage whatsoever, only disadvantages.
        Too 9y ago
        I'm also curious about this "cost of static typing" that is always brought up. What is the cost really? Typing and reading 5 extra characters per function argument?! It's not like every single line of your algorithm inner loop code will be littered with types, there you still keep it clean and skimmable with inferred types. You only make the interfaces type safe, this prevents function misuse, simplifies refactoring and makes the architecture graspable.
        ubernostrum 9y ago
        The cost is up-front having to think carefully about types when you're not yet done exploring the problem space. Types, if you're going to use them, should be decided on after you've completed that step. This is why if you're going to do it, a dynamically-typed language that allows adding hints/annotations later on is an ideal choice. And this is not a purely hypothetical objection: once you put types in a program, you're constraining the future of what you can do unless/until you go back and change them. Those constraints are a very real and, in my experience, very high cost.

seanwilson 9y ago

> Statically-typed Python 2 would not have solved this, since the problem was a single type permitting both string-like and bytes-like operations. A static type checker would simply say "yup, that type supports that". You'd have to change type definitions then...if you define the type to allow those operations then obviously a static type checker isn't going to help. From the article they have this Python 2 -> 3 example which seems like static typing would catch: self.streams = zip(sizes, page_lists) and # zip return a generator on Py3 self.streams = list(zip(sizes, page_lists)) > Also, I've been involved in porting very large codebases and have never felt a need for static typing to assist. The "dynamic typing is only for tiny puny baby child's toy programs" meme does not reveal your sagacity; it reveals your ignorance. Why would you not want assistance from the computer to automatically check things for you given the choice? Why would you not want ways to automatically refactor your code? Those are good reasons, not memes or ignorance... Basic refactorings like changing an ID field between being a number and a string type are just horrible with languages that have dynamic types and implicit conversions for example.

ubernostrum 9y ago
Did you know that automated refactoring was first invented and implemented in a dynamically-typed language?
- seanwilson 9y ago
  Yes, but they're usually unsound. If you rename a field in thousands of lines of JavaScript code for example, you've no guarantee it's still going to work because of JavaScript's dynamic nature. I'm not saying refactoring dynamically typed code it impossible, it just makes life harder and I don't understand why you'd want that if you had a choice.
  - ubernostrum 9y ago
    Because everything has a cost, and the cost of static typing, as it stands right now, is far higher than any hypothetical you can propose about more difficult refactoring or unsuitability for "large" codebases.
    - tigershark 9y ago
      What is the "far higher" cost of static typing? In F# you don't even need to specify the types, they are (almost) all inferred. And you can be sure that you won't ever multiply feet with meters and crash some space probe on Mars for example. I think that the cost of the lost space probe is far higher than whatever advantage you find in dynamic typing. From my point of view I can see no advantage whatsoever, only disadvantages.
      - Too 9y ago
        I'm also curious about this "cost of static typing" that is always brought up. What is the cost really? Typing and reading 5 extra characters per function argument?! It's not like every single line of your algorithm inner loop code will be littered with types, there you still keep it clean and skimmable with inferred types. You only make the interfaces type safe, this prevents function misuse, simplifies refactoring and makes the architecture graspable.
      - ubernostrum 9y ago
        The cost is up-front having to think carefully about types when you're not yet done exploring the problem space. Types, if you're going to use them, should be decided on after you've completed that step. This is why if you're going to do it, a dynamically-typed language that allows adding hints/annotations later on is an ideal choice. And this is not a purely hypothetical objection: once you put types in a program, you're constraining the future of what you can do unless/until you go back and change them. Those constraints are a very real and, in my experience, very high cost.