[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

[Stepan Roh <stepan@xxxxxxxx>]

On Sun, 2 Dec 2001, Andrew Sutton wrote:

> On Sunday 02 December 2001 07:40 pm, Stepan Roh wrote:
> > Java speed is not an issue. JIT compilers are doing well. Truly compiled
> > Java is in its early stage, at least in GCC suite, and I certainly won't
> > be using it for production code, but maybe someday....  The biggest Java
> > problem is that it takes a lot of memory. GC, threads, objects, everything
> > takes memory which is not under your control (contrary to C). RMI (if used
> > for networking - I discourage from that as it is strongly Java-tied)
> > consumes more bandwidth than plain sockets (possible in Java too). But
> > Java has better designed OO than C++ (which is a mess).
>
> right... but c++ doesn't incur all that overhead for GC and threading (as
> threads are implemented externally). also, java RMI is based on CORBA - it
> uses IIOP for the protocol.

No, that's not true. It runs over its own protocol suit. You can switch to
RMI-IIOP, but than you'll loose DGC (distributed GC) and things go little
bit slower.

> if we use java RMI, we might as well be using CORBA. anyway, RMI isn't
> sufficient for a protocol. for one thing, RMI and CORBA don't really
> support server-to-client notifications - and this is a requirement of
> freeciv.

It can be done "easily" by sending client remote object to the server.
But that means you have 2 two-way sockets instead of 1 two-way socket,
which is bad. As I say, RMI is a bad choice for freeciv, using plain
sockets is better (which can be also done in Java, of course).

> as for the java/c++ issue, i think i could really care less. i'm much more
> familiar with c++ - MUCH more familar, so it's my preference. but we'll see
> what comes out in the wash.

I personally dislike OO syntax in C++. Interface is not separated from
implementation, multiple imheritance causes problems (virtual classes?
pah), I/O (<<,>> and iostreams) is complicated like hell (composition is
used more those days), STL is overkill (well, Java's Collection Framework
is not very well designed too) and C++ Task Group (or how they are named
in ISO or where) is definitely group of mad people :-).

> as for the configuration language, we could write our own. it might not be a
> bad consideration.

There are dozens of all-purpose as well as specific function aimed
languages. No need to write new one. I think that rule-based or functional
language will be probably the best choice for it. What about lisp?  xconq
has whole logic written in it (I think).

I don't think that rewriting Freeciv is necessary, but if someone will do
it in C++ or Java or whatever, I can live with it. But first of all, some
goals should be made and some design docs should be written. And some
UML diagrams (that's very modern :-) ).

Have a nice day.

Stepan Roh