4 ms·

I think it's difficult to search a functionality by words. For example, if I want to fund matrix multiplication, the function name could mulmat, matrixProduct .

I think it's difficult to search a functionality by words. For example, if I want to fund matrix multiplication, the function name could mulmat, matrixProduct .... could be anything. second, even code is found, building requires lots of work. missing dependency, mismatching interfaces, unsupported os...

pizza 10y ago
type interface is usually enough https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/
- thelambentonion 10y ago
  Expanding on this a bit, the concept that Hoogle embodies is extremely powerful and I wish it were more widely available in other languages. In Haskell's case, due to the particulars of the type system, something like Hoogle is _relatively_ straightforward. More importantly, the same system that makes Hoogle possible also enables safe code exploration and reuse. Eschewing simpler examples for something a little more production-y, I dug up something that came about after a conversation a few weeks back: ( MonadIO m , PersistEntity val , PersistEntityBackend val ~ SqlBackend ) => m [Entity val] Line by line, the signature (roughly) encodes the following [1]: 1) The context `m` must provide the ability to perform I/O 2) `val` must have some representation understandable by the Persistent ORM [2] 3) `val` must have some backend within the Persistent ORM [2] that satisfies the `SqlBackend` constraint 4) The function provides a list of `Entity val`, where `Entity` is a Persistent-specific implementation detail, within some context `m`. IMO, this is incredibly useful for searchability because it encodes everything I said above (and more precisely, at that!). Further, these terms can be pulled apart, rearranged, and composed to form more, or less, specific concepts in a query. This is _also_ useful for code reuse, as seeing these specifications can help identify points of repetition, and encourage higher levels of abstraction. Apologies if this got a little away from the heart of the discussion and turned into a bit of a brain-dump towards the end :) [1] I'm not using the most precise wording here, mostly due to my own incomplete understanding of things [2] Persistent isn't exactly an ORM, but it's the closest analogy I can think of given how comprehensive it is
  - Apsion 10y ago
    This is great - checking out Hoogle now. I love abstractions, although at times they become a barrier to edge use cases. I guess the art is determining how much to abstract. Perhaps I am oversimplifying the way I was imagining the search. In my mind it could simply be a pattern match (including special characters) and return the results. Then the zoom in/out capability would allow you to determine if the result is applicable.
thisrod 10y ago
Smalltalk had a neat solution to this. You gave some arguments and a result, then it tried all the methods with the right types, and listed the ones that gave the result. Searching for '(a b c) and 'a would tell you what car is called in Smalltalk.
- billconan 10y ago
  this sounds cool, but the order of parameters matters. for example, in the case of matrix multiplication, A * B is valid, B * A could be invalid. How to pass the parameters in right order for searching?
- mbrock 10y ago
  How did it avoid calling methods with dangerous side effects?
- segmondy 10y ago
  prolog does this too, but it's not enough. if you don't have enough data, you could find a match that will fail in the future. To answer OP's question, the reason people rewrite is that it's "faster" to write a new one than find what's out there OR I don't want an entire house when all I want is a faucet. Today if you want a faucet. you might have to do something such as house = new House(); faucet = house.getFaucet(); So you have to tear apart/copy and paste the code, if it's loosely coupled enough, you find yourself dealing with all the dependencies. This is a question lots of people have been asking tho, checkout this talk from the creator of Erlang asking the same question https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
  - Apsion 10y ago
    The house analogy makes sense - I need to research Smalltalk and Prolog Checking out the video - thanks

pizza 10y ago

type interface is usually enough https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/

thelambentonion 10y ago
Expanding on this a bit, the concept that Hoogle embodies is extremely powerful and I wish it were more widely available in other languages. In Haskell's case, due to the particulars of the type system, something like Hoogle is _relatively_ straightforward. More importantly, the same system that makes Hoogle possible also enables safe code exploration and reuse. Eschewing simpler examples for something a little more production-y, I dug up something that came about after a conversation a few weeks back: ( MonadIO m , PersistEntity val , PersistEntityBackend val ~ SqlBackend ) => m [Entity val] Line by line, the signature (roughly) encodes the following [1]: 1) The context `m` must provide the ability to perform I/O 2) `val` must have some representation understandable by the Persistent ORM [2] 3) `val` must have some backend within the Persistent ORM [2] that satisfies the `SqlBackend` constraint 4) The function provides a list of `Entity val`, where `Entity` is a Persistent-specific implementation detail, within some context `m`. IMO, this is incredibly useful for searchability because it encodes everything I said above (and more precisely, at that!). Further, these terms can be pulled apart, rearranged, and composed to form more, or less, specific concepts in a query. This is _also_ useful for code reuse, as seeing these specifications can help identify points of repetition, and encourage higher levels of abstraction. Apologies if this got a little away from the heart of the discussion and turned into a bit of a brain-dump towards the end :) [1] I'm not using the most precise wording here, mostly due to my own incomplete understanding of things [2] Persistent isn't exactly an ORM, but it's the closest analogy I can think of given how comprehensive it is
- Apsion 10y ago
  This is great - checking out Hoogle now. I love abstractions, although at times they become a barrier to edge use cases. I guess the art is determining how much to abstract. Perhaps I am oversimplifying the way I was imagining the search. In my mind it could simply be a pattern match (including special characters) and return the results. Then the zoom in/out capability would allow you to determine if the result is applicable.

thisrod 10y ago

Smalltalk had a neat solution to this. You gave some arguments and a result, then it tried all the methods with the right types, and listed the ones that gave the result. Searching for '(a b c) and 'a would tell you what car is called in Smalltalk.

billconan 10y ago
this sounds cool, but the order of parameters matters. for example, in the case of matrix multiplication, A * B is valid, B * A could be invalid. How to pass the parameters in right order for searching?
mbrock 10y ago
How did it avoid calling methods with dangerous side effects?
segmondy 10y ago
prolog does this too, but it's not enough. if you don't have enough data, you could find a match that will fail in the future. To answer OP's question, the reason people rewrite is that it's "faster" to write a new one than find what's out there OR I don't want an entire house when all I want is a faucet. Today if you want a faucet. you might have to do something such as house = new House(); faucet = house.getFaucet(); So you have to tear apart/copy and paste the code, if it's loosely coupled enough, you find yourself dealing with all the dependencies. This is a question lots of people have been asking tho, checkout this talk from the creator of Erlang asking the same question https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
- Apsion 10y ago
  The house analogy makes sense - I need to research Smalltalk and Prolog Checking out the video - thanks