The recently revived discussion around ImageJ's roadmap has me sifting a
little bit through older mails, so here I react to one which is two
On 7/10/09 18:58, Wilhelm Burger wrote:
> > Hello ImageJX-List,
> > I only now had the time to look at Curtis' document (
> > http://imagejx.googlegroups.com/web/ImageJ+Hardening+aims.rtf
> > ) submitted at
> > the end of August - I really like it and many of the issues agree
> > perfectly with those in one of my earlier postings.
An interesting document indeed, now also accessible in its revised form
as announced by Curtis Rueden a week ago at
I find the declared aims very promising and coherent. One comment
nevertheless along the lines of the second comment by WB:
> > 2) Maintaining backward compatibility and keeping the IJ community on
> > board has been a central issue in this list from the beginning. But
> > assuming the API is not so important, would it be conceivable to write
> > a radically new API together with a scripting layer that emulates IJ's
> > existing functionality? I.e, to keep the crowd happy while at the same
> > time providing a clean foundation for further development?
I agree this is the way to go: free your mind of the
continuity/compatibility requirement, and worry about it afterwards.
Better to have a sound and promising structure and API which requires
editing existing plug-ins than censoring some choices out of fear of
breaking existing code. To recall, the NIHImage -> ImageJ transition at
first did not care about 100% compatibility (for the parts which could
have been, e.g. the macro language came back only progressively, and
even that not necessarily 100% compatible; if we had waited for full
integration of live camera acquisition we'd maybe still be waiting...).
This has been said before, and is probably in the minds of Curtis, Grant
and the other imagedev people (it's maybe not the last in the list of
Aims without a reason), but doesn't hurt insisting on. Maybe this is a
point where starting from scratch and recovering as much as possible
from the old later is more efficient than trying to continuously bend
the existing into a new shape with all the acrobatics which that will
> > I am still having second thoughts about the possible return of such an
> > investement and would like to raise a few fundamental questions,
> > hoping not to upset anyone:
> > 1) From the main IJ newslist my experience is that the vast (and
> > growing) majority of postings deals with macros of some sort. Are
> > there enough IJ users that still write Java code and would possibly
> > benefit from an improved API?
I am one of those (dinosaurs?) who prefer writing Java plug-ins rather
than macros. My reasons (just to illustrate why, not claiming they are
- I am very easily frustrated when a language doesn't allow me to do
what I want when I know it should be possible. Wayne Rasband does react
very quickly in general when a shortcoming of the macro language is
voiced on the ImageJ-list, but not fast enough for fast prototyping ;-)
- Having a few lines of includes and class declaration around
essentially similar code doesn't frighten me; conversely I like the Java
language's strong typing (which helps me avoid a few mistakes), the
compiler's generally helpfull error messages, the powerful standard
library (Maps, Lists, Swing, ...!), the fact that I can re-use other
Java projects' code just by copying a jar and using the API, and
generally Java's solidity.
- Laziness: not Yet Another Language to learn, at least Java was a good
investment, usefull for other tasks too. Of course it's not hard to
it still is a pain when you don't code every day to remember all the
small differences in syntax, library functions etc of N>>1 scripting
languages. Would rather learn a new real-world-tongue instead (wish I
could speak as many real-world-tongues as the number of
languages/dialects I have hacked code in).
> > 3) I am reading about support for more (unsigned) primitive data
> > types, use of generics etc. I consider myself a Java person, but this
> > is where Java is particularly bad at, not to talk about some notorious
> > performance issues. How important is Java in this context?
I personnally seldom have performance issues with ImageJ, and I have no
interest in support of other primitive data types (an import/export into
some other possibly larger data type is all I ever needed). The only
comment I therefore have is that performance considerations must include
the likely cost of conversions, the need for which will statistically
increase with the number of different primitive types: I frequently
write plug-ins only for the types I think I'll come across (8bit
unsigned and float for instance), and I suspect most of us do, so an
end-user who attempts to chain plug-ins might have a frustrating
experience of incompatibilities and inserting back-and-forth conversions. In this context mechanisms that allow a plug-in programmer to write algorithms easily for several data types at once would be precious, even if they come at a performance cost.
best regards from freezing Paris,
Preisknaller: GMX DSL Flatrate f�r nur 16,99 Euro/mtl.!