[jira] [Comment Edited] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0

["Endre Stølsvik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187217#comment-16187217 ] 

Endre Stølsvik edited comment on GROOVY-8329 at 9/30/17 10:01 PM:
------------------------------------------------------------------

First off, I actually use Groovy quite a bit these days. I do all "prototyping" and much of the actual coding in Groovy, and Java has become more of the "API level language" - that is, I still consider my at-work projects to be Java, so the app-internal API is pure Java (and Groovy-specifics cannot be passed around, i.e. Closures) - but most actual code ends up being Groovy. If this makes sense.

But: I pretty much _never_ use the dynamic parts of it - I use @CompileStatic on every single class, except on the few parts where I actually want to use the delegates and methodMissing and this stuff, i.e. DSLs - and also the few times I want to dynamically invoke stuff based on strings, like mentioned above. It is just so much simpler than introspection. Also, the GroovyShell with its Binding - love it! (I've made a JRebel-like tool that I use in exploratory settings: https://github.com/stolsvik/groovy-egl - but even inside scripts I slap @CompileStatic on everything!)

I actually got slightly shocked when I first came over the @CompileStatic - most of my Groovy stuff compiled just fine right away when I added the @CompileStatic over it. I had at least expected Closures to immediately be banned, but no. Sometimes I forget the annotation, and I get annoyed why things crash in runtime, and then I see the IntelliJ "greyness" over a part in the code, slap on @CompileStatic, and lo and behold - it turns red. It would have been caught by the compiler, but since it is dynamic, it _might_ have worked, so the compiler can't stop you from calling toStriing().. I love Types.

So my point is this: It works already! Typing is fantastic, and Groovy is in my eyes a fine typed language! I just find it sad that a language which has so much niceness with it, is dynamically typed by default, and not the other way: The dynamic abilities is the optional part which you can opt-in to use on specific parts.

Configscript is something "outside" of the groovy files. And that immediately makes things more problematic: this option needs to be part of any compile stage, in any build, and the IDEs.

Anway, I just wanted to chip in an opinion from a fan - but based on the reactions, it doesn't really seem like it will happen!

Hey, this literally just hit me when about to hit "Add comment": *What about a different file-ending for statically compiled groovy files?! "HelloWorld.groovys"!* I made GROOVY-8335 for that suggestion.


was (Author: stolsvik):
First off, I actually use Groovy quite a bit these days. I do all "prototyping" and much of the actual coding in Groovy, and Java has become more of the "API level language" - that is, I still consider my at-work projects to be Java, so the app-internal API is pure Java (and Groovy-specifics cannot be passed around, i.e. Closures) - but most actual code ends up being Groovy. If this makes sense.

But: I pretty much _never_ use the dynamic parts of it - I use @CompileStatic on every single class, except on the few parts where I actually want to use the delegates and methodMissing and this stuff, i.e. DSLs - and also the few times I want to dynamically invoke stuff based on strings, like mentioned above. It is just so much simpler than introspection. Also, the GroovyShell with its Binding - love it! (I've made a JRebel-like tool that I use in exploratory settings: https://github.com/stolsvik/groovy-egl - but even inside scripts I slap @CompileStatic on everything!)

I actually got slightly shocked when I first came over the @CompileStatic - most of my Groovy stuff compiled just fine right away when I added the @CompileStatic over it. I had at least expected Closures to immediately be banned, but no. Sometimes I forget the annotation, and I get annoyed why things crash in runtime, and then I see the IntelliJ "greyness" over a part in the code, slap on @CompileStatic, and lo and behold - it turns red. It would have been caught by the compiler, but since it is dynamic, it _might_ have worked, so the compiler can't stop you from calling toStriing().. I love Types.

So my point is this: It works already! Typing is fantastic, and Groovy is in my eyes a fine typed language! I just find it sad that a language which has so much niceness with it, is dynamically typed by default, and not the other way: The dynamic abilities is the optional part which you can opt-in to use on specific parts.

Configscript is something "outside" of the groovy files. And that immediately makes things more problematic: this option needs to be part of any compile stage, in any build, and the IDEs.

Anway, I just wanted to chip in an opinion from a fan - but based on the reactions, it doesn't really seem like it will happen!

Hey, this literally just hit me when about to hit "Add comment": *What about a different file-ending for statically compiled groovy files?! "HelloWorld.groovys"!*

> Consider statically typed/compiled as default for Groovy 3.0
> ------------------------------------------------------------
>
>                 Key: GROOVY-8329
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8329
>             Project: Groovy
>          Issue Type: New Feature
>            Reporter: Endre Stølsvik
>
> Personally, I do not understand why anyone would ever want to drop typing from JVM based languages (or in any other language, for that matter). Thus, I only started using Groovy "for real" when I discovered the @CompileStatic annotation, which really made everything great!
> If I could choose, I'd go for statically typed by default, with @DynamicCompile or somesuch as an annotation I could turn on for methods that uses the XML parsing features etc.
> To me, it seems like more and more people are realizing that statically typed languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting of types onto PHP with Hack, and even PHP's own typing in PHP 7.
> Now with Kotlin joining the fray of JVM-based languages, whose literally first two words on the wepage is "statically typed", getting special support in Spring, and - notably - getting full support in Gradle, I'd say that this applies more than ever. If Groovy "looses Gradle" to Kotlin due to the ability to get a statically typed build script (oh, the joy!), I believe Groovy will have a much harder time attracting new users. Turning Groovy into one of the statically typed JVM languages, instead of hampering users with "everything is an Object"-based runtime resolution, will increase the appeal of the language.
> The 3.0 can be a great point to change this. It could of course be reverted back to previous logic by some -D switch (would need support in IDEs too, I guess), or by sticking some magic "whole-sale annotation" at the top of the source file, or something like this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)