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:blackd...@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.
