indeed the solution in java is to code @specialized, most likely with
it provides run-time specialization
+ no need to recompile to support new datatypes
+ smaller binaries
- slower startup
while I'm a die hard fan of functional programming (haskell in
particular), these hyped languages cost a lot to use:
* typically poor tool support (IDEs)
* at minimum, refactoring tools are still weak for Scala
* tools to refactor code in multiple languages does AFAIK not exist at all
* not a problem for scala, but python/perl/ruby all have dynamic typing.
these are unsuitable for large scale programming or code you want to be
able to read
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
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...
> I have seen a suggestion of OSGi. I think it is tested by many people,
> flexible and would be a good option. About the complaint against the core
> plugins option: you can sign the core plugins and based on the presence or
> absence of that signature you can give more or less permissions (for example
> to access the menu/toolbox/...) for the plugins. I would definitely go on
> this way (I mean to have even some of the core functionalities as
> plugin(s)). The plus side of OSGi that you can have multiple versions of a
> bundle loaded to your application, so if there is an incompatibility between
> versions you can have more loaded.
I have seen complaints against OSGi for being very heavy-weight
(disclaimer: I have not used it). in fact, I think the plugin hysteria
has been taken a bit too far in many cases; most of the time you just
want code to be modular and easy to add. things like loading/unloading
plugins during runtime might cost more in terms of work than it
provides. after all, this is something that has to be coded into each
plugin so it's not a pay-once cost.
given how many features you can squeeze into 1MB code (vs 10GB images),
it's hard to even motivate why you would like to download plugins
separately rather than the entire project in one go. that cuts away the
need for a plugin manager and yet another automatic updating system
(that has to be made secure).
check java 1.7 super packages if you haven't already.
> It would be really cool if there were an option to use -if available-
> computations/transformations... (
> JOCL <http://www.jocl.org/>)
you can also use the OpenCL bindings I have written for Endrov.
unlike JOCL, it's open source