Current thinking around the development language

[Bahman Rabii]

Hi folks,

What is the current thinking around the future of the development language for Angband? I argued more than five years that straight C is not a suitable choice for the large amount of high-level code in Angband. Even without a major rewrite, it is would be possible to allow limited use of selected C++ features.

I am not planning to get involved in development in the foreseeable future, so please take this question as friendly curiosity. I am not volunteering/asking permission to do a pilot program.

FYI:

What put this back in my mind was the observation that Google's protocol buffer format would make an excellent replacement for the edit-file ascii format used in Angband, but that protobuf only works in C++, Java, and Python.

I use protobuf at work and it is a much stronger solution writing a custom parser. It is also nicer than XML for a few reasons: it has a nice compact ascii format, it handles typed data much better, and the programmatic APIs are good enough to use the parsed data structures directly without moving them into a different in memory representation.

This would also be nice for savefiles.

If you are curious there are more docs: http://code.google.com/apis/protocol.../overview.html

[d_m]

What is the current thinking around the future of the development language for Angband? I argued more than five years that straight C is not a suitable choice for the large amount of high-level code in Angband. Even without a major rewrite, it is would be possible to allow limited use of selected C++ features.

I think we have stuck with C mostly because no one really wants to write C++

To be less glib--I personally like the idea of using something like Python, but I'm not sure that I have the energy/willpower to port the exact Vanilla Angband gameplay (and front-ends) over to Python. I'd probably just build an independent game inspired by Angband.

I think only real way that the Vanilla codebase escapes C is if it can be modularized and then controlled (at a high level) from something like Python or Lua (I like Python a lot, I think many of the devs like Python and/or Lua). This was attempted earlier with Lua but didn't take. I think someone (Sirridan?) on oook started writing porting Angband to Python from scratch, but AFAIK it stalled out.

DarkGod has written Tome4 entirely in Lua so it's clearly possible (although I think it required abandoning much of Tome2-3 to get there).

[Bahman Rabii]

I think we have stuck with C mostly because no one really wants to write C++

I got a similar reaction 5 years ago, and I still don't understand the level of antipathy for C++ in this community. I do not recall hearing any specific reasons.

Just allowing classes and STL would probably reduce the size of the angband codebase by 15-20%, while improving readability.

[takkaria]

I'd say there are a bunch of reasons. The easiest one is that not all the devteam code in C++ and switching to a new toolchain and language would be a big disruption. I understand that we could refactor stuff in C++ to be more efficient and have fewer lines of code but we're largely doing that already without needing to switch language, and we have collectively a better grasp of C idioms than we do of C++. It would also break variant portability.

I think another factor is that the bigger issues with the code are structural ones; stuff like bare array accesses using numeric indexes, or rewriting the UI code to handle tiles as first-class citizens of the display rather than as a pretend terminal character. These things aren't fixed or become any more fixable in C++, they can just be fixed differently and switching language would IMO be a distraction from actually sorting them out, especially given that the devs don't know C++.

In short, I don't think the disruption would be outweighed by the gains, though personal preference obviously comes into it too.

As to parsers for edit files: we have a consistent and clear API for parsing in modern V (see parser.c and most of init2.c); the format may not be perfect but the opportunity cost of changing format is high compared to its marginal gain (which may well be a loss, since cross-variant portability would go out the window even if we had a better format).

As to savefiles, modern V has a nice versioned and chunked savefile format which allows a lot more flexibility than the old code did along with better indicators of where savefile loading and saving is failing. Having rewritten the savefile code a couple of times for unreleased variants and seen the effort put into an abortive rewrite by one of the V developers, I have learnt that it too has a high opportunity cost and incremental change worked out to be the best strategy given the small gains made from wholesale replacement.

[Bahman Rabii]

Fair points. I think I have fairly strong counter arguments to all of them, but since I am not in a position to contribute the work, it is a moot point.

[Magnate]

but since I am not in a position to contribute the work, it is a moot point.

I think this is the reason behind a lot of suboptimal outcomes in a lot of FOSS projects. If there was a driving personality on the devteam who loved C++ and was willing to mentor me in it, I would happily assist with conversion, and I suspect others would too. (Ditto to switch to Python, or anything else that would ultimately be better than C.) But no such person has stepped up, and those with the time to contribute don't have the knowledge or inclination to switch language. It's just so much easier to improve what's there than to start over - as Sirridan found out with the Python attempt, ditto the author(s) of Java Angband all those years before.

How DarkGod found the time/dedication to rewrite ToME4 almost from scratch I have no idea.

[Antoine]

It's just so much easier to improve what's there than to start over - as Sirridan found out with the Python attempt

Is that project officially dead, or just gone quiet?

A.

[Chud]

I have toyed on and off with the idea of a Java version... but each time a voice in the back of my head mutters "you think you have *how many* free hours these days??"

Mostly with an eye toward the graphics and window management stuff, which I am always bad at (though I imagine it's easier in java than in C...)

[Derakon]

And I'd love to see it rewritten in Python, my favorite language these days, but similarly lack the time. Oh, well...

[Therem Harth]

I think part of the problem is that Angband is not structured like a program written in a higher-level language would be (or rather, should be). Python Angband *might* be doable without a complete from-scratch rewrite, but it would be very ugly and probably hard to maintain. Java Angband would require a rewrite, as the entire procedural coding style is just not usable in Java.

(Well, I suppose you could rewrite most of the Angband source files as abstract classes full of static methods... I probably ought to be smacked for thinking of that, though.)

[Derakon]

Any rewrite into a modern language would require a redesign as well. There's no point in porting to a different language if you aren't going to do it properly.

[CJNyfalt]

The problem is that C++ is both the only language AFAIK that allows a gradual conversion, and the hardest to learn of the possible candidates.

Still, the fact that C++ has strings in the STL is an even better selling point than all classes in the world. C string handling is icky and error-prone.

[PowerDiver]

The problem is that C++ is both the only language AFAIK that allows a gradual conversion, and the hardest to learn of the possible candidates.

Still, the fact that C++ has strings in the STL is an even better selling point than all classes in the world. C string handling is icky and error-prone.

Just the strong typing and the ability to define variables where you use them is enough to make C++ better, even if you don't use a single other feature of C++.

[takkaria]

Just the strong typing and the ability to define variables where you use them is enough to make C++ better, even if you don't use a single other feature of C++.

Strong typing? Is C not strong enough?

And C99 allows you to define variables where you use them, but it turned out that MSVC doesn't accept that so we went back to C89 style...

[AnonymousHero]

Strong typing? Is C not strong enough?

And C99 allows you to define variables where you use them, but it turned out that MSVC doesn't accept that so we went back to C89 style...

EDIT: (In short: ) Any "safety" afforded by C++ is purely theoretical. (Though technically it is slightly safer than C.)

Any type safety "guaranteed" by C++ is completely moot since it doesn't have memory safety... and lots and lots of "undefined behaviour".

Frankly it's an abomination (with some good ideas, badly implemented) which is lumbered with backward compatibility and hysterical(sic) mistakes.

Without memory safety there can be no type safety. And without type safety, S* H* Panda is sad .