5 ms·
I was surprised to find that the lack of static types in python made the documentation less clear for me. I had to read through the documentation to get a grasp
by 10ren 17y ago
I was surprised to find that the lack of static types in python made the documentation less clear for me. I had to read through the documentation to get a grasp of what the formal parameters meant (e.g. were they strings, or more complex data structures), and with several parameters, I kept forgetting which was which. I think there are conventions that experienced python programmers would pick up (e.g. in the naming of parameters). but I didn't know them. Sort of, informal static typing, no?
In Java, the types of parameters give succinct guidance (though I hadn't appreciated this til I saw python docs). You can follow the hyperlinks to get the definitions.
In Haskell, people claim that its more expressive type-system enables you to quickly search for relevant functions, without knowing their names. (I can't verify this personally).
For me, it's very much an unexpected benefit of static type systems.
PS: I don't think Python users need the reassurance, but the actual library being explained by the docs was a lot simpler and easier to use than the equivalent in Java.
- loup-vaillant 17y agoIn Haskell, what you are talking about sounds like type-based search. Like, if you know you're looking for a function of type `[Int] -> Int`, you probably want `sum` or `product` (which are of the compatible type `Num n => [n] -> n`). Am I right? My first guess is that this kind of search is possible in other languages, yet easier and more accurate in Haskell and ML because their type system is paranoid, not because it is expressive.
- jerf 17y agohttp://www.haskell.org/hoogle/?hoogle=[Int]+->+Int http://www.haskell.org/hoogle/?hoogle=[Int]+->+Int Unrelated to that link: "Paranoid" and "expressive" are... hard to relate to each other. I certainly can't call them opposing forces in type signatures. It's a more complicated relationship. Type signatures that can carry lots of information can be both very "paranoid" (excluding many possibilities) while at the same time being very expressive (permitting many possibilities). In English that doesn't make much sense, but it makes perfect sense in the context of something like Haskell's type system, or other similarly carefully-crafted ones.
- 10ren 17y agoThat's a startlingly awesome search engine, especially in its suggestions ("did you mean: "). http://www.haskell.org/hoogle/?hoogle=[a]+->+maybe+a http://www.haskell.org/hoogle/?hoogle=[a]+->+maybe+a But it seems to suggest many non-exact matches, like google does. Useful in a search engine, but not for seeking an exact function - though I guess it doesn't hurt to have too many results, provided the exact ones are always first. (I don't know enough Haskell to be certain)
- 10ren 17y agoThat seems right, though I was thinking more of alternate ("union"?) types, like `A -> A | null`. That's the expressive part. (nb: I'm not a Haskell user, so my syntax aims to be more suggestive than correct. I only know about it from some paper I came across). But you're right you could do that example in Java (4eg): int xxxxx(int[] x)
- loup-vaillant 17y agoIn Haskell, what you call a union type is more often called "sum type", or "tagged union". You declare them this way (your syntax was quite good): data IntOrNothing = AnInteger Int | Nothing You can use it that way: test :: IntOrNothing -> bool -- optional type declaration test AnInteger i -> True test Nothing -> False This is not overloading. This is the same function. I also can write it this way: test :: IntOrNothing -> bool -- optional type declaration test intOrNot = case intOrNot of AnInteger i -> True Nothing -> False So, the "choice" of union type is in the world of values, not in the world of types. Therefore, it isn't particularly relevant in the case of a type-based search.
- dkersten 17y agoThats a good point, actually. If Pythons docs gave better type information for the parameters, then this would be solved..