http://imagej.273.s1.nabble.com/Scripting-languages-and-API-tp3689913p3689919.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.
>>
Personally, I very much like the classic IJ-macro language. I don't
reasoning. No doubt OOP has advantages for programming but for
(e.g. threading with Java; experts will understand what I mean).