Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2003:
[Freeciv-Dev] Re: Python?
Home

[Freeciv-Dev] Re: Python?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Freeciv-Dev" <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Python?
From: "Brandon J. Van Every" <vanevery@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 23 Nov 2003 04:38:14 -0800

This is long, but IMO cordial.  As I said before, this is not a war for
me.  I didn't expect anyone here to be interested in doing any Python
code at all.  I'm just planting some seeds in your brain, to see if they
possibly flower into Python "someday."  If you hear this sort of stuff
from enough people, and somehow it starts ringing true, you might make
the move.


From: Vasco Alexandre Da Silva Costa [mailto:vasc@xxxxxxxxxxxxxx]
> On Sat, 22 Nov 2003, Brandon J. Van Every wrote:
>
> > 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.

With that level of experience, I don't understand why you ran into so
many OO disasters.  I can understand why you might have run into *C++*
disasters, it's a shit of a language as things get more complex.  But
surely, you've figured out how to avoid gratuitous refactoring mistakes
by now.

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

Those who can, do.
Those who can't do, teach.
Those who can't teach, administrate.

I'm sorry, but "OO is a step backwards" is the biggest foolishness I've
heard in a long time.  The vast majority of the computer industry does
not agree.  OO approaches are commercially proven to save work *when
correctly applied.*  OO is not a step backwards; people can always use
any programming paradigm regressively.

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

Anything complicated is going to be unreadable except at the local
level.  That's the point: at least you can locally understand it.  You
want global understanding, you're going to have to sit around and
scratch your head a loooooong time, with any system.  At least the OO
approach doesn't force you to swallow it all at once!

> You might say you aren't forced to program like this. The
> fact is all the C++ code I usually see is like this.

OO is not the problem.  C++ is the problem.  It's baroque and awful.

> If you look at the nightmare of
> muck code that is a C++ STL implementation, then you start to
> get sick.

You are preaching to the choir.  Again, OO != C++.

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

Really.  At the risk of drifting into topics nobody cares about, please
eneumerate the various ways in which C is "more than a portable
assembler."  Feel free to do so by private e-mail if you think people
will get tired of this.  And fair warning: I won't debate the point for
long.

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

Hm, not how I'd call it.  The major problem of C is a lack of data
encapsulation, inheritance, higher level data types, and garbage
collection.  Libraries, I know about plenty of C 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.

So if this bugs you, switch to Python and be happy.

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

Why are you so worried about bringing in "the whole house?"  This is
2003.  Unless you're doing embedded stuff, being a resource miser is an
inappropriate attitude.  If you're going to be cheap with your
resources, you're going to get what you pay for.

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

Well, it's ok to move on to standard paradigms, and not defend ancient
un-integrated cruft unduly.  "If only Cobol were just more like this and
that...."  Well, that's why people came up with other languages.

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

Yes but Freeciv got started in 1995.  I was writing a 3d software
rendering library called "Free3d" back then, on a 486.  We didn't have
3d graphics cards on PCs back then!  This is 2003.  If you think
computers can't handle Python you're being a cheap bastard.

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

I don't have to wonder.  I live in Seattle, just an artillery shell away
from MicroSquish.  Have you ever wondered why 53% of the job sites are
asking for Java?  It's got the greatest job market share of any language
out there.  If you think "nothing meaningful" is written in Java, you
are simply not respecting / understanding the problem domains it has
been applied to.

> Interpreted languages are used for toy programs, for simplistic
> interfaces.

That's a profound prejudice.  I've been a 3d graphics optimization jock
for 11 years.  Have you done enough nitty gritty high performance
optimization to know when it is needed and when it is not?  Or are you
one of these guys who thinks "everything" has to perform?

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

What the hell difference does it make?  A huge honkin' bottleneck is a
huge honkin' bottleneck.  You are worrying about the order of smalls.

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

Maybe not.  I'm not sure how much the Mono project has accomplished in
this regard.

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

No, I don't.  I don't care about anything that asshole company produces.
I hate their churn rate, and I do my best to distance myself from it.  I
refuse to become an expert in every single damn thing they barf out of
their Redmond guts.  That's how they control people, by "burned out
lightbulbing" them.  As a developer, it is the primary waste of my time.
But I am a pragmatist, I know where the game market is at.  I can only
distance myself from Microsoft, not escape it.  Some of their tools are
better for working with their GUIs than anything else, so I use those.

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

Built into the language, interpreted, and dynamically typed?  I doubt
it.  And no, I haven't noticed.  I haven't looked at Freeciv's codebase,
and I wouldn't unless there's some interest from some quarter about
embedding Python in it.

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

Well, I don't know how well organized your Freeciv code is.  In the
Xconq code, both the GUI and the AI were deeply entwined everywhere.
Looked like nothing but pain as far as the eye could see.  The only line
of separation was "kernel" vs. "GUI," and those 2 layers talked to each
other so much, how could you tell them apart?  Look through 400 Tk GUI
functions to figure out how to write a new GUI?  No thanks!

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

Realities of having looked at C projects before.  Knowing what's
required to make minimal changes to get a new GUI or AI working.  OO is
a superior paradigm when you don't want to understand and just want to
change a little thing.

Freeciv might surprise me, but I won't know unless someone says they're
interested in embedding Python.  :-)  Meanwhile, "as a gambling man," I
concentrate my energies on finding projects where I don't have to
convert anybody.

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

Again... OO != C++.  You are preaching to the choir.

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

Well, part of your problem is possibly the amount of time it takes you
to do those things in C?  Only you could judge that.  If C is
lickety-split for all patches and features you try to implement, then
you don't have any problems.  "It's working for you."




Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie



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