On 27.06.2016 03:44, Winnebeck, Jason wrote:
For the static side, Kotlin is a very interesting language compared to Groovy looking at
total new projects and teams not strongly trained in either, although even in that case
my intuition tells me that Groovy would be easier to learn as it is more like Java --
none of the developers on my team have has issues picking up Groovy especially since
essentially most Java syntax compiles directly as Groovy. Even as a static language,
Kotlin seems a lot more strict in that it wants to also enforce nullability in types,
while Groovy follows Java's semantics. In my mind Kotlin tries to "double down"
on compile-time analysis even compared to Java.
Kotlin wants to be stricter than Java, what would a static language gain
from being less strict? The problem is with the type system, which is
the core of a static language in the end. But if you evolve the type
system, you get into trouble with the Java world very soon. If you limit
yourself to synthetic sugar, you will be always in danger of being taken
over by Java.
SO I can fully understand they want to make this separation between
nullable and non-nullable types. It helps finding bugs after all, and
that´s what static languages are for.. right?
Btw... there s something about the name Kotlin... it sounds very much
like Kotling if not spoken out right.. then you are not at an island,
but at a mushroom group growing on excrements. No name is perfect ;)
But, if you have a project with dynamic and static requirements -- as far as I
know Kotlin has no dynamic capabilities for example to do things like gpath on
XML files -- now you have a dilemma if you have dynamic languages in your
toolbelt.
In theory a static compiler would be able to do gpath to some extend,
based on the schema of an xml file. For things like that, you need that
feature builtin or an extensible compiler... I have not seen an
extensible compiler for Kotlin as of yet. But yes, I know your point.
[...]
would I have a project mixing dynamic Groovy with static Kotlin and legacy
Java? Is such a thing even possible?
In practice it would probably fail at the joint compiler. To citate
https://discuss.gradle.org/t/kotlin-groovy-and-java-compilation/14903/2:
"""
* you can jointly compile Groovy and Java
* you can jointly compile Kotlin and Java
* you can serially compile any combination (but that means
dependencies can only go in one direction, e.g. Java < Groovy < Kotlin)
"""
So possible yes, easily no. You can btw replace Groovy with Scala here
and have the same issue. So it is not because of dynamic typing.
If it was a hard-sell to "train a team" in two languages (Java and Groovy),
yes, that´s a problem too.
I doubt most organizations would go for Java + Groovy + Kotlin. So now I have
both existing project that could never (rationally) displace Groovy, and even
if I was starting a new project, I can't say Kotlin can do everything I'd want
to do in Groovy but I can say the opposite (except for the unfortunate
occasional static compiler bugs and occasional IDE limitations) -- that Groovy
can do static and it can do dynamic and it can do Java++ while Kotlin only does
2 of those.
In that situation many start writing in Java, what Groovy would normally
do for them. That means dynamic dispatch through instanceof-chains
(including all the problems), programming a lot of generic code in
reflection and so on. Nobody cares about nice or slow in those cases.
So for any team that has embraced the value of a dynamic programming tool in their belt,
I can't see any room for Kotlin. Having static abilities in Groovy then handles the
"Java++" component and prevents the case of saying Groovy is useful for only a
small part of an app, because you can still get static benefits of refactoring and
compile-time checking if you wish.
A team that has truly embraced the value of a dynamic programming
language will tend to question the static language ;)
bye Jochen
