×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Your Thoughts on the Groovy Scripting Language?

Cliff posted about 8 years ago | from the coffee-with-sugar-and-cream dept.

128

lelitsch asks: "Does anyone have first hand experience with Groovy? I am just coming off implementing a Plone-based intranet CMS and got hooked on scripting languages and Python all over again. Since most of my projects in the near future are going to be in Java or have large Java components, I was wondering if it's time to trade Jython--which seems to be falling further behind the Python release cycle--for something else. Groovy sounds like a fun thing to look at, but it seems a bit new and thin. Also, what are other languages (JRuby and Rhino, for example) you have used to script in Java?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

128 comments

My opinion (0, Funny)

Anonymous Coward | about 8 years ago | (#15154429)

It's a pretty Groovy language. I still prefer Object Cobol though.

Jython and CPython (4, Insightful)

CRCulver (715279) | about 8 years ago | (#15154438)

I was wondering if it's time to trade Jython--which seems to be falling further behind the Python release cycle...

Who cares if Jython is a little behind CPython if it already has all the features you need at this point? When I do work with CPython, I work from a relatively old edition of O'Reilly's Python in a Nutshell [amazon.com] as reference, and find that the language at version 2.0 already does everything I need it to. While features added at 2.2 and 2.4 are undoubtedly useful for certain audiences, the language itself was complete for most purposes some time ago, and Jython should serve most people fine.

Re:Jython and CPython (2, Informative)

RovingSlug (26517) | about 8 years ago | (#15154991)

Fyi, I have also used Jpype [sourceforge.net] with success, which allows bidirectional operation between Java and CPython.

Re:Jython and CPython (3, Informative)

bwt (68845) | about 8 years ago | (#15157035)

Groovy offers significant advantages over jython and jruby because it was designed specifically to run in the JVM. In particular: a) groovy's class library is the java class library -- you do not subject development teams to two competing sets of class libraries, b) groovy compiles to bytecode which means its interoperability with java is seamless c) groovy can and does actually add syntax and functionality to existing java classes via the GDK.

The problem with groovy is that it is young. It is just starting into the release candidate phase. Some people have written articles bashing groovy for missing expected features like good parsing error feedback. These articles are unfair since they are evaluating a product that is unfinished. I do not recommend groovy for any production purpose yet, it's simply not ready.

Have you tried ColdFusion? (1, Funny)

Anonymous Coward | about 8 years ago | (#15154439)

Seriously... it runs on top of Java.

Ruby (1, Informative)

Anml4ixoye (264762) | about 8 years ago | (#15154442)

I also have been enjoying scripting languages, mostly Ruby. JRuby is still in active development, contrary to belief, and they have versions of IRB running with it.

I'm giving a presentation on using Ruby for scriptable .NET apps at an upcoming Code Camp in St. Louis.

I haven't played much with Groovy, but I like the idea of Ruby in that I can write scripts that will run standalone, in .NET, or in Java (not that Ruby is the only one that can do that)

Re:Ruby (0)

Anonymous Coward | about 8 years ago | (#15154492)

I've been studying Ruby, and it appears very intriguing, and hope to use it in future projects. But JRuby? Point of Ruby (in comparison to Java) is its dynamic typing system, if I understand it correctly. Doesn't JRuby defeat the purpose? Back-and-forth round run to emulate dynamic types on top of JVM (or CLR)? This sounds like double-whammy: dynamic-type language on top of P-code execution. I understand the portability issue, but how's performance hit?

Re:Ruby (1)

Anml4ixoye (264762) | about 8 years ago | (#15154549)

Well, it depends on what you are using it for.

For example, I had a boss want to add scripting support to a C# windows app. With Ruby for .NET, we could do something like:

form = Form1.new
button = form.cmdGo
button.click.add do
name = form.username.text
result = verify_name(name)
form.result.text = result
end

So, while the above example may be a lame one, the point is that because you have full access to the .NET objects, you can deploy a scriptable app, without your users having to write C# code and compile it on the fly.

Also, with JRuby, they are working on getting Rails working with it (and are pretty close). So then you get Rails being able to be deployed wherever you have a JVM.

Is it an Amazing Discovery Which Will Rock The World? No. Do you take a performance hit? I'm sure you might, though perhaps not as bad (though I haven't done any performance testing - maybe I'll work on that this week). It's just another tool in the bag. There's more books on Python, so that might be a better choice. Or the tons of other options out there.

Re:Ruby (1)

shutdown -p now (807394) | about 8 years ago | (#15154804)

So, while the above example may be a lame one, the point is that because you have full access to the .NET objects, you can deploy a scriptable app, without your users having to write C# code and compile it on the fly.
Compiling on the fly is not exactly a problem with CodeDom APIs available for all MS .NET languages, and I found JScript.NET to be a very good scripting language, as well as being familiar to many people out there (everyone who worked with DHTML).

Re:Ruby (0)

Anonymous Coward | about 8 years ago | (#15154954)

Here's my guess,

When .Net came out people said it wasn't language independent because languages with dynamic typing couldn't work well with it, and so they wrote IronPython to demonstrate this, and surprisingly it was proved that .Net could do dynamic languages very well.

I believe JRuby is compiled down to bytecode for the JVM just like Java is. Perhaps the JVM can handle dynamic languages like .Net can.

Re:Ruby (1)

RegularFry (137639) | about 8 years ago | (#15155275)

Actually, IronPython came out of an attempt to prove that the CLR was rubbish for dynamic languages. Amusingly enough, He What Begat IronPython (whose name I have forgotten) found exactly the reverse :-)

Re:Ruby (1)

Samus (1382) | about 8 years ago | (#15156600)

Actually the author of IronPython (Jim Hueggins same guy from Jython) joined MS to help them make the CLR more friendly to dynamic languages. That's probably why IronPython never went very far on the 1.x CLR. .Net doesn't have near the flexibility in loading assemblies that Java has with its classloaders so you don't see interesting things like AOP. This rigidity and closed nature seems to pervade the .Net platform. Non-overridable methods by default? The "You can have it my way not your way" mentality of the platform really makes it unpleasant to work with.

Bean Shell Script (5, Informative)

Elias Ross (1260) | about 8 years ago | (#15154457)

From what I've seen, Groovy's a half-baked programming language and unfinished product. See this [cabochon.com] criticism for a start.

If you want to do embedded scripting in Java, I suggest Bean Shell [beanshell.org] instead. As a library, Bean Shell is about 280K, Groovy is about 1.7M. And Bean Shell has been around for a lot longer.

I'd like to see Sun add closures and better support for lists/maps in Java itself (e.g. a map function). I'm hoping that pressure from Ruby will make the language grow. C# already made them change their mind about Generics.

Java had generics before C# (2, Informative)

SuperKendall (25149) | about 8 years ago | (#15155309)

Come on, there was a beta version of Generics floating around (that worked in 1.4) before C# was even out. The guys adding Generics wanted to add it much sooner (even in 1.3 I think) but there was too much contention in the community about how best to add it.

Java was a little slower actually getting it in, but that's because they had a lot of legacy code to consider and how to make generics that would be useful even with older libraries. In no way was Java actually pressured to include Generics just becasue C# had it, they faced a lot more pressure from a world of developers wanting something like generics from 1.0 on.

Java doesn't need a map function (1)

brunes69 (86786) | about 8 years ago | (#15156084)

I don't know Ruby, so I will use perl's map function as an example.

In Perl:

      map { $_ * 2 } @arr;

In Java:

      for( Integer key : arr ) { key *=2; }

Now exactly, what would be the benefit of having a map function in Java, aside from obfuscating things? Everything in Java is already a pointer so operations inside your for() loop are already altering the objects in the array or collection.

     

Re:Java doesn't need a map function (1, Informative)

Anonymous Coward | about 8 years ago | (#15156490)

Hi,

you wrote:
> Perl: map { $_ * 2 } @arr;
> Java: for( Integer key : arr ) { key *=2; }

This is clearly not what 'map' is intended for.
map works entirely in 'block context', it
takes a list (array) as a whole, does something
an returns another list (array). You wouldn't
modify the original array in a map block.

This is what you might 'map' use for:
@words = ('here', 'we', 'have', 'some', 'words');
@indices = (1, 2, 3, 4, 5);

print join '_', map { $words[ $_-1 ] } reverse @indices;

Regards

AC

Re:Java doesn't need a map function (1, Informative)

Anonymous Coward | about 8 years ago | (#15156611)

In Perl:
map { $_ * 2 } @arr;
In Java:
for( Integer key : arr ) { key *=2; }
That Java code doesn't do anything. The variable named 'key' starts by holding a reference to an Integer object; then you (implicitly) call Integer.intValue() and multiply the result by 2; and then call Integer.valueOf(that) to get a reference to a new Integer object; and that object reference is stored back in the variable 'key', replacing 'key''s original object reference.

Variables in Java do store references (pointers) to objects - but when you use the "=" operator (including "*=", "+=", "++", etc), it assigns a new object reference to that variable, and does not affect the object which was previously referred to. It's like saying "int i; int* pi = &i; ...; pi = &((*pi) * 2)" in C (except more valid), and the value of i is never changed.

To modify it in-place, you'd have to do something like

ListIterator<Integer>; it = arr.listIterator();
for (Integer i = it.next(); it.hasNext(); i = it.next()) { it.set(i*2); }
(though that only works if it's a List of Integers, and you have to write completely different code if it's an array). If you don't want to modify the original, that'd be
List<Integer> arr2 = new LinkedList<Integer>();
for (Integer i : arr) { arr2.add(i*2); }
It works, but it's just a little bit inelegant.

Re:Java doesn't need a map function (1)

angel'o'sphere (80593) | about 8 years ago | (#15157823)


    for( Integer key : arr ) { key *=2; }


I beliefe you mean something like this:


    for (int i = 0; i < arr.length; i++) {
          arr[i] *= 2;
    }


I would be surprised if your code example works (as intended) as it has to unbox the Integer, then multiply it with 2, and then descide if the array was made from ints or Integers and again descide if it boxes or unboxes them again. Oki, I fire up the compiler and check it: it does not work neither when arr is an array of int nor when it is an aray of Integer.

angel'o'sphere

Re:Java doesn't need a map function (0)

Anonymous Coward | about 8 years ago | (#15158623)

Try using Java5.

The enhanced for loop as well as auto-boxing are both new to Java5.

Re:Bean Shell Script (1)

gz718 (586910) | about 8 years ago | (#15156336)

I'd also recommend bean shell over groovy. I went through this a year ago trying to add some scripting capability to a graphics library. What I like about groovy was that you could derive from an abstract class while for beanshell you can only derive from an interface and then need to add an invoke() method if you don't handle all the functions in the interface. Also there was a little problem with the fact that groovy did not work at all with jogl, it would give a stack overflow error what with all the reflection method calls. No complaints with bean shell and now that it passed some jsr voting it will have an even larger following.

Re:Bean Shell Script (1)

L'homme de Fromage (838405) | about 8 years ago | (#15156882)

I also think that BeanShell is the way to go for "Java scripting". The thing I like about BeanShell is that it eliminates the need to learn a whole new language, since it's just Java. Some of the other languages people have mentioned here look interesting, and I may try a few of them out (like Lua and Nice), but I tend to be wary of investing time learning various small obscure languages.

Re:Bean Shell Script (1)

bwt (68845) | about 8 years ago | (#15157438)

From what I've seen, Groovy's a half-baked programming language and unfinished product. See this criticism for a start.

Groovy does not claim to be a finished product. Does anyone suggest otherwise? Why do so many people need to make long winded disections of exactly how it is unfinished? This critique provides a set of likes and dislikes. Unfortuantely, the section of dislikes is an example of the kind of unhelpful impatience that many people seem to be hurling at groovy now. Every single one of the criticisms can be summaries as "groovy is still a work in progress", which is something that you don't need to read a review to know.

Open source project should "release early, release often", not so that people can tell them "you released early, damn you" but so that people who want the project to succeed can see what needs to be done and help. This is a good thing, and people who bash it are wrong.

Re:Bean Shell Script (1)

fm6 (162816) | about 8 years ago | (#15158111)

Groovy does not claim to be a finished product. Does anyone suggest otherwise? Why do so many people need to make long winded disections of exactly how it is unfinished?
Because the product has been around long enough to be a lot less unfinished.

Re:Bean Shell Script (1)

bwt (68845) | about 8 years ago | (#15159714)


Because the product has been around long enough to be a lot less unfinished.

What are you basing that on? You own opinion of how long it "should" take to create a new language? Please provide your evidence/reasoning to justify this. I recall using mozilla a couple years in and it sucked pretty bad. Now firefox is awesome. I recall the same chorus of "why are you taking so long, why do you have so many bugs?". In fact, I think that kind of impatience only happens to projects that will be great. It's only if people are excited by the positives that they bother complaining about the things that prevent them from using the innovations.

In addition to "release early, release often", another principle of open source is "it will ship when it's ready". If you think they are taking too long then either a) pitch in and help or b) try back later. Whining doesn't benefit anybody.

Re:Bean Shell Script (0)

Anonymous Coward | about 8 years ago | (#15159085)

what you say is true. however, beanshell has always been of a higher quality than groovy, even going back to the old days. i've worked with both sources. i think it's the attitude of the developers to the project. bsh was controlled by pat neimeyer for a very long time (recently he's let additional devs come on), and he kept the code small and features concentrated. releases--even betas--had few problems. contrast that to strachan and laforge's "anything-and-everything" approach to groovy development and it's easy to see why they have a reputation. ant-swing-foo-builder, gpath, groovlets, bytecode generation (could be good if it was done properly), and so on, while the core code flounders. i have no quantitative data to back it up, but having used both extensively i'd guess the quality of the later groovy jsr releases is still below that of the bsh 2.0 betas that were around for so long, and possibly below that of the 1.3 alphas. i prefer groovy syntax over bsh, so i want groovy to succeed. but it will not happen until they calm down.

Re:Bean Shell Script (1)

angel'o'sphere (80593) | about 8 years ago | (#15157888)


  C# already made them change their mind about Generics.


C# has generics since C# 2.0 (which is officially released since 3 monthes)
Java has generics since Java 1.5 (no called Java 5) whichis officially released since 16 monthes (or something).
Inofficially Java has generic extensions since 1.4 (as an add on to teh compiler) since 3 years, or more.

When in C# 1.0 the talks about gnerics and how they will work started, Java had generics some days alter. The very first generics for Java wehe from the year 1997 in the Pizza Compiler from Markus Odersky, this way to do generics is more or less now in Java (with extensons)

Claiming that C# had anything earlyer than Java had it ,is manly marketing hype and only true for Properties (which are done wrong in C# and .Net) and for Annotations (which IMHO are done wrong by C# and Java -- for your interest: Annotations should be classes in a seperate source tree and not lines of text int the source they annotate. Reason: annotations could change independend from the source they are contained in, depending on the deployment environment. Now you would have different sourcefiles if you changed an annotation .... braindead imho).

angel'o'sphere

Re:Bean Shell Script (0)

Anonymous Coward | about 8 years ago | (#15158793)

what i like most about beanshell is its stability. new features trickle in slowly over time, with a lot of thought beforehand. we've been using 2.0beta4 in production for over a year, without problem. contrast that to groovy, where each new beta or jsr release introduces shiny new features that are horribly broken, as well as introducing any number of regressions on previous features. that *never happens* with beanshell. it's kind of sad... i *really* like groovy's syntax, but the devs over there are just too sloppy.

Re:Bean Shell Script (0)

Anonymous Coward | about 8 years ago | (#15159126)

I'm not sure what's meant by half-baked but it's been good enough since last summer for a real project I'm working on. We've got about 30,000 lines of Groovy code working quite well. Be sure to look closely at the version someone is reviewing when reading comments or reviews. Some of the links are pretty old and refer to the pre-JSR versions.

Re:Bean Shell Script (0)

Anonymous Coward | about 8 years ago | (#15159584)

+1 I've been liking bean-shell more and more. Using it to implement some custom ant build functionality. What sold me was when I copied and pasted a java example for jdom into a bean-shell script that included a new class definition and it worked as expected.

Re:Bean Shell Script (1)

blackdrag (969484) | about 8 years ago | (#15160110)

first about the criticism: you really shouldn't use a page that covers Groovy from 1 year ago. I dion't know about Beanshell, but Groovy changed much in this time. about the size: that's true, this is work that needs to be done. But is Beanshell able to implement interfaces, subclass normal and abstract classes and give them back to Java as normal classes with methods that can be called in the Java way? I don't think so. I just want to say, that the big size comes through used libraries, if you remove them, then Groovy isn't that big at all. about Closures: How do you think this should ever work in Java? I mean where is the type information? A small detail? No, it bloats the syntax very much. Java would drive better if there is a way todefine inner anonymous classes in a shorter way. This won't get you closures, but it would get you as near to cosures as possible in Java without destroying the elegance of a closure completely. Think about it: Groovy Closures are nice because they don't care much about static typing!

Re:Bean Shell Script (0)

Anonymous Coward | about 8 years ago | (#15160118)

C# 2.0 has closures too, I tried it out the other day. And 3.0 will have type inference.

groovy (-1)

Anonymous Coward | about 8 years ago | (#15154461)

Groovy! Yeah baby, yeah!

Why? (4, Insightful)

zaguar (881743) | about 8 years ago | (#15154482)

I think you always need a reason before you try something new and unproven. If it is an enterprise app, why? Is there a feature that Python et al. does not do? If you have no experience with it, and no good reason to switch - Why bother?

Stop the groovy naming (2, Insightful)

AubieTurtle (743744) | about 8 years ago | (#15154519)

I wanted to use Drools and Groovy a while back to set up the variable pricing for a tollway. But who on earth is going to put that kind of system in the hands of technology named Drools and Groovy? No one wants to sound like an idiot going to their boss to suggest using anything with those names. Digital started off as Digital Intergalatic Research but quickly realized that suits don't use products that they feel stupid saying. A pun here or there is ok but there is a limit and I think Groovy, no matter what the technical benefits, has stepped over that line and can never be taken seriously. At least the Java community for the most part has gotten over the coffee metaphors when naming new products.

Re:Stop the groovy naming (5, Funny)

Anonymous Coward | about 8 years ago | (#15154850)

I pronoune it D-rulez for that very reason. Then I throw up some gang signs.

Re:Stop the groovy naming (1)

blueZhift (652272) | about 8 years ago | (#15156034)

I agree, the whimsical names can be a problem for some. For this reason, perhaps it should become standard practice to have some "suit"-able nicknames. Like Groovy might be referred to as Gr or GrV. If there is a suitable nickname in common usage, then upper management types won't come up empty if they Google it to get additional information (a usually unlikely event). This would be like when Kentucky Fried Chicken changed its name to KFC in order to sound hip and cool.

Re:Stop the groovy naming (0)

Anonymous Coward | about 8 years ago | (#15156274)

I could be wrong, but I thought Kentucky Fried Chicken became KFC so as to drop the 'Fried' part of their name during the health food craze where anything fried was bad.

Re:Stop the groovy naming (1)

The Wicked Priest (632846) | about 8 years ago | (#15156697)

It seems to be a rule that every company with a three-word name eventually drops the name in favor of the abbreviation. Most times it makes no sense.

fact clarification (1, Informative)

Anonymous Coward | about 8 years ago | (#15156177)

Intergalactic Digital Research (not DIR) was the original name of Digital Research (who sold CP/M and DR DOS) not Digital Equipment Corporation (selling the scrummy VAX minicomputers)

Re:Stop the groovy naming (2, Informative)

jasondlee (70657) | about 8 years ago | (#15156494)

The rule we use around the shop is what my boss calls the Front Porch Test, which really comes from the pet world. It goes something like this: When naming a pet, imagine yourself standing on your front porch calling loudly for your pet (presumably a dog, as cats come around when they want ;). If you would feel stupid if your neighbor were to hear you yelling the proposed name, then don't pick that name. We apply the same logic to application/system names. Works pretty well for us.

There are exceptions, however. More accurately, we have our inside names and the names we tell our customers. For example, we have one web app that allows our users to search for orders in the system, which they call Order Finder, a nice, generic, informative name. The URI for the app is /dwmo, which reflects our internal name, "Dude, Where's My Order." :)

Nothing beats Lua (4, Informative)

Cthefuture (665326) | about 8 years ago | (#15154524)

for lightness and performance. At least as far as scripting languages go. I can't say I'm a fan of Java but if you insist:

There is Java/Lua integration in the form of JLua [hetland.org] and LuaJava [keplerproject.org]. Possibly other tools as well.

Re:Nothing beats Lua (3, Informative)

Johnso (520335) | about 8 years ago | (#15154614)

Seconded. Lua is the nicest scripting language I've worked with. It embeds beautifully in both Java and .Net.

http://lua-users.org/ [lua-users.org] is your friend.

Re:Nothing beats Lua (1)

belmolis (702863) | about 8 years ago | (#15155528)

The one downside to Lua is that it doesn't have real regular expressions. Of course that only matters for some applications.

Re:Nothing beats Lua (1)

after fallout (732762) | about 8 years ago | (#15156288)

They are close. I suppose you could write a patch to make them pre compliant.

Re:Nothing beats Lua (1)

belmolis (702863) | about 8 years ago | (#15158198)

It depends on what you consider "close". If you list the notation that Lua has, it appears to have most of the constructs that true regular expression packages have. However, it lacks alternation and closure, which are two of the three defining properties of regular expressions. It even appears to have these, but if you look carefully, it turns out that it has them only for singletons, not for arbitrary subexpressions.

I don't doubt that Lua could easily include a real regular expression package, but it doesn't. This was apparently an explicit decision of the developers in order to keep the footprint small.

Re:Nothing beats Lua (1)

angel'o'sphere (80593) | about 8 years ago | (#15158160)


The one downside to Lua is that it doesn't have real regular expressions. Of course that only matters for some applications.


Hm, AFAIK lua has a VERY GOD expresion mathcing system. the WoW client is scripte with Lua and all string matching there are more or less "one liners", not true regexps it seems, but very easy to sue, nevertheless (I did never dig ito it, can only tell from sources I modifeid).

angel'o'sphere

Re:Nothing beats Lua (3, Interesting)

david.given (6740) | about 8 years ago | (#15155684)

for lightness and performance. At least as far as scripting languages go.

*nods*

I never use anything else any more --- it's small (compiling into an 200kB binary with no dependencies on my platform), it's fast (faster than Python!), it's simple (you can easily understand the entire language), it's elegant (closures, coroutines, a superb callout interface...), and it's flexible (there's enough functionality under the surface that you can, e.g., rewrite the OO system to better suit your needs). It's also BSD licensed, which means that there are no legal hurdles to using it in your project; if you play games, you've probably already used Lua without realising it.

I will admit to not being overly enamoured with its syntax --- it uses Pascalish if...then...end style rather than C's if () {} style --- but I can easily live with that.

Testimonial: I wrote a gaim plugin not long ago for the Citadel BBS. It was easier to bolt the Lua engine onto gaim and write the logic in gaim rather than try and figure out how to do it in gaim. Lua's coroutines support allowed me to turn gaim's callback-based API into a callout-based structure, which in turn allowed me to invert all my nasty complex state machines, which made the whole thing an order of magnitude less complex. Good stuff.

Esoteric languages (1)

Seriously, who (969215) | about 8 years ago | (#15154690)

Seriously, who would choose to use this over an existing and popular scripting language? Given than Jython and JRuby exist, and Groovy doesn't offer much that they don't, what is the point other than to be deliberately obscure?

Re:Esoteric languages (1, Informative)

Decaff (42676) | about 8 years ago | (#15154759)

Given than Jython and JRuby exist, and Groovy doesn't offer much that they don't, what is the point other than to be deliberately obscure?

Groovy does offer things they don't, primarily the ability to compile to class files so that Groovy classes can be used from Java classes and vice versa. This also allows Groovy to run at high speed (as the byte code in the class files is optimised at run time).

However, JRuby plans to allows this in the near future as well.

Re:Esoteric languages (1)

mcasaday (562287) | about 8 years ago | (#15154878)

Groovy does offer things they don't, primarily the ability to compile to class files so that Groovy classes can be used from Java classes and vice versa.

Jython has this feature [jython.org].

Below are two bullet points from the linked page:

  • Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
  • Optional static compilation - allows creation of applets, servlets, beans, ...

Re:Esoteric languages (1)

Decaff (42676) | about 8 years ago | (#15154976)

Jython has this feature.

Below are two bullet points from the linked page:

        * Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
        * Optional static compilation - allows creation of applets, servlets, beans, ...


I didn't realise that - this looks powerful, although translating via the production of Java source may not be the best way to get high performance. Some of the other languages on the VM do something similar, and it does not work well in this respect.

Re:Esoteric languages (1)

angel'o'sphere (80593) | about 8 years ago | (#15158182)

Oo ....

First of all Groovy is Java. Neither Ruby nor Jython is that. So it offers far mroe than both the others. Also in my eyes Ruby is obscure and as well Pythons is ;D and both don't support giving avariable a type.

Finally: both use their own libraries (e.g. collections) while Groovy sues the java.util.* classes.

angel'o'sphere

A missing purpose (0)

Anonymous Coward | about 8 years ago | (#15154740)

If I'm going to the trouble of writing a new language, I have to have some motivation. What is it about existing languages that makes it necessary to create a new one. What is it supposed to do differently?

What I got from tfa was something like: "It's a scripting language and it's kinda more like java than the other scripting languages or something like that."

I started to use Python when I was looking for a cross-platform language to replace visual basic/qbasic. There was an article on Slashdot about developers at Sun who found that java didn't work very well in their programming environment. They suggested a couple of alternatives and Python was one. I had considered java but with Python I was much more productive. I wonder if that would be true for Groovy.

My first reaction to what I saw in tfa was: "Oh goodie, it should be fairly easy to write obfuscated code." Not much of a recommendation.

Anyway, if anyone groks why this language was created, I'm curious.

People who like general-purpose languages (1, Flamebait)

Ivan Matveitch (748164) | about 8 years ago | (#15154827)

other than ocaml and ruby are totally insane. I mean, I can code in java or c just fine, but it makes me want to pull my hair out, and all decent normal people must feel the same way.

Re:People who like general-purpose languages (2, Funny)

Slack3r78 (596506) | about 8 years ago | (#15155009)

I can't think of any reason people would choose C [debian.org] or Java [debian.org] over Ruby.

Even other scripting languages like Perl, [debian.org] Lua, [debian.org] or Python [debian.org] would clearly be foolish choices as well.

Seriously, Ruby's a great, well thought-out language, but if you listened to the hype you'd think that there couldn't possibly be anything better for any task at all. The fanboyism that's grown up around the language is starting to become really irritating.

Re:People who like general-purpose languages (1)

geniusj (140174) | about 8 years ago | (#15155225)

I can't tell if you're serious or not. I love Ruby and all and have been using it since early 1.6, but C definitely has its uses. You'll generally get nowhere near C's speed with Ruby, though you can embed it in your ruby app, which is quite handy if you have a small section that needs to be really fast. Either way, you'll end up using C. Execution speed and memory footprint are C's primary advantage, and sometimes they're necessary.

Re:People who like general-purpose languages (1)

Slack3r78 (596506) | about 8 years ago | (#15156584)

That was more or less my point. If you look at the links I provided in my post, they show Ruby being absolutely thrashed as far as performance goes. I've seen it suggested that the 2.0 VM should be much, much faster, which is swell, but for the here and now, the language tends to be slow.

Once again, I've got nothing against Ruby as a language, the passing experience I've had with it showed it to be a fairly elegant, easy-to-use language. That doesn't make it the all-powerful duct tape of the universe that spits out 42 to every problem the fanboys would have you to believe it to be, however.

Groovy Falls Behind True Scripting Languages (1, Interesting)

Anonymous Coward | about 8 years ago | (#15154877)

I've used Java a long time, and when I got tired of the hoopla about how scripting languages are so much better than strongly typed languages, I thought Groovy would be a good choice, since "Groovy is an agile dynamic language for the Java Platform with many features that inspired languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax." So, I set out to develop a small (internal) project, but after a couple weeks I got tired of the clunky syntax (not to mention the sparse documentation) -- I just couldn't express myself. A few months later I came back and reimplemented the project in Ruby in a fraction of the time, much more clearly and concisely. Now I 'get' what scripting languages are all about.

My (anonymous) $0.02: go with the real scripting languages (Perl, Ruby, PHP, Python, etc.).

Am I not getting something? (1)

SpaghettiPattern (609814) | about 8 years ago | (#15155095)

Simply put, Java is a language to write programs and scripts connect programs.

If I want to script from a Java program, I call ascript using Runtime.getRuntime().exec(cmd). The de-facto scripting languages are Bourne shell or Perl. Most scripters can read/maintain these. Only very reluctantly I will write scripts in any other language than these. As a very strict rule, anything I cannot do in Bourne, I do in Perl.

What makes Java very unsuitable for scripting is the absence of a Posix package. Setting ownership and mode of a file is a pain. Don't even think about hard and symbolic llinks, let alone Unix devices.

Re:Am I not getting something? (1)

masklinn (823351) | about 8 years ago | (#15155197)

Issue here is that "scripting" is used very liberally and is misleading.

Here, it is used to label every language that has anything that looks like dynamic typing, which means that Python or Ruby get labelled as "Scripting Language" while they're much closer to general purpose programming languages that allow rapid application developments and have script-type glueability.

While Python or Ruby can be used to (and often are) glue several components, they do shine on larger applications, they're not limited to scripting (Perl isn't either, of course, but it's syntax and random maintainability and readability means that it's much more dangerous, hence much less used for applications).

What so-called JVM scriting languages bring to java isn't "scripting", it's readability and development speed via the sheer expressiveness and power of languages such as Ruby or Python (or even Nice, a very good JVM language even though I'm not sure it can be seen as a JVM scripting language). And the fact that they run on the JVM, compile to bytecode and allow the reuse of Java tools and libs of course.

Hecl (2, Informative)

DavidNWelton (142216) | about 8 years ago | (#15155166)

Hecl: http://www.hecl.org/ [hecl.org]

it is perhaps less general-purpose than the poster might want, but I have different design considerations in mind:

Small, flexible, very dynamic, and concise - in other words, I want it to be a complement to Java, rather than simply a scriptable Java, ala Beanshell. This means that perhaps you wouldn't want to write the entire app in Hecl, but on the other hand, as a language to write quick extensions with, perhaps it's a bit faster/easier to work with.

The most interesting feature at this point is that Hecl is small enough to run on Java-enabled cell phones, even pretty basic ones like my Nokia 3100, which only accepts Java stuff - no symbian. This means that you can code apps with no recompiling, and also make them very dynamic (you could make an app that downloads code, stores it and runs it as needs be).

Also, for the folks who like this stuff, Hecl is still young, so there's lots of room to fiddle with the language itself, and learn about how a scripting language is built [dedasys.com].

Astute observers will note that Hecl is similar to Jacl, but like the poster complaining about Jython getting a little bit out of date... it always seemed like a bit of a losing proposition to me to do a copy of a language in Java, because you miss out, if nothing else, on a *lot* of libraries, and the JRuby/Python/Tcl implementations have always seemed to be playing catch-up.

Ruby/Python + Objective-C (2, Interesting)

JPyObjC Dude (772176) | about 8 years ago | (#15155230)

I have looked at Groovy but it does not seem stable enough to use in enterprise apps. However GNUStep for server side development is very solid platform. Objective-C, the language of GNU Step, is very good at talking with Ruby and Python.

My money is that there will be alot of attention passed to GNUStep in the near future as a condender on server side and even client x-platform side app development.

My Ideal web/app server is Free BSD + GNUStep + Ruby and/or Python.

JsD

SISC Scheme and Scala (2, Informative)

Anonymous Coward | about 8 years ago | (#15155327)

There is a really nice Scheme interpreter on the JVM called SISC:

http://sisc.sourceforge.net/ [sourceforge.net]

IMNSHO Scheme is so much nicer than Python et al that there's not even a decision to be made here as far as dynamic languages on the JVM.

There's also Scala, which is another statically typed language on the JVM. It is SORT of like Java, and can use Java classes natively, but is about 20 times more pleasant to use than Java (if you're into higher-order functions and pattern matching and that kind of thing... but then, everyone should be into that stuff). Anyway, Scala isn't a scripting language, but depending on what you're planning on doing, using it may persuade you that you didn't actually need a scripting language, you just needed a language that wasn't painful to use like Java is.

Scala:
http://scala.epfl.ch/ [scala.epfl.ch]

Re:SISC Scheme and Scala (1)

fm6 (162816) | about 8 years ago | (#15158178)

Scheme is an important language. But it has never been widely used and never will be. Why? No state variables. That is, you can never assign a new value to an existing variable, you can only create new variables.

Of course, that's by design, and there are good reasons to write programs that way. There are all kinds of errors you avoid by not having state variables, especially in concurrent programming. But to most programmers the concept is profoundly counterintuitive.

Why bother (flamebait +1fp) (0, Flamebait)

jschmerge (228731) | about 8 years ago | (#15155367)

With the advent of Java, a lot of young programmers finally saw a way of running their OS-specific programs on other platforms. Unfortunately, the limitation was that a Java VM had to be ported to the platform that they wanted to run their code upon. This Java VM was written in C or C++. Sadly, the distraught Java programmer could not contribute to the effort to port the Java VM to their favorite platforom because they did not understand the intricacies of such things as memory management. Thus, their code did not run on their favorite platform.

These programmers, being passionate about their art, resolved to learn the skillz they needed to port the Java VM to their favorite platform. As they learned the necessary knowledge to run their code, realized that they could have gotten their code to run on any platform much more easily if they wrote it in a compiled-to-machine-code language. These programmers are no longer Java programmers.

Why write code in a scripting language that runs on fewer platforms than other scripting languages? The main advantage of a scripting language is (arguably) the ability to run your code on multiple platforms. A scripting language should be ubiquitous; tying your code to both a compiler that some guy created and the Java VM is not a good idea(tm).

Nice (1)

arevos (659374) | about 8 years ago | (#15155420)

Nice [sourceforge.net] is another JVM-based language that could do with a mention. It puts more emphasis on programming correctness than Groovy, including features such as pre-conditions and post-conditions and safety from NullPointerExceptions. According to the Computer Language shootout, it compares favourably to Java [debian.org] in terms of speed and efficiency, whilst Groovy [debian.org] somehow manages to be several hundred times slower in places.

Re:Nice (1)

jaguarul (779396) | about 8 years ago | (#15155763)

Scala [scala.epfl.ch] is a language that targets the JVM and nicely fuses the object-oriented and functional programming paradigms. It is statically typed, has closures, a powerful collections library, integrates perfectly with Java (all Java classes can be imported 'as-is' in your program), pattern matching, and much more. See also the discussion on Lambda the Ultimate [lambda-the-ultimate.org].

Re:Nice (1)

arevos (659374) | about 8 years ago | (#15155788)

I believe Scala has been mentioned in an earlier thread, which is why I didn't draw attention to it in my post. Scala has a lot of interesting features that Nice doesn't have, but Nice still some advantages to it's name.

Nice is a little faster, more lightweight, and deviates less from Java than Scala, making it a hell of a lot easier to get to grips with. Like Scala, Nice supports closures, is statically typed, and integrates perfectly with Java (as do most JVM-based languages). It's been a while since I touched Scala, but IIRC Scala doesn't have the same null-safety Nice has, and I'm fairly sure Scala can't add methods to existing classes, whereas Nice can. Feel free to correct me on the latter point.

Re:Nice (1)

jaguarul (779396) | about 8 years ago | (#15156115)

Yeah, now I see it was mentioned before, I didn't see that when I posted..

Unfortunately, I didn't use Nice so far, so I can't comment on speed. However, I can't say Scala code was too slow, except maybe for the compiler :-). Although Scala has no 'nullable' types as Nice, they can be emulated using the Option class (heavily used in the library). For the latter point, indeed, Scala can not inject methods into existing classes, but up to a point, they can be achieved using views [scala.epfl.ch].

An interesting comparison between Nice and Scala can be found here [sourceforge.net] although it might be out of date (it considers Scala 1.0, while Scala 2.1 has been released recently).

Re:Nice (1)

arevos (659374) | about 8 years ago | (#15157314)

Scala seems more actively developed than Nice, which is inching its way to 1.0 extremely slowly. Scala also seems to support more features, and appears quite a bit more complex (which can be a good thing). The Haskell of JVM-based languages, as it were ;)

Sometime I really have to get around to writing some code in Scala, but currently I'm finding my attention diverted by dynamically typed language. Alas, my spare time to investigate new computer languages is quite reduced these days.

As for speed, I should clarify my statement. Scala is slightly slower than Nice, it would appear, but not by any particularly large amount, at least according to the Computer Language Shootout. Compare this to Groovy, which is one or two orders of magnitude slower than both Nice and Ruby - ouch!

Still, I should talk - compared to Java, my current language of choice, Python, seems quite sluggish in places.

Is this usefull ? (0)

Anonymous Coward | about 8 years ago | (#15155585)

Not to flame, but why would _anyone_ in their right mind try to run a script inside java, of all things ! To my mind, if I want to be absurd, I would say this doesn't go far enough; why doesn't anyone invent a machine virtualisation layer inside said scripting language ? But all absurdity aside - I know java isn't up to scratch; it's a young language and its libraries aren't standardised, all-encompassing as they should be, and as they are in C or perl. But to get over this limitation by implementing a scripting language inside it is a bit rich; what, do you people _eat_ cpu-cycles for lunch or something ? Why isn't the time invested in producing said scripting language not instead invested in writing usefull libraries ? This just sounds like another tech that's written because you guys didn't stop to think whether you should, you only though that you could.

Re:Is this usefull ? (0)

Anonymous Coward | about 8 years ago | (#15155629)

I think it's all Sun's fault; API's (and the whole intended purpose of java) have changed so much over the short years of java's existence, that 'library' is now a dirty word in java circles. We rather use 'patterns' to write 'frameworks', inventing lots of meta-languages and sub-languages on the way, all in the name of cross-platform-ness, all the while limiting your ability to get things done. Sun should get off its high horse, differentiate their libraries accross platforms (so that you can actually get things done), and start calling code for multiple uses libraries again (so the java types can communicate with the rest of the world again). The chances of that happening ? Ha ! If there's one thing that Sun's shown itself to be good at, it's java evangelism. I once got rejected for a job offer by a java shop because I had the audacity to mention perl, even though I'm a java programmer (but not a religious nut) since jdk 1.0.7. The fanboys will scream bloody murder before you can take the frameworks and the bean-scripting lanugages out of their hands, even when you show them that things can be done in a much simpler way. In other words, it won't.

Re:Is this usefull ? (1)

jonabbey (2498) | about 8 years ago | (#15157421)

Because you may implement a framework of object functionality in Java, but then want to allow developers to write scripts to drive your framework.

QED

At first, it seemed perfect (1, Funny)

cerberusss (660701) | about 8 years ago | (#15155645)

At first, it seemed perfect for an enterprise-level project that we were doing. We coded a small main() in Java and then continued to code up the app in Groovy.

After a few months we were at abt. 85% done and then the shit hit the fan. I walked into the development room and then I heard this strange computer voice saying:

"Who the fuck are you?"
And I said, "I'm Cerberusss, and who the fuck are YOU?"
Computer: "I'll tell you who the fuck I am. I'm GroOOOOovy! Punch the green button!!"

At that point, I was shitting in my pants so I walked to my terminal and said: "OK, I'm punching the green button!" but instead, I punched the RED button.

The strange computer voice: "NooOOOOoooo You shouldn't!... have TOUched... the red.... buttonnnnn...."

Needless to say, I never went back to Groovy.

bash (1)

sentientbrendan (316150) | about 8 years ago | (#15155732)

I wouldn't get too caught up in learning every dinky scripting language out there.. if you want to invest time learning a new language learn a primary language.. maybe a cool one like Haskel or Ocaml.

The ultimate "scripting" language is of course.. bash... or zsh. As long as you don't need to do too much math, you can do fairly complicated things in bash and do it *fast* by virtue of the fact that everything you do just launches a native binary, usually written in c, that's specialized for performing whatever task you are doing. Shell scripts also make it easy to do some parallelism via pipes.

Also, just launching the environment for a lot of other interpreted languages (java esp) takes longer than many bash scripts run.

Of course bash is oriented towards handling text files and has lots of limitations outside of that field (basic math operations require launching bc and storing results as strings in environment variables) but if you primarily do text manipulation, you can probably do it pretty darn fast and easy with bash.

Re:bash (1)

L'homme de Fromage (838405) | about 8 years ago | (#15157079)

I like bash a lot, but I think KornShell [kornshell.org] is better. It can do basically everything bash can do and then some. For example, the current version (ksh93) supports floating-point arithmetic. So it can perform all the math operations that bash can't do, without having to call external programs like bc. You can get ksh93 for Linux, and it's already on most commercial UNIX systems (as /usr/dt/bin/dtksh on systems that have CDE installed).

Re:bash (0)

Anonymous Coward | about 8 years ago | (#15158336)

Of course bash is oriented towards handling text files and has lots of limitations outside of that field (basic math operations require launching bc and storing results as strings in environment variables)

Bash does have the $(( expression )) [gnu.org] syntax for basic math operations [gnu.org]. It doesn't do floating point though.

Rhino / ecmascript. (2, Informative)

gedhrel (241953) | about 8 years ago | (#15157417)

I've used the rhino implementation of javascript as the basis for a scripting engine in a number of projects now. Javascript is lightweight, supports many useful idioms, and with rhino, integrates well with existing apps. Exposing your APIs to a scripting layer is pretty simple.

What particularly attracted me to rhino (apart from being a bit of a js nut) was the security model. That is to say, it has one, and it's pretty well worked out. It's typically nontrivial to add sandboxed scripting support to an application that integrates with the application's model of user permissions*: if you look around, you'll find lots of examples of various scripting languages being plumbed into applications, but typically the scripting layer is available to "admins only" due to these kinds of security concerns.

* even in java, which already has a semi-decent security model**

** It's a lot of work getting security providers to stack properly. Layering application-domain runtime security over an application running inside a container with its own security provider is barely doable.

Groovy is cool but ... (1)

angel'o'sphere (80593) | about 8 years ago | (#15157460)

If you do Java, Groovy and BeanShell (or DynamicJava) are the two scripting languages of your choice.

Main reason: the syntax and the class library of both scriptiing languages is: Java. Further more both languages allow you to type your variables (but as in most scripting languages types are optional, while Jython is always typeless --- and besides the wiered syntax of python, the main reason I don't use it: its variables are dynamic typed)

Groovy has disadvantages however. When groovy was "young" it was a very cool language. But then they descided to put up a JSR. During that they changed the syntax for lots of constructs, and not to the good but to the bad imho, now I don't really like it anymore as the reading of source code hurts my eyes, bah!

However for ppl who are not somewhat familiar to the old syntax Groovy might be perfect for you, so give it a try!

angel'o'sphere

Java perl php etc (1)

chrisranjana.com (630682) | about 8 years ago | (#15158188)

With the advent of each new scripting language the old ones seems to go to dust Take for example perl Perl is such a powerful language indeed but now it has taken a backseat and Php rules ! If a system can be put in place where new scripting languages like ruby php etc can take advantage of old languages and somehow integrate into them and old languages can still be used. Yes it will be an Utopian world !

SISC and SISCweb (1)

TheRealFoxFire (523782) | about 8 years ago | (#15158851)

For something different, you'll find SISC [sf.net] brings actual new expressability to the Java platform, rather than just scripting the same old stuff. This lets you do radically different things, as demonstrated by SISCweb [sf.net], which allows you to write web applications without dealing with the stateless, page-centric nature of HTTP.

Plus, you'll learn Scheme, which will make you a better programmer.

Speaking from experience (1)

jshickey (969462) | about 8 years ago | (#15159298)

I have been using it on a project for 9 months now it has been great to use. I haven't used Jython but I it's the only scripting language I've seen besides Rexx that defaults to using BigDecimal for numbers. Contrary to what many people write, it's not dead. My experience is that bugs get fixed relatively quickly. The project is definately moving closer to a 1.0 release. Most of the bugs that I've seen have been corner cases that don't affect 99% of what we do. Just my experience.

Everyone overemphasizes the language (4, Insightful)

danpsmith (922127) | about 8 years ago | (#15160205)

A language doesn't have to be updated every 20 seconds to be good. If you started off working in JPython, I don't understand why you would switch it out for a less supported, and less developed language. Python has been kicking around for a while, enough time that they got most of the major kinks out long ago, so I don't think "falling behind in the development cycle" is as crucial as you might think it is. Why not stay with what works unless you specifically REQUIRE the new version's functionality? People are too quick to be trendy with languages...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...