Re: Static typing question

On Mon, Jan 1, 2024 at 1:57 AM MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]> wrote:

> 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
>
>
>
>  @CompileStatic predecessor Groovy++ (which later afaik gave birth to
Kotlin).

I totally agree here. In a sense Kotlin is a statically-typed Groovy.


-- 
Dr. Vasileios Anagnostopoulos (MSc,PhD)
Researcher/Developer