Groovy was great for “more than Bash” and DSLs.
I was wrong. Last year we gave Kotlin a try as a team and at this point we’re 100% Kotlin where we would’ve been using Java or Groovy (which would be the vast majority of our code).
Spring and IDE support has made this transition easy. Coroutines are great for the type of code we write, SAM advances in Kotlin 1.4x have removed the last couple “I like the way Java handles that better”. Best off, all of those libraries we already created and use are still completely usable, we didn’t have to rewrite anything.
For me nullability checks by default, synthetic/map backed properties, extension functions, inline/reified functions, and coroutines have so drastically improved the readability AND conciseness of our code I can’t imagine going back.
By way of example:
Final classes by default with an open keyword instead of open by default with a final keyword. Inheritance is a very tricky thing to get right and it’s better to explicitly say “I thought about this and put in the effort to make it work”.
Checked exceptions are a contentious topic and I’m not sure which choice I prefer, but Kotlin chose to remove that, and it has an impact on style.
...is exactly the wrong way around. Inheritance is very much about unplanned reuse and programming by difference. That is: there is something that almost works the way you want, but not quite.
If you are actually planning this ahead, then typically inheritance is the wrong approach and you're better off using composition.
Interfaces are completely free of this burden. Abstract classes signal that you're working with an incomplete implementation and you're expected to cooperate with the base case to make things work. Final classes just opt out of this whole thing altogether.
What, exactly, does a class being open say? In a default-open context, you don't know whether this is an omission or a design choice. In a default-final context, you're explicitly allowed to mess with the class (and, because of the explicitly open methods, only in safe ways).
I think there are a whole lot of people who might disagree with the assertion that this is "the whole point" of OOP. Including one Alan Curtis Kay.
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
> Open classes are useless without open methods
You seem to mix "class" and "object" rather freely. They are quite different things. Also, not sure what you mean with "open methods". I can add methods to something in a subclass. I can override methods in a subclass.
> letting your child classes mess up those invariants.
Who is the "you" of the "your" in this context? A class? But a class is not a really a thing, objects are. And it is the objects that are the units of encapsulation in OOP. Not classes. Classes are just convenient bundles of behaviour and templates for state that is attached to objects.
You might think this is silly nitpicking, but it's actually a really, really important distinction:
As a teacher of object-oriented programming, I know that I have succeeded when students anthropomorphise their objects, that is, when they turn to their partners and speak of one object asking another object to do something. I have found that this happens more often, and more quickly, when I teach with Smalltalk than when I teach with Java: Smalltalk programmers tend to talk about objects, while Java programmers tend to talk about classes. I suspect that this is because Smalltalk is the more dynamic language: the language and the programming environment are designed to help programmers interact with objects, as well as with code. Indeed, I am tempted to define a “Dynamic Programming Language” as one designed to help the programmer learn from the run-time behaviour of the program.
http://web.cecs.pdx.edu/~black/publications/O-JDahl.pdf
And the object in question is an instance of the subclass, and if you are going to involve classes, it is the subclass that is responsible for maintaining invariants. The superclass no longer has that responsibility for instances of the subclass. So nobody is messing with anyone's invariants.
A lot of those are almost philosophical differences, though. A Java feature that is unambiguously bad, but probably impossible to remove, is the different equality semantics between atomic types and their boxed versions.
Simply because using Kotlin brings in more moving parts. For example: https://docs.micronaut.io/latest/guide/index.html#kotlin
> When you use any Micronaut AOP Advice, it creates a subclass at compile-time to provide the AOP behaviour. This can be a problem because Kotlin classes are final by default. If the application was created with the Micronaut CLI, the Kotlin all-open plugin is configured for you to automatically change your classes to open when an AOP annotation is used. To configure it yourself, add the Around class to the list of supported annotations.