Discussion

Sign in or Join to comment or subscribe

2023-01-16T17:25:08Z ago

This was a tough one to get through - mostly because “data oriented programming,” as defined, came off as a total straw man argument. If the answer to the question: “what kind of advantages does this offer over a statically typed approach” comes as “well, it’s just better,” you might be part of a straw man debate!

I also think that Mr. Sharvit entirely misses the point of static typing - not that they’re alone in this. Their example of generative testing (which is actually just mutation testing, but that’s an aside …) is a great example of missing the forest for the trees. I recently refactored the GitHub Action of a friend from Google’s from JavaScript to TypeScript. One of the first things that I found, while importing the proper types and converting the files, was that a hashed set being passed around had an incorrect value in it. The benefit of static typing isn’t binding your schema to your types - if you’re doing that, you’re just imperatively programming and that’s not really object-oriented anyway. The benefit is that there are whole suites of tests that you don’t have to write, because your program cannot even compile if you get something wrong. I don’t need to mutation test the proper usage of that hash set anywhere; it’s enforced for me at compile time.

Let’s take the creation of an API as another example - the deferral of schema creation from compile time to PR review time is an example of shifting right; the exact opposite of what we want. Shifting left, or getting feedback earlier on in the development cycle, isn’t just some industry buzzword - it’s a methodology that prevents us from having to write the kind of code (or, even worse, some sort of markdown checklist present during a review) to validate that something exists when the alternative would be… letting the compiler do that for us without having to write anything at all.

Lastly - there are plenty of great applications out there which conform to the stated principles of data-oriented programming (passing generic iterables, immutable data, schema divorced from types, etc …). So - data oriented programming (as stated) fits within the confines of both functional and OOP paradigms - much like design patterns, it can be a useful device to keep in mind, but I would describe it ultimately as a tool rather than as something scoped larger than that.

2023-01-19T11:46:03Z ago

I totally double your point.

Moreover, being a former clojure programmer I find it amusing that clojurians have the same argument over and over again “oh, we’re using plain persistent data structures and it is awesome” for last 10 years. Well, it is awesome until it isn’t and that’s why we have schemas in clojure nowadays.

Why clojure is cool? Because you can grasp lisp homoiconicity and treat code as data, you have plenty of functions to work with your data and you are in Java ecosystem which enables access to ton of great libraries.

Why clojure is not cool? Well, it has performance problems, it has readability problems when you’re overconfident with macros and you must have a lot of schemas to ensure you can find loose ends when things go wrong.

2023-03-22T00:44:35Z ago

I don’t know anything about clojure; I had never heard of it. But as someone who would classify themself as more of a data engineer than a more well rounded and experienced software engineer, I found the proposal lacking a lot of substance. Yes, when you’re developing a data heavy application or process, you should treat the data as a first class citizen, but if it’s not data heavy, then don’t. There are plenty of ETL tools out there, and plenty of API tools/libraries out there. And Python+Pandas+SQLAlchemy+FastAPI is a good example combination. Databricks+Scala, etc.

Player art
  0:00 / 0:00