I would love to work with someone who can explain complex low-level problems so accessibly and move from the big picture to the details and back with ease as Mr. Brian Goetz does! It would've make my developer career so much easier and enjoyable.
There seems to be a pattern here. Brian's talks tend to have dull and somewhat uninteresting titles, but then turn out to be chock full of extremely well explained software engineering wisdom.
Gawd, I can't help but think how I wish to just for once work on something where I can iterate many times to get it right, instead of the usual "ship the proof of concept" approach.
And after shopping poc, just fix all the bugs before the next release, and keep in mind that we are going to connect new partners already the next month.
I like how the Java ecosystem is clearing up the technical debt. JVM languages have come and gone, Java has borrowed some of their best parts and made itself better. JDK 21 onwards, Java's future looks bright. Next I would like to see is a culture of less verbosity in code. This is as much a function of coding culture in Java community as much it is about language support.
Java's future does look bright! There is such a thing as good verbosity... I would describe it as 'terse verbosity" that minimizes the possibility of ambiguity in the reader's interpretation. timeout = 50 // could be interpreted as seconds, milliseconds, or minutes by both the reader and the CPU, depending on how it's used timeoutMs = 50 // interpreted as 50ms by the reader, could be interpreted differently by the CPU depending on how it's used timeout = Duration.of(50, MILLISECONDS) // means the same thing to the reader as it does the CPU Like the talk says... "find the primitive" and build outward from that... this reduces "noisy" verbosity and cultivates "terse" verbosity Edit: a lot of "noisy" verbosity is often associated with unwieldy designs - let's call them either "jellyfish" or "sea urchin" designs depending on if they are too amorphous or too rigid. Developers working on large teams often use verbose names to either prop up jellyfish designs... or to fit in with the hierarchical rigidity of a sea urchin design. Verbosity that brings clarity is good... verbosity that doesn't communicate intent or that confuses the reader is probably symptomatic of something deeper
The lambda builder stuff seems like a solution in search of a problem. All you're doing there is filling in a buffer and passing it to the "assembler". The builder doesn't really seem at add anything. Sure you can then run the lambda twice, but if you'd just stuck with a buffer you wouldn't have to run all that code twice.
cool api. since they designed everything from scratch I find it a bit odd that they have slots as int instead of properly exposing a record type (e.g., SlotId) so you can't accidentally pass an int from elsewhere. It's not like you'd need to do arithmetic on slot ids (if you use the api to create them)
I would guess the tradeoff is avoiding allocations of trivial types at the expense of some safety. Valhalla may have made it redundant but delaying the API for when Valhalla eventually lands would not have been acceptable. To me it seems they still went with the best choice they had.
![fellow fellow - พรุ่งนี้ไม่มีใครรู้ feat. INK WARUNTORN [OFFICIAL MV]](http://i.ytimg.com/vi/QP6JyjYx_W0/mqdefault.jpg)
I would love to work with someone who can explain complex low-level problems so accessibly and move from the big picture to the details and back with ease as Mr. Brian Goetz does! It would've make my developer career so much easier and enjoyable.
14:00 Best explanation of how Inversion of Control really works
At19:08, eliminating magic numbers for slots makes the code so much clearer. At 21:40 is the wisdom take-away. I'm excited for this.
There seems to be a pattern here. Brian's talks tend to have dull and somewhat uninteresting titles, but then turn out to be chock full of extremely well explained software engineering wisdom.
Gawd, I can't help but think how I wish to just for once work on something where I can iterate many times to get it right, instead of the usual "ship the proof of concept" approach.
And after shopping poc, just fix all the bugs before the next release, and keep in mind that we are going to connect new partners already the next month.
We must be working for the same company. Actually, pretty much all the companies I've worked for.
i'm a simple man. i see brian goetz, i click
"They took away your IDE like 7 years ago" and what comes afterwards: Even a proper. good sense of human. Great session, thank you!
Great improvements
Great presentation! Can't help to think how interesting would be to see this API usage in Kotlin.
Really looking forward to testing that!
Will the code generation also be a part of the project? I see the mention of "write" there in JEP summary =)
I like how the Java ecosystem is clearing up the technical debt. JVM languages have come and gone, Java has borrowed some of their best parts and made itself better. JDK 21 onwards, Java's future looks bright. Next I would like to see is a culture of less verbosity in code. This is as much a function of coding culture in Java community as much it is about language support.
Verbosity is fine. It's layered the way it is for a reason so you could swap out the layers.
Java's future does look bright!
There is such a thing as good verbosity... I would describe it as 'terse verbosity" that minimizes the possibility of ambiguity in the reader's interpretation.
timeout = 50 // could be interpreted as seconds, milliseconds, or minutes by both the reader and the CPU, depending on how it's used
timeoutMs = 50 // interpreted as 50ms by the reader, could be interpreted differently by the CPU depending on how it's used
timeout = Duration.of(50, MILLISECONDS) // means the same thing to the reader as it does the CPU
Like the talk says... "find the primitive" and build outward from that... this reduces "noisy" verbosity and cultivates "terse" verbosity
Edit: a lot of "noisy" verbosity is often associated with unwieldy designs - let's call them either "jellyfish" or "sea urchin" designs depending on if they are too amorphous or too rigid.
Developers working on large teams often use verbose names to either prop up jellyfish designs... or to fit in with the hierarchical rigidity of a sea urchin design.
Verbosity that brings clarity is good... verbosity that doesn't communicate intent or that confuses the reader is probably symptomatic of something deeper
Verbosity should not be reduced. Just use ide
It would be strange if you did not have a strict model in the API for something that obviously had a strict model.
The lambda builder stuff seems like a solution in search of a problem. All you're doing there is filling in a buffer and passing it to the "assembler". The builder doesn't really seem at add anything. Sure you can then run the lambda twice, but if you'd just stuck with a buffer you wouldn't have to run all that code twice.
cool api. since they designed everything from scratch I find it a bit odd that they have slots as int instead of properly exposing a record type (e.g., SlotId) so you can't accidentally pass an int from elsewhere. It's not like you'd need to do arithmetic on slot ids (if you use the api to create them)
I would guess the tradeoff is avoiding allocations of trivial types at the expense of some safety. Valhalla may have made it redundant but delaying the API for when Valhalla eventually lands would not have been acceptable. To me it seems they still went with the best choice they had.
looks like llvm … … 👍👍👍