second, even code is found, building requires lots of work. missing dependency, mismatching interfaces, unsupported os...
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]
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
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.
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
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?