Slashdot Mirror
Groovy in Action
Simon P. Chappell writes "I missed the partying in the 70's and so was not exposed to the full groovy experience that was available. You could say that I was a late developer (pun intended). Thankfully, I am now able to make up for lost time by learning the Groovy scripting language. For those of you not familiar with Groovy, it is a dynamic language designed to run on a Java Virtual Machine and be easy for Java programmers to work with; it looks very similar to Java and will freely inter-operate with Java objects and libraries. I've been tinkering with Groovy on and off for about two years now; learning Groovy in the old days, prior to this year, was a challenge with all of the design changes that were taking place. Groovy in Action (GinA) is the book that I'd wished was available back then. Dierk König, a committer for the Groovy project, has written this definitive guide to Groovy and after what has seemed an eternity to those of us on the Groovy mailing list, it is finally available." Read below for the rest of Simon's review.
Groovy in Action
author
Dierk König, Andrew Glover, Paul King, Guillaume Laforge, Jon Skeet
pages
659
publisher
Manning
rating
9
reviewer
Simon P. Chappell
ISBN
1932394842
summary
A practical how-to book for Groovy
The obvious candidate for this book is the programmer that wants to learn Groovy. What is less obvious, is just who those people are, because programmers who would find Groovy useful are likely to come from quite a wide selection of backgrounds. If you thought that Groovy wasn't for you, read on and consider whether you may have judged in haste.
Current, or former, Java programmers will love Groovy and they will likely make up the greatest proportion of the readership. They will especially appreciate the interoperability of Groovy with Java: your Groovy objects are Java objects, right down to the bytecode level.
As a dynamic language, Groovy attracts a good quantity of the traditional users of scripting languages. Expect to see more than a few system administrators and build managers pick up on Groovy as they realise the benefits it brings. Further sweetening the pot, for build managers, is the ability to use Groovy as a scripting language within Ant. Another group of readers may well come from the dynamic language communities. I think that Ruby and Python programmers may well find this an interesting book to help them understand this new arrival on the scene. With the steady maturing of the Grails project, that uses Groovy as it's implementation and development language, even the Ruby on Rails folks might be curious.
For a book that's setting out to teach you a programming language, the structure is fairly standard. The contents are divided between three parts that theme the Groovy Language, the Groovy Libraries and then wrap up with Everyday Groovy. I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it. This is a very welcome development in programming language books; other publishers and authors please take note!
For the purpose of full disclosure: I had been talking to Manning about writing more of a practical how-to book for Groovy, but with GinA being so good, those conversations stopped almost as soon as they got started.
The first chapter is the standard fare of what Groovy is and why you want to use it. This is important material for those who may be new to the language and it's covered very well. Some book's initial chapters can be a little dry, as if the author was in a hurry to get to the good stuff, but here, Mr. König has recognised that the language is in an early enough phase that explaining why you would want to use it is the good stuff.
I'll save you from a big list of chapter headings and just relate that part one covers the basics, including how to compile and run code and how to run it as an interpreted script. The fundamental Groovy datatypes are introduced and we learn about the joys of optional typing, for those occasions when it's not obvious that the object is a duck. Groovy has all the things you'd expect from a dynamic language: strings, regular expressions, ranges, lists, maps, closures, control structures and finally, to make it in the corporate programming world these days, it has objects.
As we skipped chapter headings for part one, I'll follow precedence and skip them for part two as well. Part one taught us the basics of the language, part two looks to help us now integrate with the Java environment and existing Java code and systems. Builders are an important part of using Groovy to it's full dynamic extent and these are covered extensively. Groovy also brings it's own library extensions for the standard Java libraries, and they are known as the GDK, even though they're technically not a development kit. Groovy works nicely with databases and is able to use any existing JDBC drivers you may have. XML, whether you love it or hate it, is a big part of the life of a corporate programmer these days. Groovy has built in smarts for working with XML and you'll learn about those in this part. There are many useful Java tools, libraries and frameworks available today and Groovy can work with almost all of them. Much good information on integrating with everything from Spring to the new scripting interface defined by JSR-223 is covered.
Part three is the Everyday Groovy part. It starts with Tips and Tricks. Things to remember, useful snippets of code, advice on calling Groovy from a command-line, and writing automation scripts. There's also a full chapter on Unit Testing with Groovy, covering testing of both Groovy and Java code. The last two chapters cover optional stuff for Groovy. Groovy on Windows looks at the use of the Scriptom tool for those who use Windows. (As a Mac user, I admit that I skipped this one.) The last chapter is an introduction to Grails, the web application framework written in Groovy and which can run in any standard J2EE environment.
There are a couple of slim appendixes at the back with installation information, language information and an API Quick Reference for the GDK.
There is much to like about GinA. Mr. König and his co-authors writing is clear and engaging and Manning's layout and typography are up to their usual excellent standards. On it's own, these are good reasons to consider this book if Groovy interests you, but when you mix in the fact that Mr. König is a committer on the Groovy project and has taken an active role in the creation of the language itself, then you have a very compelling reason to choose it.
Groovy in Action is an excellent book, written by one of the designers of the Groovy language. If you have any interest in modern scripting languages at all, I would recommend that you check out this book.
You can purchase Groovy in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The obvious candidate for this book is the programmer that wants to learn Groovy. What is less obvious, is just who those people are, because programmers who would find Groovy useful are likely to come from quite a wide selection of backgrounds. If you thought that Groovy wasn't for you, read on and consider whether you may have judged in haste.
Current, or former, Java programmers will love Groovy and they will likely make up the greatest proportion of the readership. They will especially appreciate the interoperability of Groovy with Java: your Groovy objects are Java objects, right down to the bytecode level.
As a dynamic language, Groovy attracts a good quantity of the traditional users of scripting languages. Expect to see more than a few system administrators and build managers pick up on Groovy as they realise the benefits it brings. Further sweetening the pot, for build managers, is the ability to use Groovy as a scripting language within Ant. Another group of readers may well come from the dynamic language communities. I think that Ruby and Python programmers may well find this an interesting book to help them understand this new arrival on the scene. With the steady maturing of the Grails project, that uses Groovy as it's implementation and development language, even the Ruby on Rails folks might be curious.
For a book that's setting out to teach you a programming language, the structure is fairly standard. The contents are divided between three parts that theme the Groovy Language, the Groovy Libraries and then wrap up with Everyday Groovy. I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it. This is a very welcome development in programming language books; other publishers and authors please take note!
For the purpose of full disclosure: I had been talking to Manning about writing more of a practical how-to book for Groovy, but with GinA being so good, those conversations stopped almost as soon as they got started.
The first chapter is the standard fare of what Groovy is and why you want to use it. This is important material for those who may be new to the language and it's covered very well. Some book's initial chapters can be a little dry, as if the author was in a hurry to get to the good stuff, but here, Mr. König has recognised that the language is in an early enough phase that explaining why you would want to use it is the good stuff.
I'll save you from a big list of chapter headings and just relate that part one covers the basics, including how to compile and run code and how to run it as an interpreted script. The fundamental Groovy datatypes are introduced and we learn about the joys of optional typing, for those occasions when it's not obvious that the object is a duck. Groovy has all the things you'd expect from a dynamic language: strings, regular expressions, ranges, lists, maps, closures, control structures and finally, to make it in the corporate programming world these days, it has objects.
As we skipped chapter headings for part one, I'll follow precedence and skip them for part two as well. Part one taught us the basics of the language, part two looks to help us now integrate with the Java environment and existing Java code and systems. Builders are an important part of using Groovy to it's full dynamic extent and these are covered extensively. Groovy also brings it's own library extensions for the standard Java libraries, and they are known as the GDK, even though they're technically not a development kit. Groovy works nicely with databases and is able to use any existing JDBC drivers you may have. XML, whether you love it or hate it, is a big part of the life of a corporate programmer these days. Groovy has built in smarts for working with XML and you'll learn about those in this part. There are many useful Java tools, libraries and frameworks available today and Groovy can work with almost all of them. Much good information on integrating with everything from Spring to the new scripting interface defined by JSR-223 is covered.
Part three is the Everyday Groovy part. It starts with Tips and Tricks. Things to remember, useful snippets of code, advice on calling Groovy from a command-line, and writing automation scripts. There's also a full chapter on Unit Testing with Groovy, covering testing of both Groovy and Java code. The last two chapters cover optional stuff for Groovy. Groovy on Windows looks at the use of the Scriptom tool for those who use Windows. (As a Mac user, I admit that I skipped this one.) The last chapter is an introduction to Grails, the web application framework written in Groovy and which can run in any standard J2EE environment.
There are a couple of slim appendixes at the back with installation information, language information and an API Quick Reference for the GDK.
There is much to like about GinA. Mr. König and his co-authors writing is clear and engaging and Manning's layout and typography are up to their usual excellent standards. On it's own, these are good reasons to consider this book if Groovy interests you, but when you mix in the fact that Mr. König is a committer on the Groovy project and has taken an active role in the creation of the language itself, then you have a very compelling reason to choose it.
Groovy in Action is an excellent book, written by one of the designers of the Groovy language. If you have any interest in modern scripting languages at all, I would recommend that you check out this book.
You can purchase Groovy in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Groovy in Action (GinA) is the book that I'd wished was available back then.
Is this 'gina freely available in bookstores, or do you have to show ID to see it?
The theory of relativity doesn't work right in Arkansas.
It's nice to see that Slashdot has finally started linking to the Amazon listing instead of the wildly overpriced Barnes & Noble as it inexplicably did for several years. Do, however, take a look at the "Used and new..." listings, since the third-party sellers usually offer new copies even cheaper than Amazon itself does.
The reviewer is an author of several Groovy articles and has a vested interest in seeing the book succeed. How about a little objectivity and professionalism?
I assume the Groovy IDE is in your choice of colors: avocado or paisley
Startup plays "Disco Inferno"
Comes with a draft notice for assignment to Korea (coming around again soon!)
Has built in 300 baud serial modem to connect to a BBS
Intron: the portion of DNA which expresses nothing useful.
...than the Hip Hop programming language. # include numba main { hollar ("Wassup, world!"); giveItUp 0; }
It is dangerous to be right when the government is wrong.
Groovy.
The computer world is running out of names... when I saw "Groovy", I thought of the engine used in The 7th Guest and 11th Hour. (sorry, cant find the links anymore).
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
C#.
Comments welcome.
import org.apache.commons.lang.WordUtils class Greeter extends Greet { Greeter(who) { name = WordUtils.capitalize(who) } }
new Greeter('world').salute()
Ugh. Like Java this gets it all backwards. A string should know how to capitalize itself.
You could have at least made reference to a user group based in Virginia: the VAGinA User Group
I'm gonna need a spec.
why do you hate end users so much? this manifests as nothing more than a way to make java even slower and more painful to run.
developers - "but it's object oriented!!!!"
Caution: Mildly flamey (this is liable to really wind some people up, but I'm sure as many will agree :-)
e -before-in-some-circumstances languages. I just don't think the effort involved in people getting to grips with it and having to support what ever is implemented in it is liable to be worth while.
I don't know where people get the idea that coming up with a new incrementally different languages and ever mote elaborate frameworks, when we have a large number of functional ones already is worthwhile endeavor (outside of academia and research labs). IME, "agile programmers" (the 'paired programming', 'what radical new methodology can we hop on board with this week' variety) are the worst offenders of this sort of thing.
Languages like C (in it's range of distinct flavors), Java, ASP, PHP, Perl, VB.NET are surely enough for what people are typically doing (which for the vast majority of developers basically, is the same old fairly simple stuff over and over again - web services, XML parsers, and database interfaces). It's simple stuff, my mind boggles at the thought of people *PAIRING* for this sort of thing. If you don't know how to write that sort of thing solidly and reliably WITHOUT pairing and unit testing, you probably shouldn't be writing software in the first place.
It's not that I'm against people trying things out and moving forward with new ideas.
For example: It's fair to say that mod_perl is less than ideal (read: pretty kludgy) and people have legitimate reasons for not liking PHP (though with PHP 5's OO support it's getting better) and they have issues with Smalltalk, and so I can see a case for people liking something like Ruby - so I'm not entirely against new languages that only have some fairly incremental improvements over others, as in some cases it's reasonably justifiable (even if I personally don't see the point in Ruby, I can see why other people do).
But this sort of thing? An "agile dynamic language for the Java Platform" to quote the first line of the blurb on it's homepage. To me, that sounds like someone who prefers playing buzzword bingo to just getting on and doing Real Work. From a brief description of it, I can see something of a case for it, or rather I could if people weren't coming up with a myriad of new similarly arguably-incrementally-more-useful-than-whats-gon
When people implement this sort of stuff, they completely discount that developers who come after the people who write this sort of thing (and Java enterprise development is full of contractors - especially in the so-called 'agile' market) will have to look after the mess that gets created. I am highly skeptical that it's more beneficial to jump on the band wagon of some new language or framework rather than just hire developers who can write proficiently in a small number of common and widely supported languages (e.g. C, Java and Perl/PHP - or say C++/C#, VB.NET and ASP).
It seems these days a large proportion of new developers are primarily one trick Java poneys, with a fondness for frameworks of dubious merit and a lack of appreciation for basic OS fundamentals and established (and functional) scripting languages. Or am I just working in the wrong place? 8)
Jython is an implementation of the high-level, dynamic, object-oriented language Python seamlessly integrated with the Java platform. The predecessor to Jython, JPython, is certified as 100% Pure Java. Jython is freely available for both commercial and non-commercial use and is distributed with source code. Jython is complementary to Java and is especially suited for the following tasks:
Hmmm, I wonder if it could be useful for teaching robotics on Lejos http://lejos.sourceforge.net/ ?
Engineering is the art of compromise.
Why does this sound more like a porno flick than a scripting guide..
Great new book on Evolution: The Greatest Show on Earth by Richard Dawkins
You must be new here.
That's "Mr. Soulless Automaton" to you, Bub.
So Goovy is like Mondad, I mean PowerShell, I mean PERL ripoff for Windows but not M$'s proprietary system? Groovy, I'll have to try that out.
Could somebody in the know let me know if Groovy has the flexibility of PowerShell? Thanks in advance.
- I voted for Nintendo and against Bush
Bean Shell? Dynamic Java? How is this language going to be easier to learn for Java developers than the other 2? And if I have to do some learning why not just learn Python and use Jython?
-1? C'mon, folks. I, for one, thought it was hilarious!
Ironically, "Groovy Inaction" is the canonical book on accomplishing nothing at all.
Not that this wasn't entirely predictable.
Interesting how 2005 is now being referred to as "the old days" and 13 months is referred to as "an eternity". Personally I would've gone with "not too long ago" or "just before last year's taxes were due."
Sorry, I've gained a bit of perspective. I wrote the preceding paragraph back in the golden days of typing, in the age prior to taking a sip of my Mt. Dew, but I'm no longer posting in the same world it was back then.
Walt Disney? I'm sure you mean Rick Dees.
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
Anyone? Noone? OK, fine, I'll throw it out there, but I know you're all thinking it! :)
Groovy in Action Always, or GinAA.
bash: rtfm: command not found
Summary:
* Groovy is in Java, and therefore current and former Java programmers will love it (wtf?)
* Groovy is a dynamic language and therefore attractive to people who work in scripting languages (wtf?)
* Grails is implemented using Groovy and therefore Ruby on Rails programmers will be interested.
* Groovy is awesome!
* This book is awesome!
I've seen a lot of advertising masquerading as book reviews on slashdot, and I don't generally mind 'em too much, but this one's over the top. The author seems to think that the book will appeal to every group of people that could possibly be touched by some aspect of Groovy, and gives very odd reasoning for each case. The review imparts almost no information beyond that and a summary of the table of contents. If the book is half as proselytistic as this review, then it's unlikely to be worth the paper it's printed on. Then again, you shouldn't judge a book by its review.
My favorite sentence is:
"I like the approach of including guidance for using the language after you've learned it, because it acknowledges that the purpose of learning a programming language is to then use it."
To me, the java vm seems like the natural choice for a gigantic, mission-critical, server-side application that you start once and then allow to run without restarting for a long time. I don't understand why you'd want a scripting language that targets the java vm. Starting up the vm, and loading all its libraries, takes time, and for a typical application of a scripting language, that time could easily be an order of magnitude more than the time it should take for the code to run. Also, you don't get the benefit of JIT compilation if it's just a script that runs, does a job, and exits. Of course I realize that scripting languages aren't just for the kind of thing that unix shell scripts can do, but really, that's a major part of a scripting language's natural niche. Also, part of the Unix Way is that you write lots of small tools that work together; but if each of those tools is starting up a java vm, and then maybe invoking ten other tools that start their vms, it just sounds like a recipe for horrible performance.
I haven't used rails, and don't know anything about grails, but I assume that a rails or grails application runs as a cgi, with a new process starting every time a user does something in a web interface. As a user of web interfaces, the last thing on earth I want is a web interface that has to start up a java vm every time I click on a button to submit a form. As a webmaster, I also can't see that as a good use of server-side resources. Or is there some mechanism similar to mod_perl that allows you to avoid this overhead?
OK, correct me if I'm way off base, here!
Find free books.
Rick Dees Nuts!
'Groovy' is a 60's word. By the 70's it was only used in Archie comics
Embed Groovy in your Java application to provide scripting extensions, and call the methods from inside your Java code.
Let's see, runs under Java virtual machine, uses Java libraries and objects... Wouldn't that make it, um, Java?
Why? To run those tiny scripts from your giant business app or a heavyweight desktop app once it's all started up...
JDK 6 even includes a new extensible scripting framework support just for this very purpose, and ships with the Rhino JavaScript engine...
Embed Groovy in your Java application to provide scripting extensions, and call the methods from inside your Java code.
OK, seems logical. Are a lot of people actually using it for that? The review mentions "calling Groovy from a command-line," "writing automation scripts," and Grails for web applications. It doesn't mention the idea of using it as an extension language for java.
Find free books.
So Goovy is like Mondad, I mean PowerShell
No, PowerShell is a shell, as the name suggests, and is based on the CLR. Groovy is a compiled language for the JVM.
I mean PERL ripoff for Windows but not M$'s proprietary system?
Well, no, Perl is a weakly-typed scripting language.
I'm sorry programming languages are a blur for you, but there are big differences between them. Groovy is a god-sent for the Java platform, given what an awful language Java has turned into. Personally, I have no use for either Perl or PowerShell, and I think both of them have serious problems.
Groovy was designed as a dynamically typed language that is compiled into the Java VM. Examples of scripting languages based on the Java VM are Beanshell, Jython, and JRuby. In terms of language features, the two kinds of languages may seem fairly similar, but Groovy should perform better than the scripting languages.
Well, it's a "scripting language", but it won't get started and stopped on every request like a Perl script in 1995. Groovy compiles to Java ByteCode, so the application server doesn't know you were naughty and didn't use a completely statically typed language.
but I assume that a rails or grails application runs as a cgi, with a new process starting every time a user does something in a web interface.
.net, you name it) this was proven not to scale over a decade ago. :)
yeah, this assumption is quite wrong. i don't know of *any* even remotely popular language targeting web apps that does this. (django, ruby, java, php,
http://kered.org
Addendum: I would probably turn round and hassle the other people (be they internal, customers or vendors) to fix their broken system or write a specific class/classes in Java to fix the problem (e.g. load a specific class to extend the primary class to unmangle things) to try and keep the logic in one place (and also because I'm a huge fan of 'get other people to write non broken systems' approach, of course they always do, but that doesn't discourage me any in trying to get rid of it when I see it, I'm often a huge PITA in that respect - not that I mind working round things, but I like to make it clear when someone else has done something stupid and can't/won't fix it :-).
:-).
Your example actually reminds me of a similar example someone gave here recently (also a Java developer, who must have been using something very similar to Groovy, if not in fact Groovy itself). So while it's probably not something I would do, I wouldn't say 'never' (I can see the benefit, certainly if you can keep control of it and don't have wacky developers doing dubious things with it down the line
He liked the NICE language the best.
[% slash_sig_val.text %]
Second that. So he's even later than he thinks.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Groovy to this point has concentrated on loose data-typing
Languages are classified into strong/weakly typed, and statically/dynamically typed.
strongly typed: Java, Groovy, Python, Eiffel, Lisp
weakly typed: Perl, Tcl, assembler
statically typed: C, Java, Eiffel
dynamically typed: Groovy, Python, Perl, Lisp
Scripting languages are usually dynamically typed, but not all dynamically typed languages are scripting languages. And many dynamically typed languages are strongly typed.
You mean that was proven back in the day when a significant percentage of CPU cycles were needed to fork a process?
Today I bet it's absolutely a non-issue, and huge layers upon layers of frameworks are likely a much higher burden on both the machine and the developer. (This is not saying that all frameworks, or Java are bad, or that you should do everything CGI. Definitely not. And there's also FastCGI; same idea, but more efficient.)
If dynamic typing really bothers you, you aren't writing unit tests.
In fact, it might make a great replacement for Java. Features that really should've been there from the beginning are no easy to access (ranges, easy to use lists & associative arrays, reasonable string handling)
Although you can start out simply in Groovy, I find some of the funky "iterator attributes calling code snippets declared in 'closures' " to be cryptic. Here's an example (basically from listing 7.23 of the Groovy in Action book, see http://www.benslade.com/projects/java/groovy/Listi ng_7_23_GPath.groovySelfDoc.html for the full example):
I think this says:
I'm just starting out so maybe it'll start to make sense to me later, but Groovy's more advanced features are definitely not for beginners or simple scripting applications.
Ben Slade
Chevy Chase, MD
Ben in DC
"It's the mark of an educated mind to be moved by statistics" Oscar Wilde
Here's the interesting thing: it does not really matter anymore, if all we care about are other interpreted, programmer-friendly scripting languages.
If we're concerned about using this against Perl, Python, PHP, Smalltalk or Ruby, using the great language shooutout benchmark*, Java is about on par, if not better overall based on CPU time alone.
My understanding of the jvm, which may be flawed, is that it first interprets the bytecode and eventually gets around to compiling it into native machine code - meaning that over the life time of large apps it has a negligible performance hit. So, in theory, Java can only ever be, at worst, as slow as any other interpreted language.
This is something we've come to accept; linux installers are built on python, large websites on ruby and we constantly call perl scripts from our command lines. It's not really that terrible as for the majority of apps these languages are fast enough.
The same should apply to groovy. It also seems that groovy is intended for current Java devs for quick prototyping, so it's not like they don't have to load the jvm constantly anyways.
Finally, as far web apps are concerned, I know for a fact that Java is used all over the place in companies for stuff like that, and that it's a popular backend language. I can only imagine that all of these apps find *someway* of keeping the JVM alive long enough to get that amortized reduced performance cost. It'd just be silly not to.
*disregarding, of course, all of the obvious problems with using that benchmark. We're doing back of the envelop stuff here, nothing too serious.
I believe firmly that new language should appear in the world butt-naked beautiful. Elegant, consistent, and with a good formal footing. They grow warts as they age, though some (like Lisp) have managed the wart stage with much more elegance than others (like C++).
Here's the thing. As I've watched it, Groovy has appeared on the scene as a big giant hack. It's got a piecemeal formalism: it was clearly conceived originally by people who do *not* know how to make programming languages, and then as it somehow squirmed its way into a JSR it gathered the interest of people who *do* know what good languages looke like, and they tried hard to clean it up, but not entirely. And it's got HUGE numbers of ugly inconsistencies, compounded by a need to be approximately backward-compatable with Java for no particularly good reason (interoperability and sermantic compatability != syntactic compatability).
And... it's slow. That's a big deal. Take kawa, for example, the leading Scheme system written in Java. Kawa has optional type declarations, and with them added in, it's about 1.5 times slower than Java. Without them, it's 10-40 times slower, more or less like Groovy. The point is that kawa, a language *totally* *alien* to Java semantics, is decently fast. Groovy, a language which is attempting to be a superset of Java, more or less, is *not* decently fast. It's not like you can't _make_ a fast Java language. Kawa did it. Groovy's a mess.
There's my rant.
I have tried using Groovy for command line utilities and JVM performance has, in fact, been an issue. There are ways such as Nailgun for elminating JVM startup overhead, but Groovy (last I checked) doesn't provide an "out of box" solution.
1) Basically any server application needs to run all the time.
2) Starting the vm on a modern machine takes about 0.5 seconds.
3) Loading a few MB worth of libraries of course takes time; in any language. J2ee servers are indeed huge. But then they also include a lot of functionality and actually most of the time it spends booting it is actually executing functionality rather than loading libraries.
4) Groovy is compiled to bytecode. That means it is being JIT compiled. Which makes perfect sense in a server environment. Since the JVM has mechanisms for dynamically loading and unloading classes, that does not conflict with the dynamic nature of a language like groovy.
5) Scripting is about more than the unix shell, although ant+groovy is a very useful addition to that toolset.
6) Serverside groovy doesn't work like cgi scripts (well it could but only a retard would use it like that). It merely builds on one of the early innovations over cgi to not kill the process in between requests. This has been commonly used in the servlet APIs since about 1998 and most apache modules now do something similar (e.g. php). Building on the J2ee architecture gives a few scalability benefits to groovy that most other scripting just lack.
7) If you are a webmaster, you should know all of the above.
And yes, you were way off base. Basically all the assumptions you made are plain wrong.
Jilles
It sounds like you think these two things (forking a CGI on every hit and using a lot of abstraction layers) have independently computable performance impacts. If you indeed believe that, you're dead wrong - the performance penalty of the abstraction layers is largely paid on startup, so it's negligible in a long-lived process FastCGI, and horrible in a process-per-hit like CGI. In other words, if you measured these four quantities:
You'd find that (D - C) >>> (is much greater than) (B - A). Also that C >>> B. The comparison between A and B will be much closer, and can really go either way.
Why, you ask? fork() is comparatively cheap, yes. That's never been why CGI is horribly expensive. The real cost begins with execv("/usr/bin/perl", ...), continues with loading all those modules, and finishes with creating a new RDBMS connection and requerying any otherwise-cacheable state. You seem to be saying "you need to reduce the number of modules to make it fast", but the real answer is make all of those costs 0 - don't redo that work on every request. This is the solution people came up with 10 years ago, and it's more valid now than it ever has been. Those layers of abstraction serve a purpose - they make it much easier to write large systems, and often they provide performance benefits through easy-to-use pooling and caching.
Consequence: A mod_(perl|python|php|ruby), FastCGI, or servlet engine-based system, with or without all those modern layers of abstraction, will mop the floor with a Perl CGI every time. If you doubt that, don't make silly bets on slashdot - just do the benchmark.
Here's the rough equivilent in PHP:
Or in less dense form:$ExpensiveItems = array();
foreach ($invoices->objLineItemList() AS $aLineItem)
{
if ($aLineItem->totalCostLineItem() > 7000)
{
$ExpensiveItems[] = $aLineItem;
}
}
$ExpensiveItemNames = array();
foreach ($ExpensiveItems AS $aLineItem)
{
$ExpensiveItemNames[] = $aLineItem->product()->name();
}
assert(array('UCL') == $ExpensiveItemNames);
Oops, add return(..) around the create_function bodies; no implicit return values in PHP.
I'm referring to the Walt Disney version of the song. I wasn't aware that someone else wrote it.
With all the new cores/gpus available and programming getting complex everyday, we do need much more optimized and easier to use languages.
I am a huge fan of easier to use (and more specifically, maintain), and more 'automatically optimized' languages.
I think Java's syntax (copied by everything from C# & VB.NET and PHP - you write eerily identical code in all four now) is actually pretty great, that doesn't much to do with the efficiency of the implementations though (when it comes to multi core systems). Sun's gcc-workalike C compiler is great for building software target to systems like T2000's, and making use of threads in things like Perl is fairly trivial (let alone something like Ruby) - it's not as if it's significantly easier in Java. In the case of web services apps (particularly with scripting languages), the web server (typically Apache) does much of the work too (at least, if you have designed your software appropriately!).
I don't know that Groovy has anything special to offer in this regard, again I don't see what it has over existing tools in respect to the issues you've raised. For the most part I expect many (not all, but a significant number at the very least) won't even really have a proper awareness of other ways they could be working or other established tools they could be using (frankly, I think because they are not engaged much in the field they have chosen to specialize in, and because most higher educational establishments - where most of them learned how to be code monkeys - don't bother to explore as part of a wider and more rounded curriculum).
All they know is "Java is best thing to use right, because everybody uses it?" and "Sun T2000 must be awesome because it has loads of cores.". Managers also often come to similar conclusions. Same deal with the man-on-the-street and the PS3 really (for not quite identical, but very similar, reasons). In truth, the T2000's, much like the PS3's, are still going to get spanked pretty much every time by less exotic decent (x86/x64) multi core system. I think there are parallels there with approaches to software development too.
In most real world enterprise scenarios an 8 CPU Sun Fire 4600 will spank a 32 CPU Sun Fire E20K. Forget the hype about 'cell processing' you might have read! Half the 'optimization' advice Sun give is around using different *zones* in multiple CPU systems (which is, basically, pointless and a rehash of the blade idea that has failed to catch on, because the cost of ownership isn't very good), and as I've said writing threaded/parallel software is nothing new. In by far the majority of cases, 16 fast (3.0 Ghz AMD) cores will beat 72 slower (crappy UltraSPARC) cores IME, and it's cheaper too.
IMO, write your software to scale horizontally, beware of "new shiny" snake oil and you are some way to being on the right track. Google's systems are a good example in this respect. The enterprise level stuff that most of us are writing on a day to day basis is pretty straight froward to both write in an entirely scalable fashion, it's just that some people manage to make an almighty mess of it and then convince themselves what they are doing is in some way uniquely difficult.
I had to laugh when I read some one having a go at games development programmer on a forum recently "What's the deal with you games programmers anyway? Why do you think what you are doing is so much harder than what other developers are doing?". I do not develop games for a living, but I have - and do - play around with games development for fun. It's several of orders of magnitude more difficult to do well. I just though "Man, these enterprise guys really have no idea how easy the work they are doing is.".