Principles of Data Oriented Programming

I think for untyped languages like clojure, you lose nothing. For typed languages that don't support parametric polymorphism, you trade type safety for flexibility and code simplicity. For typed languages that support parametric polymorphism, I don't see the advantage.

Depending on how a language defines their syntax.

Often times literals are only things like `"string"`, `0` and so one.

But thinks like `[ 1,2]` would be a array expression where each "entry" is syntax wise an expression (and any literal is an expression itself).

I don't know if JavaScript specifically does define object literals or object expressions, in the end it depends on what you define a literal as.

Lastly depending on the language something like `[ 1,2]` might literally de-sugar to something like following pseudo code `var tmp = Array.new(capacity=2); tmp.push(1); temp.push(2)`.

So a better way would be that a formulation like "data should be creatable without explicitly doing any function calls, variable assignments or similar. Creation must not depend on implicitly captured data".

The "DOD of games" is just a "special case" of more generic Data Orientated design/programming.

E.g. ECS is a direct consequence of seperating data from code.

Furthermore for it to work well you normally also want #2, #3 and #4.

Sure you can build a ECS without #2,#3 and #4 but it makes it more complex.

Lastly in a ECS you split up components into many parts each having their own data and you normally want the idea behind #5 to apply to each of the parts.

EDIT: Well ok, weather #2 makes any sense at all depends on the language you use. And using a language where #2 makes no sense can be a as reasonable choice. I only would apply #2 IF it makes sense for you language of choice.

Principle #2 always bothers me.

"Model the data part of the entities of your application using generic data structures (mostly maps and arrays)."

and example

function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; }

For a simple, obvious object like "person" it might work, but for a complicated domain object with many other composed objects this starts to be a pain.

I am not feeling ready to memorize all the field names, I prefer to have an object with documentation for each field.

If you use simple data structures without logic, it is basically what he is saying. Basically `createAuthorData` is a data structure constructor. There are some advantages by using _.pick or something in JS land, but these don't work for other more strictly typed languages.

Also, I would be careful with using it so much as his example:

``` function createAuthorData(firstName, lastName, books) { return {firstName: firstName, lastName: lastName, books: books}; }

function fullName(data) { return data.firstName + " " + data.lastName; }

function createArtistData(firstName, lastName, genre) { return {firstName: firstName, lastName: lastName, genre: genre}; } ```

you can also do `fullName({firstName: 'Elmond', not:'really'})` and have an hard to catch bug (where an actual typesystem would catch it).

You can either use a Protocol for this (PersonName) or a base class (though those are going out of fashion nowadays)