Hi Caleb,

literally what OC wrote.

Groovy has many hats, and the one you seem to know (and it seems dread) is it being used to create a non-static DSL for Gradle.

The other two hats are Groovy being used as a script language, and - and this is the one you should have a closer look at - being used as a full blown, nearly 100% Java compatible programming language. What OC writes below is true, Groovy is - by ongoing design, which many discussions on this mailing list on how to integrate new Java/JVM features into Groovy attest to - a drop in replacement for Java, aiming to make Java more Groovy. When someone finds a Java sample code snippet on the internet, all he needs to do use it in Groovy is to copy & paste it into his project, and do a regex search & replace of \s*;\s*$ w an empty string to remove the redundant semicolons at the end of each line.

Also, while e.g. IntelliJ Support for Groovy is not perfect or completely bug free, it is still very good, and it does not have the problems you describe in your last posts: e.g. jumping to definitions of classes/methods works, even when using standard (= dynamic) Groovy (i.e. not @CompileStatic/@TypeChecked annotated). While all JVM languages stand in the long shadow of Java, Groovy is the second largest of them by many metrics, and support for it is accordingly high. (Your trans-compiled Java+ would face problems with IDEs, btw, since no IDE will understand your extensions, and will therfore only support Intellisense with regards to the transcompile pure Java code, not Java+.)

But most importantly: You would loose so many great Groovy features, such as:

1. The multitude of ways to define string constants (multiline,
   regex-friendly, etc).
2. Strings with embedded variables (which can even be closures), i.e.
   GString|s.
3. The multitude of useful annotations, such as @InheritConstructors,
   @Canonical, etc.
4. Newer Groovy convenience features such as e.g.
   SV(myLongVariableName), which auto-expands to the GString
   "myLongVariableName=$myLongVariableName", which is very useful for
   debug logging.
    1. (and which is made possible by  the underlying Groovy's macro
       feature)
5. The clever Closure syntax which allows to pass the last argument of
   a method outside of the paramter enclosing brackets if that
   parameter is a closure, which allows for the creation of extremely
   elegant AND readable APIs.
    1. we use e.g. database.withTransaction { /* SQL that shall be
       executed within a database transaction bracket */ } for our own
       SQL code as well as for Ebean.
    2. or database.eachRow(sql) { row -> ... } for code that shall be
       applied to each row in a result set.
6. and so forth.
7. all of which have Intellisense support in e.g. IntelliJ.

Getting people to try a different language is a matter of ease of transition (which Java to Groovy definitely has in troves over any alternative), as well as enticing new features - it is not about fooling people into believing that they are still using Java, it is about them realizing how many cool treasures lie on the other side of the fence, and no language can make that easier with regards to Java than Groovy G-)

Cheers,
mg


On 25/03/2024 16:34, OCsite wrote:
The vast advantage of Groovy is that you can take a big project, just rename all *.java to *.groovy, and it will essentially work (well, as someone already wrote, 99 % — my experience is rather 99.99 %, but indeed there are things which need fixing and there are a couple of gotchas, but there's really a very very small number of them). Then you can work on with the project and gradually change the stupid Java patterns to the pretty decent Groovy ones, part by part, method by method and if need be, practically line by line, without losing any functionality during the process. No other language I know of allows anything like this.

Reply via email to