On 06/22/2016 07:02 PM, Mr Andersson wrote:
On 06/22/2016 03:06 PM, Alessio Stalla wrote:
Also good tests help. However I agree that if you prefer the
tradeoffs that static languages give you then probably Groovy is not
the wisest choice.
It's nice to have good speed in critical sections of the code without
having to rewrite them in Java, but a fully static
Groovy IMHO is just a quirkier, slower, less supported Java with some
nice syntactic sugar. It just wasn't designed for that.
That's exactly what I need at times. To be able to use Groovy
alongside Java when I need to, to a minimal. Writing regexes,
multiline strings, inline variable strings, writing sql, use some
libraries on occasion, and other things that are really ugly to do in
Java.
The static version for me would be a compliment to go the Groovy way
when I need to, not replace Java.
To replace Java, I think a new Grooyv language that is written from
scratch, has similar syntax as Java + Groovy, and performs equally
would be required.
Java features are so slow to be developed that I am sure if the Groovy
devs decided to fork the Java compiler and start adding many new
features it would develope so much faster.
Basically, the world is crying out for a fork of Java, that can develope
the language faster than Oracle. Not a completely new language that runs
on the JVM.
I once saw a seminar of someone hacking the Java compiler in 20
minutes to add the elvis operator. Now, consider adding closures (
better syntax than Java lambdas ) and removing all other cludd that
Java requires, and we have a hit run.
Many just need to write less code
On 22 June 2016 at 14:50, Thibault Kruse <[email protected]
<mailto:[email protected]>> wrote:
> People want to be able to refactor without risking of the code eventually
> breaking totally, and that's the problem with Groovy. Code will
eventually
> become stale and stop working if it is put on layway for a
while. No compile
> time checks is a problem for anyone interested in code quality.
For that purpose, it might be sufficient to make @TypeChecked the
default, or a compiler option.
That would catch most such problems at compile time.
