Hello Before I go on, I'll note that I myself have read many Python programs and I cannot get the hand of it yet. Whereas I learned C in such a natural manner that I cannot really explain, and the object-oriented part of C++... I learned it by reading Wesnoth's source code (most parts). A good couple of books taught me the rest. And experience, experience gained while writing *my own* C++ programs - to see if you can make something simple out of a complex language. And it seems to be certainly possible for me.
But considering Eric's usual curses about C++... of course there are some parts of Wesnoth's source code which are not elegant C++ at all, but those should not be considered as "examples of C++'s illness" because they are too particular cases, e.g. current WML parser/preprocessor implementation, vconfig interface and implementation, game events implementation, etc. etc. However, most of them seem to be that way because they got added over the top of the original, tiny codebase in a bad manner; in such case the programmers are to blame, not the language. I could perfectly say that English or Spanish languages encourage people to swear and curse, or to use too few words and not be able to express themselves right; however, the fault is actually by both the people who use the language and those who taught them the language. And I am not a native English speaker. I'll now go on not considering other devs' opinions, just to note that this is my personal opinion. On Fri, Jan 02, 2009 at 10:19:26AM -0500, Eric S. Raymond wrote: > A potential contributor, Ivan Illarionov, reports that he has > translated a substantial portion of Wesnoth into Python and has a > version running with several key framework classes in Python. In his > words: "It replaces parts of WML and parts of C++, and yes, game > controller, play controller are all implemented in Python, only core > game engine is C++" The game controller and play controller parts of the C++ are a total mess. But this isn't the language's fault and could be fixed with some efforts from our part. There is both an interface and implementation tangle in it that requires a rewrite. To me it is obvious that it is caused by the addition of more complexity over the original, tiny (prototype) source code that David White wrote at the beginning. It would have happened even if it was Python. > This cracks open a problem I've been thinking about for months but > have not been able to make headway on because I've been too busy > fighting fires: Moving as much as possible of the Wesnoth codebase > out of C++ to Python. Fighting fires? Flaming about a language isn't exactly "fighting a fire". It's more like, making some more fire. > Sirp agreed in principle on IRC with moving the Wesnoth codebase > towards Python many months ago, basically in order to attract a larger > population of developers - because, even though Sirp doesn't > particularly *like* Python, he knows it's more accessible than C++. The C++ engine is a total mess due to the many developers that have worked on it, and their extremely differing coding styles (*indentation and spacing* does not count; I am talking about interface design and such things). I don't know if Python can magically solve that, but it is something to keep in mind. > The main reason to hesitate before moving core code to Python is that > it will require Wesnoth developers to know two languages before > working on the code. I do not view this as a major problem, as Python > is much easier to pick up than C++; I learned it in four days. Refer to paragraph 1 of this message. Of course this is just me I guess... > A lesser thing to worry about is performance. Python is an > interpreted language and relatively slow. Experience with Python AIs > has shown that this is not a blocker in practice, and machines > are still getting faster. And many Wesnoth players or developers cannot afford such new machines, or need/want to run Wesnoth under conditions on which memory read/writes and CPU cycles do matter. > Most of you know that I have taken primariy responsibility for > triaging bugs and keeping the tracker bug list clean over the last > year or so; if you get a bug assigned to you, it was likely I that > did it. I have also engaged in several major bug hunts during which > I've personally dispatched a couple of hundred bugs. And? > Accordingly, I probably have a more detailed sense of the project's > defect patterns than anyone else now active. 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. We are vulnerable anywhere where we don't coordinate our work or settle upon a common coding style, and a good *design style*. That's almost everywhere unfortunately, but I still can't find a good reason to blame C++. It's not like many major program suites (including free and propietary software alike) don't use C++ already, and do their work fine. And a language which does not offer data-type enforcement to me is just scaring, which is why it took me so long to learn Perl: unwillingness to surrender to type unsafety. > 1) No more memory-allocation screwups, *ever*. Python has no pointers > and is garbage collected. I suppose I can still tell Python "I do not want you to drop this allocated block of memory because I may need it under rare conditions", or "I want you to allow me direct access to object X, please do not clone it for me because my users will be unhappy for the added memory allocations". > Python applications cannot core-dump. But broken interpreters can. And there's no "standard" Python interpreter AFAIK. > The complex tangle of standard and local custom memory allocators we > presently use, and that are the source of so many of our bugs [...] Good example of non-coordination amongst developers. Um, why is C++, as a language, guilty? Ah, because it offers the possibility to do that magic. C is guilty too because C++ is derived from it. And the creators of C are guilty for having offered us the way to create C++. I'll stop the recursive search now. The vconfig case: it is obvious that this is caused by specific people. The people who maintained it in the past, and maintain it now. That seems to be only two people: Patrick P. <sapient> and the copyright holder of variable.[ch]pp (Philippe Plantier <ayin>). I stand corrected if I am wrong. The poolalloc.c and malloc.c case: it is David's attempt at reducing memory usage. Obviously it failed due to portability issues (since one of the major platforms is not really POSIXly correct), but most of the code is Doug Lea's work, who also seems to have commited code to the GNU C library project. malloc() code, it seems. This is an exceptional case of memory management that I have not seen in any other C (or C++) source code set, and that is obviously suicide due to the sole idea of overriding the runtime environment's idea of the Right Thing. I am sure you can manage to do the same in Python, if you wanted. What are other *technical cons* on Python now? I have read a social one and an economical/hardware-resources one, but nothing else. I am also interested on what other free software projects using standard C++, rather than C or some non-standard dialect of any of the two, you work for. Or, if you practice writing C++ stand-alone applications to learn it, or you just stick to the first impression in Wesnoth. > I think integrating Ivan's code should be our main project for > early in the 1.7 cycle. I am willing to take primary responsibility > for reviewing and merging; actually, I can't imagine a better use of > my project time than that. I suspect loonycyborg will be taking an > active role in the merge as well. Well, I cannot help you on that one because I don't know Python nor have time to learn it at the moment or future, but I want to try to librarify the WML parser and preprocessor once I rewrite them from scratch for my own WML-based game. I just have to learn the whole lexical parsing paradigms (that is not a C++-specific problem, you know) and I may have it done before two years pass. That would empower the project as a whole; not only because of the reusability of its components, but also because it would allow us, eventually, to unify the game engine with the maintenance tools (Python or not). By the way... > We have another technical problem; GNA blocks Ivan's ISP for some > unknown reason. Somehow we need to straighten that out so he can have > dev access. File a support request to Gna!. The only problem is: if they didn't want to solve the issues that Patrick P. <sapient> had with Hotmail being blacklisted for the mailing list software, I don't think they'll solve Ivan's issue very soon, or even make an exception. In my opinion, switching to other hosting service should be a higher priority once 1.6 is out. I know you try to be very objective on this issue, and I do so, although Wesnoth has made me fall in love with C++; but somehow I suspect this may turn into a flamewar. However, I hope you read this message and give me some sort of reply to the points I raised at the beginning, at least, even though I got into the discussion rather late because I lack my own Internet connection. (I cannot afford an Internet connection; could I then afford new computers? I bet not.) Best regards -- Ignacio Riquelme Morelle <shadowmaster> _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
