No, this couldn't be further from the truth and is the reason why things like entity component systems exist - to graft data on to code and make data-driven programming easier. In Lisp-like languages, this is more true. In C++ which most games are written in and even Lua which is a common scripting language, this isn't really true. There is a wealth of information about how code is not data all over the web - google it please.
A few reasons why in C++, C, and Lua, and in general in most game programming languages code is not the same as data:
- Tends not to be editor friendly
- Requires heavy meta programming to achieve the same as other formats
- Requires compilation and/or interpretation
- Is not necessarily idempotent depending on compiler options and platform. The same data should be the same cross-platform, and code is almost definitely not because at a minimum level, it can generate vastly different assembly depending on compiler flags or processor targets.
- Purely composite. I would argue that as much as we try, it's hard to compose a lot of code properly and without considerable effort in games. Conversely, composing data can be quite easy.
- Cannot on its own be serialized/deserialized easy while in a runtime state
- Not network transparent
- Cannot be compressed/decompressed in real-time as easily
See my points in other posts in this thread. I am assuming you downvoted me, which is ridiculous and childish, especially given your brief response without any reasoning or evidence despite being contrary to all computer science research.
Sorry, but as a long-time Lua user, I have not found any of your points to be true at all. Lua is truly editor friendly; I can even use cscope with it. Meta-programming is light, that is why it is meta-. Idempotency is one thing: shipping code is something else, and a well managed Lua project ships.
Composition: see meta-tables. Repeat until completion.
Again, you're welcome to disagree. We're talking about game development in particular, not Lua in general. I've used Lua and almost always look to it for scripting in game engines I have built.
It's telling that all the major game engines and a large portion of papers and talks disagree with you. If Lua was the solution to data-driven development, people wouldn't bend over backwards looking for solutions like entity component systems. Lua is nice, but not suitable for most professional game development as a primary language. As such, it makes it completely unsuitable because Lua data, especially things that depend on runtime state are utterly useless.
Your shipping comment also makes no sense in this context. Tons of other languages have more games shipped than Lua. There aren't too many people relying on Lua for composition and data-driven development in games, because it doesn't work. Even Lisp doesn't work in this context putting speed and other things aside, because of so many reasons I've already listed. Code in the context of game development is not data by the definition of data I am referencing.
A few reasons why in C++, C, and Lua, and in general in most game programming languages code is not the same as data:
- Tends not to be editor friendly
- Requires heavy meta programming to achieve the same as other formats
- Requires compilation and/or interpretation
- Is not necessarily idempotent depending on compiler options and platform. The same data should be the same cross-platform, and code is almost definitely not because at a minimum level, it can generate vastly different assembly depending on compiler flags or processor targets.
- Purely composite. I would argue that as much as we try, it's hard to compose a lot of code properly and without considerable effort in games. Conversely, composing data can be quite easy.
- Cannot on its own be serialized/deserialized easy while in a runtime state
- Not network transparent
- Cannot be compressed/decompressed in real-time as easily
See my points in other posts in this thread. I am assuming you downvoted me, which is ridiculous and childish, especially given your brief response without any reasoning or evidence despite being contrary to all computer science research.