Boilerplate free case classes, sealed hierarchies and exhaustive pattern matching are my favourite aspects of scala (and other analogous features found in more functional languages) I'm very happy to see these features finally make their way into the latest java versions. Nice talk!
Dear Mr. Bierman, thank you very much for clearly explaining to us the purpose of the Amber project and the relationship between the features that compose it to give Java the complementary dimension of data-oriented programming.
A thing of sheer elegance and beauty. JSON in Java is as simple as it should be and no simpler. I’m loving this!!! Great job dear ninja architects. I want to be like you when I grow up.
Nice presentation of the new ways to use Java and one of the best introductions I've seen to sealed classes--something that many people (me included) don't initially understand, or understand the point of, or know how and when to use.
Is there any advantage/disadvantage of using say a pattern-matched switch case over the Visitor pattern? Aside from being less complicated. I've always worked under the assumption that one should avoid explicitly type-checking and instead use method overloading to determine the type you'd like to use for a specific action. Would like a reason to revisit that assumption.
I agree this mental change has been silently brought in without proper discussion. My understanding is that the Visitor pattern still makes a lot of sense when you want to make that boundary highly flexible, moving the decision to runtime, e.g. a plugin api for your software. Conversely, when you have very high cohesion on that boundary, you prefer to have type-based pattern matching, so that things immediately break at compile time without introducing any runtime reasoning (e.g. the calculator API shown must never allow you to define operators that don't have a proper routine to compute the result)
@@ennioVisco Further, the whole issue is that Java doesn't support proper algebraic types(aside from exceptions for some reason), so this pattern matching seems like a crude hack to enable this basic feature with moderate amount of boilerplate so it works 99% of the time. It's still the same issue of language being broken fundamentally and all fixes are weird hacks that kinda remedy the issue rather than actually fixing it, so it's not gonna be the proper full solution, it's just one more hack on your toolbox to work around language limitations. That being said, I'm quite happy about this hack. You get tagged union types 99% of the time with acceptable amount of boilerplate. Boilerplate is always going to be an issue, and I think the 1% where the hack fails are not gonna be situations that would bother me that much. But seriously, Java has full tagged union support for checked exceptions, with *less* boilerplate, since forever. Why do they rather poorly try to reinvent the wheel and produce this square monstrosity, rather than just use the existing functioning one they use to carry the square wheels to the market?
@@gJonii Some issues that I know of/things I have seen people complain about with checked exceptions in Java: - Don't really work with streams (afaik this can't really be fixed) - Can't be generic (which can't be changed due to how type erasure works) - Fairly ugly and annoying to use in code, if you have a bunch of them - A lot of people don't like them, to the point where some other JVM languages, like Kotlin, didn't even include them at all
They all are nice features. But I'm yet to see a connection with misleading video title. Data oriented programming is about organizing data and computations the way so it will be fetched by cpu in a most efficient way. This doesn't even try to scratch that topic :(
@nevgeniev in the functional programming circles i travel in this use of the phrase "data oriented programming" fits. It more or less means data structures oriented programming, a good example being the last part of this video where the hidden json was traversed "without" statements. This is a long winded way of saying, his use of the phrase makes sense to me and likely many others.
I'm somewhat worried; if the 'record Point(int x, int y)' is defined and a record pattern matches it with 'instanceof Point(int x, int y)' what happens if I decide to change the order of the record's constructor to '(int y, int x)'? I hope the compiler will detect that. Hmmm, need to run some test with these features.
you'd face the same issue when using a regular constructor too - you'd have to change the parameter order everywhere you instantiated it in the program
@@mihaiapostol7864 Yeah, was afraid of that, and I think that is fragile. One of the things records lack IMHO is a very simple builder for all the constructor parameters; Point.x(...).y(...). The sequence is fixed and the last parameter-method is the 'build'. If you change the constructor's parameters, even the order, the compiler would require you to revisit all usages. Because Point(1,2) means something else now, and I need to write Point.y(...).x(...). I do not see an easy pattern for doing something similar with record patterns. Maybe the IDE's will pick this up.
what about 'prefer polymorphism over if/else or switches' This is a new style, and one might want to see a bit more of motivation to reverse the concept in these cases.
It's basically a more direct version of the visitor pattern. The point is to use it when you have a limited number of types but lots of operations on those types. The design challenge in using pure polymorphism is blowing up the interfaces of your limited number of types. The previous danger of type checking with if/else or switches without the compiler checks is you might accidentally miss a scenario. Thus the visitor pattern was born. Now when you have enums or sealed classes, you can confidently use switch expressions and not worry about silent failures - the compiler will let you know. It streamlines a style of programming that many problems are amenable to. Beyond that, I would imagine some of this is forward looking to Project Valhalla, and the JVM will be able to better optimize this pattern. But that's pure speculation.
@@encapsulatio (1) Not modeling data as objects (2) organizing data in memory so it can be iterated over quickly (e.g. instead of a list of vectors being laid out in memory as xyzxyzxyzxyz, have it xxxxyyyyzzzz). (3) Not thinking in terms of single objects, but in terms of objects as part of particle systems.
@@Tekay37 I agree it should probably be called Value-Oriented Programming or something. Lack of control over memory layout is the only thing that I consider to be missing. From the examples in the video, records do not seem to exhibit behavior, and they definitely lack internal state, so I don't see a reason to refer to them as objects in the OOP sense.
@@nathansgreen They are "POJOs" (Plain old Java Objects), as Robert Martin would call them in his "Clean Code" and "Clean Architecture" books. I don't see anything new or non-OOP about them. They are just the kind of Object, you'd use to pass around data in an OOP system.
@@Tekay37 I too got confused, but what you are talking about is "Data-oriented design" which is about speed, cache friendliness, data layout etc. There are other talks and videos about "Data-oriented programming" which I guess is just a fancy name for "functional programming", or at least the concepts are very similar. It has nothing to do with "DOD" and used only for readability and simplicity, not performance boost.
That's how Java works. It's a "last mover" language. The Java developers first look at how language features do in other languages, and whether they prove themselves over the course of (afaik) years, and what issues they might potentially have. And only then, it is considered whether Java adopts a feature as well, and if so what the best version of that feature might be (evaluating what was learned by how other languages implemented the feature). Innovation, on the other hand, does happen too, but it happens on the side of the Java Virtual Machine!
Boilerplate free case classes, sealed hierarchies and exhaustive pattern matching are my favourite aspects of scala (and other analogous features found in more functional languages) I'm very happy to see these features finally make their way into the latest java versions. Nice talk!
Scala lead the way several times I think..but always great to get these in to java eventually.
Dear Mr. Bierman, thank you very much for clearly explaining to us the purpose of the Amber project and the relationship between the features that compose it to give Java the complementary dimension of data-oriented programming.
A thing of sheer elegance and beauty. JSON in Java is as simple as it should be and no simpler. I’m loving this!!! Great job dear ninja architects. I want to be like you when I grow up.
Nice presentation of the new ways to use Java and one of the best introductions I've seen to sealed classes--something that many people (me included) don't initially understand, or understand the point of, or know how and when to use.
Good Summary of the new features in Java- Thanks!
Thank you, this episode really helped me understand what I still was not 'getting' about the new patterns Project Amber features!
Good explanation and summary of the goodies of project amber.
Good presentation, I liked it. 💚💙💜💛🧡 Thanks!
Thanks for sharing this new concept. Quite enjoyed it.
Making Java do DOP seems so much more complex than in other languages. I would question the cost/benefit of using Java for the approach.
What's the question? If you need to use Java, why not handle the problems he covers with the tools he presented? What do you think the downsides are?
very impressed! thanks
Is there any advantage/disadvantage of using say a pattern-matched switch case over the Visitor pattern? Aside from being less complicated.
I've always worked under the assumption that one should avoid explicitly type-checking and instead use method overloading to determine the type you'd like to use for a specific action.
Would like a reason to revisit that assumption.
I agree this mental change has been silently brought in without proper discussion. My understanding is that the Visitor pattern still makes a lot of sense when you want to make that boundary highly flexible, moving the decision to runtime, e.g. a plugin api for your software. Conversely, when you have very high cohesion on that boundary, you prefer to have type-based pattern matching, so that things immediately break at compile time without introducing any runtime reasoning (e.g. the calculator API shown must never allow you to define operators that don't have a proper routine to compute the result)
@@ennioVisco Further, the whole issue is that Java doesn't support proper algebraic types(aside from exceptions for some reason), so this pattern matching seems like a crude hack to enable this basic feature with moderate amount of boilerplate so it works 99% of the time.
It's still the same issue of language being broken fundamentally and all fixes are weird hacks that kinda remedy the issue rather than actually fixing it, so it's not gonna be the proper full solution, it's just one more hack on your toolbox to work around language limitations.
That being said, I'm quite happy about this hack. You get tagged union types 99% of the time with acceptable amount of boilerplate. Boilerplate is always going to be an issue, and I think the 1% where the hack fails are not gonna be situations that would bother me that much.
But seriously, Java has full tagged union support for checked exceptions, with *less* boilerplate, since forever. Why do they rather poorly try to reinvent the wheel and produce this square monstrosity, rather than just use the existing functioning one they use to carry the square wheels to the market?
@@gJonii Some issues that I know of/things I have seen people complain about with checked exceptions in Java:
- Don't really work with streams (afaik this can't really be fixed)
- Can't be generic (which can't be changed due to how type erasure works)
- Fairly ugly and annoying to use in code, if you have a bunch of them
- A lot of people don't like them, to the point where some other JVM languages, like Kotlin, didn't even include them at all
@@ennioVisco Thanks for that explanation. Much appreciated!
Very useful presentation - thanks.
Glad you enjoyed it!
They all are nice features. But I'm yet to see a connection with misleading video title. Data oriented programming is about organizing data and computations the way so it will be fetched by cpu in a most efficient way. This doesn't even try to scratch that topic :(
I came exactly for this. And got disappointed 🫠
@nevgeniev in the functional programming circles i travel in this use of the phrase "data oriented programming" fits. It more or less means data structures oriented programming, a good example being the last part of this video where the hidden json was traversed "without" statements.
This is a long winded way of saying, his use of the phrase makes sense to me and likely many others.
28:03 wouldn't it be more uniformly to write it like this?:
if ( j instanceof JsonObject ? (pairs) ) { ... }
Why Map instead of Map? If this was done intentionally, it should be explained, because it doesn't seem obvious at first glance.
I'm somewhat worried; if the 'record Point(int x, int y)' is defined and a record pattern matches it with 'instanceof Point(int x, int y)' what happens if I decide to change the order of the record's constructor to '(int y, int x)'? I hope the compiler will detect that. Hmmm, need to run some test with these features.
you'd face the same issue when using a regular constructor too - you'd have to change the parameter order everywhere you instantiated it in the program
@@mihaiapostol7864 Yeah, was afraid of that, and I think that is fragile. One of the things records lack IMHO is a very simple builder for all the constructor parameters; Point.x(...).y(...). The sequence is fixed and the last parameter-method is the 'build'. If you change the constructor's parameters, even the order, the compiler would require you to revisit all usages. Because Point(1,2) means something else now, and I need to write Point.y(...).x(...). I do not see an easy pattern for doing something similar with record patterns. Maybe the IDE's will pick this up.
@@TomEugelink interesting solution with the builder :)
what about 'prefer polymorphism over if/else or switches' This is a new style, and one might want to see a bit more of motivation to reverse the concept in these cases.
It's basically a more direct version of the visitor pattern. The point is to use it when you have a limited number of types but lots of operations on those types. The design challenge in using pure polymorphism is blowing up the interfaces of your limited number of types. The previous danger of type checking with if/else or switches without the compiler checks is you might accidentally miss a scenario.
Thus the visitor pattern was born.
Now when you have enums or sealed classes, you can confidently use switch expressions and not worry about silent failures - the compiler will let you know. It streamlines a style of programming that many problems are amenable to.
Beyond that, I would imagine some of this is forward looking to Project Valhalla, and the JVM will be able to better optimize this pattern. But that's pure speculation.
Would appreciate if it was a dive into an actual example, I've seen these intros a lot on the channel.
This is not Data-Oriented Programming. It lacks the core elements of Data-Orientation.
Which are......?
@@encapsulatio (1) Not modeling data as objects
(2) organizing data in memory so it can be iterated over quickly (e.g. instead of a list of vectors being laid out in memory as xyzxyzxyzxyz, have it xxxxyyyyzzzz).
(3) Not thinking in terms of single objects, but in terms of objects as part of particle systems.
@@Tekay37 I agree it should probably be called Value-Oriented Programming or something. Lack of control over memory layout is the only thing that I consider to be missing. From the examples in the video, records do not seem to exhibit behavior, and they definitely lack internal state, so I don't see a reason to refer to them as objects in the OOP sense.
@@nathansgreen They are "POJOs" (Plain old Java Objects), as Robert Martin would call them in his "Clean Code" and "Clean Architecture" books. I don't see anything new or non-OOP about them. They are just the kind of Object, you'd use to pass around data in an OOP system.
@@Tekay37 I too got confused, but what you are talking about is "Data-oriented design" which is about speed, cache friendliness, data layout etc.
There are other talks and videos about "Data-oriented programming" which I guess is just a fancy name for "functional programming", or at least the concepts are very similar. It has nothing to do with "DOD" and used only for readability and simplicity, not performance boost.
This has nothing to do with data oriented design as layed out by Mike Acton.
Are this not all the things Kotlin did hmmmm?
That's how Java works. It's a "last mover" language. The Java developers first look at how language features do in other languages, and whether they prove themselves over the course of (afaik) years, and what issues they might potentially have. And only then, it is considered whether Java adopts a feature as well, and if so what the best version of that feature might be (evaluating what was learned by how other languages implemented the feature).
Innovation, on the other hand, does happen too, but it happens on the side of the Java Virtual Machine!