Data Oriented Programming in Java 21 by Nicolai Parlog
Вставка
- Опубліковано 21 сер 2024
- In data-oriented programming (DOP), we model data as data and polymorphic behavior with pattern matching. This talk will introduce the concept of DOP and its four principles:
- model the data, the whole data, and nothing but the data
- data is immutable
- validate at the boundary
- make illegal states unrepresentable
We'll also explore how to use pattern matching as a safe, powerful, and maintainable mechanism for ad-hoc polymorphism on such data that lets us define operations without overloading the types with functionality. The talk ends with a juxtaposition to OOP, so you not only learn how to employ DOP but also when (not).
I found this talk did a good job of relating a lot of the new features and justifying them, which was very helpful when I then watched one of Brian Goetz's recent talks on new features in Java.
it is always great to see concepts put into real example that can be translated into other similar abstractions and use cases
Been using this technique in Kotlin/Scala for a while and really like it, glad to see it finally land in Java.
have been happily pattern matching and doing data driven design in Scala since around 2007... 20 years after and it's still only fully available in Java 22(!). Probably another 10 years before 8 and 17 go out of business. A feature gap of 30 years is huge, that's an entire generation of new developers who never had a chance to use these principles. I still don't get why Scala couldn't make it on JVM (despite the usual controversy)
+20 years ago DDD gave us VALUE OBJECTs to help us with immutability in OOP and now JAVA is given us Record, Thank you Team.
Awesome video! I like the way you combined several features and explained them in the context of solving a real problem (crawling).
Is it functional? I am not familiar with FP. But it's definitely procedural. Uncle Bob mentions exactly this in his CC book.
And also mentions the tradeoff being made.
It general PP makes it cheap to add new behaviour but expensive to add new types. Imagine you want to add new GH page type, then you have to update all the methods, but you can keep the the old types intact. With OOP it's the opposite.
31:31 must be able to add new types without touching existing code (open/closed principle)
I see having error pages as a bit of an abuse. In this case I would introduce another hierarchy of Response-like objects that may wrap real pages (IssuePage, PrPage, etc) and provide HTTP layer response metadata (statuscode, headers, etc)
Awesome
nice
Very interesting topic; thank you for posting it.
I don't like how the presentation shows the speaker and their screen at the same time. It's annoying to have to follow both.😞 And what's with the video's background;? What a waste of bandwidth; it could have been used to show more detail of the speaker's screens.
Just watch Mike Acton, unfortunately Brian Goetz got it wrong this time
You're joking of course. Acton says "solve for transforming the data you have given the constraints of the platform [by which he means the Hardware] and nothing else." The fundamental principle upon which Java was founded is WORA: "write once, run anywhere". Mobile code. Acton does not use Java, and cannot, because it is fundamentally hardware independent. He programs games for consoles.
Acton's obsession is with performance so he is concerned only with the fantasy world within his program without any concern for its relation to the real outside world, so he has no use for abstraction.
Why this mofefokas aren't concise and clear,?😅
You can actually apply DOP to big complex data calculations as well. Consider big games for example, where you have lots and lots of stuff transforming around the world. It's much more easier to use mental model of OOP to make this game world. But once you build it with DOP mindset, you would have no reason to switch back to OOP mindset. There is actually zero reason to not program in DOP mindset. Encapsulation - is not really a thing. You are hiding information from programmers, not from the actual program. The reality is that most of the time your incapsulated information will run on the same machine, same virtual memory, same process, etc. The only reason to consider encapsulation as a rule of thumb - is because of mental model culture, thinking that every object in your code is an isolated unit with hidden information, when in reality - it's not.
The core idea of DOP - is to utilize your CPU resources, with data vectorization(SOA), in/out functions that operate on the only data they need, parallelization.
I already like the idea that someone at least try to bring DOP into Java, because Java is so overloaded with OOP and natively inherits a lot of bad practices and brings a lot of "abstraction software engineers" into the life. Of course, it would be better if someone could upgrade Java and finally add manual memory managment, raw pointers, custom mallocs, heap/stack managment, maybe some compile time generation feature and still have high-level syntax. BUT again, the problem is that the language was originally architected around OOP mindset, so it would be easier to just make new language from that point.
I didn't learnt anything in this fuckin😂courze
This guy continually calls things polymorphism which arent...I feel sorry for new java developers..
"This guy" here. Can you point at a few of those things? I want to make sure not to mislead new Java devs. 😉
Why this modafukas aren't clear? Why they want to show that they knows google knowledge?😅
I hope my comment serves as a good guide for beginners, assuming that your comment is satirical!:
Dynamic dispatch _is_ polymorphism, fellow internet stranger!
You see, C++ programmers don't get this feature without an extra keyword (which notifies them that this feature is going to be used, which can sometimes be a bad thing for performance, hence it is a language feature).
Imagine making an instance (an object!) of a subclass (so, a class that extends another) and calling a method on it.
If this method was overridden by the subclass, then, _no matter_ what the type of the variable was, the method called would be the overridden version from the subclass.
This happens because the compiler stores an extra table (called the "V-table", or in Java's case, the "I-table") along with EVERY OBJECT[!], to keep track of what version of a method should be called.
Method calls that need the V-table are called "virtual calls" (because... we make the concept of an object "virtual", and go on to call methods that were not defined in the class the object is from, but were defined in other classes, because we used inheritance).
Virtual calls are often avoided in data-oriented design (as shown in this talk, in the form of the separation of processing methods), because looking into a table is simply extra work we can avoid using a data-oriented design.
To answer those wondering why a hierarchy for `Page` was used, well, please recall the fact that `Page` is a `record`, which means that the compiler is already making some optimizations for when they are used, and that the hierarchy exists only for pattern-matching, since we're using a sealed interface.
_I hope this helps someone!_
First Nicholai defined Polymorphism as Runtime Polymorphism (method overriding) in Java which is what most people mean by it. He proceeded to show a new concise alternative using switch on Types, gave a good example, and explained its limitations and when you might want to use it (to maintain separation of concerns when adding an ancilliary feature - my interpretation). I had some concerns during the presentation but by the end I was very satisfied with the talk as a whole and got his message.