4 ms·

Being able to search for functions/libraries by type signatures is very, very useful.

by smanek 18y ago

sctb 18y ago
I completely agree, and I believe that this is something unique to Haskell+Hoogle+Hackage.
silentbicycle 18y ago
Though thinking about functions/libraries in terms of their type signatures is, in itself, a pretty new concept to a lot of people.
- time_management 18y ago
  I remember, about a week into my exposure to Ocaml, asking what a functor was. "It's a function from a module to a module." My response was along the lines of, What? It turns out, though, that Ocaml functors are really cool and can provide some of the functionality of Haskell's type classes.
andreyf 18y ago
Even more useful: searching for functions/libraries with a unit test?
- alexfarran 18y ago
  Kind of like Squeak Smalltalk's method finder http://wiki.squeak.org/squeak/1916 http://wiki.squeak.org/squeak/1916 And a reimplementation in Ruby http://www.nobugs.org/developer/ruby/method_finder.html http://www.nobugs.org/developer/ruby/method_finder.html
time_management 18y ago
Indeed. Type signatures mean that the code is naturally self-documenting. My stance on the static/dynamic controversy is that static typing becomes a win as the amount of time spent reading others' code increases. A single programmer is probably going to be more productive in Lisp than in ML. (I don't know enough about Haskell to speak for it.) On the other hand, if I were choosing a base language for a team of 10 people who would all be editing the same code, I'd most likely choose one that's statically typed. Static typing enforces interfaces and allows the compiler to detect a decent share of bugs as well as most code breaks.
- anamax 18y ago
  > Indeed. Type signatures mean that the code is naturally self-documenting. Really? Knowing that a function takes two ints and returns a function is documentation? And to think that I spend my time worrying about what a function does.
  - snprbob86 18y ago
    (Note: I have only read a bunch about Haskell. I am by no means an expert) In my hobby work with Python, I absolutely have no choice but to read the documentation for a function to know what it does. The dynamic typing necessitates that the function itself tells me nothing. Consider: def get_console_type(console) Does this function take a console object? The string name of the console? The IPAddress of it? In my professional work with C# (well, in this case C), the type signature tells me quite a bit more information. ConsoleType GetConsoleType(IXboxConsole*) One step further: does GetConsoleType have any side effects? It shouldn't by naming convention. But it turns out it did. It updates a cache, which can have a major effect on some totally unrelated thing. Haskell, being a pure language, has to declare the presence of side effects. I'd have know this right away, without having to look at any documentation (there isn't any!). Furthermore, what if the function wasn't actually called GetConsoleType. What if it was called GetXboxType? I really wished I could have searched for "All functions that return ConsoleType"...
  - time_management 18y ago
    Not all ML/Haskell functions are semantically transparent based on the type signature, but type signatures are really useful. You might wonder what function you use to find the length of a list in ML. The function obviously has to exist, but there are a number of things it could be called (length? count? size?). At the toploop, you type "Module L = List" and you get the module's type signature. You see that a function called length exists with type signature 'a list -> int. You know that that's the function you're looking for. Other functions' type signatures give a great indication of what the functions do. For example, List.map : ('a -> 'b) -> 'a list -> 'b list List.filter : ('a -> bool) -> 'a list -> 'a list List.filter_map : ('a -> 'b option) -> 'a list -> 'b list All of these do the most intuitive thing that a function with that type signature should do. Obviously, not all functions can indicate their semantics through their type signature. For example, you might have one called partition with the following signature: partition : ('a -> bool) -> 'a list -> ('a list) * ('a list). You don't know whether the "true" list appears first or second in the returned tuple, but you can easily check this at the toploop. When you're reading other peoples' code, static typing can be a huge win. If the writer of the code used the type system properly, this cuts your read-work by 80%, even without any other documentation.
anamax 18y ago
> Being able to search for functions/libraries by type signatures is very, very useful. I can't remember the last time that I wanted to find a function that took two ints and returned a function. I can remember the last time I wanted a function that did a particular operation.
- 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.

Being able to search for functions/libraries by type signatures is very, very useful.

by smanek 18y ago

Being able to search for functions/libraries by type signatures is very, very useful.

sctb 18y ago

I completely agree, and I believe that this is something unique to Haskell+Hoogle+Hackage.

silentbicycle 18y ago

Though thinking about functions/libraries in terms of their type signatures is, in itself, a pretty new concept to a lot of people.

time_management 18y ago
I remember, about a week into my exposure to Ocaml, asking what a functor was. "It's a function from a module to a module." My response was along the lines of, What? It turns out, though, that Ocaml functors are really cool and can provide some of the functionality of Haskell's type classes.

andreyf 18y ago

Even more useful: searching for functions/libraries with a unit test?

alexfarran 18y ago
Kind of like Squeak Smalltalk's method finder http://wiki.squeak.org/squeak/1916 http://wiki.squeak.org/squeak/1916 And a reimplementation in Ruby http://www.nobugs.org/developer/ruby/method_finder.html http://www.nobugs.org/developer/ruby/method_finder.html

time_management 18y ago

Indeed. Type signatures mean that the code is naturally self-documenting. My stance on the static/dynamic controversy is that static typing becomes a win as the amount of time spent reading others' code increases. A single programmer is probably going to be more productive in Lisp than in ML. (I don't know enough about Haskell to speak for it.) On the other hand, if I were choosing a base language for a team of 10 people who would all be editing the same code, I'd most likely choose one that's statically typed. Static typing enforces interfaces and allows the compiler to detect a decent share of bugs as well as most code breaks.

anamax 18y ago
> Indeed. Type signatures mean that the code is naturally self-documenting. Really? Knowing that a function takes two ints and returns a function is documentation? And to think that I spend my time worrying about what a function does.
- snprbob86 18y ago
  (Note: I have only read a bunch about Haskell. I am by no means an expert) In my hobby work with Python, I absolutely have no choice but to read the documentation for a function to know what it does. The dynamic typing necessitates that the function itself tells me nothing. Consider: def get_console_type(console) Does this function take a console object? The string name of the console? The IPAddress of it? In my professional work with C# (well, in this case C), the type signature tells me quite a bit more information. ConsoleType GetConsoleType(IXboxConsole*) One step further: does GetConsoleType have any side effects? It shouldn't by naming convention. But it turns out it did. It updates a cache, which can have a major effect on some totally unrelated thing. Haskell, being a pure language, has to declare the presence of side effects. I'd have know this right away, without having to look at any documentation (there isn't any!). Furthermore, what if the function wasn't actually called GetConsoleType. What if it was called GetXboxType? I really wished I could have searched for "All functions that return ConsoleType"...
- time_management 18y ago
  Not all ML/Haskell functions are semantically transparent based on the type signature, but type signatures are really useful. You might wonder what function you use to find the length of a list in ML. The function obviously has to exist, but there are a number of things it could be called (length? count? size?). At the toploop, you type "Module L = List" and you get the module's type signature. You see that a function called length exists with type signature 'a list -> int. You know that that's the function you're looking for. Other functions' type signatures give a great indication of what the functions do. For example, List.map : ('a -> 'b) -> 'a list -> 'b list List.filter : ('a -> bool) -> 'a list -> 'a list List.filter_map : ('a -> 'b option) -> 'a list -> 'b list All of these do the most intuitive thing that a function with that type signature should do. Obviously, not all functions can indicate their semantics through their type signature. For example, you might have one called partition with the following signature: partition : ('a -> bool) -> 'a list -> ('a list) * ('a list). You don't know whether the "true" list appears first or second in the returned tuple, but you can easily check this at the toploop. When you're reading other peoples' code, static typing can be a huge win. If the writer of the code used the type system properly, this cuts your read-work by 80%, even without any other documentation.

anamax 18y ago

> Being able to search for functions/libraries by type signatures is very, very useful. I can't remember the last time that I wanted to find a function that took two ints and returned a function. I can remember the last time I wanted a function that did a particular operation.

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.