Groovy, the Python of Java
pixelmonkey.org
pixelmonkey.org
Where Python is usually trying to have just "one way" to do things, Groovy offers you a million. Python actually share's much of Java's annoying desire to keep the default namespace clean and hence make you import modules to do just about anything useful. While Python puts simplicity and cleanliness on a pedestal, Groovy is unashamedly pragmatic, letting you do any dirty thing you feel like or need to do to get your job done.
In complete contradiction to Python's direction of eliminating it (eg: forcing brackets on print() statements) Groovy gives you incredible amounts of optional syntax - add semicolons? if you want ... or not ... except sometimes the syntax gets ambiguous they are required. Use brackets on your function calls? If you want ... or not ... except sometimes the syntax gets ambiguous, so they are required. The author didn't even mention optional static typing which not only enforces type correctness on parts of the code you apply it too, but dramatically speeds them up. So much freedom makes it easy for Groovy code to end up messy and unstructured compared to Python.
I'm currently in a situation where I switch between Groovy and Python coding on alternate days. I definitely prefer different things about each. Groovy definitely seems more powerful when I just need to get a simple job done. It is incredible what you can cram into a single line.
I hope Groovy continues to prosper, but I worry it's getting lost among the hype around more "sexy" languages. I think it's by far the best language for many jobs.
If anything, Python seems to be dominating in large part because of its unabashed lack of sexiness (or what passes for it in modern programming circles: cleverness, and cuteness).
When the syntax get ambiguous, it's up to the developer to know they're required, just like with parentheses around expressions using infix operators of various precedences. The compiler or IDE won't tell you - you just get the incorrect result from running the code.
> The author didn't even mention optional static typing which not only enforces type correctness on parts of the code you apply it too, but dramatically speeds them up.
Groovy's original use case was quick and dirty scripts running tests, Grails scripting, and more recently Gradle, none of which use the static typing in Groovy. Gradle even still ships with Groovy 1.x. Unlike Groovy dynamic typing codebase, only one developer wrote the static typing codebase and it's still a little buggy. Best wait until Grails uses it before trusting it.
(a little Googling later...)
"Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." [1]
[1] http://macstrac.blogspot.com/2009/04/scala-as-long-term-repl...
Edit: I should add that I'm considering using Groovy with a micro-framework called Ratpack (http://www.ratpack.io/), so I'm only bringing this up as a part of the conversation if someone's trying to figure out what they want to learn next.
But Clojure is so dramatically different from both Java (the language) and dynamic languages more broadly (e.g. Python/Ruby), that it's a bit of a leap for workaday programmers; it's certainly no clean-up man.
[sigh]
It's a sign of the times when HN posters say "dynamic languages" and manage to ignore the Elder Language, the language from whence all dynamic languages sprung. And that language is...
(but I'd argue it wasn't until InterLISP and Smalltalk that all the pieces were there)
If you were already writing pure functions in python and then creating data flows using generator expressions or list comprehensions, moving to Clojure is very natural. If you aren't, and if your job is to move bits from one place to another performing transformations along the way, you were already having issues in Python and might want to consider the approach regardless of the particular language employed.
Groovy is perfect for me, because it has a familiar syntax, but it allows me to do much more in a much more readable way than Java would.
You can just stick the required syntax atop Clojure, using parsers and macro forms. For an example, see my https://github.com/gavingroovygrover/grojure
I still think Groovy is valuable as a "better Java than Java" but it's kind of hard to explain to newcomers how much ahead Clojure is. It took me a while to leave my prejudices against the parens and try to understand why it was so powerful and why the LISP family of languages is still alive. It's not by mere coincidence.
I switched to their Python IDE (PyCharm) and have never looked back.
here's a short video demoing coding in Groovy and other jvm languages:
http://www.youtube.com/watch?v=AqeOS2hqtMg
We use JSR-223 to support the various languages
On the product home tab there is the link to the user guide and design document.
...why do we have both a Ruby-like language and a Ruby implementation running atop the JVM? Sounds like a lot of fragmentation and wasted resources.
Edit: I guess I should explain this a little:
Groovy: A superset* of the Java language, you can (generally) rename a .java file to get a valid .groovy file. Groovy uses the Java libraries -- a Groovy string is a Java string. A Groovy object can subclass a Java object and vice versa.
Groovy is perfect for Java developers who want a gentle learning curve for new language features and want fine-grained interaction with other existing Java (and JVM) libraries and components.
JRuby: A full* implementation of JRuby and libraries that runs on the JVM. A Ruby string is not a Java string. JRuby can call Java and vice versa, but there's some impedance mismatch because of differences in the object libraries.
JRuby is great for Ruby developers and/or people who need to run Ruby-based technologies in the JVM environment (e.g. Rails, Asciidoctor, etc.)
Most people knowledgable of both technologies would not view this as (unnecessary) fragmentation. There has also been some work on the JVM that has benefitted both languages -- most notable the InvokeDynamic byte code additions to better support dynamic languages (benefiting Groovy, JRuby, JavaScript, and others.)
* There are some corner-cases where valid Java is not valid Groovy. Similarly, there are some C-language extensions in Ruby that aren't' available in JRuby. But in both cases the exceptions are rare enough to be relegated to a footnote.
That is not true. Java was written to target C++ programmers.
List("Rob", "Christopher", "Joe", "John").filter{
_.size <= 4
}.foreach {
println _
} List("Rob", "Christopher", "Joe", "John").filter(_.size < 5).foreach(println)Not to mention the name is a homophone.