Posted by
ctrueden on
Dec 24, 2009; 12:22am
URL: http://imagej.273.s1.nabble.com/Scripting-languages-and-API-tp3689913.html
Hi everyone,
In recent years a wealth of scripting languages have emerged (Clojure,
Javascript, Groovy, Jython, JRuby, Jaskell, etc.). And starting with Java 6,
Java includes a scripting framework for supporting these various languages (
https://scripting.dev.java.net/; or see
http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages for a great
example of calling from Groovy to other scripting languages). ImageJ has
traditionally provided scripting through its macro language, but Fiji has
added support for other means as well.
We are interested in improving this scripting support—specifically, coupling
a redesigned Java API more directly with a scripting framework and ImageJ's
macro recorder (as Johannes Schindelin and Adrian Daerr describe below).
This scheme makes it easier to develop scripts by providing more flexibility
in how they can be written, as well as the potential to call into existing
libraries written in those same scripting languages.
However, some people have objected to having more scripting choices (e.g.,
Johan Henriksson below), arguing that these additional languages provide
minimal gains while confusing end users who may need to debug scripts in
unfamiliar languages.
Do others agree that this potential for confusion is a greater concern than
the increased flexibility in scripting?
Lastly, regarding Wilhelm Burger's question below about whether a redesigned
API would be worthwhile, the ImageJDev project strongly asserts that it
would be. Scripting is great for many tasks within the ImageJ application,
but we are looking to expand the project into a general-purpose library
usable from other applications as well, which means a robust Java API. The
very rough software architecture plan I posted to the ImageJDev web site (
http://imagejdev.org/plan) lists several layers and components that we hope
to establish, so that the code can be used to facilitate image processing
and visualization at a variety of levels.
-Curtis
[was: API vs. Scripting?]
On Wed, Oct 7, 2009 at 10:58 AM, Wilhelm Burger <
[hidden email]> wrote:
> 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.
>
> 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?
>
[was: Outsider's opinion]
On Fri, Oct 23, 2009 at 4:38 PM, Johan Henriksson <
[hidden email]>wrote:
> but the worst problem is that we are building a tower of babel by using
> additional languages for minimal gains, that does not provide any gains
> for larger programs (no surprise, I've veto'ed the addition of
> jython/clojure/whatever-support for my tool Endrov). I consider Fiji the
> prime worst example, with Clojure, JRuby, Javascript and Jython. great,
> so now biologists have to know 5 languages instead of 1 to be able to
> read and modify all the scripts/code out there. hackers who fight over
> syntax might like that but I have trouble enough convincing my coworkers
> to just look at java...
>
[was: Performance, was Re: API vs. Scripting?]
On Wed, Dec 16, 2009 at 11:21 AM, Adrian Daerr <
[hidden email]> wrote:
> I am not Johannes, but what I think he is saying is that a good scripting
> interface will essentially mirror the API into the scripting language. That
> is, instead of forcing the developers to manually add a macro command every
> time some API element should be made available for scripting (as Wayne does
> currently, if I understand correctly), a "good" scripting interface can and
> will automatically expose the API calls to the scripting language and thus
> cause no additionnal work when said API is extended. The logic, coherence,
> names etc are chosen only once, scripting follows practically for free.
>