4 ms·

Haskell has algebraic data types, which are much more expressive than conventional types. You can see that from his example. Of course, the types don't define t

by 11ren 18y ago

Haskell has algebraic data types, which are much more expressive than conventional types. You can see that from his example. Of course, the types don't define the functionality, but they narrow it down much more quickly than the ints of C and Java (similar to google ranking of search results). Python documentation, in contrast, seems to downplay (read: hide) the return type! It's not helpful to me (maybe I'm doing it wrong, or just not used to it). For example: http://docs.python.org/library/httplib.html#httplib.HTTPConnection.getresponse http://docs.python.org/library/httplib.html#httplib.HTTPConn...

deleted 18y ago
[deleted]
newt0311 18y ago
Python tends to deemphasize types due to its reliance on ducktyping and type-inferencing. If you look in the documentation, they don't really care about the input types either. Would it be nicer to have more typing? IMHO, it really depends on the setuation. It would be nice to have multimethods but declerative statements like in C would be horrible.
- 11ren 18y ago
  I thought that was the reason - but if I give the wrong types, it won't work. Often, I can infer the types myself, but why not just tell me? I think there are conventions, like "it's a string or a number unless stated otherwise", and these defaults work great. You just need a little faith in the library writer. For example, xmlrpclib.ServerProxy takes an URI - is that a string or a special URI object? I guess it's most convenient if it's just a string, but if you had just constructed the URI by concatenating the separate parts, it's inefficient to immediately parse them apart - and so Java has URI objects. Maybe it's just that Python admits it's a scripting language, and uses machine cycles to serve you - instead of the other way round. That's a nice idea.
- blasdel 18y ago
  For the Nth time, dynamic type-checking IS NOT TYPE-INFERENCE. Please stop willfuly misusing nomenclature. Please.
  - newt0311 18y ago
    Right. Sorry.

by 11ren 18y ago

deleted 18y ago

[deleted]

newt0311 18y ago

Python tends to deemphasize types due to its reliance on ducktyping and type-inferencing. If you look in the documentation, they don't really care about the input types either. Would it be nicer to have more typing? IMHO, it really depends on the setuation. It would be nice to have multimethods but declerative statements like in C would be horrible.

11ren 18y ago
I thought that was the reason - but if I give the wrong types, it won't work. Often, I can infer the types myself, but why not just tell me? I think there are conventions, like "it's a string or a number unless stated otherwise", and these defaults work great. You just need a little faith in the library writer. For example, xmlrpclib.ServerProxy takes an URI - is that a string or a special URI object? I guess it's most convenient if it's just a string, but if you had just constructed the URI by concatenating the separate parts, it's inefficient to immediately parse them apart - and so Java has URI objects. Maybe it's just that Python admits it's a scripting language, and uses machine cycles to serve you - instead of the other way round. That's a nice idea.
blasdel 18y ago
For the Nth time, dynamic type-checking IS NOT TYPE-INFERENCE. Please stop willfuly misusing nomenclature. Please.
- newt0311 18y ago
  Right. Sorry.