Hey folks!
I just created a new support forum for the Groovy Language: www.itsjustgroovy.com.
Groovy is probably the best scripting language for jME applications. It extends the Java Langauge, so anyone that can program in Java can program in Groovy. It has a facility for writing DSLs, domain-specific languages (see http://en.wikipedia.org/wiki/Domain-specific_programming_language), via its
i've tried groovy (and ruby) once. both gave me the creeps.
you get an object and do not nessecarily know its type or what methods it has (expandos). 2/3 of my ide's (IDEA) refactoring capabilities would be useless because of the dynamic nature of groovy.
you may get a closure without knowing how many parameters it needs. the compiler won't tell you. if you call a method and give it a closure, you won't know if it will be called correctly until you run the program.
dynamic scripting languaged invite anyone to write really, really unreadable code.
shiver
I second your sentiment regarding dynamic typing being creepy, HoD. But I still think scripting can be very useful if used carefully.
For example, in my orpg project I use javascript (rhino) even in the update loop, with good results.
It makes adding a spell, item or weapon with virtually any effect a matter of dumping a few strings into the game server's world database rather than having to create new classes and then recompile and deploy at least one jar.
The latest release of Groovy 1.5, has added Java
I'm a little behind in posts (having been and still sick for the last 6+months)
For compiled scripts, Groovy is the only way to go.
For interpreted scripts, Groovy is easily 2 maybe 3 on the list (but the interpreter is getting a lot faster); pnuts, IMO, would be above Groovy in that respect, however, I've not seen any current metrics between them.
As for pnuts vs Groovy there really isn't a comparison that can be done on syntax… both syntaxes are quite similar.
For a choice between pnuts and Groovy it is really up to the developer at that point. Each has their own adv and disadv.
For syntax and reduction in lines of code, Groovy is far superior to other scripting languages (namely those competing against each other Groovy, JRuby, Jython, etc to be a Java first class citizen) and that I would and do take to the bank.
The debate on scripting languages is as volatile in the Java realm as religion or politics… it can get very heated and there are three sides, those Java developers that absolutely HATE Groovy, those that don't know about Groovy, and those that absolutely LOVE Groovy.
I happen to be the latter and incorporate it into my work as often as is allowed. I have whole sections of game code in Groovy (compiled and interpreted)…
I know that there are a few things that drive some Java developers nuts about Groovy (absolutely no pun intended referencing part of pnuts) as have been mentioned in this thread.
- compiler will compile even if the code is wrong when calling a closure
- don't understand that all closures return a value no matter what
- don't understand closures, currying, or other things Groovy has that has been incorporated from other languages
- it's not Java.
I know there have to be others, and I'd welcome any thoughts on the subject. I don't understand why the aversion, so help me understand what it is you don't like about Groovy.
What I like about Groovy:
- it can be compiled to byte code and can be run and used with ANY Java class
- it takes far fewer lines of code to do most common things in Java (like reading or writing Files)
- I don't have to write property accessors to conform to JavaBeans specs (it's already done behind the scenes)
- it has major IDE support above ALL other scripting languages
- I can use all of my existing Java code in Groovy, even changing the extension from .java to .groovy and it will still compile and work the same
What I don't like about Groovy:
- it can be a little slow on the interpreted side
- DF hates me b/c I love it
@DF, is this post is as bloated as my code? :evil:
As I said, it's a matter of developer preference and there's seldom anything anyone can do to change minds, but I'd be happy to go head to head with comparisons. I can be, and have been, wrong before (right DF?). More than anything I'd like to know why a preference to another scripting language. Most of the time I've found that it's a matter of experience over convention. Someone who is a great Python developer prefers JPython b/c it's similar to what they've done before (or Ruby/JRuby).
thx for reading
timo
Pnuts is preferred to me if I have to use something other than Java. Pnuts has the best scripting integration with Java as it can directly use any Java object and interact very well with the VM. However, why use anything but Java? What advantages does Groovy provide that BeanShell does not? I have yet to receive a good answer for this question. For anyone that prefers other languages to Java that's fine, but why a Java developer would intentionally mix languages is beyond me to understand. 
darkfrog said:
Pnuts is preferred to me if I *have* to use something other than Java. Pnuts has the best scripting integration with Java as it can directly use any Java object and interact very well with the VM. However, why use anything *but* Java? What advantages does Groovy provide that BeanShell does not? I have yet to receive a good answer for this question. For anyone that prefers other languages to Java that's fine, but why a Java developer would intentionally mix languages is beyond me to understand. :P
In my own project I thought for a while how to go ahead with events etc. And basically I came to the same conclusion - I should stop thinking about which scripting language to use and start thinking about a good API for achieving the same thing with pure Java. It seems to be a popular trend to use scripts, and in many cases the use of a scripting language is even well justified.. but in even more cases, there is no need to make use of one.
I'll admit I just skimmed…long post late in the day…my eyes glaze over. :o
Compilation…I don't know if Pnuts can be compiled either. However, if I really care about compiled then I'll either, ya know, use Java since the reason I'd be using a scripting language in the first place was for the benefits of non-compiled code. Or, for whatever reason the code is dynamically generated but I still want the benefits of compiling…one word: Janino…or JDT if you want to Eclipsify. :o
Sure there are coding shortcuts that many languages have that allows you to write smaller (albeit, I would consider, less readable) code, but the example you mentioned:
class DarkFrog {
String name
boolean lovesJava
}
Though not the recommend approach for bean design, there's nothing inherently wrong with it. Essentially you're doing the exact same thing in your Groovy example, but you're saying it's bad just because there are actual standards in Java versus Groovy? ;)
<soapbox>
Groovy, Ruby, and all the other scripting languages that are constantly trying to push themselves up into Java developer's purview boast the simplicity of code, but that's in fact one of the main reasons I refuse to use them. The forced structure in Java, though I get to see a lot of crap code these days, keeps up code readability to a level that is completely lost in these other languages. You can't trust your peer developers to write concise and well constructed code unless you force them to do so. Take Perl for example. It's a very loose language and you'll often hear Perl coders say, "Oh, I could write that in one line of Perl"....and they can, but it's unreadable garbage. :o These languages I like to refer to as "write-only" languages...you can write them when you're coding the first time through, but when you come back you end up having to start over because you simply can't figure out what in the world you were doing the first go-around.
</soapbox>
I just played around with groovy a bit (we are about to integrate a skripting language into designer) but as far as I know the integration with exisitng java objects/libraries is as good as with pnut.
It seamlessly integrates with existing stuff and can directly access java objects. So what is the big advantage of pnut (please put the syntax aside) over groovy?
Well, performance aside (http://pnuts.org/benchmark/pnuts.org/) Pnuts does provide better integration with Java than any other scripting language. I just learned that you can actually compile Pnuts scripts into Java classes even.
However, if you like Groovy, use it. I still cannot find many circumstances where I would even use a non-Java language at all, but perhaps that has to do with the type of work I do.
Always wondered what the fuzz was about scripting languages. After reading this topic I got a good idea what to expect and think it would be silly to use one when you're able to write Java.
Maybe its an outcome for dev's that aren't into Java but want to develop parts of a game as well… then again… learn the whole deal I tend to agree with Darkfrog that not using a strict structured language will make your code look unreadable eventually.
i tried to use groovy once, but i didn't see any big benefit and never needed most of the features - my ide is doing the job of writing the same code again and again, so less code doesn't mean less typing for me
Well, I've yet to see the IDE that generates code for even the first of the links I gave (let alone the one below that). And even if it did, it wouldn't be more readable.
I always disliked having useless crap cluttering up your source files. It's one of the reasons I like Java, no declaring your methods for example.
Honestly, it's been so long since I've done anything with Pnuts, and very little even then you'd be better off taking a look at the project for more information. I do remember reading a comparison between Groovy and Pnuts and they explicitly said that Pnuts offered better Java integration than Groovy, but it was perhaps quite slanted as it was a pro-pnuts article. 
operator overloading is a double edged sword. while "myimpulse = mymassmyspeed" is pretty straightforward, easy to read and short, one might assume that "myimpulse = myspeedmymass" also works - which means, the same logic has to be implemented twice, once in each class, or one redirects to the other. or you get a compile error. i prefer myimpulse.init(myspeed, mymass).
for the xml stuff: i don't use it. can't comment.
darkfrog said:
I'll admit I just skimmed...long post late in the day...my eyes glaze over. :o
Compilation...I don't know if Pnuts can be compiled either. However, if I really care about compiled then I'll either, ya know, use Java since the reason I'd be using a scripting language in the first place was for the benefits of non-compiled code. Or, for whatever reason the code is dynamically generated but I still want the benefits of compiling....one word: Janino....or JDT if you want to Eclipsify. :o
Sure there are coding shortcuts that many languages have that allows you to write smaller (albeit, I would consider, less readable) code, but the example you mentioned:
class DarkFrog {
String name
boolean lovesJava
}
Though not the recommend approach for bean design, there's nothing inherently wrong with it. Essentially you're doing the exact same thing in your Groovy example, but you're saying it's bad just because there are actual standards in Java versus Groovy? ;)
lol, uh no... the meaning was that the getters and setters may not be IN the code, but they are PART of the code, you just don't see them... so in Java
getName() is written out, in Groovy, it's just not seen... the convention is there still, but it's behind the scenes... standards are extremely important.
darkfrog said:
<soapbox>
Groovy, Ruby, and all the other scripting languages that are constantly trying to push themselves up into Java developer's purview boast the simplicity of code, but that's in fact one of the main reasons I refuse to use them. The forced structure in Java, though I get to see a lot of crap code these days, keeps up code readability to a level that is completely lost in these other languages. You can't trust your peer developers to write concise and well constructed code unless you force them to do so. Take Perl for example. It's a very loose language and you'll often hear Perl coders say, "Oh, I could write that in one line of Perl"....and they can, but it's unreadable garbage. :o These languages I like to refer to as "write-only" languages...you can write them when you're coding the first time through, but when you come back you end up having to start over because you simply can't figure out what in the world you were doing the first go-around.
</soapbox>
I disagree with the Groovy portion to an extent. I've SEEN Ruby, but never USED Ruby... as for Perl... I've never understood writing a line of code that's a regex and I have no idea what it does... it's like obfuscating my code then trying to remember what I did.
ANY language can produce unreadable crap (as you pointed out). As with all of them used in the right hands it is just as readable as anything else. Code readability can be just as "lost" in Java as well. Take simplification (the paradigm I had been taught and have done my best the last year to move away from it)... it [simplification] took great Java code and tried to make it a 'silver bullet'... it produces almost completely unreadable code... so your argument doesn't fly... Groovy has standards the same as Java, but standards doesn't mean you MUST use them. Standards are like code style or best practices... you may use them or you may not, it is still your call. By following this train of thought even further, IMO, why would you write methods or utility classes? You're not following a standard... if it were standard to code 40 lines of code every time, then you would never make a method to encapsulate those calls. I definitely understand exactly what you're saying (and I always have); however, all of your arguments for the "scripting languages" apply to Java (CSS, XHTML, HTML, JS, JSON, XML, and on and on) as well (and you may very well not use those languages as well, if you don't have to)... none of these is a bad thing.
I had a long conversation with developers that utilize Ruby, JRuby, BSF (beanshell), JPython and a few others. The comment that was brought up was "if HTML were a good programming language we would never have to use anything else. However, we are FORCED to use it if we want to communicate over the web". That is absolutely correct.
My point, as is inline with yours, is that in less skilled hands readability is lost... For me, tho, I chose Groovy b/c of the simplicity of doing things... so maybe in my case it was the difference between writing utilities that did the work OR using Groovy which does everything behind the scenes and now my utilities and their utilities are the same. (It is entirely possible).
And just so no one misunderstands, I totally respect the opinion to disagree or agree. I would simply like to know why one preference over another and more-so, why NOT Groovy.
darkfrog said:
Well, performance aside (http://pnuts.org/benchmark/pnuts.org/) Pnuts does provide better integration with Java than any other scripting language. I just learned that you can actually compile Pnuts scripts into Java classes even.
However, if you like Groovy, use it. I still cannot find many circumstances where I would even use a non-Java language at all, but perhaps that has to do with the type of work I do.
Nice! <caveman>compilation gooood</caveman> In which case Pnuts vs Groovy comes down to which syntax you prefer.
For the later point, (final sentence), I suppose that would be the case for almost everyone. This is the argument that I am presented more often than not.
See, most Java developers start off learning Java with what? AWT (and moreso since 99ish) Swing? I did not. I was hired for the Job I have now with no Java experience at all... but I did know html, css and javascript. That put me into JSPs which are an entirely different animal than desktop apps... they might look and kind of act the same, but they are waaaayyy different. So, when I work on an application, I will prototype in Groovy (and pretty soon, I'll play with pnuts so I have a better idea of it's scale) and simply load that script on the fly (when I need to 'tweak' parameters). So, I just finished writing a web app in Java/JSP/Freemarker that gives the user the ability to go to another website based on their search (long story, but the gist is that if you look up a specific item then it will take you to another site)... so, to test the parameters based on the business owner, I didn't want to stop, change params, adjust values and then compile and restart my appserver... at times can be a long process. Using a scripting language I've got a hook into the Servlet that calls the groovy script and I can then add params that the business forgot about or tweak a color or whatever with the business owner on the phone... very powerful for that. With Swing I will use the SwingBuilder, but again, margins, or placements, or even for listeners... But, there are times when I couldn't see using a different language of any type unless your entire application was written in that language. At the same time, and this goes for other languages, why would you use JNI? LWJGL maybe? You have dlls which process information faster and are highly optimized and Java connects to it. There are times when I've used it and it comes in handy... but you can't use it for every project.
HamsterofDeath said:
operator overloading is a double edged sword. while "myimpulse = mymass*myspeed" is pretty straightforward, easy to read and short, one might assume that "myimpulse = myspeed*mymass" also works - which means, the same logic has to be implemented twice, once in each class, or one redirects to the other. or you get a compile error. i prefer myimpulse.init(myspeed, mymass).
for the xml stuff: i don't use it. can't comment.
Your point is, mostly, totally valid. However, if the base object implements operator overloading for * (AND myspeed and mymass are both of the same object type) then there's no problem at all Most operator overloading I've used matches the OpenGL work I've done for so long... which, for me, not starting with Swing, but Basic (one a TI99) then VB, C, C++ and finally HTML (et al) followed years later by Java, operator overloading makes perfect sense to me. Most of the OpenGL work I've done with C++ libraries utilizes operator overloading and I'm here to tell you that there are times when it can be just as confusing to read as Perl. I've NEVER had an instance to use currying, it makes sense, but I've never had an instance to use it. It's just like statically overloading a method:
public void bob(String str) {bob(str, false)}
public void bob(String str, boolean value) {}
which, for me I use less often than I do setting default values:
def bob = {String str, boolean value = false ->}//where if no value is provided for value, then it's defaulted to false
enough of that:)
darkfrog said:
Honestly, it's been so long since I've done anything with Pnuts, and very little even then you'd be better off taking a look at the project for more information. I do remember reading a comparison between Groovy and Pnuts and they explicitly said that Pnuts offered better Java integration than Groovy, but it was perhaps quite slanted as it was a pro-pnuts article. ;)
lol. Well, it's entirely possible, bias is everywhere in programming... Java always rules:-D