Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: C vs C++ vs Java
Home

[Freeciv-Dev] Re: C vs C++ vs Java

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gregor@xxxxxxxxxxxxx
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: C vs C++ vs Java
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Mon, 03 Dec 2001 02:45:24 -0500

The Choice of language should depend on your design goals. And in
some designs using a number of languages may make more sense than
a mono-cultural decision.

If there is no real change in style, stick with "C" and make the 
most of code reuse and of dinosaur programmer's reflexes :-).

If you are going to do something more adventuresome, then Java has
a lot of strong features. Most of the ones cited as reasons against
like "no pointers" are actually very strong reasons for, but there
will need to be a significant shift in programming style to make
this work and I suspect you will lose most of the older crowd, and
a lot of short-range, linear thinkers.

An Application Framework is not developed by people looking for neat
unit Objects, or concerned about keeping the binary statically linked
into a rigid monolith.

On the otherhand an Application Framework may give you a game in which
Freeciv vs Teamciv is just a matter of how many additional Displays
or autonomous console apps you want to spin off to handle your Civ
management issues. Or whether you use a CivII or CivIII ruleset and
load in a small class of alternate plugins for the appropriate 
extension flavours like new unit commands, whether you want to play Civ 
II with an AC Governor/Display setup (with Civ II menu/actions of course), 
etc.

Also, it is really worthwhile to figure out how to come up with a 
prototyping interpreter for really fast development. After building 
things and experimenting in a highlevel mode, you can recompile or
reimplement the submodules in a lower level mode and add them into 
the available configuration options for mix and match play. 

Python is actually supposed to be somewhere between Java and Perl
with Java on the programming language side, and perl the interpreter.
But it really isn't widespread, or supported enough to be a good
choice yet and it has faults of either side as well as benefits. 
But Python and Perl, or even ksh might be useful for some elements.

The key to this is good interfaces, highlevel design concepts and
modular building blocks that only get specific at the last subclass
or ruleset parameterization. With an appropriate adapter, you should
be able to hook almost anything up to anything else through the defined
interface, and have it just work as a configurable runtime option.

And, one last thing ... this is a network client-server application,
so heterogeneous, portability really helps. Running the same binary
code everywhere, or being able to ship pieces of it around as opposed
to going through layers of translation and protocol, is a good thing.
When you deal with objects, remember this is code+data.

Cheers,
RossW
=====

At 01:51 PM 01/12/02 +0100, Gregor Zeitlinger wrote:
>Ok. We've had a long discussion about what language to use.
>I think it's clear that C, C++ or Java are the only viable choices. I
>heard alot of positive Java feedback, which I like. Then some said C is
>the only way to go.
>So what's acutually the point of using C++? I heard the ACE, but the
>licence issue is still pending there and I'd bet there's something for
>Java alike, although I'd have to check.
>
>So what I'd be interested in. How many programmer are would be willing to
>use which language.
>
>-- 
>Gregor Zeitlinger      
>gregor@xxxxxxxxxxxxx




[Prev in Thread] Current Thread [Next in Thread]