DOP is a good fit for building information systems

DOP is not the same as DOD [1]

1: https://blog.klipse.tech/visualization/2021/02/16/data-relat...

Don't confuse Data-Oriented Design with Data-Oriented Programming[1]

[1] https://blog.klipse.tech/visualization/2021/02/16/data-relat...

Ballerina team told me that in the future Ballerina will not be hosted on JVM.

> Ballerina team told me that in the future Ballerina will not be hosted on JVM.

They also told me that back at Kubecon in 2018 :D

https://github.com/ballerina-platform/nballerina :) This is an active project.

2017 but still relevant in 2022

I was a fine piece, to be sure. The point is, it's customary to append that the title (so people aren't drawn into clicking on the article as if it's something new).

Will do next time. Thanks for the tip!

Today, we are celebrating the first birthday Partying face of "Data-Oriented Programming".

What a journey since the first MEAP version of the book has been released on January 30, 2021.

My book "Data-Oriented programming" is #1 Manning best seller for 2021.

The book formulates the principles of an approach to data that reduces complexity and illustrates how to apply them in a statically-typed language like C# or Java or in a dynamically-typed language like JavaScript, Python or Ruby.

Here are the 4 principles of Data-Oriented Programming:

1. Separate code (behaviour) from data

2. Represent data with generic data structures

3. Data is immutable

4. Separate data schema from data representation

It might sound like Functional Programming but if you look closer at the principle list, you will notice that principles #2 and #4 are not part of FP.

For those who already bought the book or are interested, I released the book's source code to https://github.com/viebel/data-oriented-programming. The publication is expected for March 2022.

If you guys aren't sure about buying the book, contact me on Twitter @viebel, I'll DM you a preview.

After 18 months of development, I am glad to announce that I finally completed the first draft of my book: Data-Oriented Programming.

I wanted to thank all the people from the Clojure community that helped me in the thinking and the writing process.

The book is my attempt to formulate the underlying principles of Clojure approach to data and illustrate how to apply them in another language.

Here are the 4 principles of Data-Oriented Programming:

1. Separate code (behaviour) from data

2. Represent data with generic data structures

3. Data is immutable

4. Separate data schema from data representation

I am strongly considering buying a copy of your book and giving data-oriented programming a go in my day job. My only hesitation is data immutability. I work in a data-intensive scientific field where we frequently use custom, mutable data structures holding massive amounts of data. Creating persistent versions of these data structures would be an extremely complex undertaking. Do you have any thoughts about using data-oriented programming in situations when data mutability is difficult to avoid?

Could you elaborate about the complexity involved in using immutable data structures in your use case? Is that a performance concern?

That’s right. Our data structures are designed for working with large amounts of compressed text (dynamic FM-Index is one example). They are pretty hard to implement so making a persistent version of such a data structure would require a big time commitment. I imagine that my use case is not that unique and there are many situations where mutable data structures are hard to avoid.

In most languages, there are libraries that provide efficient implementation of persistent data structures.

What languages do you use?

I use C++ and Rust. Unfortunately, there are no persistent versions of the data structures I need available in any language (using dynamic FM-index as an example again). It is just interesting to think about “hybrid” systems where most of the code follows principles of data-oriented programming and some of the code deals with any unavoidable mutability.

I totally agree

Here are a few things my editor provided me: 1. A process for writing the manuscript 2. Contacting external reviewers 3. Marketing 4. Feedback on a monthly basis

Totally agree. Especially in READMEs