Re: API vs. Scripting?
6 views
Skip to first unread message
Adrian Daerr
Dec 15, 2009, 5:46:34 PM12/15/09
to ima...@googlegroups.com, wil...@ieee.org
Hello ImageJX-readers,
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
month old:
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
http://imagejdev.org/aims
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
demand.
> > 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
particularly good):
- 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
learn macro-scripting when you know e.g. Java, JavaScript, Matlab, but
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,
Adrian
--
Preisknaller: GMX DSL Flatrate f�r nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02
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
month old:
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
http://imagejdev.org/aims
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
demand.
> > 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
particularly good):
- 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
learn macro-scripting when you know e.g. Java, JavaScript, Matlab, but
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,
Adrian
--
Preisknaller: GMX DSL Flatrate f�r nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02
Dimiter Prodanov
Dec 15, 2009, 6:33:03 PM12/15/09
to ima...@googlegroups.com
Hello Adrian,
I think that we should anticipate also another possibility. Notably,
the use of ImageJ with specific hardware, for example writing code to
employ the parallel core of the GPUs. This can in itself require mass
rewriting of the code.
best regards,
Dimiter
I think that we should anticipate also another possibility. Notably,
the use of ImageJ with specific hardware, for example writing code to
employ the parallel core of the GPUs. This can in itself require mass
rewriting of the code.
best regards,
Dimiter
Joris Meys
Dec 15, 2009, 7:15:27 PM12/15/09
to ima...@googlegroups.com
If I may add to the discussion :
I'm more a Perl than a Java adept, mostly because of the quicker programming and greater flexibility. But my main scripting language now is R, as I am doing advanced statistics and neither Jave nor Perl is simply quick enough for matrix calculations. R is built with C, which helps greatly on the performance.
This said, I greatly appreciate the scripting language in R, although R is freeware and can be extended with C code (but who's willing to do _that_? ;-) ). I could see a similar thing happening with IJX : the possibility to use a scripting language for fast and optimal image manipulation and analysis, and the possibility to extend IJX and the scripting language using Java.
A last request would be the possibility to either implement a more mathematical framework to allow for statistical calculations to be programmed, or an extended interface/export facility to get the data of the pictures into for example R.
I know, impossible to please everybody, but as statistics on images is a growing field (e.g. remote sensing for model building, classification,...) and I strongly believe IJX can play an important role there.
Cheers
Joris
I'm more a Perl than a Java adept, mostly because of the quicker programming and greater flexibility. But my main scripting language now is R, as I am doing advanced statistics and neither Jave nor Perl is simply quick enough for matrix calculations. R is built with C, which helps greatly on the performance.
This said, I greatly appreciate the scripting language in R, although R is freeware and can be extended with C code (but who's willing to do _that_? ;-) ). I could see a similar thing happening with IJX : the possibility to use a scripting language for fast and optimal image manipulation and analysis, and the possibility to extend IJX and the scripting language using Java.
A last request would be the possibility to either implement a more mathematical framework to allow for statistical calculations to be programmed, or an extended interface/export facility to get the data of the pictures into for example R.
I know, impossible to please everybody, but as statistics on images is a growing field (e.g. remote sensing for model building, classification,...) and I strongly believe IJX can play an important role there.
Cheers
Joris
--
You received this message because you are subscribed to the Google Groups "ImageJX" group.
To post to this group, send email to ima...@googlegroups.com.
To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.
Grant
Dec 15, 2009, 7:23:25 PM12/15/09
to ImageJX
Why not API *and* scripting ?!
I think we can have a robust and flexible set of API's that can be
easily exposed to most any scripting language you can think of using
the Java Scripting API (see https://scripting.dev.java.net).
-- Grant
I think we can have a robust and flexible set of API's that can be
easily exposed to most any scripting language you can think of using
the Java Scripting API (see https://scripting.dev.java.net).
-- Grant
Dimiter Prodanov
Dec 15, 2009, 7:35:35 PM12/15/09
to ima...@googlegroups.com
Hi, I have developed Image-to-R interface but since I don't know very
well R can't go beyond the basics.
well R can't go beyond the basics.
Adrian Daerr
Dec 15, 2009, 9:48:04 PM12/15/09
to ima...@googlegroups.com, Grant
Grant wrote:
> Why not API *and* scripting ?!
Oh, absolutely! I just meant to say there is still interest in Java-plug-in-programming, but also having scripting is great. If it can be some already known language, like the bunch of scripting languages added by
> Why not API *and* scripting ?!
Johannes Schindelin and coworkers, even better.
As to Dimiter's comment, there is indeed no doubt that adapting to new computing strategies like using graphic processors or even just multiple CPU cores will require an overhaul of ImageJ's structure, at the very least to make it thread-aware or thread-compatible.
Johannes Schindelin
Dec 16, 2009, 3:37:47 AM12/16/09
to Grant, ImageJX
Hi,
We thought about that, too, in the Fiji project, but we still support
32-bit Leopard, which is stuck with Java5. And that does not include the
scripting API, only Java6 and later do.
Ciao,
Dscho
32-bit Leopard, which is stuck with Java5. And that does not include the
scripting API, only Java6 and later do.
Ciao,
Dscho
Wilhelm Burger
Dec 16, 2009, 5:29:11 AM12/16/09
to ImageJX, Adrian...@gmx.de, wil...@ieee.org
Hello Adrian and others,
thanks for picking up this topic again (I was surprised that there was
no reaction to my initial post). Perhaps my points about API vs.
scripting were not clear enough, so let me add a few more lines:
* Most of us in this group are used to program in Java and know all
the related benefits, including those you mentioned. Personally I have
never used a macro but I understand why many users prefer the
(superficial IMO) simplicity of macros and scripting languages. I
noticed that on the IJ newsgroup there are only few questions (now)
whether a certain IJ/Java method exists for some purpose but rather if
there is a suitable macro.
* In the context of refurbishing the plugin model I was thinking about
the role of plugins in general. Initially (I believe), IJ had no
scripting functionality and writing plugins was the only way to extend
IJ's builtin capabilities. At the same time, plugins have been used as
a substitute for enhancing the IJ API, with the disadvantage of
loosing compile-time safety features. I would argue that this should
be better done by adding the corresponding functionality to the API
itself.
* But given that scripting is available (and preferred by many users)
to implement specific functionalities, is there still a role for
plugins? If IJ had a comprehensive and clean API + scripting (as was
said in another post), are plugins in their current form needed at
all? My opinion is no, scripting should be sufficient, preferably
using a well-documented, "real" standard language with a broad
knowledge base and transparent access to Java components.
* Performance IS an issue and for image processing and some of us
would prefer to rather get 10x the current power of our current
computers than only 25%. To obtain this level of performance, some
central parts (eg., filters and other regular but time-consuming
tasks) must be recoded in one or the other way, possibly using GPU
functionality. In an earlier post I called these modules "performance
packs", which will be plattform-dependent (as as the JVM) but should
be installed transparently to the API user.
* So from my perspective one could end up with essentially 3 layers of
software:
a) scripting layer (for development of user-specific functionality
and application libraries),
b) Java API (the core of it, no more plugins),
c) optional performance packs (written in C/C++, OpenCL, etc.).
Hope this not more confusing than my initial post.
-- Wilhelm
On 15 Dez., 23:46, "Adrian Daerr" <Adrian.Da...@gmx.de> wrote:
> Hello ImageJX-readers,
>
> 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
> month old:
>
> On 7/10/09 18:58, Wilhelm Burger wrote:
>
> > > Hello ImageJX-List,
>
> > > I only now had the time to look at Curtis' document (
...
thanks for picking up this topic again (I was surprised that there was
no reaction to my initial post). Perhaps my points about API vs.
scripting were not clear enough, so let me add a few more lines:
* Most of us in this group are used to program in Java and know all
the related benefits, including those you mentioned. Personally I have
never used a macro but I understand why many users prefer the
(superficial IMO) simplicity of macros and scripting languages. I
noticed that on the IJ newsgroup there are only few questions (now)
whether a certain IJ/Java method exists for some purpose but rather if
there is a suitable macro.
* In the context of refurbishing the plugin model I was thinking about
the role of plugins in general. Initially (I believe), IJ had no
scripting functionality and writing plugins was the only way to extend
IJ's builtin capabilities. At the same time, plugins have been used as
a substitute for enhancing the IJ API, with the disadvantage of
loosing compile-time safety features. I would argue that this should
be better done by adding the corresponding functionality to the API
itself.
* But given that scripting is available (and preferred by many users)
to implement specific functionalities, is there still a role for
plugins? If IJ had a comprehensive and clean API + scripting (as was
said in another post), are plugins in their current form needed at
all? My opinion is no, scripting should be sufficient, preferably
using a well-documented, "real" standard language with a broad
knowledge base and transparent access to Java components.
* Performance IS an issue and for image processing and some of us
would prefer to rather get 10x the current power of our current
computers than only 25%. To obtain this level of performance, some
central parts (eg., filters and other regular but time-consuming
tasks) must be recoded in one or the other way, possibly using GPU
functionality. In an earlier post I called these modules "performance
packs", which will be plattform-dependent (as as the JVM) but should
be installed transparently to the API user.
* So from my perspective one could end up with essentially 3 layers of
software:
a) scripting layer (for development of user-specific functionality
and application libraries),
b) Java API (the core of it, no more plugins),
c) optional performance packs (written in C/C++, OpenCL, etc.).
Hope this not more confusing than my initial post.
-- Wilhelm
On 15 Dez., 23:46, "Adrian Daerr" <Adrian.Da...@gmx.de> wrote:
> Hello ImageJX-readers,
>
> 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
> month old:
>
> On 7/10/09 18:58, Wilhelm Burger wrote:
>
> > > Hello ImageJX-List,
>
> > > I only now had the time to look at Curtis' document (
Dimiter Prodanov
Dec 16, 2009, 5:46:20 AM12/16/09
to ima...@googlegroups.com, Adrian...@gmx.de, wil...@ieee.org
I totally disagree with the idea of abandoning plugins.
In fact the easy extensibility with plugins according to me is one of
the historical advantages of ImageJ. Almost the entire IJ is plugins.
If you abandon the plugins many people will switch to versions/distros
of IJ which support them
Dimiter
In fact the easy extensibility with plugins according to me is one of
the historical advantages of ImageJ. Almost the entire IJ is plugins.
If you abandon the plugins many people will switch to versions/distros
of IJ which support them
Dimiter
Johannes Schindelin
Dec 16, 2009, 8:23:41 AM12/16/09
to Wilhelm Burger, ImageJX, Adrian...@gmx.de
Hi,
On Wed, 16 Dec 2009, Wilhelm Burger wrote:
> * Performance IS an issue and for image processing and some of us would
> prefer to rather get 10x the current power of our current computers
> than only 25%. To obtain this level of performance, some central parts
> (eg., filters and other regular but time-consuming tasks) must be
> recoded in one or the other way, possibly using GPU functionality. In
> an earlier post I called these modules "performance packs", which will
> be plattform-dependent (as as the JVM) but should be installed
> transparently to the API user.
While I agree that performance is important, I think that it is
unfortunate that the discussion about API vs scripting is sidetracked with
this unrelated issue.
Back to the real issue: somebody mentioned that the solution must be to
have an API _and_ scripting; I might want to add that they are not only
non-exclusive, but that one can follow from the other. I.e. if you have a
good scripting interface, this gives rise to an enforced API naturally.
Ciao,
Johannes
On Wed, 16 Dec 2009, Wilhelm Burger wrote:
> * Performance IS an issue and for image processing and some of us would
> prefer to rather get 10x the current power of our current computers
> than only 25%. To obtain this level of performance, some central parts
> (eg., filters and other regular but time-consuming tasks) must be
> recoded in one or the other way, possibly using GPU functionality. In
> an earlier post I called these modules "performance packs", which will
> be plattform-dependent (as as the JVM) but should be installed
> transparently to the API user.
unfortunate that the discussion about API vs scripting is sidetracked with
this unrelated issue.
Back to the real issue: somebody mentioned that the solution must be to
have an API _and_ scripting; I might want to add that they are not only
non-exclusive, but that one can follow from the other. I.e. if you have a
good scripting interface, this gives rise to an enforced API naturally.
Ciao,
Johannes
Wilhelm Burger
Dec 16, 2009, 9:15:14 AM12/16/09
to ImageJX, Johannes....@gmx.de, wil...@ieee.org
Johannes,
On 16 Dez., 14:23, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
down this discussion - though I still think performance should be kept
in mind from the beginning. It may partially answer the question,
whether plugins are important or not. For example, Adobe Photoshop
provides a (rather complex) C-based plugin mechanism that is used to
implement many high-perfomance routines - of course not by average
users but skilled programmers. It also provides scripting at a higher
level for the end user. In contrast, InDesign has no plugin capability
that I know of but explicitly supports scripting with JavaScript etc.
Unfortunately, the speed penalty makes it difficult to implement
anything but small scripts.
> Back to the real issue: somebody mentioned that the solution must be to
> have an API _and_ scripting; I might want to add that they are not only
> non-exclusive, but that one can follow from the other. I.e. if you have a
> good scripting interface, this gives rise to an enforced API naturally.
I am not sure I understand this. I assume one could implement
something like ImageJ using only the plain Java JDK (ImageIO etc.) and
JavaScript on top, without any additional API, no? Can you explain
what you mean by "a good scripting interface"? And what is (or should
be) the role of plugins from your point of view?
--Wilhelm
On 16 Dez., 14:23, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
> Hi,
>
> On Wed, 16 Dec 2009, Wilhelm Burger wrote:
> > * Performance IS an issue and for image processing and some of us would
> > prefer to rather get 10x the current power of our current computers
> > than only 25%. To obtain this level of performance, some central parts
> > (eg., filters and other regular but time-consuming tasks) must be
> > recoded in one or the other way, possibly using GPU functionality. In
> > an earlier post I called these modules "performance packs", which will
> > be plattform-dependent (as as the JVM) but should be installed
> > transparently to the API user.
>
> While I agree that performance is important, I think that it is
> unfortunate that the discussion about API vs scripting is sidetracked with
> this unrelated issue.
Right, this is a side line and I will be more than happy to narrow
>
> On Wed, 16 Dec 2009, Wilhelm Burger wrote:
> > * Performance IS an issue and for image processing and some of us would
> > prefer to rather get 10x the current power of our current computers
> > than only 25%. To obtain this level of performance, some central parts
> > (eg., filters and other regular but time-consuming tasks) must be
> > recoded in one or the other way, possibly using GPU functionality. In
> > an earlier post I called these modules "performance packs", which will
> > be plattform-dependent (as as the JVM) but should be installed
> > transparently to the API user.
>
> While I agree that performance is important, I think that it is
> unfortunate that the discussion about API vs scripting is sidetracked with
> this unrelated issue.
down this discussion - though I still think performance should be kept
in mind from the beginning. It may partially answer the question,
whether plugins are important or not. For example, Adobe Photoshop
provides a (rather complex) C-based plugin mechanism that is used to
implement many high-perfomance routines - of course not by average
users but skilled programmers. It also provides scripting at a higher
level for the end user. In contrast, InDesign has no plugin capability
that I know of but explicitly supports scripting with JavaScript etc.
Unfortunately, the speed penalty makes it difficult to implement
anything but small scripts.
> Back to the real issue: somebody mentioned that the solution must be to
> have an API _and_ scripting; I might want to add that they are not only
> non-exclusive, but that one can follow from the other. I.e. if you have a
> good scripting interface, this gives rise to an enforced API naturally.
something like ImageJ using only the plain Java JDK (ImageIO etc.) and
JavaScript on top, without any additional API, no? Can you explain
what you mean by "a good scripting interface"? And what is (or should
be) the role of plugins from your point of view?
--Wilhelm
Adrian Daerr
Dec 16, 2009, 12:21:10 PM12/16/09
to ima...@googlegroups.com, wil...@ieee.org, Johannes....@gmx.de
> Johannes Schindelin wrote:
>> Back to the real issue: somebody mentioned that the solution must be to
>> have an API _and_ scripting; I might want to add that they are not only
>> non-exclusive, but that one can follow from the other. I.e. if you have a
>> good scripting interface, this gives rise to an enforced API naturally.
>
> Wilhelm Burger replied:
>> Back to the real issue: somebody mentioned that the solution must be to
>> have an API _and_ scripting; I might want to add that they are not only
>> non-exclusive, but that one can follow from the other. I.e. if you have a
>> good scripting interface, this gives rise to an enforced API naturally.
>
> I am not sure I understand this. I assume one could implement
> something like ImageJ using only the plain Java JDK (ImageIO etc.) and
> JavaScript on top, without any additional API, no? Can you explain
> what you mean by "a good scripting interface"?
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.
> something like ImageJ using only the plain Java JDK (ImageIO etc.) and
> JavaScript on top, without any additional API, no? Can you explain
> what you mean by "a good scripting interface"?
Adrian, interpreting Johannes through his crystal ball :-)
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Wilhelm Burger
Dec 16, 2009, 1:22:34 PM12/16/09
to ImageJX, Adrian...@gmx.de, Johannes....@gmx.de, wil...@ieee.org
Hello Adrian,
> > what you mean by "a good scripting interface"?
>
> 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.
Yes, I would absolutely agree. Everything else means unnecessary work
and results that are error prone and never complete. Thanks for
clarifying.
> Adrian, interpreting Johannes through his crystal ball :-)
Just wonder (since I have not used the Java scipting API) - do IDEs
(Eclipse and so) yet support features like auto-completion etc.
between JavaScript and Java?
--- Wilhelm
> > what you mean by "a good scripting interface"?
>
> 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.
and results that are error prone and never complete. Thanks for
clarifying.
> Adrian, interpreting Johannes through his crystal ball :-)
(Eclipse and so) yet support features like auto-completion etc.
between JavaScript and Java?
--- Wilhelm
Reply all
Reply to author
Forward
0 new messages