Gamasutra – Features – Sponsored Feature: Data-Oriented Design – Now And In The Future.
I know I probably shouldn’t care, but it really irks me when people attach a schnazzy new name to an old idea a claim the idea was theirs.
Data Oriented Design? Are you kidding me? This is NOT a new idea. It’s been around since the 60’s and 70’s, only then it was called Data Driven. Try looking up JSD or Data Flow Diagram.
Perhaps part of the reason software design has progressed so little over the years is that people keep “inventing” old ideas without ever learning from the past.
I don’t recall anyone pretending they invented this idea of making data flow central to program design. What I do know is that the vogue for it is justified and driven entirely by the practical necessity of getting the most out of current hardware (mostly on consoles, especially the PS3).
In some ways the game industry is like anti-academia: it really doesn’t matter who thought of it, it only matters if it’s practically applicable to your shipping project today. In fact if it wasn’t necessary to give the idea a name in order to talk about it amongst the industry, I’m pretty sure they wouldn’t have even bothered with that.
While there is no claim that the author invented the idea, there is also no acknowledgment that it is an OLD idea. It is presented as a fresh alternative to OOP. For some of us, who learned to program in the days before OOP, the excitement about OOP as “THE” answer to all our programming woes was seen with a large helping of skepticism, that has really never been proven wrong. OOP has never resulted in efficient programs (quite the opposite), and efficiency has always been a big consideration in game design, which is why it surprises me that it is so popular. For many, both in and out of the game industry, devotion to OOP takes on almost cult-like qualities. I blame academia for much of that – for the most part, CS programs really don’t teach people how to program any more. As Kurt Guntheroth so wisely said: “CS may be more than programming, but it is not less than programming”.
As for recognizing that Data-Oriented Design is an old idea with a new name, I don’t care much about the Academy these days either, but acknowledging the ancestry of ideas is useful – especially if we want to learn from past mistakes. I consider it common courtesy to acknowledge those whose ideas they were. I agree that the preoccupation with citations in the Academy is not useful in the game industry, but knowing your own history is, and, while we’re on the subject, knowing something about software design (which, by the way includes ideas other than OOP) is good for the bottom line.
That’s pretty much why I called it “anti-academia”, there’s very much a cowboy culture still in existence where a idea’s ultimate validation comes from whether it used in a previous (successful) title. There’s actually a fairly justified reactionism against academic ideas for fear they are untried and may derail the project and the jobs of everyone on it.
As for your point regarding OOP, its wide-spread adoption is not a matter of cult worship, but rather a sign of it’s success in allowing programmers to reduce complicated problems into something a human can fit in their head long enough to solve them. It’s an easily comprehensible, universally available pattern that allows decomposing and layering code to a degree that anything before didn’t allow.
The only problem I see is some people seem to think OO is the only way to do this, and that OO on modern hardware is leaving performance on the table — which is fine for most apps, but not some of the most interesting ones.
As far as I’m concerned reliance on single languages in universities (whether its Java or C#) ends up creating a monoculture in thinking in its grads. Every second year student *should* be able to program in a machine-level language (asm, C, C++, Cg), an OO language (Java, C#), and a functional language (Haskell, Lisp/Scheme, OCAML); or express all of these styles in a multi-paradigm language like Python.
I think it’s very wise to be suspicious of the Academy – I know FAR too many CS profs who haven’t written a program in years (and some of whom never could). It’s also true that the Academy is littered with people who think they have better ideas, but whose ideas have never been tried in a real situation (“In theory, there is no difference between theory and practice. In practice, there is a big difference.” ).
As for being effectively uni-lingual when it comes to programming – I have always thought that was a really bad idea. (I commented on it in a previous post) I was the one who pushed for our department to teach Pascal as a first language. This was for 2 reasons: 1: Pascal is still a good training tool, and 2: it will force the students to learn more than one language. If you only know one language well, then everything you do is going to be fitted to take advantage of the good aspects of the language AND to compensate for the bad aspects of the language, whether or not that is the best approach for the problem. Given the choice of viable languages today, that is not reasonable, nor is it an efficient use of people or horsepower.
Bill Buxton makes a similar point in many of his talks. Software developers are notorious for redesigning what was completed in the 70s. For my generation of researchers (currently in grad school), the 90s are often ignored. I am constantly have to go back to the old journals and to look for graphically ugly attempts to do the same conceptual work. There were lots of problem solved a long time ago.
Programming is often personal expression so every programmer wants to do his or her take on the subject. We all want our chance to write the string library. A second reason might be that a quick google scholar search often does not turn up conceptually similar ideas so it is easy to miss literature if you don’t know just the right keywords. For fields which differ in language, but are conceptually similar, it is to difficult to find parallel literature.
We need better software tools to allow researchers to explore bodies of literature and actually make sense of what is going on. Secondly, we need research supervisors who still feel obligated to keep up with the literature. I think too often they have become middle managers and have lots touch with their field, possibly riding on the back of previous success.
Developing brand new tools, and generating original knowledge is hard and there is no shortcut. A researcher/developer simply has to put in the time. (Too bad Canada’s research funding system only supports short cycles. I would love a 5yr grant, where I can get to the heart of an issue.)