86400 / 10 = 8640. You're telling me it's 8640x faster to use an HTML parsing library than building one from scratch? That's way overexaggerated, even for a big exaggeration.
You have to factor in the cost of finding the library, evaluating it (possibly rejecting it), reading its documentation (if it exists and is accurate and up-to-date), and living up with most of its warts because you can't be bothered to learn the innards of the library to make those few changes that would simplify your work. Or you could contact the maintainers and hope they will maybe honor your feature request/bugfix at some point. Libraries do have overhead.
edit: In the specific case of HTML parsing libraries those caveats probably don't really apply because it's a well-known problem with a well-known solution. But in the general case those are valid considerations.
There are many library functions that would take a day to write. If you need one, and you are missing it, then you will spend a day when you could spend 10 seconds. It's that simple.
In mature platforms most specific problems have official solutions either in the core libraries or in the extended standard library set (for java, which I currently use, that would be Sun + Apache).
Also from building a first draft (could take less than a day) to a professional solution you have to pass two big hurdles: feature set and performance. Each of them done properly can take easily more then a week.
I do like the idea of using the libraries of different platforms. Wrappers are much easy to write, and a mechanism for using java classes from arc/lisp would solve a world of problems. Unfortunately I can't imagine it being done without a big performance hit.
Comments
86400 / 10 = 8640. You're telling me it's 8640x faster to use an HTML parsing library than building one from scratch? That's way overexaggerated, even for a big exaggeration.
You have to factor in the cost of finding the library, evaluating it (possibly rejecting it), reading its documentation (if it exists and is accurate and up-to-date), and living up with most of its warts because you can't be bothered to learn the innards of the library to make those few changes that would simplify your work. Or you could contact the maintainers and hope they will maybe honor your feature request/bugfix at some point. Libraries do have overhead.
edit: In the specific case of HTML parsing libraries those caveats probably don't really apply because it's a well-known problem with a well-known solution. But in the general case those are valid considerations.
I am not exaggerating.
There are many library functions that would take a day to write. If you need one, and you are missing it, then you will spend a day when you could spend 10 seconds. It's that simple.
In mature platforms most specific problems have official solutions either in the core libraries or in the extended standard library set (for java, which I currently use, that would be Sun + Apache).
Also from building a first draft (could take less than a day) to a professional solution you have to pass two big hurdles: feature set and performance. Each of them done properly can take easily more then a week.
I do like the idea of using the libraries of different platforms. Wrappers are much easy to write, and a mechanism for using java classes from arc/lisp would solve a world of problems. Unfortunately I can't imagine it being done without a big performance hit.