Slashdot Mirror


Your Thoughts on the Groovy Scripting Language?

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?"

128 comments

  1. My opinion by Anonymous Coward · · Score: 0, Funny

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

  2. Jython and CPython by CRCulver · · Score: 4, Insightful

    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 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.

    1. Re:Jython and CPython by RovingSlug · · Score: 2, Informative

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

    2. Re:Jython and CPython by bwt · · Score: 3, Informative

      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.

    3. Re:Jython and CPython by jma05 · · Score: 1

      Actually I saw *NO* advantages with Groovy other than a more familiar syntax for Java programmers.

      None of those limitations you state are real.

      1.) Jython compiles to Java byte code just like Groovy (jythonc is the compiler included with Jython).
      2.) Jython supplies it's own class library based on CPython that can be used from Java (after you compile to byte code since they are written in Python).

      Jython may lag behind CPython but it is great port of a battle tested language and I doubt it lacks any features compared to Groovy.

  3. Have you tried ColdFusion? by Anonymous Coward · · Score: 1, Funny

    Seriously... it runs on top of Java.

  4. Ruby by Anml4ixoye · · Score: 1, Informative

    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)

    1. Re:Ruby by Anonymous Coward · · Score: 0

      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?

    2. Re:Ruby by Anml4ixoye · · Score: 1

      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.

    3. Re:Ruby by shutdown+-p+now · · Score: 1
      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).
    4. Re:Ruby by Anonymous Coward · · Score: 0
      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.

    5. Re:Ruby by RegularFry · · Score: 1

      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 :-)

      --
      Reality is the ultimate Rorschach.
    6. Re:Ruby by Samus · · Score: 1

      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.

      --
      In Republican America phones tap you.
    7. Re:Ruby by jovlinger · · Score: 1

      And here I was thinking that IronPython was chugging along very well; last I heard it was faster than CPython.

    8. Re:Ruby by Samus · · Score: 1

      I haven't looked at it recently but I do believe that there are at least some 1.0 betas out if not an RC. However you won't find it on the 1.x framework only 2.x. I think some changes were made to 2.x to work better with dynamic languages (the whole point of Hueggins going to work at MS) and that implementing them on 1.x is just too difficult. I've looked at how Jython implements the dynamic typing and if the IronPython way is similar you won't get near the performance of an object written in C#. That's just the price you pay for the dynamicness I guess.

      --
      In Republican America phones tap you.
  5. Bean Shell Script by Elias+Ross · · Score: 5, Informative

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

    If you want to do embedded scripting in Java, I suggest Bean Shell 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.

    1. Re:Bean Shell Script by Will+Sargent · · Score: 4, Informative

      Also see Mike Spille's criticism.

    2. Re:Bean Shell Script by gz718 · · Score: 1

      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.

    3. Re:Bean Shell Script by L'homme+de+Fromage · · Score: 0

      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.

    4. Re:Bean Shell Script by bwt · · Score: 1

      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.

    5. Re:Bean Shell Script by angel'o'sphere · · Score: 1


        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

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:Bean Shell Script by fm6 · · Score: 1
      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.
    7. Re:Bean Shell Script by Anonymous Coward · · Score: 0

      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.

    8. Re:Bean Shell Script by Anonymous Coward · · Score: 0

      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.

    9. Re:Bean Shell Script by Anonymous Coward · · Score: 0

      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.

    10. Re:Bean Shell Script by Anonymous Coward · · Score: 0

      +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.

    11. Re:Bean Shell Script by bwt · · Score: 1


      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.

    12. Re:Bean Shell Script by blackdrag · · Score: 1

      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!

    13. Re:Bean Shell Script by Anonymous Coward · · Score: 0

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

    14. Re:Bean Shell Script by angel'o'sphere · · Score: 1


      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.


      Yes, it is!

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    15. Re:Bean Shell Script by Anonymous Coward · · Score: 0

      > What are you basing that on? You own opinion of how long it "should" take to create a new language?

      Compared to dozens of other perfectly working languages, yes. His opinion is most likely an informed one.

      "It's beta" should not be a synonym for "It's broken".

    16. Re:Bean Shell Script by MemoryDragon · · Score: 1

      Yea sure, recommending beanshell over groovy? Is this a joke? Groovy is not perfect, it is in its infancy yet, but it already beats Beanshell by miles and the language and community is very active.

  6. Flavor of the Month by MyLongNickName · · Score: 0, Troll

    n/t

    --
    See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
  7. Why? by zaguar · · Score: 4, Insightful

    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?

    --
    "Sure there's porn and piracy on the Web but there's probably a downside too."
  8. Stop the groovy naming by AubieTurtle · · Score: 2, Insightful

    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.

    1. Re:Stop the groovy naming by Anonymous Coward · · Score: 5, Funny

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

    2. Re:Stop the groovy naming by blueZhift · · Score: 1

      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.

    3. Re:Stop the groovy naming by Anonymous Coward · · Score: 0

      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.

    4. Re:Stop the groovy naming by jasondlee · · Score: 2, Informative

      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." :)

      --
      jason
      Have a good day?! Impossible! I'm at work!
    5. Re:Stop the groovy naming by The+Wicked+Priest · · Score: 1

      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.

      --
      Share and Enjoy: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    6. Re:Stop the groovy naming by brix · · Score: 1

      OT, but the truth seems to be far stranger than the fiction in this case.

  9. Nothing beats Lua by Cthefuture · · Score: 4, Informative

    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 and LuaJava. Possibly other tools as well.

    --
    The ratio of people to cake is too big
    1. Re:Nothing beats Lua by Johnso · · Score: 3, Informative
      Seconded. Lua is the nicest scripting language I've worked with. It embeds beautifully in both Java and .Net.

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

      --
      I'm a signature virus. Please copy me to your signature so I can replicate.
    2. Re:Nothing beats Lua by belmolis · · Score: 1

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

    3. Re:Nothing beats Lua by david.given · · Score: 3, Interesting
      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.

    4. Re:Nothing beats Lua by after+fallout · · Score: 1

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

    5. Re:Nothing beats Lua by angel'o'sphere · · Score: 1


      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

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:Nothing beats Lua by belmolis · · Score: 1

      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.

    7. Re:Nothing beats Lua by nuzak · · Score: 1

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

      Lua also has no integers. All numbers are floating point. Float imprecision scares the hell out of me, I just know I'm going to end up comparing 5 to 5.00000000001 because of it.

      The implementation of tables as both numerically indexed and associative arrays is a real weird piece of work worthy of Perl's SV/IV/AV/HV gobbledygook. Well, more readable anyway. Not sure how it optimizes the integer key case in the face of its lack of integers, but it does.

      It still is quite clever and fast though. Its virtual machine is truly elegant and beautiful.

      --
      Done with slashdot, done with nerds, getting a life.
    8. Re:Nothing beats Lua by Anonymous Coward · · Score: 0

      Lua also has no integers. All numbers are floating point.
      iirc Lua can be built to use integers (but then there are no floats).

    9. Re:Nothing beats Lua by corysama · · Score: 1

      The standard configuration for Lua uses 64-bit double precision floats for numbers. If you look in to how the format works you'll see that doubles can exactly represent a wider range of integers than standard 32-bit ints.

      If you stick to addition, subtraction and multiplication, integer math will stay quite integer using doubles. Divides will result in reals, but you can floor(x/y) if you need to.

  10. uhhh by PeelBoy · · Score: 1

    it's groovy?

  11. Esoteric languages by Seriously,+who · · Score: 0

    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?

    1. Re:Esoteric languages by Decaff · · Score: 1, Informative

      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.

    2. Re:Esoteric languages by mcasaday · · Score: 1
      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.

      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, ...
    3. Re:Esoteric languages by Decaff · · Score: 1

      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.

    4. Re:Esoteric languages by angel'o'sphere · · Score: 1

      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

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    5. Re:Esoteric languages by jma05 · · Score: 1

      >> although translating via the production of Java source may not be the best way to get high performance.

      Why? Do you have a better approach in mind?

      Java source generation is seen only in static compilation. No source is generated while the interpreter is run.

    6. Re:Esoteric languages by Decaff · · Score: 1

      >> although translating via the production of Java source may not be the best way to get high performance.

      Why? Do you have a better approach in mind?

      Java source generation is seen only in static compilation. No source is generated while the interpreter is run.


      Yes, there is a far better approach - statically compile directly to optimised bytecode. I believe this is what the JRuby people are planning to do.

    7. Re:Esoteric languages by loqi · · Score: 1

      Also in my eyes Ruby is obscure and as well Pythons is ;D and both don't support giving avariable a type.

      Eh? Type is pretty fundamental to variables in both languages. I'd like to see a case of a variable in either one not having a type.

      I assume you mean there's no syntax built directly into the language to perform type checking. I see it more as the language doesn't force me to type-check every single variable I use in a program. Static code analysis is a continuum, I could just as easily accuse Java of "not supporting" the code checks Jlint could provide at compile-time.

      --
      If other reasons we do lack, we swear no one will die when we attack
    8. Re:Esoteric languages by angel'o'sphere · · Score: 1


      I assume you mean there's no syntax built directly in ...


      You assumew correct. As I wrote: giving avariable a type. I wrote giving, not having.

      The article is about why is groovy a good scripting language for Java ... my answer is: its similar to Java, e.g. you can declare the type of a varibale. People like *I* want that.

      I know that Python variables have a type .... as long as they are not null, however. Your comment is completely out of scope of my comment and the whoe thread ;D

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    9. Re:Esoteric languages by loqi · · Score: 1
      As I wrote: giving a variable a type. I wrote giving, not having.

      You're not really giving variables types in Java, either, their type is intrinsic upon construction. All you're doing is constraining what variables a reference may point to at compile-time.

      I'm being nitpicky because this terminology gets thrown around a lot when talking about static vs. dynamic languages, and it's too imprecise to capture the details of the differences. The difference between Groovy and Python is that Groovy supports static type-checking.

      I know that Python variables have a type .... as long as they are not null

      Actually, that's a Java idiosyncrasy. Observe:
      >>> x = None
      >>> type(x)
      <type 'NoneType'>

      Your comment is completely out of scope of my comment and the whoe thread ;D

      My comment was nitpicky and pedantic (this one doubly so), but correcting something I perceive to be a misinterpretation isn't out of the scope of your comment.
      --
      If other reasons we do lack, we swear no one will die when we attack
  12. YASL by ajw1976 · · Score: 0, Redundant

    YASL

    --
    1. Bad signature
    2. ?????
    3. Profit
  13. A missing purpose by Anonymous Coward · · Score: 0

    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.

  14. If You Enjoy Scheme.. by swdunlop · · Score: 2, Informative

    There is JScheme, and Kawa.

    1. Re:If You Enjoy Scheme.. by Anonymous Coward · · Score: 1, Informative

      Or, how about trying SISC?

    2. Re:If You Enjoy Scheme.. by aminorex · · Score: 1

      And SISC. SISC is actually a living project. I wish the best virtues of the three could be merged. In an Eclipse environment, this would be the most productive of all possible programming worlds.

      --
      -I like my women like I like my tea: green-
  15. People who like general-purpose languages by Ivan+Matveitch · · Score: 1, Flamebait

    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.

    1. Re:People who like general-purpose languages by Slack3r78 · · Score: 2, Funny

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

      Even other scripting languages like Perl, Lua, or Python 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.

    2. Re:People who like general-purpose languages by geniusj · · Score: 1

      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.

    3. Re:People who like general-purpose languages by Slack3r78 · · Score: 1

      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.

    4. Re:People who like general-purpose languages by srussell · · Score: 2, Interesting
      I can't think of any reason people would choose C or Java over Ruby.
      I can.

      Mind you, I'm do a lot of Ruby coding, and I love the language. However:

      1. It is not fast. The speed difference shows up in non-trivial applications, or when processing large amounts of data.
      2. It has no support for compile-time type checking. It doesn't have to be strongly typed, but for non-trivial applications, type checking is a big help.
      3. It is interpreted, and so has a loose binding to runtime dependencies. This is a huge problem if you're writing applications that you want to distribute, or expect to have running for long periods of time. I can write an app in C and statically compile it, and odds are good that it'll still run four, five years from now. Odds are equally good that something in Ruby is going to change within the two or three years that will break existing applications. Proof of this are the running problems with YAML in Ruby. Heck, I've caused similar regressions in the Ruby standard XML parser on occasion.

      Again, I love Ruby. I'd rather code in Ruby than Java or C. I'm more productive in Ruby; it is a better language than C or Java. However, I'm really nervous about using it for any large (code-base) project.

      --- SER

    5. Re:People who like general-purpose languages by Slack3r78 · · Score: 1

      Read my post again, and, specifically, look at the links. They show Ruby being trashed in the performance deparment, though a lot of Ruby appologists will tell you that those benchmarks somehow "aren't really applicable to Ruby." Basically, I pretty much agree with you on all fronts. :-)

        It's a good language, but it certainly has its weaknesses, not the least of which are performance or the lack of a good UI toolkit.

    6. Re:People who like general-purpose languages by srussell · · Score: 1
      Basically, I pretty much agree with you on all fronts. :-)
      My choice of word emphasis was misleading. I wasn't implying that you though Ruby was fast; I was emphasizing that Ruby isn't fast. It looked, in my post, like I was contradicting you, when I wasn't. Sorry. :-)

      It's a good language, but it certainly has its weaknesses, not the least of which are performance or the lack of a good UI toolkit.
      I like the Qt bindings. They're pretty easy to use, and it provides a look-and-feel that integrates well with my desktop.

      I'm not convinced that the lack of a good UI toolkit is a Ruby problem, per-se, as much as it is the lack of a good cross-platform toolkit. Creating a good cross-platform UI may be an unsolvable problem. Certainly, a lot of really smart, good programmers have been working on the problem for years, and there are a lot of really decent cross-platform libraries that fail to deliver what users really want: good integration with their desktops.

      Application developers often make, what I believe, is a fundamental false assumption: they believe that users want the application to look the same on whatever platform they're running it on. I believe that people want an application to look and behave like every other application they're used to, and they want it to share data with other applications that they're using.

      We don't need a UI that looks consistent no matter which platform you run it on; we need a really good, cross-platform, well-integrated data transfer mechanism, that adopts the style of whatever platform you're running it on. I'm not sure that this is achievable, but I hope it is, and any such solution would accomplish two main goals:

      1. It would be high level and not attached to any specific toolkit. It would therefore have back-ends for/on each platform on which it ran.
      2. It would allow developers to easily define different UIs for each platform. Windows paradigms do not translate well to OSX -- you pretty much have to re-design the UI.
      3. It would use native key bindings for common actions. Cut/copy/paste must be bound to whatever is most common for the target platform.
      4. It would adopt whatever application data transfer mechanism is used by the underlying system

      It may be that the second point would be sufficient to avoid the troubles that plagued AWT, but maybe not. I don't know -- as I said, smarter people than I have worked on this problem, and have yet to succeed. However, I am fairly convinced that the problem isn't particular to Ruby. I've yet to see any language that has a satisfactory cross-platform GUI, so the next best thing is to really enforce MVC separation and write a different UI for each platform. For myself, I write apps for myself, so I use Ruby's Qt bindings. It is about as good as I can get.

      --- SER

  16. Groovy Falls Behind True Scripting Languages by Anonymous Coward · · Score: 1, Interesting

    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.).

  17. Am I not getting something? by SpaghettiPattern · · Score: 1

    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.

    --

    I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
    1. Re:Am I not getting something? by masklinn · · Score: 1

      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.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  18. I use Sleep by HvitRavn · · Score: 1

    I use Sleep, a perl-like scripting language for java which is extremely easy (and fun) to embed and extend.

    1. Re:I use Sleep by after+fallout · · Score: 1

      Thats kinda neat.

  19. Hecl by DavidNWelton · · Score: 2, Informative

    Hecl: http://www.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.

    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.

  20. Ruby/Python + Objective-C by JPyObjC+Dude · · Score: 2, Interesting

    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

  21. Java had generics before C# by SuperKendall · · Score: 2, Informative

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  22. SISC Scheme and Scala by Anonymous Coward · · Score: 2, Informative

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

    http://sisc.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/

    1. Re:SISC Scheme and Scala by fm6 · · Score: 1
      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.

    2. Re:SISC Scheme and Scala by TheRealFoxFire · · Score: 1


      Not true:



      (let ([x 3])
          (set! x 4)
          x)
      => 4

    3. Re:SISC Scheme and Scala by Anonymous Coward · · Score: 0
    4. Re:SISC Scheme and Scala by aminorex · · Score: 1

      Very, very not true.
      There are things that turn people off from Scheme, but that's not one.

      Allergy to parentheses is one. That's a fault of the user.

      Lack of a consensus on portable interfaces for things outside the Scheme world is another. That's a fault of the Scheme community.

      --
      -I like my women like I like my tea: green-
  23. Groovy seems to be dead by peter_p_s · · Score: 1

    I am wondering if Groovy is not dead. For example see this:
    http://jira.codehaus.org/browse/GROOVY-1194

    This bug is pretty serious and it was filed 4 months ago. No reaction so far.

  24. Why bother (flamebait +1fp) by jschmerge · · Score: 0, Flamebait

    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).

  25. Nice by arevos · · Score: 1

    Nice 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 in terms of speed and efficiency, whilst Groovy somehow manages to be several hundred times slower in places.

    1. Re:Nice by jaguarul · · Score: 1

      Scala 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.

    2. Re:Nice by arevos · · Score: 1

      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.

    3. Re:Nice by jaguarul · · Score: 1
      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.

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

    4. Re:Nice by arevos · · Score: 1

      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.

  26. Judo? by Raypeso · · Score: 1

    We use judoscript at work. It lets us call java classes from a scripting language.

  27. Is this usefull ? by Anonymous Coward · · Score: 0

    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.

    1. Re:Is this usefull ? by Anonymous Coward · · Score: 0

      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.

    2. Re:Is this usefull ? by jonabbey · · Score: 1

      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

  28. At first, it seemed perfect by cerberusss · · Score: 1, Funny
    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.

    --
    8 of 13 people found this answer helpful. Did you?
    1. Re:At first, it seemed perfect by ryarger · · Score: 1

      Let's all say it together: "Slashdot and LSD just don't mix."

  29. bash by sentientbrendan · · Score: 1

    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.

    1. Re:bash by L'homme+de+Fromage · · Score: 0

      I like bash a lot, but I think KornShell 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).

    2. Re:bash by Anonymous Coward · · Score: 0

      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 )) syntax for basic math operations. It doesn't do floating point though.

  30. Java doesn't need a map function by brunes69 · · Score: 1

    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.

    1. Re:Java doesn't need a map function by Anonymous Coward · · Score: 1, Informative
      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
    2. Re:Java doesn't need a map function by Anonymous Coward · · Score: 1, Informative
      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.
    3. Re:Java doesn't need a map function by angel'o'sphere · · Score: 1


          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

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    4. Re:Java doesn't need a map function by Anonymous Coward · · Score: 0

      Try using Java5.

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

    5. Re:Java doesn't need a map function by bkeeler · · Score: 1
      Congratulations on completely missing the point of map.

      Your perl example didn't modify @arr; in fact it did nothing at all. Try something like:

      @arr2 = map { $_ * 2 } @arr;
      Where map really starts to shine in applications like the Schwartzian Transform.
    6. Re:Java doesn't need a map function by angel'o'sphere · · Score: 1

      Probably you should have read my post mroe carefully.

      I tried this with int and Integer as type for the variable arr, in all except Java 5 (.5) using an Integer would have given compiler errors.

      As several posters pointed out: the original code generates interims helper objects, which are modified, the original array is never changed.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  31. fact clarification by Anonymous Coward · · Score: 1, Informative

    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)

  32. Indent by Vexorian · · Score: 3, Funny

    At least it uses brackets instead of depending on indentation .

    --

    Copyright infringement is "piracy" in the same way DRM is "consumer rape"
  33. Groovy project manager says "don't change" by garvon · · Score: 1

    http://www.pythonthreads.com/news/latest/there-s-n o-compelling-reason-to-choose-groovy-over-jython.. html
    I just saw this yesterday. Guillaume Laforge the project manager for Groovy
    said if you already know python stick with jython if you don't have a reason to change.

  34. Rhino / ecmascript. by gedhrel · · Score: 2, Informative

    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.

  35. Groovy is cool but ... by angel'o'sphere · · Score: 1

    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

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  36. Java perl php etc by chrisranjana.com · · Score: 0

    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 !

    --
    Chris ,
    Php Programmers.
  37. Jacl! by MORTAR_COMBAT! · · Score: 1

    Jacl is a fantastic scripting language for Java:
    http://tcljava.sourceforge.net/docs/website/index. html

    I also enjoy just using Javascript for this kind of thing. See the Rhino project:
    http://www.mozilla.org/rhino/

    --
    MORTAR COMBAT!
  38. SISC and SISCweb by TheRealFoxFire · · Score: 1

    For something different, you'll find SISC 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, 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.

  39. Speaking from experience by jshickey · · Score: 1

    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.

  40. Everyone overemphasizes the language by danpsmith · · Score: 4, Insightful

    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...

    --
    Judges and senates have been bought for gold; Esteem and love were never to be sold.
  41. Groovy is not Java by blackdrag · · Score: 1

    Was there a missing "not"? I mean there are surely Java programs than can be run in Groovy wihtout change, but there are also Ruby programs that can be run in Groovy without change. If you insist on typing then you maybe better use nice or scala. The core of Groovy is dynamic and with that it differs in essential parts to Java. Just because there is a much syntax in common doesn't mean that Groovy is Java

  42. Jpype -- how active, how serious? by Latent+Heat · · Score: 1
    How would you rate jpype in terms of how serious and effort and how active in development and how far along?

    The sense I get is that there is a world of people reconciled to Java, and a world of people who have issues with it and want something else -- see RMS recent and recurring remarks about how Java hurts FOSS everywhere, everytime (or is it that other dude who has issues with Java numeric processing?).

    I don't have to get in on the pissing context of t'is, t'ain't regarding whether to go with the Java or the anything-but-Java camps. On the other the divide is real. What I am wondering is if CPython is more in the anything-but-Java camp culturally, and hence the preference is to have people write Python extension modules in . . . C! I got a sense that jpype and that other thing that preceded it are not active, enthusiastically supported, or very complete.

    On the other hand, if someone comes up with a good JNI bridge, you can use Java extension modules in Python as an option -- Jython is pretty much restricted to Java for extension modules. Hey, there is even a good ActiveX bridge in Python (actually two of them I know about), and ActiveX is as Microsoft-lock-in non-FOSS-friendly as it gets, and people didn't have to hold their noses to do it. But with Java, I get the sense that the enthusiasm is not quite there for a Java bridge.

    1. Re:Jpype -- how active, how serious? by jma05 · · Score: 1

      >> How would you rate jpype in terms of how serious and effort and how active in development and how far along?

      Not that many people need to interface Java with CPython. It's sufficiently functional for those who need it.

      I just don't quite get what your main point of the post is.

      >> see RMS recent and recurring remarks about how Java hurts FOSS everywhere, everytime (or is it that other dude who has issues with Java numeric processing?).

      Sure. Soon as you post a link. I don't follow every remark RMS ("or some other dude") makes.

      >> Jython is pretty much restricted to Java for extension modules

      You state that as if it is Jython's fault :-). Jython *IS* Java. It intefaces with anything Java does.

      Python on the other hand interfaces with EVERYTHING - C/C++/Java/.NET/ActiveX/dll/so

    2. Re:Jpype -- how active, how serious? by Latent+Heat · · Score: 1
      Here's the deal. I am coming from a Windows world and have developed 2-D graphics widgets to display data for a specific problem domain. I have ActiveX versions of those widgets, and the folks most interested in using my graphics widgets are hardcore Matlab people.

      Matlab is actually pretty good about hosting ActiveX widgets if you observe some not-insurmountable restrictions. If I go about supplying ActiveX widgets to people happy to use Matlab under Windows, life is good, but for long term, this is double vendor lock-in. I am beginning to look at alternatives and among them, I am experimenting with Java Swing. Java Swing is actually farthest along in terms of the 2D graphics features and multithreading that I need for the animations of the displays. I have seriously looked at wxPython, and it lacks 2D graphics features I can find in Windows as well as in Swing.

      Matlab for some time has been able to script Java -- either non-visual classes for doing numeric computations or for launching Swing apps in separate windows. Matlab 7 now has a not-yet-well-documented feature to host Java Swing widgets inside Matlab GUI applications.

      If I come out with Java Swing versions of my widgets for use under Matlab as a Java scripting environment, I have broken through the restriction of Windows-only, but then I am locked in to Matlab, which is highly proprietary and costs major bucks but is widely available in academic computing, and I am committed to Java, which is free-as-in-beer but not free-as-in-speech. If I can find another scripting environment such as Jython, CPython, Groovy, whatever, that hosts Swing widgets, that would be really helpful in terms of avoiding lock-in.

      Matlab is unique in being able to host either ActiveX or Java Swing widgets or some mix of the two inside a GUI (a Matlab figure window). CPython can host ActiveX. While Jython looks like it fits the bill as a Matlab alternative to hosting Java Swing, being able to work with ActiveX and Swing at the same time would be helpful to me in a transition period.

      I was thinking-out-loud whether Java bridges were a step-child in the CPython world, in part because there is Jython for people who need seemless Java interoperation and in part because people were looking for a non-Java cross platform deal. No, I am not going to look up the link, it is public knowledge that RMS is trying to persuade people leaving Windows to not get locked in to Java, and there was a thread on Slashdot in the past week discussing that. I wasn't trying to get into the merits of the Java/not Java camps; I was wondering if legitimate Java concerns (and mind you I am not trolling against Java because I am moving in the direction of Java) influenced what was available under CPython.

      For CPython to host ActiveX controls must have been a major level of work. CPython could, I suppose, host Java Swing widgets as well, but someone would need that itch to scratch along with the technical know-how to pull it off. I wish I could get some insight into how Matlab is able to do both ActiveX and Java Swing widgets in the same GUI frame but then Matlab is letting out their trade secrets. Java SWT has an ActiveX bridge, but I haven't gotten into that because if I am going to do Java, I thought I would do Java Swing for its features and greater acceptance. Java Swing once had an ActiveX bridge, but that looks like it is thoroughly orphaned.

      I am not trying to troll here -- I am seriously thinking about alternatives about which way I want to go with my work.

  43. I am looking for a Matlab replacement by Latent+Heat · · Score: 1
    I am not quite sold on the idea of doing everything in a scripting/dynamic language. Try doing real time graphics animations without some supporting primitives (written in extension modules) in one of those languages. On the other hand, Matlab is really popular among engineers and engineering students, and Matlab is pretty much a proprietary scripting language. But Matlab can host ActiveX controls (restricted to Windows) and more recently Java Swing components (platform neutral), which can display themselves in a Matlab figure window and permit interaction with these displays from the Matlab command prompt or from Matlab scripts (M-files).

    To me, the advantage of scripting languages is that you can rapidly assemble applications from highly-functional components, components that aren't written in that scripting language, for legacy reasons or for performance reasons, and then you can interact with that application to do exploratory data analysis (for my work in signal processing) from a command prompt or can write a script to automate more complex analyses.

    I believe I have seen a demo of an application written in Jython that uses Java Swing to produce a graphical scratchpad doodle area to make drawings, and then it has a text window with a Jython command prompt that you can do things to the scratchpad -- change the colors, erase, print, invert the picture, etc. Yes, you could interact with such an application by adding a menu, but the command prompt has access to component classes of the application and their methods to do exploratory analysis, testing, debugging, etc. The idea is that the application is written in Jython -- that way every GUI widget is a Jython object that you can poke at from the command prompt. On the other hand, the widgets themselves are Java Swing widgets -- either standard ones or new ones implemented using Java classes.

    Matlab allows you to do this with ActiveX controls -- so does Python using the PyCrust/PyShell feature of wxPython. Matlab allows you to do this with Java Swing controls -- so does Jython (they tell me). There isn't a free thing that allows me to do both, but my druthers are to look to the future and develop my custom widgets in Java and use a Java/Jython type scripting language. RMS tells us not to do Java, but aside from ActiveX, aside from Java Swing, what out there allows you to develop custom widgets (not standard widgets -- everyone has that) and script them? Mono/.NET? What out there even hosts a .NET control apart from .NET -- Matlab doesn't, Python doesn't.

  44. Pnuts by pnutsman · · Score: 1

    If you are interested in JVM languages, you might as well look at Pnuts. It runs roughly as fast as Lua.