[IPOL discuss] The Hatchery: an informal index of available code within our community.

[Miguel Colom]

> About using external library...
> cons:
>   - it makes the algorithm often library dependent...
>   - it makes your algorithm dependent of the library's potential bug,
> limitation of the library.
> pros:
>  - it makes often the code more readable trough the usage of high level
> interface.
>  - you write and suppose that the code you use is bug free.

What I suggest is a framework, not a library. This distinction is important.

Making it a library means that the main program USES (relies on) a
external set of functions to do its duty.

Making it a framework means that the main program is the framework itself
and the program is a part of it.

I don't really agree with these cons:

- "it makes the algorithm often library dependent...".
    It won't be a library, but a modular framework. It means that one
could easily remove those parts that aren't needed. For example: if
you don't need wavelets, just remove the "wavelet" directory of the
source tree and compile your application.

- "it makes your algorithm dependent of the library's potential bug,
limitation of the library".
    I think it's the opposite. If a certain code part is used on a
particular program and a bug is found, it's likely to be corrected
only in that program, and not in the rest of programs that use the
same code. Moreover, if there's a bug in the code of the framework,
it's likely to be found very quickly, because it's used by much more
people than the single program. And when it's improved or corrected,
all applications can profit it. One should trust more the framework
code than the code copied into a single application.

Best,
Miguel