Honestly, the driving script in bash feels like it’s cheating. It actually feels like despite all the new toys, metaprogramming in C++ still isn’t that powerful.
Couldn’t this be done more easily with lisp macros? I can sort of see how to do it with D compile-time structures.
I don’t think there’s much point comparing such exercises across languages. For instance, with Template Haskell, you can run arbitrary Haskell code and even do IO at compile time, you could even write a 3D shooter, but I’d still say C++ templates are more powerful than TH in many aspects, due to the way they interact with the rest of their respective languages.
Maybe I shouldn’t have said “powerful”, but “convenient”? I think it does make sense to have these comparisons at least for this example. In both Lisp and D, you have all of the language at compile time, so you can do just about anything.
It appears that even when attempting a ridiculous feat, thus accepting some inconvenience, C++ compile-time features are still too onerous to put the whole game loop into them.
Edit: After thinking about this for a second, I’m not sure it’s possible in D anymore since compile-time D functions have to be deterministic.
I understand your point about the convenience, but my point is that the real purpose of the metaprogramming features isn’t to write interactive games. What matters is how it interacts with the run-time features. For instance, C++ templates are more powerful than Template Haskell, because of template argument deduction and due to how template instantiation can cause other templates to be instantiated seamlessly. Whereas in TH, you cause all template expansions by hand.
Without considering the interaction with the rest of the language, the best metaprogramming would simply be generating C++ code using C++, then running that program as a preprocessing step. That’s why I think comparing the power of metaprogramming features accross languages through non-metaprogramming things you can do with them is pointless.
Yeah, it is, TH is much more bolted-on in Haskell compared to templates in C++, but on the other hand, Haskell’s type system is vastly more powerful without metaprogramming, so you rarely really need it. As I said, hard to compare across languages :)
That was my first thought, that the actual game loop is still implemented at runtime (with a bash runtime), which is sort of cheating. On the other hand, since one of my research areas is modeling game mechanics in formal logic, it somehow feels natural to accept an implementation of a state->state' transition function as morally equivalent to an implemention of a game. :-)
Yeah, the Wikipedia article has noted prior art. It’s the typical problem of bad patents being so expensive and long to fight that even a successful dispute is a significant loss to the one company doing it. The overall benefit outweighs that cost, but it’s spread across all the end users and the company’s competitors.
My revulsion is only surpassed by my awe.
I bet this would look so much nicer in that programming language I keep talking about.
Honestly, the driving script in bash feels like it’s cheating. It actually feels like despite all the new toys, metaprogramming in C++ still isn’t that powerful.
Couldn’t this be done more easily with lisp macros? I can sort of see how to do it with D compile-time structures.
I don’t think there’s much point comparing such exercises across languages. For instance, with Template Haskell, you can run arbitrary Haskell code and even do IO at compile time, you could even write a 3D shooter, but I’d still say C++ templates are more powerful than TH in many aspects, due to the way they interact with the rest of their respective languages.
Maybe I shouldn’t have said “powerful”, but “convenient”? I think it does make sense to have these comparisons at least for this example. In both Lisp and D, you have all of the language at compile time, so you can do just about anything.
It appears that even when attempting a ridiculous feat, thus accepting some inconvenience, C++ compile-time features are still too onerous to put the whole game loop into them.
Edit: After thinking about this for a second, I’m not sure it’s possible in D anymore since compile-time D functions have to be deterministic.
I understand your point about the convenience, but my point is that the real purpose of the metaprogramming features isn’t to write interactive games. What matters is how it interacts with the run-time features. For instance, C++ templates are more powerful than Template Haskell, because of template argument deduction and due to how template instantiation can cause other templates to be instantiated seamlessly. Whereas in TH, you cause all template expansions by hand. Without considering the interaction with the rest of the language, the best metaprogramming would simply be generating C++ code using C++, then running that program as a preprocessing step. That’s why I think comparing the power of metaprogramming features accross languages through non-metaprogramming things you can do with them is pointless.
Ah, it does sound inconvenient in TH to not have automatic instantiations.
Yeah, it is, TH is much more bolted-on in Haskell compared to templates in C++, but on the other hand, Haskell’s type system is vastly more powerful without metaprogramming, so you rarely really need it. As I said, hard to compare across languages :)
In Lisp you have the full language in disposal at compile-time, so it’s way too easy.
That was my first thought, that the actual game loop is still implemented at runtime (with a bash runtime), which is sort of cheating. On the other hand, since one of my research areas is modeling game mechanics in formal logic, it somehow feels natural to accept an implementation of a
state->state'transition function as morally equivalent to an implemention of a game. :-)Lucky for them that U.S. patent #5718633 prohibiting minigames in loafing screens is safely expired.
I’m still surprised nobody managed to knock that one out on prior art, I remember fastloaders for 8-bit computers that had a built-in minigame.
Yeah, the Wikipedia article has noted prior art. It’s the typical problem of bad patents being so expensive and long to fight that even a successful dispute is a significant loss to the one company doing it. The overall benefit outweighs that cost, but it’s spread across all the end users and the company’s competitors.
Great googly-moogly.