groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Mon, 27 Jun 2016 19:22:53 GMT
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

Mime
View raw message