[Freeciv-Dev] Re: Python?

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

On Sat, 22 Nov 2003, Brandon J. Van Every wrote:
> From: Vasco Alexandre Da Silva Costa [mailto:vasc@xxxxxxxxxxxxxx]
> > On Fri, 21 Nov 2003, Brandon J. Van Every wrote:

> 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
> 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.

> 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

What you may not realize is that I have done several 10k-50k projects in
C++. Of those only *one* was well suited for a pure OO methodology.
A raytracer.

OO is usually a waste of time. Encapsulation and separation of data on
the other hand are nearly always useful. However, like one of my teachers
used to say, C++ and other OO languages are a step *backwards* in
this respect because they mix code with data declarations. Then they go
even more backwards by encouraging people to do it. A C++ class declaration
is an aberration.

Just watch the trends in OO language design. You declare variables
anywhere, put some code in the class declarations, some other code
somewhere else. It is a nightmare of unreadability, that is what it is.

You might say you aren't forced to program like this. The fact is all the
C++ code I usually see is like this. If you look at the nightmare of
muck code that is a C++ STL implementation, then you start to get sick.

> 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.

It is not just a portable assembler. It may be a concise language, but it
is much more than that. Sure it has its faults, but I would rather take
its faults than those of other languages in most cases.

> 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.

In retrospect, I could have added everything I wanted to add in C using
the time I wasted dabbling in C++.

The major problem of C is a lack of large standard libraries. The major
advantage of C is a lack of large standard libraries.

Say you want to use regular expressions. Or arrays, lists, trees, etc.

Java, Python, etc come with all this crap built-in. Perl at least comes
with regular expressions AFAIK.

The C standard library doesn't have it, so you either roll you own (most
people do), or use a pre-existing version. If you don't roll your own
you have to bother with how the user will install the requirements, etc.

This means you have to search for libraries or make libraries instead of
spending time coding in the first place like in say Java or Python. Which
is bad.

However it also means your programs will only need as baggage the features
in the libraries they need, instead of bringing the whole house with you.

Thankfully, C has a wide range of 3rd party libraries available. The thing
is the range is so wide, no two people use the same solutions in a
consistant way.

> 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.

In my experience this usually boils down to the feeble C standard library
features more than any faults of the language on its own.

> 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.
>
> 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.

I have felt that way often in C++ as well. The funny thing is C irks me
less in large projects.

> > 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!

Standard argument. Fact is speed does matter. Check out *why* the Freeciv
project was started in the first place by the Danes and what happened to
the other project they didn't like written in Tcl/TK.

Ever wondered why there are no meaningful programs written in Java? Ever
seen a web browser, word processor, etc written in it in wide use?

No, just servlets and that kind of cruft. I remember Limewire (P2P
program) was Java based and most people avoided it like the plague. It was
hardly a complex program.

Interpreted languages are used for toy programs, for simplistic
interfaces. Some for not very large batch scripts where performance isn't
important and rapid development time is mandatory.

> 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.  :-)

At least I have more margin to work with than if I was using a slow
interpreted language.

> > 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.

Let's say I want to make a C# GUI program. What do you suggest I use?
WinForms? Oops. There goes portability.

You are a Windows developer and don't care about Microsoft API changes?
I guess you have a thinko somewhere.

> > 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.

In case you didn't notice, we have implemented those for Freeciv already.

> 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.

Hmmm... let us see. You want to change the Windows client city dialog.
Where could be the code? Perhaps in the client/ dir? Oh so many files and
directories.

gui-win32/ seems interesting... Hmmm... perhaps citydlg.c has the city
dialog code?

If you don't even try, how can you honestly say it is hard?

Regarding the "yes if it was in language X it would be better" crowd, I
point you in the brave direction followed by the last people who wanted to
port the entire codebase to C++. I warned them they were wasting their
time, but did they listen? No.

We are having enough problems trying to find time to integrate patches by
the developer community of Freeciv. We don't need useless distractions.

Features. Functionality. Things that work and do stuff. Not technology for
technology's sake. That's how you end up with Space Shuttles with less
reliability than old Apollo capsules, X-33 projects which never fly in
anything else than computer animations. Welcome to the real world.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa