3 ms·

> I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," Depends on context.. If it's someone learning, or hacking o

> I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," Depends on context.. If it's someone learning, or hacking on some personal project, go ahead! It's a great way to learn. However, if we're talking about a programmer in a commercial company, it's a different story. Your purpose is not to produce the most amount of your own code, your task is to produce a service of some sort. Unless the software/service you're working on a is a database, I expect you would use an existing database (assuming you need one). If the code you're creating needs to manipulate dates, I expect you use an existing library for such things. It will be available, it will be tested, it will handle all edge cases. Why would it be acceptable to spend a lot of time on reinventing that particular wheel, fixing bugs as they arise, etc?

agentultra 16y ago
I don't think it's entirely unreasonable to expect someone to use an available library for parsing dates. It's not a terribly good example. There are cases where "reinventing the wheel," is simply an ignorant statement. Perhaps the system in question has developed semantics for working with date-based data that the grammar of the existing date-parsing library's API doesn't match well with. This extremely contrived example may force the developers to write a lot of code for working around those inconsistencies which themselves can lead to bugs and maintenence headaches in the future. What if your lack-wit developer who wrote his own date-parsing library saw these problems and wrote a library whose API resolved them? Or perhaps in another scenario the existing libraries are simply inefficient for some metric of acceptable performance in your system. Maybe this ignorant developer simply writes a better library that allows you to do more. Either way, there is reason to believe that either scenario is valid. It is likely that writing a date parsing library is not going to be terribly useful. That doesn't mean it's impossible and so one must be willing to evaluate evidence and draw conclusions rather than hide behind blanket statements. What I'm really talking about is the attitude people have when they think someone is "reinventing the wheel." While some people are helpful and will politely point out that there are existing date-parsing libraries, there are a great many more it seems who will assume that the person who is "reinventing the wheel" is a clueless loser who wouldn't make such a "stupid mistake" if they were worth their salt. That kind of reaction isn't helpful at all.
spc476 16y ago
Well, at work, we were using C-Ares (a C-based DNS resolving library) for two different projects and both were mired in problems involving said library; race conditions, having to add support for NAPTR records (I checked about half a dozen different DNS resolving libraries and none supported decoding that record). Even though it wasn't part of my job description, I wrote my own DNS resolving library over a weekend that better matched what our needs were. It was just as fast, easier to integrate (since it made fewer assumptions about network usage), and the runtime memory footprint of at lease one project dropped from 15M to less than 400k, due to my "reinvented" wheel. Had I not done that (back in November) we still would probably be fighting with C-Ares today in both projects.

agentultra 16y ago

I don't think it's entirely unreasonable to expect someone to use an available library for parsing dates. It's not a terribly good example. There are cases where "reinventing the wheel," is simply an ignorant statement. Perhaps the system in question has developed semantics for working with date-based data that the grammar of the existing date-parsing library's API doesn't match well with. This extremely contrived example may force the developers to write a lot of code for working around those inconsistencies which themselves can lead to bugs and maintenence headaches in the future. What if your lack-wit developer who wrote his own date-parsing library saw these problems and wrote a library whose API resolved them? Or perhaps in another scenario the existing libraries are simply inefficient for some metric of acceptable performance in your system. Maybe this ignorant developer simply writes a better library that allows you to do more. Either way, there is reason to believe that either scenario is valid. It is likely that writing a date parsing library is not going to be terribly useful. That doesn't mean it's impossible and so one must be willing to evaluate evidence and draw conclusions rather than hide behind blanket statements. What I'm really talking about is the attitude people have when they think someone is "reinventing the wheel." While some people are helpful and will politely point out that there are existing date-parsing libraries, there are a great many more it seems who will assume that the person who is "reinventing the wheel" is a clueless loser who wouldn't make such a "stupid mistake" if they were worth their salt. That kind of reaction isn't helpful at all.

spc476 16y ago

Well, at work, we were using C-Ares (a C-based DNS resolving library) for two different projects and both were mired in problems involving said library; race conditions, having to add support for NAPTR records (I checked about half a dozen different DNS resolving libraries and none supported decoding that record). Even though it wasn't part of my job description, I wrote my own DNS resolving library over a weekend that better matched what our needs were. It was just as fast, easier to integrate (since it made fewer assumptions about network usage), and the runtime memory footprint of at lease one project dropped from 15M to less than 400k, due to my "reinvented" wheel. Had I not done that (back in November) we still would probably be fighting with C-Ares today in both projects.