Print

Print


Forwarded on behalf of Krysztof, who is having difficulty posting
himself.

Sean

Begin forwarded message:

> From: Krzysztof Krawiec <[log in to unmask]>
> Date: October 26, 2005 2:17:05 PM EDT
> To: Sean Luke <[log in to unmask]>
> Subject: ECJ upgrade
> Reply-To: [log in to unmask]
>
>
> Dear Sean,
>
> For some technical reasons I could not send my posting to ECJ-
> INTEREST-L list, though I'm its member since may 2004. Would you be
> so kind and send this posting for me (attached below)?
> Thanks in advance,
> Chris
>
> -------------------
>
> Dear all,
>
> Let me shortly express my opinion on the very hot topic of the
> hypothetical ECJ 'revolutionary' upgrade.
>
> I think that in this discussion we miss an important point: who is
> ECJ's
> 'consumer', i.e., who is ECJ targeted at? I always thought that
> Sean's idea was mostly to provide the community with an open,
> flexible, extensible, and object-oriented framework for performing
> advanced research/experimenting in EC (correct me please if
> I'm wrong). From the discussion we've been listening to recently,
> I've got an impression that major ECJ's mission is to meet the most
> recent standards of software engineering and IT in
> general. From my viewpoint, this is putting the cart before
> the horse.
>
> I have been using ECJ since its sixth version, not only in its basic
> ('standalone') form, but also extending it in many ways, including:
> - distributing individuals' evaluation on a cluster of PCs (using ECJ
> version 8),
> - integrating it with C/C++ (computer vision libraries) via JNI,
> - combining it with other Java libraries (WEKA, Java Advanced
> Imaging),
> - coevolution (before it was introduced in ECJ).
>
> Believe me or not, but I have never met any substantial technical
> difficulties that would prevent me from implementing my ideas in
> ECJ. With a few minor exceptions, ECJ worked well and effectively.
> Extensions were easy to implement by creating new classes inherited
> from ECJ's class hierarchy and overriding a few methods. The
> placement of those classes in  particular directories of ECJ file
> hierarchy was of secondary
> importance for me.
>
> IMHO, the potential benefits resulting from the proposed changes are
> rather minor and of technical character. For instance,
> the MAKE/ANT issue matters mostly if ECJ is to be frequently rebuilt
> (this applies also to some other issues discussed here, like code
> formatting style). And this is not the way most people use it, AFAIK.
> On the other hand, the price to be paid for those changes may be
> substantial, loss of backward compatibility for example.
>
> This is of course my viewpoint that results from my personal
> experience
> with using ECJ. But so far I did not notice in this discussion
> any opinion like this mine, that's why I've decided to add my two
> cents.
>
> If I'd have any right to vote, I'd vote for evolutionary rather than
> revolutionary changes in ECJ ;)
>
> Regards,
> Krzysztof / Chris
>
> | Krzysztof Krawiec, Ph.D., hab.
> | http://idss.cs.put.poznan.pl/~krawiec/
> | Intelligent Decision Support System Lab (IDSS)
> | Institute of Computing Science
> | Poznan University of Technology, Poznan, Poland
>
>
>
>
>