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.
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.
Private interface methods, statics in non static innerclasses, default
public, and so on. Many just need to write less code. Oracle is so slow
with everything. Can you believe we still don't have multiline strings.
Jeezus, what are those guys doing over there, drinking coffee?
If only I new how to write a language. Don't get me started :P
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.
