[Freeciv-Dev] Re: Python?

[Raimar Falke <i-freeciv-lists@xxxxxxxxxxxxx>]

On Sat, Nov 22, 2003 at 04:14:37PM -0800, Brandon J. Van Every wrote:
> From: Vasco Alexandre Da Silva Costa [mailto:vasc@xxxxxxxxxxxxxx]
> > On Fri, 21 Nov 2003, Brandon J. Van Every wrote:
> > >
> > > Has anyone ever been interested in making the Freeciv code OO, i.e.
> > > migrating away from C by gradual, hodgepodge methods?
> >
> > [snip failed C++ OO story of woe]
> 
> I would submit that OO has many possible pitfalls, and these have to be
> mastered before OO is of real use.  For instance, the pitfall of useless
> refactoring.  You only want to refactor things that you *know you need
> now*.  Don't waste time refactoring for abstract, perceived future
> benefits.  Most of those benefits will never materialize, because you'll

Ack.

> take too long doing your project and then your project will be cancelled
> somehow.  Not enough time, energy, money, or morale to continue with it.

Freeciv as a project will not be canceled because it took too much
time, energy or money. Developer may not contribute anymore. But this
is not because of refactoring.

> There are 2 kinds of C developers:
> - those that don't know OO methodologies
> - those that do, but are using C on a particular legacy project

Hopefully we all fall in the second category ;)

> Python of course sounds much better to the latter than the former.  I
> agree that C++ sucks, make no mistake.  The problem is, for a lot of
> problem domains C also sucks.  It is merely a portable assembler.

C isn't perfect. Show me the better alternative.

> > I spent precious time with this useless effort when I could have been
> > adding *features* which is what users really want.
> 
> The question is, do you find all of your features easy to code in C?  If
> so, there's no reason for you to change what you're doing.  Your
> language is fitting your problem domain.

> On the other hand, do you find that implementing certain features in C
> is a real chore?  Do you hate the amount of time and pain it takes for
> you to accomplish certain things?  Do you avoid certain things because
> you *have* been there, done that, and you know that C isn't going to get
> you anywhere?  If you find yourself running into these sorts of issues,
> it is appropriate to use a language more suited to your problem domain.
> Something higher level than a portable assembler.

An alternative is to make yourself comfortable in C. Adding code which
handles lists easy. Adding code allows you to easy use a set of bits
and so on.

> Speaking for me personally, C only makes me happy when I'm preparing to
> implement standalone ASM files.  I don't need it for inline ASM, only
> for standalone ASM.  C has easier calling semantics than C++ if you're
> going to write a function entirely in ASM.  I always write a C version
> of the function before writing the ASM version, so that I have a "known
> good" to compare it to.

Writing ASM? Where do you need that these days? Access to the special
instructions (MMX, SSE) which the compiler doesn't support?

> C++ makes me happy when I need high performance, am not ready to drop to
> ASM yet, and can keep the design very simple.  The minute the design
> gets complicated, I start to hate C++.  In the future I'll be happy to
> do as little C++ code as possible.
> 
> > C is simple, portable and it works. C++ is complex, less portable.
> > Java leads to ugly code and is slow, Python is even slower.
> 
> But Python does not lead to ugly code and is fast to implement.  The
> tradeoff is developer time vs. program execution time.  For most things,
> I know where my priorities are!

> I mean look, for instance, I've submitted a bug about the server dying
> because the map reveal takes too long.  C doesn't automagically save you
> from performance nightmares.  You have to use your brain and design
> well, or at least use your profiler if you're opposed to using your
> brain.  :-)

The GUI output is too slow. Every layer adds cost. The xaw client is
fast compared to the gtk1 one. The gtk1 client is fast compared to the
gtk2 one. It looks like the win32 client is even slower than the gtk2
one.

> > C# actually would be ok if it could be compiled to binary
> > format, didn't
> > require a huge runtime to do anything, wasn't designed by MicroSoft.
> 
> Being designed by Microsoft is not a problem.  Being beholden to
> Microsoft is.  There are standards efforts; some have been completed,
> others are underway.  I'm unclear about the details.  I don't yet care
> because I'm a Windows developer.
> 
> > We need better graphics, sound, higher level features with sane code.
> > We do not need to get stuck into a language porting morass.
> 
> The question is whether Python OO-ification actually makes better
> graphics, sound, and higher level features easier.  I doubt it can make
> the creation of Art and Audio assets easier.  I think you need artists,
> musicians, tools, and standard file formats for that.  But certainly
> it's a good choice for higher level features, being a higher level
> language with built-in list and hash table types, etc.

> I haven't perused the Freeciv codebase, actually.  My experience looking
> at the Xconq codebase is there's no way in hell I'm touching that stuff
> "as is."  Wondering about which of the 400 functions I need to implement
> to get an AI or a new GUI going, no thanks!  I've talked to some of
> their mailing list lurkers, and some have said, "Yeah, if only we had
> Python or something like that, we'd actually contribute something."
> Most people in 2003 do not like C for application development.

Is this really a problem of the language? It can also come from poor
naming, poor abstraction, poor documentation and a lot of other
deficits. It doesn't have to be the language.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Living on earth may be expensive, but it includes an annual free trip
  around the sun.