5 ms·

I'm going to sign in as a partisan here. I firmly believe that Python is the worst language that people actually use. DuckTyping is the most deeply misguided a

by bhickey 15y ago

I'm going to sign in as a partisan here. I firmly believe that Python is the worst language that people actually use. DuckTyping is the most deeply misguided aspect of python. With the discover of Hindley-Milner type inference 40 and 30 years ago, this sort of sloth is simply inexcusable. Pythonistas will say "Oh, I don't care if it's a duck or a swan, as long as it quacks." Guess what? You can treat function calls as a statement that an object is an instance of some typeclass and that typecheck that. With a sufficiently intelligent compiler/interpreter author this is transparent to the programmer.

cpeterso 15y ago
I enjoy Python's aesthetics and extensive libraries, but wish it had (practical) static type inference. (RPython isn't really practical.) And to confuse matters, Python 3 added optional type annotations that are ignored by the runtime!
TylerE 15y ago
With fairness, no you can't, not truly. Please point me to the version of HM the works with inheritance. Plus, due to stuff like __getattr__, the interpreter may not know until the method is called if it even exists. It would be totally possible in python to write a class where when any arbitrary method is called on a class, a function is randomly generated and called, with a random number of arguments, etc. It doesn't even have to be consistent from call to call. How on earth would H-M type inference cope with that?
- bhickey 15y ago
  I never said inheritance, or method for that matter. You can do H-M on typeclasses. Philip Wadler has a paper on it and it's alive and well in GHC: http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.htm... The fact that Python allows you to do something absurd is simply an argument against its design. Edit: Uh oh, looks like I ruffled some snakeskin!
  - TylerE 15y ago
    The point is you can't just bolt on H-M to a typical scripting language and expect it to work, like, at all. It's a pretty huge sea change, and it would warp the underlying language to the point where you'd just end up with some of non-lazy, non-pure Haskell.
- deleted 15y ago
  [deleted]
- deleted 15y ago
  [deleted]
lubutu 15y ago
Well, duck typing can still be statically checked, so I'd argue that dynamic typing is more misguided. That said, I do agree that duck typing is fundamentally flawed. I think swans actually don't quack, they honk, but so does a car. Here we can see a problem with both synonymous and homonymous verbs. I think it comes down to namespacing: we use modules to prevent naming conflicts, allowing us to compose two modules, but if we do the same with objects their attributes conflict. In Haskell everything has a namespace — there are no methods, only functions — and type classes provide polymorphism without (henceforth) 'quack conflicts'. Two terrible examples of quack conflicts from the Python standard library are '+' meaning both "add" and "append" (the latter being non-commutative), and the comparison operators '<', '<=', '>=', '>' actually meaning ⊂, ⊆, ⊇, ⊃ when dealing with sets.
- bhickey 15y ago
  Sorry for conflating duck typing with dynamic typing. I appreciate the correction!

by bhickey 15y ago

cpeterso 15y ago

I enjoy Python's aesthetics and extensive libraries, but wish it had (practical) static type inference. (RPython isn't really practical.) And to confuse matters, Python 3 added optional type annotations that are ignored by the runtime!

TylerE 15y ago

With fairness, no you can't, not truly. Please point me to the version of HM the works with inheritance. Plus, due to stuff like __getattr__, the interpreter may not know until the method is called if it even exists. It would be totally possible in python to write a class where when any arbitrary method is called on a class, a function is randomly generated and called, with a random number of arguments, etc. It doesn't even have to be consistent from call to call. How on earth would H-M type inference cope with that?

bhickey 15y ago
I never said inheritance, or method for that matter. You can do H-M on typeclasses. Philip Wadler has a paper on it and it's alive and well in GHC: http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.html http://homepages.inf.ed.ac.uk/wadler/topics/type-classes.htm... The fact that Python allows you to do something absurd is simply an argument against its design. Edit: Uh oh, looks like I ruffled some snakeskin!
- TylerE 15y ago
  The point is you can't just bolt on H-M to a typical scripting language and expect it to work, like, at all. It's a pretty huge sea change, and it would warp the underlying language to the point where you'd just end up with some of non-lazy, non-pure Haskell.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]

lubutu 15y ago

Well, duck typing can still be statically checked, so I'd argue that dynamic typing is more misguided. That said, I do agree that duck typing is fundamentally flawed. I think swans actually don't quack, they honk, but so does a car. Here we can see a problem with both synonymous and homonymous verbs. I think it comes down to namespacing: we use modules to prevent naming conflicts, allowing us to compose two modules, but if we do the same with objects their attributes conflict. In Haskell everything has a namespace — there are no methods, only functions — and type classes provide polymorphism without (henceforth) 'quack conflicts'. Two terrible examples of quack conflicts from the Python standard library are '+' meaning both "add" and "append" (the latter being non-commutative), and the comparison operators '<', '<=', '>=', '>' actually meaning ⊂, ⊆, ⊇, ⊃ when dealing with sets.

bhickey 15y ago
Sorry for conflating duck typing with dynamic typing. I appreciate the correction!