Finding New Code

tabandmountaindew writes "Too much time is wasted re-implementing code that someone else has already done, for the sole reason it's faster than finding the other code. Previous source code search engines, such as google codesearch and krugle, only considered individual files on their own, leading to poor quality results, making them only useful when the amount of time to re-implement was extremely high. According to a recent newsforge article a fledgling source-code search engine All The Code is aiming to change all of this. By looking at code, not just on its own, but also how it is used, it is able to return more relevant results. This seems like just what we need to unify the open-source community, leading to an actual common repository of unique code, and ending the cycle of unnecessary reimplementing."

Comments

I call bullshit on this

[analog_line]

I'm not a coder, but my impression of the vast majority of coders is that they reinvent the wheel because they believe that everyone screwed up their wheel implementation and if no one is going to do it right, they should.

Re:I call bullshit on this

[Anonymous Coward]

What I tend to find is that a lot of existing code is not sufficiently abstracted enough from the original implementation, or contains too many dependencies on either the rest of the original codebase or has external dependencies that I am either unable or unwilling to satisfy. If I have to import 3000 lines of structure definitions, macros and constants and modify my code just to be able to re-use a couple of functions, it's likely going to be less work and effort in the long term to write my own implementation.

Re:I call bullshit on this

[wizbit]

I agree, but with a slightly less hostile view to coders, since I am one:

I like to code. I'm a programmer because I like to write code. If given the choice between learning and re-implementing somebody else's solution - for non-trivial tasks, this is usually the best way to go, but also takes a long time - and writing my own solution, I tend to gravitate toward the latter. Why? It usually is faster development-wise. Probably not in the long-run, since well-known code is also usually well-tested and my solution could invariably have bugs that the other would not. But I'd be intimately familiar with whatever I come up with, and it lets me write code immediately, instead of learning somebody else's and trying to meld our two styles/approaches.

It's not arrogance; it's a decision with a slight bias against delayed gratification.

Three things that make this article suspicious

[knightmad]

1) "Java Only for now, more coming soon!"
2) "Alpha"
3) The linked article is a "product announcement" on Newsforge

This is slashvertisement for a vaporware product. Although this is promising, there is nothing concrete there to call it "what we need to unify the open-source community", not even an alternative to Google codesearch.

Btw, is alpha the new beta?

Dependency Rejection

[aprilsound]

I'm of the opinion that most frameworks and libraries don't reimplement enough. In the FOSS Java world, everyone has a dependency on some version of Apache Commons Lang. For what? Just so we don't have to write StringUtils.isEmpty?

Don't get me wrong, if you're developing a stand alone project that wont be a dependency for someone else, then you absolutely want to rewrite as little code as possible. Let someone else maintain as much of your codebase as possible. But if you are writing something that other projects will be using as a dependency, don't you dare make me download four other libraries just to run your code. Write your own dang StringUtils or, if you're lazy and your project is GPLed, just copy the code.

Re:Dependency Rejection

[ComputerSlicer23]

Or better yet, ship a "minimal dependency library". That has all of the minimal sets of dependencies inside of it (either of real code or replacement code). Thus if you are using "Apache Commons Lang" already, it'll pick and use that. If not, you can use the drop in replacement code.

Kirby

not all SW can be reused.

[apodyopsis]

I am an embedded engineer. Various firms I have worked for have tried to implement some kind of "reuse" code store. But every time real-time considerations and platform specifics have derailed it (thankfully) in the early stages. At the low-level so called "code reuse" is (IMHO) a nothing short of a right royal pain in the neck. It looks good on paper, managers like the concept - but it is impossible to implement without large amounts of hardware abstraction. Maybe it makes more sense further up the SW tree, at a higher level when things are not so resource critical.

Why I rewrite code...

[pbhogan]

While I certainly would welcome anything that could help me find code, the reason I'd want it is to find reference code, not reusable code. I've been programming for, oh, two decades now and one thing I find myself doing constantly is finding a bunch of libraries or bits of code and coming to the conclusion that I should just write it myself because of one of the following:

1. The library/code is good, but doesn't quite work the way I want it to
2. The library/code is close, but getting it to work the way I want is painful
3. The library/code is bad
4. The documentation is bad/nonexistent
5. The license is prohibitive or annoying (i.e. it's not LGPL or BSD or the like)
6. I enjoy writing code and sometimes I feel I could do it more elegantly, or efficiently (I might just want a very specific and optimized part of it)

More often than than not though I just enjoy coding and I love learning to code by writing new code. The black box thing... eh... I like to tinker under the hood and find out how things work.

But my point is that finding code is not that hard. It's finding code that fits *exactly* what we want. Code is usually just not quite as modular as we'd like to believe and, if we're honest, as programmers we have a certain vanity about writing code so it does things My Way. :)