Whereas the Java language has won over an entire generation of programmers with its commitment to exactitude and extensiveness, Groovy heralds a new era of programming on the Java platform, one defined by convenience, expedience, and agility. This article shares an informal introduction to the proposed addition to the standard programming languages for the Java platform.
Groovy forever changes the way that you view Java
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
it has some things from the Ruby scripting language. But one thing stands I sure don’t feel “groovy” coding it.
You mean I can add an interpreted language with a clean syntax on top of the JRE. Wow, why didn’t someone think of this before? *cough*jython*cough*
Nothing Groovy here except the poseur name. Even the excerpt describing this article is marketing drivel at its absolute best. Move along…
Long live Perl!!!!
…is built in associative arrays! Sorry, I know this is OT but I just had to tell someone!
You know, Groovy isn’t really a scripting language. Neither are Python, Ruby, etc. They are full-featured programming languages, that just happen to be dynamic and object-oriented. The are wholly unlike *real* scripting languages like Bash and Applescript, which are geared entirely towards scripting a set of programs. Now, this isn’t just a matter of semantics. When you lump languages like Python, Ruby, etc, into the domain of “scripting languages” you imply that they shouldn’t be used for “production work” like C and Java are. Of course, that concept is crap. The semantics of Ruby, Python, and Groovy are not really far off from Lisp or Smalltalk, which are considered to be general purpose languages. No matter how you cut it, these languages are all general-purpose languages, not scripting languages.
Beyond that, I see little point in distinguishing scripting languagse from general purpose languages in most cases. People talk about how Ruby and Python are so productive and fast to develop in, and then turn around and say that they are no replacement for C and Java on “real” projects. That concept is crap. Why do programmers think there is a trade-off between robustness and productivity? Certainly, there are a whole host of languages that show you that you can have the productivity of something like Python (or even more), with the performance of something like C. More programmers need to get their heads out of their asses and realize that high-level, powerful languages need not be reserved for scripting tasks. Rather, they can be used for general programming tasks in general. High-level languages should be the *first* thing a programmer considers, and they should use C and Java only if a better language isn’t suitable for the given task.
High-level languages should be the *first* thing a programmer considers, and they should use C and Java only if a better language isn’t suitable for the given task.
And of course there’s no reason to just choose one. Many of these languages have a C API. You can drop into this and use it to wrap native code up in a Ruby/Python/etc. API.
And of course you use Java classes from Groovy, so anything Java can do, Groovy can as well.
These are not “real” languages because they are so unconstrained. Java is very intentionally constrained.
Once you take these languages, and try to apply them to a huge system, the complexity of the unconstrained-ness gets larger than the benefit of being able to write it quickly.
Thats certainly not to say these languges don’t have a place or that that place shouldn’t play a part in large systems.
I’d be happy to be proved wrong.
When some library uses Python features it’s said to be Pythonic. When other library uses Ruby features it’s said to be Rubyish. Many of the Java features were meant to help tool developers.
That is, I’m not sure it would be great to use some language like Groovy, because 99% of its environment would have been built for Java. The same should be true to the .Net languages. It would just feel weird. Languages such as Groovy are meant to be niche languages, until proven contrary.
Ugh…it inherits Java’s verbosity. But is resembles Python on a lot of levels.
Java has great IDE and Open source codebase support. This is the failing point of script-like languages (or dynamic object oriented, whatever you name it) for JVM. Take IDEA, one can write much faster code with Java than any other language in the world for especially middle sized and big projects (hmm. yes all of them). The “less syntax” pros of the Groovy and alike is just a ALT+Insert or CTRL+Space ahead for a java programmer. Maybe if they focus on Eclipse integration, odds would be better.
Plus, many like Java because it is deliberatly constrained (including me).
But, agreed that Ruby, BeanShell, Jython or Groovy, has their user base and they can be handy in many cases. As for groovy, Groovy is the only one accepted by the JCP, so chances of being popular is better for it.
@Ores: I don’t buy that. Constraints are orthogonal to the semantics of the language. Languages should have simple, powerful semantics, and allow for the programmer to impose constraints on the code that make sense in the context of the problem domain. In any case, there are very large systems written in “flexible” languages like Smalltalk and Lisp, so I don’t think it’s a given that an intentionally limited language naturally leads to better scalability.
@aaa: That’s quite a bit of overstatement about the productivity of IDEA. IDEA helps for a certain type of programming. When you can solve your problem mostly by stringing together pre-built modules, the main task of the programmer is to maintain the structure of the program. IDEA, with it’s tools, is helpful for that sort of thing. However, when you’re working on logically complex problems, the task of the programmer is to develop the logic and the computational abstractions, and IDEA can’t help for that. In any case, the statement “you can write much faster code with Java than any other language in the world” is positively silly in the face of advanced Lisp and Smalltalk IDEs, the latter of which were where most of the cool ideas in IDEA came from.
this is a scripting language. It may be a full-featured language too, but it is a scripting language. Perl, Python, etc aren’t so much in a similar way- they can be used to dynamically script app written in those language. Something you cannot do in C, C++ or Java- all traditional languages. In practice, those languages aren’t used for scripting all that much, more as a traditional language.
AppleScript, on the other hand, has been gaining traditional abilities, but is still very much a traditional scripting language. But a scripting language is only a scripting language when in the context of an app system that allows scripting- like Mac OS. Two required parts of the system. It’s a shame other OSes don’t have the hooks for such an extensive setup. Even in the context of the Mac OS Perl, Ruby, Tcl and JavaScript and others can be used for doing all the stuff AppleScript can by tying into the AppleEvent system.
But what is the point of Groovy? So far, it doesn’t look like all that much more than an interpretable Java. So- why not use the Bean script interpreter?
A language does need to have better rules and more restrictive syntax. Let me give you a very different example why i think doing this is right thing.
How hard is it to make a computer understand english i.e natural language processing of english. I will say very hard because of its lose syntax. If english had a fixed syntax rules and proper grammer, it would have been much easier.
If anyone of you out their know “Sanskrit” Language (ancient indian language, though Hindi is pretty close to it), it had a very strict syntax and very well defined rules for making statements. If “sanskrit” was as popular as english is in real world, we would be talking to our computers like humans 5 years back.
Hence i believe, a language which keeps tight constraints is usually better when it comes to big projects with many people involved because it makes them follow same rules.
On the other hand, for quick dirty works, a language like perl or python is good enoguh.
I think the trend these days leans towards development platforms rather than the qualities that distinguish one programing language from another. So the question isn’t what makes a programing language enjoyable, but what makes a great development platform.
I will add my irrelevant opinion on what I think makes a great development platform.
1). The language.
-terse
-compact
-keywords that fits my brain
-very little typing, yet potently expressive
-maintainable 5 years down the road
-doesn’t force me into a programing paradigm (OO, Aspect Oriented, Procedural)
-no needless ceremonies or rituals to perform tasks(i.e. straightforward)
-unambiguous and consistent semantics.
2). Rich, easy to use and well designed APIs.
-XML
-GUIs
-Networking
-Database
-Internet
-IO
-String
-Math
-Graphics
-etc
3). Tools:-
Debugging tools
Profiling tools
Graphical tools
Advanced IDEs
Monitoring tools.
4). Bindings- More often than not, project have to be linked to another project written in a different language. How easily does a platform provide bindings for other languages. .NET excels here. Many open source projects too excel here.
5). Performance-I like platforms that are fast and don’t choke my system resources. Java and .NET fail miserably here.
6). Openness-I don’t want the fate of my works to be dependent on proprietary vendors. I don’t want to be locked in and forced to through endless upgrade cycles. I want to be able to contribute to and fix the language if I have to.
7). Cross platform-ability. Right once run everywhere.
This in my opinion, is what makes a great developer platform. This is why I am thrilled about the future of Python. Because while it doesn’t satisfy all the above, it comes closer than any general purpose language I know(Admittedly, I haven’t worked with too many other languages).
In particular, Python fails at number 3. And that’s why I think it’s not as popular as it should be. It also fails at number 5, but almost all high level languages suffer that unfortunate fate. It is also an intentional trade off by the Python folks for developer convenience.
I haven’t played with Groovy, but it seems to exhibit some of the language qualities I am drawn towards. I don’t know how well it ranks from points 2 to 6 above however.
A language does need to have better rules and more restrictive syntax. Let me give you a very different example why i think doing this is right thing.
How hard is it to make a computer understand english i.e natural language processing of english. I will say very hard because of its lose syntax. If english had a fixed syntax rules and proper grammer, it would have been much easier.
If anyone of you out their know “Sanskrit” Language (ancient indian language, though Hindi is pretty close to it), it had a very strict syntax and very well defined rules for making statements. If “sanskrit” was as popular as english is in real world, we would be talking to our computers like humans 5 years back.
Hence i believe, a language which keeps tight constraints is usually better when it comes to big projects with many people involved because it makes them follow same rules.
On the other hand, for quick dirty works, a language like perl or python is good enoguh.
You make it sound like computers have some difficulty with the syntax of Ruby, Python, Perl, etc.
They seem to do fine with these languages… as do humans who’ve taken a few days to become familiar with the basics.
I think he’s referring to large projects handled by multiple developers. The reas as: if the language is constrained, it tends to lead to stricter but standard ways of doing things among multiple developers with the trade-off of verbosity. But then, in my opinion, what is most important in any project is proper communication among the people involved.
I’ve worked with perl, python, groovy, nice, and beanshell. I’ve gotta say, contrary to what seems like a legion of dedicated scripting fanatics, I don’t see the touted benefits of scripting languages in general. The only scripting languages that I have found useful are useful not for any of the main reasons that are usually cited for scripting languages (by the way, I find awk, sh, and sed to be very useful). Dynamic typing? Honestly, it hasn’t saved me much time . . . this aspect is marginal in terms of advantage to say C or Java. I mean really, half my types are completed anyways by IDEs. Even without IDEs, I don’t save much time. It’s negligible to me. Syntactic sugars? How much time do these little things save? Before I can even think of my own name, a traditional for loop is already written. And someone else already pointed out that IDEs complete those for you with like two keystrokes. There’s obviously more to the scripting language arguments, such as closures, functional programming, the lack of having to type in import statements and declaring classes and such, but again . . . not convincing.
AppleScript, on the other hand, has been gaining traditional abilities, but is still very much a traditional scripting language. But a scripting language is only a scripting language when in the context of an app system that allows scripting- like Mac OS. Two required parts of the system. It’s a shame other OSes don’t have the hooks for such an extensive setup. Even in the context of the Mac OS Perl, Ruby, Tcl and JavaScript and others can be used for doing all the stuff AppleScript can by tying into the AppleEvent system.
KDE has those hooks via DCOP – here is how you open a Konqueror window with two lines of ruby:
dcopRef = DCOPRef.new(“konqueror-1458”)
result = dcopRef.createNewWindow(“http://dot.kde.org/“)
Or read a file from disc and put it on the clipboard:
klipper = DCOPRef.new(“klipper”, “klipper”)
klipper.clipboardContents = IO.readlines(“myfile”).to_s
I agree that ruby is a full blown dynamically typed OO language, and calling it a ‘scripting language’ makes it sound like a toy. If has a very different target audience from AppleScript.
PS: I had a good chuckle over this quote from the article (the ‘small detail’ bit referring to one of java’s gross design flaws):
Primitive data types that are native to the Java language, such as int and boolean, are not considered first class objects. Many object-oriented purists lament this small detail, and some have used it to raise the question of whether the Java language is truly an object-oriented language. Groovy resolves this problem by declaring that everything is an object.
I have to mention NetRexx, which is several years old. Only a few people are using it, why should it be different with Groovy?
Though I myself typically dismiss the argument that a language is more suitable than another because of syntactic familiarity, Groovy is a lot closer to Java than NetRexx.
Many enhancements Groovy makes possible are just removing elements from Java code, rather than adding things.
“AppleScript, on the other hand, has been gaining traditional abilities, but is still very much a traditional scripting language. But a scripting language is only a scripting language when in the context of an app system that allows scripting- like Mac OS. Two required parts of the system. It’s a shame other OSes don’t have the hooks for such an extensive setup.”
The Amiga OS has had scripting for 17 years, much longer than Mac OS. The great advantage is that practically all serious programs can be scripted with the same language (ARexx, although it is now possible also to use Python), so that a single script can address several programs.
Some of the most useful Amiga programs are more extensions of ARexx than conventional GUI-based programs.
Scripting uses the Amiga’s standard message ports.
Every routine in a program should be accessible both from its GUI and from a script command.
I like when people say “scripting language”.
I don’t see it as “not a real programming language”, I read it as “care of what this thing should do, not of pesky details”.
I quote matz (of Ruby fame) and ward cunningham at JAOO/2004 for this definition.
Whenever I find myself thinking “oh, I should have done this, this is why this does not compile”, or “ah, I can’t use IArithmetic because it did not existed when Integer was defined”, or “oh, stupid ints that are not objects”, or “damn generics’ type erasure”, well, I’m missing points on the scriptometer.
Strangely enough, Nice (nice.sf.net) gets a really high value on my scriptometer
People are being rude with groovy, IMHO mainly because they expect it to be revolutionary or because they want to defend they’re own beanshell, JRuby or Jython.
Groovy is nifty, it has a nice block syntax and control structures build around that. It also has interesting things like GPath, but it’s not revolutionary and does not wants to kill your JVM scripting language of choice.
More languages on the jvm means more chance to see java evolve into something better (just think of the stuff taken from GJ ) so be happy of it
I agree with fuser that the main reason people are knocking Groovy is because it is not their scripting language even if particular features may implemented identically to their fave scripting language of choice.
I also second the “non-revolutionary” idea as well – if someone says we have a new product (with no claim to revolution) some people will just knock them because an identical product already exists.
Well in this case Groovy IS actually “new” because of how its implemented. The other languages have ported their libraries onto Java whereas Groovy uses Java all the way and only adds code to support the differences in sytntax and support for things not supported by Java. But even that code will be translated into 100% Java code.
To mystilleef:
==============
One of the more attractive features of Groovy (over Java and possibly many other languages as well) is how it supports, natively, some of the things on your list such as XML, HTML, SAX, W3C DOM, Ant tasks, Swing, etc.
Some examples and more info:
http://groovy.codehaus.org/markup.html
http://groovy.codehaus.org/sql.html
http://wiki.codehaus.org/groovy/TreeBasedSyntax
It also fails at number 5, but almost all high level languages suffer that unfortunate fate. It is also an intentional trade off by the Python folks for developer convenience.
It’s not so much a performance vs convenience trade-off, but a performance vs compiler-writer time trade-off. Lot’s of languages that are even more high-level than Python have compilers that can produce very fast binaries. It’s just that writing such a compiler is a tremendous amount of work requiring developers that are very skilled at compiler optimization. So far, nobody has stepped up to write a compiler that does for Python code what, for example, Stalin does for Scheme code. It’s not a limitation of the language, just a limitation of the available tools for it.
It’s the smallest and most Java like JVM based dynamic language. Which is great because I don’t need to learn another language syntax (ala Groovy).
~hindi is ~the 4th most used language on earth now, behind “chinese” and “english” and possibly tied with the spanish group. Depending on where the sun is, more people on earth may be speaking hindi than english if hindi has an exceptional second of time: and some places hear much more hindi.
*claps*
being addicted to live templates in idea, for<TAB> gives me for(int i = 0; i < ;i++) {, its a process that doesnt require thought anymore.
The most interesting bit of the Java JVM, and therefore all the languages that run on it, was the fine grained sandbox. This made it at the time about the only mainstream language designed for mobile untrusted code and ubiquitous networks. .NET will inherit most of it but I was wondering about how Python and Ruby handle sandboxing.
The most interesting bit of the Java JVM, and therefore all the languages that run on it, was the fine grained sandbox. This made it at the time about the only mainstream language designed for mobile untrusted code and ubiquitous networks.
Yes, I agree that this was probably java’s main innovation. On the other hand, the code checks prevent you from adding methods to an existing class. That’s fine for java, but not so good for languages that support it such as ruby.
Ruby allows you to set ‘Safe Levels’ via the $SAFE environment variable. There are five levels, and the higher the level the less that the script is allowed to do. Then potentially dangerous methods raise a ‘SecurityError’ exception.
It has the concept of ‘tainted objects’ for objects which have come from an external source, and might be considered less trustworthy. Any objects derived from a tainted object are also tainted.
“Well in this case Groovy IS actually “new” because of how its implemented.”
This is not true. Beanshell is implemented the same way. I believe pnuts is also. We’ve actually used all three where I work. For the current project we settled on groovy because of speed and a few syntax conveniences. Funny thing is, even though they’re all different languages, most of the syntax is interchangeable.
Really terrible article. I especially disliked how it needlessly tried to appeal to the ‘agile’ crowd. It’s a language folks.
actually IIRC ruby has 8 safe levels, given that $SAFE is a determined from 3 bits in every object, it just happens that the standard library uses levels from 0 to 5. pl/ruby, ruby for postgresql stored procedures, runs at safe level 7.
Another big fat solution to a problem nobody has. Java just gets decent and some ass starts bloating the crap out of it, too typical. As soon as it grows enough to collapse from it’s own weigth we’ll all go back to C and the life cycle of fad languages can begin anew.