http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693375.html
> Dear colleague Burger,
>
> for me there is only one answer: Go ahead!
>
> .. but please leave ImageJ as is.
>
> ImageJ is used by thousands of scientists as a valuable tool (and it
> was conceptualized as such) and there exist enormous amounts of macros
> and plug-ins that are used regularly over long periods of times
> without the need of adaptation. Most of us use ImageJ as a tool and
> besides many other features we love the ease of rapid prototyping by
> using the macro language.
>
> From a programmers point of view things may look different, but this
> is an old story going back to the early days of computers when there
> were people who wanted to use computers to solve problems and those
> who wanted to refine programming...
>
> Just my 5 cents.
>
> Best
>
> Herbie Glünder
>
>> 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
>
>