Re: Static typing question

Hi Vasileios,

we use our own Groovy framework to develop an in-house multi part web 
application and accompanying SQL & PL/SQL generation framework, and have 
been using Groovy for 10 years, including some dabbling in the 
@CompileStatic predecessor Groovy++ (which later afaik gave birth to 
Kotlin).

Contrary to many ppl here I love static compilation checks - in my book 
there is nothing more annoying than to get an incompatible-type-RTE, and 
it also makes code more readable to use explicit types & easier to 
refactor automatically (e.g. through IntelliJ). And no, I do not have 
time to write a test or execute a Selenium test (suite) before every 
rollout during development, to catch any potential errors of that kind, 
so I would much rather have the compiler catch those, thank you ver 
much* :-)

Having said that, I have come to realize what I actually want to use in 
Groovy 99% of the time is @TypeChecked, not @CompileStatic, and the 
reason for this is simple: Dynamic call site selection. Dynamic call 
site selection is a feature I have already seen people request for 
Kotlin, which e.g. allows one to easily add polymorphic method support 
for newly introduced sub-types, without any refactoring effort (while 
still keeping type safety, i.e. in fully @TypeChecked code).

On the other hand in practice there is most of the time very little to 
nothing to be gained from using @CompileStatic, even in low level code, 
because a) dynamic code execution is highly optimized in Groovy** so 
there is no relevant speed difference, and b) in most cases even that 
would not matter, since performance of business applications is mostly 
bound by database and network performance.

Cheers & a Happy 2024,
mg

*@TypeChecked is not yet perfect here, it on occasion lets code slip 
through, which later leads to a RTE, while sometimes complaining about 
code which is actually valid (most of the time when using generics), but 
it still is of great value, and one can of course always make a method 
fully dynamic as a workaround in these cases (a bit counterintuitively 
not by using @CompileDynamic, but @TypeChecked with TypeCheckingMode.SKIP).

**Alas that is not the case for JVM invoke dynamic, which is much slower 
when generating a really large number of objects, which recently 
required us to make a part of our SQL generation code less user 
friendly, to make Groovy 3/4 with invoke dynamic as fast as the old 
Groovy-specifc code which did not rely on invoke dynamic...


On 30/12/2023 19:17, Agile Developer wrote:
> Hi,
>
> I was a  4 years user of Grails/Groovy (last year mostly Python). With 
> the general trend of people moving to static languages, is there any 
> reason that Groovy needs to stay dynamic?
>
> I see Python having the mypy approach, I see gradle moving to Kotlin 
> and FE mostly on Typescript.
>
> I understand that the @CompileStatic is the supported method, but 
> having true static typing (with the Script-Like enhancements other 
> Languages added, would be beneficial).
>
> Is there still a reason to keep it dynamic? What is the benefit?
>
> -- 
> Dr. Vasileios Anagnostopoulos (MSc,PhD)
> Researcher/Developer