groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: Is it possible to enable CompileStatic for an entire project
Date Mon, 27 Jun 2016 19:47:20 GMT
What I'd like to see in Groovy or Kotlin is a way to be a static language but declare a type
as dynamic or a certain type of "dynamic" (like gpath/xml where you know you are accessing
map of maps). Kotlin has a feature named dynamic type, but it doesn't work in JVM, and even
if they got it to work I doubt it could compare to Groovy MOP. And it doesn't look like a
feature they would care much about.

The link you posted on the Gradle group is totally on point -- "don’t create a tower of
Babel". And that is my point for not discounting Groovy, especially static Groovy. Most must
have Java because we have years of legacy code for which there is no reason to port. In general
I prefer static languages and use them wherever possible, but see and understand the multitude
of cases were dynamic is either far easier (duck typing/scripting), or more efficient (web
services where you use a small part of a huge WSDL). As much as I like Kotlin, I like a dynamic
option more. Given that 3 languages is too many (especially if we consider JavaScript or other
frontend in many projects), and Kotlin does not support dynamic programming, Kotlin is out
because it can't do everything Groovy can do. So now we are down to asking for improvements
to the static side of Groovy so we can have it all :).

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag@gmx.org] 
Sent: Monday, June 27, 2016 3:23 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

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

----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
Mime
View raw message