On Monday, 23 April 2018, in the evening, I was attending two talks by Brian Goetz, Oracle Language Architect, at the Werkspoorkathedraal in Utrecht. The talk was made possible with the help of several parties, for example JPoint2 and Code Nomads3.
First talk - On Software Design
This first talk was not about technical details, but more about us software designers as a group, and how we tend to be tribal like the rest of the Human Race. Our tribes are split up upon the lines of programming languages, editors, software paradigms, layout, etc.
From an evolutionary standpoint this has always been a good idea, to protect the group, from predators and other software designers. Currently, it will limit us in our way of thinking, in trying new ideas (generated "outside the tribe") and promotes right-wrong judgmental thinking, etc.
All the energy that is spent condemning other practices of software design, can be better spent on becoming a better software designer.
Most users of software do not care about software design, they care about working programs.
Software design
When comparing Functional Programming to Object Oriented Design, what immediately stands out is that Objects are a bit more ambitious compared to Functions. Functions are derived from the Procedural way of programming.
Every programming language has a "Everything is an object|function|file|thingamabob", and that works for 5 minutes, and then it becomes impractical.
A lot of programming paradigms have always been quickly hailed as the solution to all our problems. So far this has not worked out. Every programming paradigm must be seen as another tool in the software designers toolbox.
One of the more interesting questions of course is when should you apply what. I think that is where the good software designer can stand out from the rest. Brian mentioned that, in the case of object oriented versus functional, the functional is a good fit for business logic, where the object oriented is a good fit for everything surrounding the business logic, for example databases and IO.
Second Talk - All Aboard Project Amber
The second talk went quite in-depth into the new features of project Amber4 and also the problems associated with changing an old language that everyone is using, without everyone trying to hang the Language Architect. As well as how to decide what new features to add, how easy they are to add, and how much use they would be.
What was interesting was to see the area each JDK focused on, the following list was mentioned:
- JDK 5
- rebooting data abstraction (by means of Generics)
- JDK 8
- rebooting behavioural abstraction (by means of Lambdas)
- JDK 9
- rebooting configuration and encapsulation (by means of Modules)
Java Language Principles
He mentioned his favorite sheet, which looked like this:
- code should be a joy to read
- the language should not hide what is happening
- code should do what it seems to do
- a clear semantic model greatly boosts reusability
- every good feature adds more bad weight
- sometimes it is best to leave things out
General rule: type inferences is ok in implementation not in APIs.
Naming is the single most expressive place to indicate to our audience what our program is.
Raw string literals
It will be possible to use backticks to indicate a beginning and an end of a string. Everything in between will be treated as raw information.
Product types
It is a class that only contains data, for example:
record Point(int x, int y)
You could call them Plain Old Data Objects - PODOs
Disclaimer: uh, the abbreviation PODO is mine, and not Brians.
Records are like Enums, in that you decide to give up some things, and in return you get reliable defaults.
Sum types
The possibility to limit the amount of subclasses, by means of a sealed Interface. For example:
sealed Interface Shape;
record Point(int x, int y);
record Circle (Point center, int radius) implements Shape;
record Rect (Point 11, Point ur) implements Shape;
Pattern matching and the improved switch
The switch statement has always been very limiting to Strings and primitive data types.
That is why usually you had to use the Visitor5 pattern to get anything complex done.
Im going to have to point you to documentation that explains this a lot more in depth, than I can in this blog6, 7.
Conclusion
Brian talked about a lot of things, some of which I have endeavoured to transcribe here. I enjoyed listening to him immensely as he is a captivating speaker, who seems to really know what works and what not in the realm of programming languages.
Brian is a big proponent of the new Java release cadence, and what it has to offer for us software designers.
Choice quotes
I always enjoy hearing pithy comments. Somewhere along the talk, he mentioned these gems:
“Homomorphism : the translation from real world to software applications (or vice versa), where all the relations stay intact. It does not work, because inevitably information is lost during the transformation.”
- Brian Goetz
“It's very common for software designers to have opinions on things they know nothing about.”
- Brian Goetz
“Nothing is more dangerous than an idea, if it's the only idea you have.”
- Émile Chartier
“Sorcerers Apprentice Objects.”
- Brian Goetz - on classes created when you are still learning the language
“Actually I made up the term object oriented and I can tell you that I did not have C++ in mind.”
- Alan Kay
“We write in C++ so you don't have to.”
- JVM software designers.
References
- [1] Brian Goetz
- https://www.linkedin.com/in/briangoetz
- [2] JPoint
- https://www.jpoint.nl/
- [3] Code Nomads
- https://www.codenomads.nl/
- [4] Openjdk - Project Amber
- http://openjdk.java.net/projects/amber/
- [5] Wikipedia - Visitor Pattern
- https://en.wikipedia.org/wiki/Visitor_pattern
- [6] JEP 305 - Pattern matching
- http://openjdk.java.net/jeps/305
- [7] JEP 325 - Switch expressions
- http://openjdk.java.net/jeps/325
