Posted by
dscho on
Mar 09, 2009; 4:56pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693368.html
Hi,
On Mon, 9 Mar 2009, Burger Wilhelm wrote:
> 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.
You mix two substantially different things here. The use of scripting
languages makes ImageJ no less portable, provided that the languages
themselves are implemented in Java.
So using Clojure, Jython, Javascript, JRuby or BeanShell does not affect
portability and ease of installation at all.
> 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.
I have to disagree. The lack of strict typing can be an advantage.
Remember: the time it takes to perform a specific task is the time it
takes for you to write the code plus the time it takes to run the code.
So, if you have a cute idea that you want to test quickly, it is a good
thing if you can just jot down a simple Jython script (that would fail
utterly when fed the inappropriate data) without strict typing and
exception handling. It makes the difference between 5 minutes and 1 hour.
> 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.
Those are laudable goals, even if you do not restrict the use to a
didactic purpuse (which is rather limiting the focus).
> 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 agree that it can be hard to provide major changes to the API without
breaking existing code.
For the end user, though, the API is not important. The existing code is.
> 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.
One of the goals of Fiji is to provide an easy platform to develop for
ImageJ, but also ImageJ itself.
> 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?
Heh. I am aware of a project which tries to rewrite something like
ImageJ. Unfortunately, even if they claim that the project is available
under the BSD license, in reality you will not get the source code. So
they lied.
But it is a major task. And you make all those plugins that are in
wide-spread use completely useless in the process.
> Is it too late for this?
It is never too late. In Open Source, you are free to do what you want.
> Anyone interested in sharing ideas or even in collaborating
> (eventually)?
Yes.
But I propose a different strategy: Keep ImageJ as it is, but provide
adapters to a new, well planned API relying on Java5 features. Write
adapters so that the API can be used seamlessly from within ImageJ. Use
the collaborative framework provided by Fiji. Gradually port plugins to
the new API. Introduce shortcuts in ImageJ to make efficient use of the
new API.
This way, you can keep existing users as well as future developers happy.
Ciao,
Dscho