Question

Why are not we using, instead of the actual packages/libraries concepts, a centralized function database? I can see many advantages.

1. Easier to grow (anyone could send his small functions, as oposed to the work necessary to sustain a big

2. Analyzable. Statisticals and graph theory tools could be used to analyze and categorize the database.

3. Ultimate productivity tool. Suppose you have the task of converting all images in a folder to black-and-white. You could google to search and install image manipulation and os packages for your language, then study then and search for the right functions. The whole process could take a day. Or you could search for an “open images files in a folder” function, a “convert images to black/white” function, and a “save image” function on said global database, and the whole process could take a minute. Now generalize this to any programming task and you can figure out why I find this so important.

Why is this concept not adopted?

Answer 1

It’s an interesting idea. I think the crux of the matter is this: a well-designed library (or set of libraries) is coherent, in that it carefully chooses a small set of functions, datastructures, and other conventions. This is what lets programmers understand, use, and reuse it.

A massive function database seems like an attempt to make an incoherent, undesigned mass of functions reusable in the same sense. But I don’t think the hard part of the problem is finding relevant functions in the first place: I’m afraid it’s the sheer combinatorial explosion of arbitrary technical choices (inherent even in moderately simple tasks) that will defeat most attempts at direct reuse (as opposed to pseudocode-like inspiration).

Take your “open images in a folder” example query, and consider how a possible target function might:

• identify the folder: directory handle, string, or one of a dozen “path” datastructures
• choose a particular image: string, pattern match, or one of many interactive UI options
• handle image formats: e.g., GIF, JPG, PNG, or a variety of polyglot image loader frameworks
• load the image: unconditionally, header/metadata then body, by tile, by row, or something else
• represent the image: what datastructure does it use to store the loaded image?
• use exceptions, errors, or intermediate decision points

Some of these possibilities can be readily handled by the programmer (assuming the function is properly documented). Some may be patchable (e.g., by finding another function to translate from the framebuffer format provided to one you can use). But others have heavyweight technical implications. An interactive UI file chooser will require the use of a particular UI framework. A polyglot image loader function can pull in dozens of image libraries, and commit you to its memory management scheme.

To put it another way: “design for reuse” has been the hopeful motto of the software engineer for decades, and our best efforts have met with only modest success. However, long experience has taught us the lesson implicit in the motto: without the “design” part, “reuse” doesn’t stand a chance.