Print

Print


My general experiences with software are the reverse. Coding for easy of use
makes hacking it much easier. The two should reinforce each other. For
example, if the GUI of ECJ would be packaged in a seperate 'project' which
would be dependent on ECJ itself, it would be easier to download and compile
ECJ, because it would not have the useless dependencies on the extra
libraries. The same would be the case for all the 'app' examples. They
should also be split off in a second example project. This is the way I
always structure my projects, I try to refactor things out so that the core
has the least amount of dependencies as possible. This improves hackability
because its easier to concentrate on one part of the program (and it
compiles much faster as well).
The same argument holds for using Java 1.5 generics.
 But on a side note, I don't think forking ECJ is a good idea. I would
prefer a Sourceforge version, where user contributions get merged in every
so often and where a open discussion about the project can be held (like now
on the mailing list).
 All new additions to ECJ should be weighted and judged on these issues:
- performance
- extendibility
- coding practices (cleaner code is easier to hack and extend)
 On a second side note. When dealing with research programmes, it should
never be a big deal if people use the latest and greatest version of
something, in our case Java. It is not business critical software which
should 'prove' itself first, it's research code. Which can be buggy by
itself and probably is a lot more buggy than Java 1.5. The first versions of
1.4 where so much more unstable than the first version of 1.5. I can't say
much about 1.0-1.3 because I didn't program that much with Java in those
times. The use of generics and arrays are a good thing for extending a
program because they enforce type safety, so I say take the plunge and
slowly incorporate Generics to ECJ.
 Arjan
 On 10/27/05, Peter Day <[log in to unmask]> wrote:
>
> I second that Krysztof's opinion.... I have been using ECJ to test /
> devlop new
> EC methods and have found it highly extensible and hackable - generally
> ease of
> use comes at the cost of versatility (which is imperitive to research).
> However I would be interested in a public packages repository in which
> people
> could deposit new & recently published evolutionary methods with
> descriptions
> and examples (such as alternate structures, parent selection strategies
> etc...).
>
> just my 2c,
> Peter
>