Re: [gnugo-devel] Gnu GO java1.5 porting

[Paul Pogonyshev]

Hi,

Just to note: I'm not a Java-hater, I'm programming in Java at my current
paid job.  I just happen to be sceptical about this stuff...

Harri Salakoski wrote:
> Just to inform you for new GnuGo Java porting project. [...]
>
> [...] I think pointer
> logic really does not give anymore much benefits in c++? So please avoid it
> :)  propably has no effects, but tried :))

Where do you get this information from?  Pointers r g00d.  Besides, GNU Go
is written in C, not C++.

> There is some developer reasons for porting(there is other more subjective
> reasons also): Javas collections framework and OO code makes code clearer
> than orginal.

Simply translating something in a different language doesn't make anything
clearer.  The most complicated things in the GNU Go is the engine.  I doubt
you will manage to clean it up a lot while translating.

Also, simply translating something into a language that is object-oriented
doesn't automagically make that something object-oriented.  You could write
OO-styled in C or not OO-styled in Java.  Java just makes going OO easier.

> Computers change faster and base speed is not so important anymore

Yet we prefer to optimize for speed when possible.  GNU Go is a CPU-intensive
program.

> (actually it is easier to code very advanced data structures using
> java and so on results can be sometimes even better)

That depends on your being able to code advanced data structures in C.

> Most of data structures are change dynamic size for example. XML makes input
> output implementations simpler and cooler :). XML is used file format.
> There is converter to      convert GnuGo patterns for XML. XML is used also
> in game format instead of SGF(and converter still misses branches).

I don't think this is a good idea.  XML is OK, but SGF is an established
and widely supported format for Go game records.  By switching to XML you
are losing compatibility with many programs.  GTP also relies on SGF to
some small extent.

> Out of porting or don't work:
> Pattern reading and usage don't work yet.
> Caches role are unclear or are out of porting like this new persistent
> cache. all parts not belong AI are out of porting.
> testing procedures are not ported(quite much work there)
> features marked as #if 0 are out
> ..

To summarize, you are leaving out large part of the infrastructure we use for
developing and debugging GNU Go.

> If there is some intrest in GnuGo community for those XML things or porting
> details I send more info. So far porting has been advancing faster than new
> code is added gnugo I think.

Well, new code is added very slowly lately, so that's not much of a surprise.

Can you please explain what are aiming at with your Java port?  Do you intend
to fork off when you catch up with GNU Go 3.6 and develop independently?

Paul