4 ms·

I think a lot of these older open source projects have a tough time because they use C++ so extensively. There are plenty of people who "know" C++, but it's not

I think a lot of these older open source projects have a tough time because they use C++ so extensively. There are plenty of people who "know" C++, but it's not a language many people can be productive in. The argument for using C++ is that it's faster and uses lower memory, but that's not actually true for naive implementations: C++ allows lots of tricks for speed and memory efficiency, but it takes work to make it actually more efficient. These days I tend to think that it's easier to write first in a higher-level language and optimize from a position of knowing where your bottlenecks will be than to write a low level language like C/C++ efficiently from the beginning, not knowing where the bottlenecks will be. I'm not saying that a rewrite is the answer, however.

m3talridl3y 11y ago
I think the real reasons are: Unity, Unreal Engine, HTML5, etc. People who would want to contribute never find BFW, instead they make their own games and satisfy their creativity that way.
zanny 11y ago
This is the case with old code in general, though. 2003 Javascript, 2003 C++, any Java, especially 2003 C#, any C, 2003 Python, etc are all horrible messes to work with today. C++ got so much better with C++11/14 I can't even think of it as the same language. Python literally broke itself. Java is pretty much dead except for on Android (consumer facing) for good reason. C# was practically an infant in 2003 and got so much better with so many frameworks around it since then. C is still as bad as ever, and Rust / Go didn't exist, and Scala came out that year. It is why frameworks and toolkits are so important. You want to minimize your codes aging surface area, and having individual parts you can manage and age independently kicks the pants off of starting from int main() and hoping for the best. Wesnoth's greatest library dependency is SDL, which honestly should make the engine fairly futureproof if they could get it ported to SDL2. But that doesn't change how everything else is pretty much raw C++, with just AI rules in Python or Lua. I'd have to look into if they are giving a thumbs up to std=c++14 or not, because if they are I might go poke around just to see how much you can fix. I'll have to read more on that though.
- copsarebastards 11y ago
  I don't really agree. The problem with C++ isn't its age, it's its complexity, or what I'd call the "too many tools" problem. None of the languages you mention approach C++ in sheer breadth of complexity. For a given problem there are 100 ways to solve it in C++ and these ways of solving it may look so different from each other that it's not even apparent they are solving the same problem. Java, in particular, doesn't have this problem: it was specifically designed to avoid this problem (read Guy Steele's interview in Coders at Work) and while I dislike Java for other reasons, it largely succeeded in solving that problem. Python's "there should be one, and preferably only one, way to do it" is similarly trying to solve a similar issue. C's lack of features also addresses this problem. C++11/14 gives you much better tools, but it doesn't solve the "too many tools" problem. The old tools are still there, and in fact, people are still writing C++11/14 using those tools. The result is that even if you endeavor to only use the new, good C++11/14 ways to do things, you're still going to run into issues with the old stuff and you're going to have to understand a the old stuff: and there is no end to it. Every time you make a significant change to a C++ codebase, you have to learn another dark corner of a language that hasn't had a feature removed in three decades. Java's solution to this problem is to add features very slowly and carefully, which makes the language hard to use sometimes due to its lack of features. Python's solution is to break reverse compatibility, which makes it difficult to run older codebases. C has this problem too, but they have been more conservative with the features they have added. C# has this problem badly, but it hasn't had as much time for it to get as bad as C++.

m3talridl3y 11y ago

I think the real reasons are: Unity, Unreal Engine, HTML5, etc. People who would want to contribute never find BFW, instead they make their own games and satisfy their creativity that way.

zanny 11y ago

This is the case with old code in general, though. 2003 Javascript, 2003 C++, any Java, especially 2003 C#, any C, 2003 Python, etc are all horrible messes to work with today. C++ got so much better with C++11/14 I can't even think of it as the same language. Python literally broke itself. Java is pretty much dead except for on Android (consumer facing) for good reason. C# was practically an infant in 2003 and got so much better with so many frameworks around it since then. C is still as bad as ever, and Rust / Go didn't exist, and Scala came out that year. It is why frameworks and toolkits are so important. You want to minimize your codes aging surface area, and having individual parts you can manage and age independently kicks the pants off of starting from int main() and hoping for the best. Wesnoth's greatest library dependency is SDL, which honestly should make the engine fairly futureproof if they could get it ported to SDL2. But that doesn't change how everything else is pretty much raw C++, with just AI rules in Python or Lua. I'd have to look into if they are giving a thumbs up to std=c++14 or not, because if they are I might go poke around just to see how much you can fix. I'll have to read more on that though.

copsarebastards 11y ago
I don't really agree. The problem with C++ isn't its age, it's its complexity, or what I'd call the "too many tools" problem. None of the languages you mention approach C++ in sheer breadth of complexity. For a given problem there are 100 ways to solve it in C++ and these ways of solving it may look so different from each other that it's not even apparent they are solving the same problem. Java, in particular, doesn't have this problem: it was specifically designed to avoid this problem (read Guy Steele's interview in Coders at Work) and while I dislike Java for other reasons, it largely succeeded in solving that problem. Python's "there should be one, and preferably only one, way to do it" is similarly trying to solve a similar issue. C's lack of features also addresses this problem. C++11/14 gives you much better tools, but it doesn't solve the "too many tools" problem. The old tools are still there, and in fact, people are still writing C++11/14 using those tools. The result is that even if you endeavor to only use the new, good C++11/14 ways to do things, you're still going to run into issues with the old stuff and you're going to have to understand a the old stuff: and there is no end to it. Every time you make a significant change to a C++ codebase, you have to learn another dark corner of a language that hasn't had a feature removed in three decades. Java's solution to this problem is to add features very slowly and carefully, which makes the language hard to use sometimes due to its lack of features. Python's solution is to break reverse compatibility, which makes it difficult to run older codebases. C has this problem too, but they have been more conservative with the features they have added. C# has this problem badly, but it hasn't had as much time for it to get as bad as C++.