http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693372.html
.. but please leave ImageJ as is.
periods of times without the need of adaptation.
>Dear ImageJ community,
>
>I have been working with IJ for many years, mainly as a teaching aid and
>a tool for implementing small imaging projects. Having used several
>other environments before, I immediately loved IJ for its simplicity,
>openness, portability, and the fact that it was pure Java - the premiere
>programming language in many undergraduate curricula! Despite its
>shortcomings, the phantastic effort by Wayne made me very confident that
>IJ would constantly improve and develop in the right directions.
>Eventually, this was also a key motive to select IJ as the programming
>platform for our book (www.imagingbook.com), which hopefully didn't hurt
>its popularity.
>
>Unfortunately, at least from my point of view, IJ development has taken
>a different and unexpected focus in the recent past. Understanding that
>many users (and some developers) appreciate the ease of working with
>macros or scripting languages, I always considered the use of a *single*
>language with precise semantics as one exciting feature of IJ. This
>contrasts many other Java-based environments that build on a C/C++ layer
>for better performance, thereby compromising on simplicity and
>portability. Personally I think that combining two (or more) programming
>paradigms should be avoided unless they are radically different from
>each other (e.g., LISP + C) and the combination provides a substantial
>overall advantage. Most scripting languages, though, seem to be too
>close to Java anyway (some are even named similarly), both in terms of
>syntax and performance, and also lack the great benefits of compile-time
>error checking provided in Java (and other modern languages). This is
>one reason why I always preferred ImageJ over Matlab, for example.
>Despite its obvious benefits, I am afraid I perceive the current
>emphasis on scripting as a dilution of ImageJ's original spirit.
>
>What I (as a developer) would have much liked to see (instead or in
>addition) is a gradual improvement of ImageJ's core API to make it
>semantically cleaner, more orthogonal, flexible, robust and
>object-oriented, which is important if used as a didactic tool.
>Unfortunately, although Wayne does a wonderful job in fixing all sorts
>of immediate problems, any major changes to the API seem to be
>completely impossible at this point without immediately breaking
>existing code. I perceive this situation as frustrating because I feel
>ImageJ is stuck and has no chance to evolve to the quality where it
>could be. Efforts like Fiji to set up and maintain consistent
>multi-functional packages, though extremely useful for many in the
>community, seem to pursue completely different goals.
>
>I guess what I am proposing is a complete rewrite of ImageJ from
>scratch, following the same concept but giving up on any backward
>compatibility. Ad hoc, key goals (among others) would include to ...
>+ improve semantics and orthogonality of the API,
>+ clearly separate data representation from viewing,
>+ create core libraries that can be used in other environments with
>minimal
> interdependencies between classes,
>+ maximize compile-time safety by avoiding typecasts and eliminating
>run-time
> type checking wherever possible,
>+ make extensive use of modern Java features,
>+ extend the plugin mechanism to operate on multiple images and other
>data types,
>+ improve performance to allow real-time applications (possibly using
>native calls,
> GPU-code etc.),
>+ ...
>
>Does this sound completely insane? Is it too late for this? Anyone
>interested in sharing ideas or even in collaborating (eventually)?
>
>Wow, this grew to a long message - cannot wait for your comments!
>
>Sincerely,
>Wilhelm
>
>--
>Dr. Wilhelm BURGER
>| Upper Austria Univ. of Applied Sciences
>| Digital Media Department
>| A-4232 Hagenberg, Austria
>| mailto:
[hidden email]
>| www.imagingbook.com