Data-oriented design / jai language

Hi all,

I was wondering if anyone has looked into data-oriented design and some of the work that has been done by proponents of this approach?

Mike Acton explaining principles of DoD before stating the three lies that have been engendered by C++.

While this is mainly driven by people from the games industry, where especially performance certainly plays a key role, a lot of the points made by DoD proponents address issues in software development in general, and I would like to get some perspectives on the topic if people here are interested to discuss this.

For example, they generally despise OOP and consider it harmful, causing not only poor performance, but also poor concurrency, testability, stability, etc., and in the wake of how prominently OOP is taught at universities (ruining generations of developers), they derive general problems in software development, sometimes going so far as drawing doomsday scenarios.
If you’d like a taste of such a persepctive you might want to watch this talk by Jonathan Blow.

Jonathan Blow also took this as an opportunity to implement his own language, Jai, to address many of the problems he identifies in a language like C++. Has anyone looked at this language? What’s you opinion on its design choices? Jai Primer, for more information.
Here’s an overview page of resources for Jai.

My motivation is not to start heated debates based on some of these rather extreme arguments made there, but rather the opposite, i.e. to try and distill the valuables out of the ideas of data-oriented design, since I’m having some troubles doing that myself, while I certainly feel like there are valuable lessons to be learned there that might be interesting when thinking about your own language design or the design of a new language workbench.

Thanks for the links - never heard of the term “Data-oriented Design” before, so I watched some bits of the talk, and read a bit on the JAI primer page.

From a perspective of a modeling enthusiast, it is kind of weird to think what to say about those ideas, which basically seem to say that abstraction, the very staple of model-driven development, is bad. Two of the stated “three lies” basically depict my view of the world of software:

  1. Software is a platform (instead, for the speaker, only hardware, and only each specific physical architecture, would be a platform)
  2. Code should be designed to model the real world or problem domain (instead, for the speaker, code should be written specifically for the actual hardware in use, and data structures should reflect that, and those details should not be hidden)
  3. Code is more important than data (instead, for the speaker, it is the opposite, the only reason code exists is to read, produce and transform data) - including this one for completeness, actually am on-board on this one, at least in isolation.

I tend to put obsolesce-proofness (ROI preservation), maintainability and development speed over performance. That is not to say I don’t care for performance - but I will wait and see for cases where performance is a problem before optimizing for it.

In cases performance is critical, I will be the first one to defend using different data structures that show to be more efficient, and exposing the guts of data structures at the expense of encapsulation as much as needed (but not more).

Bringing the topic to the context of model-driven development, the separation between the specification/modeling language and the generated code is actually a good opportunity for ensuring your generated code can take advantage of the target architecture without polluting your model with that concern, maybe only by sprinkling some markers here and there to drive the generator. Let the generator do the heavy lifting, and be coupled with the physical architecture.

1 Like