DEV Community

loading...
Cover image for Data-Oriented programming: Liberate yourself from objects

Data-Oriented programming: Liberate yourself from objects

viebel profile image Yehonathan Sharvit ใƒป2 min read

The main lesson that Clojure teaches its developers is to embrace simplicity.

The secret sauce used by Clojure to embrace simplicity is that it treats data as a first-class citizen that is manipulated with generic functions.

In the Clojure community, we call this secret sauce: Data-Oriented programming.

The good news is that this paradigm is in fact language agnostic, meaning that it is applicable in other programming languages, both OOP and FP, both statically and dynamically typed.

In Data-Oriented programming, we follow 3 principles:

  1. We separate our code from our data
  2. We represent data with generic data structures
  3. We never mutate our data

What does it mean in practice for you to adhere to Data-Oriented programming?

  1. You write your code in stateless functions (or static methods)
  2. You represent your data with hash maps and vectors
  3. You use a library that implement efficient immutable data structures

What do you get from that?

In one word: SIMPLICITY!

In a few sentences:

  1. No more complex UML diagrams!
  2. You benefit from dozens of generic data manipulation functions
  3. You can visualize any part of your system, as it is just data
  4. You liberate your mind from concurrency-related issues.

Curious to see how it looks like in a real production system?

Start reading my book Data-Oriented programming.

Here is a 50% off discount code for you: mlsharvit2. Valid until March 15.

The principles of Data-Oriented programming are explored in greater detail here.

Enjoy!

Discussion (17)

pic
Editor guide
Collapse
peppesilletti_4 profile image
Giuseppe Silletti

Thanks for sharing :) When do you think a functional approach should be used instead of an OOP approach?

Collapse
viebel profile image
Yehonathan Sharvit Author

Always๐Ÿค— !

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

That's not convincing :) Could you tell me a bit more about why you think that?

Thread Thread
viebel profile image
Yehonathan Sharvit Author

Read the book and you'll be convinced ๐Ÿ˜!

Thread Thread
brunooliveira profile image
Bruno Oliveira

Hmm, seeing this type of reply makes me a bit sad :)

I think it's fine to advocate for the book, which is actually quite interesting so far, but, most working programmers will read it with the perspective of gaining new insights and/or better leveraging the functional style tools available in their working language, and not to "abandon" objects in any way, simply because it's not possible. Only a TINY fraction of us can use functional programming on our daily job or switch technologies completely.

I think most readers will approach this book with the idea of gaining new insights to apply to their daily work or simply to gain a fresh perspective.

There is no silver bullet, and if there is, it certainly won't be functional programming.... I mean the foundations have been laid out more than 50 or 60 years ago, so if it didn't take off into the mainstream industry in that time frame, it most likely won't now :)

Thread Thread
viebel profile image
Yehonathan Sharvit Author

Actually, in the book I show how to apply the principles of Data-Oriented programming to both FP or OOP languages.

Collapse
brunooliveira profile image
Bruno Oliveira

Bought your book, can't wait for it to be completed ๐Ÿ˜ the current ~75 pages from the Manning MEAP are amazing, but I need moreeeee๐Ÿ˜„๐Ÿ˜„ ideally it'll be the kind of book I'll get back to many many times in the future, just like with Grokking Simplicity

Collapse
viebel profile image
Yehonathan Sharvit Author

Spread the word about the book among your friends๐Ÿ‘ฉโ€๐Ÿ’ป.
Tweet about it.

The world really need to get out of this insane ๐Ÿ˜ฑ complexity!

Collapse
peerreynders profile image
peerreynders • Edited

We never mutate our data
...
The good news is that this paradigm is in fact language agnostic.

Then apparently data-oriented programming has nothing to do with data-oriented design.

Data-Oriented Design came about to address the growing performance gap between CPU caches and conventional memory - Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP), Noel Llopis, 2009.

CPU vs Memory Performance Gap
source

Richard Fabian's Data-Oriented Design goes into great detail to show how OO-style C++ completely negates the performance enhancing features of modern CPUs.

The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry. โ€” Henry Petroski

So as such DOD is about optimizing code to take advantage of modern hardware performance features such as generously sized CPU caches. So it is highly "place-oriented" (rather than "value-oriented") and embraces in-place mutation. It is incredibly important to collocate data that is processed and used together. So to practice DOD you have to have control over memory layout. High level languages don't let you control memory layout - systems languages like Rust do.

From that perspective something like ECSY is nothing but a curiosity because it is written in JavaScript.

Because of these requirements Unity created HPC# (High-Performance C# - a custom language based on a subset of C# with some adaptations from C/C++) for their "Data-Oriented Technology Stack" (DOTS).

Data Oriented Design Resources


PS: While your approach seems to borrow some of the organizational principles from Entities, Components, Systems (ECS) the games industry has already established some semantics around the "Data-Oriented" space for the past 10+ years (and it has been spreading from there) that don't align with your ideals. So it may make sense to shift to a different moniker like "data-centric" (though there the relation to data-centric architecture needs to be carefully considered).

Collapse
belgoros profile image
Serguei Cambour

In short - switch to Elixir :)))

Collapse
viebel profile image
Yehonathan Sharvit Author

Why Elixir and not Clojure?

Collapse
peerreynders profile image
peerreynders

Clojure works great when you need to integrate with legacy enterprise systems.

But if you need a scalable, fault-tolerant (i.e. resilient) and highly concurrent platform with a functional language that includes primitives to support those objectives on the language-level then Erlang/Elixir is a better fit.

And frankly there is always Jinterface

The Erlang Rationale

Thread Thread
marciol profile image
Marcio Lopes de Faria

Hi @peerreynders , it'd be nice if Idiomatic Elixir makes use of more Maps and Lists and less use of data encapsulation on Structs so that we can exchange maps and lists freely and make the quote "100 functions over one data structures" more present in Elixir than "10 functions over 10 data structures" that it's what happens with the overuse of Structs.

Collapse
bias profile image
Tobias Nickel

data oriented programming. I was looking for a word for that.

"let data be data"

Collapse
viebel profile image
Collapse
macsikora profile image
Maciej Sikora

Interesting trick, as too many books have functional programming in name, you made the name different - data oriented programming, what looks different, where in real ain't ;)

Collapse
viebel profile image
Yehonathan Sharvit Author

If you read the book you'll learn what is the difference between DOP and FP.