The feature "Code Seeker" finds the code you need. It shows you real code from your, your teams, your organization or even public repositories. You can navigate the code by selecting next or previous and zoom in or out to see more of the code.
The benefit is code reusability as well as learning from existing code.
Any feedback is welcome - thanks
However...
License matters.
Control matters (what if I need to make a change to fit a certain scenario? How does that happen? Is it propagated upstream? How/when?)
Searchability matters. How do I know what I am looking for, especially across domains and companies?
The Code Seeker feature would not actually apply changes, it will allow you to import into whichever IDE you are using and the mechanism or VCS you currently use will still apply. Does this make sense or am I not understanding the Control matters part?
Indexing and Searchability are going to be interesting to implement. I use IntelliJ and Rubymine and at times the indexing is too heavy handed and they are only indexing the current project.
Anything that is generic, e.g. a double entry accounting system, an Actor model, etc. should be in a package management system - a Gem, a Nuget Package, a NPM pacakage etc. rather than copy pasted.
At the micro level for specific line-of-code level problems (usually due to language/platform quirks) we have StackOverflow.
How do I specify what I'm looking for? What level of granularity does it work at? What languages does it cover? How is this different from using libraries? How can I trust the code I find?
Does it exist yet?
I will be posting some more details, videos... Which will give you more detail of how we think it should work.
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.
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?
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
99% of programs/apps already exist.
99% of things I say and do have already been said and done before.
Code reuse is not the solution. We must rethink software and communication as a whole. As far as I know, nobody is attempting anything close to this.
PMs are welcome.
DRY typically is discussed as it relates to a single project. What are your thoughts on this? Code reused across projects or repos is not the same. We can and should have duplicated code but why write it from scratch? For a simple example if I always want to have an Avatar in a navbar, why not make it easy to find and reuse in another project.