Proposing to change the implementation language for a large project is
hardly uncontroversial, but when that proposal calls for moving from C++
to Python, one might expect an enormous flame fest. Surprisingly, a proposal to do just that with the code for the
"Battle for Wesnoth" strategy game
has resulted in a fairly flame-free discussion. Whether or not the project
actually makes the switch—it looks unlikely that any wholesale
switch is imminent—there is a great deal of value in the discussion,
particularly in its tone.
Eric Raymond is the Wesnoth developer proposing this shift, but it is not
his "personal fondness" for Python that is behind it. Instead, he sees it
as a way to reduce bugs. Raymond has been handling bug triage for the
project for the last year or so, which gives him a good grasp of where the
Wesnoth bugs tend to be:
I know where we are
vulnerable and where we tend to screw up. And *that* is why I want to
get cracking on shifting as much of the code to a language with true
variable-extent types as possible.
Raymond is cognizant of the downsides of moving to Python as well. First,
Wesnoth developers will have to be familiar with both languages, which
Raymond, at least, does not view as a problem: "Python
is much easier to pick up than C++". Performance is another
concern, one that he glosses over with a breezy "machines
are still getting faster"—others seem less sanguine
about the issue—but he does see two major benefits:
1) No more memory-allocation screwups, *ever*. Python has no pointers
and is garbage collected; Python applications cannot core-dump. The
complex tangle of standard and local custom memory allocators we
presently use, and that are the source of so many of our bugs, will
be chopped away as we move to Python -- and good riddance.
2) I have observed Python code is between 2 and 5 times more compact
than C/C++. The higher end of the range is achieved by
data-structure-intensive programs like Wesnoth. This is significant
because one of the best-established results from large-scale software
engineering is that defect-per-KLOC rates in large codebases are
*insensitive to the language used*. One of the normal effects of
moving to a higher-level language is to decrease the KLOC of the
codebase, and as a result to decrease the bug load.
Attracting more developers to the project is another reason to move to
Python, one that lead developer David White—often referred to by his
IRC nickname "Sirp"—is motivated by. Raymond has been thinking about
how to move Wesnoth to Python for a while, without making any progress, but recently a new developer,
Ivan Illarionov, has appeared on the scene having translated some portions
of Wesnoth into Python. Just how much has been done is still something of
an open question, but his approach is an evolutionary one. That is important to White:
Rather, we should take an evolutionary approach to matters. Python
already exists in Wesnoth, as an AI framework. Developers who think that
Python would advantage Wesnoth should simply begin implementing
additional components in Python.
If someone is developing a new component for Wesnoth, and that person
thinks the component would work best in Python, they should do so. If
someone is one of the primary maintainers of an existing implementation
of a component, and they feel that component would be more maintainable
in Python, then they can re-implement it in Python.
Overall, the reaction has been fairly positive, Wesnoth developers seem to
be open to the possibility that C++ is not the be-all and end-all of
languages for game development. That said, they aren't necessarily willing
to hear new developers obnoxiously proclaim that Wesnoth should be redone
because Python is "better" than C++, without much in the way of details.
Unfortunately, that is the tack that Illarionov has taken, which led White to
I'm going to be really honest: you're presenting yourself in entirely
the wrong way to the project. I don't think very many people care much
to hear "this code here should be in Python because it is better for it
than C++!!!" What we'd much prefer to hear is, "I implemented this
really cool feature which our users will love, and oh yeah...the
implementation is in Python."
Illarionov also ran afoul of Raymond, who publicly castigated him: "You [have] done
such an inept and -- at times --
arrogant-seeming job of presenting yourself that you have already
alienated some senior developers on this project in just the few days
since you've shown up here." Illarionov replied contritely, but
almost immediately stirred things up again by a posting with the subject
"Wesnoth refactoring and future direction plan". In that
thread, he also points to Linus Torvalds's rant about C++, which just gets further under
the developers' skin.
But, the Wesnoth developers have shown
a great deal more patience than many development groups would.
As White puts it: "Trust me, if you sent an email
to the Linux Kernel Developers Mailing
List entitled 'Linux refactoring and future direction', you would
receive MUCH more hostile responses then you have received here."
It is likely that much of the tone of discussion on the wesnoth-dev mailing
list derives from White's leadership; the contrast between his and, for
example, Torvalds's more combative tone is quite apparent.
There are hints that some of the conversation has been less civil,
especially on IRC but, on wesnoth-dev, even the rebukes have been relatively
polite—certainly by the standards of most development mailing lists.
This is a project struggling with a difficult decision without lashing out
at those questioning it or outright opposing it—or for that matter,
those ineptly championing it. The wesnoth-dev conversation went quiet
around January 6th, but the project is known to be very active on IRC, so
perhaps it moved there. Even if that turned ugly, the email
conversation sets quite an example.
Should it come to pass that Wesnoth starts including more
Python—by Raymond and Illarionov or others—we will get an
opportunity to see if the hoped-for improvements come about. Projects
often consider which language to choose, either initially or for
a reimplementation, but there are few examples or case studies of
comparative language benefits. A year or two down the road, Wesnoth might
provide just that kind of comparison.
to post comments)