Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Groovy / Scala anyone?
New on LowEndTalk? Please Register and read our Community Rules.

Groovy / Scala anyone?

concerto49concerto49 Member
edited February 2013 in General

Anyone do Groovy and/or Scala development here?

How does it compare to Java? I mainly do Java development and interested to look at the two as alternatives for quick scripting needs. Performance isn't as much of an issue.

JVM languages mean minor changes are required for production deployment, which is nice.

Comments

  • wlanboywlanboy Member
    edited February 2013

    Some years ago I asked quite the same question on work. I was on the search for some glue to test my Java libs faster. And yes "testing" is always the easiest step to introduce some new technology/programming language to your daily job.
    Noone wants to write tests, noone cares about how tests are done (two important reasons for failure) so if someone is making the offer "I will do the tests, if I am allowed to play with [xyz]", he gets the approvment.
    The first weeks with Groovy are cool. It is so much easier to write code. It is easier to test your interfaces. Basically to easy.
    And this is the worst problem groovy has. You do not need any brackets, dots and you can access things (reflection) you cannot do within an strict JEE environment.
    Looking to the code after a view weeks is often a shock. It is not maintainable.
    E.g. this line of code:
    take 2 bottles of water after 5 hours
    Same as:
    take(2).bottles(of).water (after).5(hours)
    You do not need much brackets, punctation, etc. So you do not use it. So you are guessing if how many parameters the method (or object?) "take" needs.
    And often your code is working because Groovy is finding some classes or methods that are matching. Even if you do not intend to use them at all.
    Forget the compiler. Groovy errors are happening on runtime. You cannot find out whats wrong? Look at your runtime libs. If they are not on the same versions as your local environment you will run into a lot of problems (funny guys adding new parameters).
    E.g. Jboss classloader vs local classloader.
    And that is one thing that is really annoying. Groovy is deciding on runtime what you might wanted to call.

    If I am looking to Java6/7 my personal impression is that (context &) dependency injections (used in the right way) does it's "glue job" better than groovy. With the advantage that the compiler is checking all annotations for you.
    Basically because CDI was developed to solve problems while groovy was developed to ease the ... well ... the typing?

    Hard words, but you do not want to maintain essential (for survival) code written in groovy on your daily job.

    I cannot say a lot about Scala - I only played with it - no project scope. It's functional approach is cool - functions are part of the language itself. Therefore you can easily extend the language. Perfect for building libs and to use recursion. Additionally there are no statics, no difference between int and java.lang.Integer (everything is an object). Everything needed to build libs. Like the fantastic concurrency library of Scala.
    But back to the topic "functional". What does this have todo with libs?
    Look to this code:
    val numberlist = List (1, 2, 3, 4, -5)
    numbers.foreach (i => println ("element of numberlist: " + i))
    This is all about the magic of Scala, how its concurrency is working so good. You can extend methods because they are accepting functions as parameters too.
    So no more overriding but extending functions (building libs).
    Or things like that:
    numberlist.count (i => i > 0).
    If I only think what I have to do to look through a list (iterator, nullpointer checks) to count every element which is greater than zero. Or look to map:
    numberlist.map (i => i + 1)
    Just add one to every element.
    Every function has an return value. So every single function can run in parallel. All things that destroy this (statics, primitives, ...) are not part of the language.

    If you think about the intention of Scala - what a flash of wit.

    Most of the time you do not want to change a function as a whole, but you want to change the way it alters values. Programming with this guidline leeds to separation of concern and context. And if you do not use abbreviations you get concurrency for free.

    Only missing thing: A project to use Scala at work.

  • @wlanboy said: If you think about the intention of Scala - what a flash of wit.

    Can't Groovy also do what you described for Scala? Pretty sure it has Lambda etc too.

    Java 8 also will feature it. However, issue is it's a lot more verbose than Scala/Groovy.

    @wlanboy said: And often your code is working because Groovy is finding some classes or methods that are matching. Even if you do not intend to use them at all.

    Forget the compiler. Groovy errors are happening on runtime. You cannot find out whats wrong? Look at your runtime libs. If they are not on the same versions as your local environment you will run into a lot of problems (funny guys adding new parameters).
    E.g. Jboss classloader vs local classloader.

    Interesting point here. Classloader issues are always a pain. A huge one.

    I was considering using Groovy for test cases, installers and some not as critical pieces of code, but hm.

  • wlanboywlanboy Member
    edited February 2013

    @concerto49 of course. Because Groovy sits on top of Java. You can even use Scala with it. Even if the Java->Scala way is not that stylish than Scala -> Java.

    Coding with Groovy is cool. But handling Groovy code is bad.
    That is may main concern.

    • Debugging -> You debug more Groovy code than your code (heavy filter list)
    • PermGenSpace -> Class definitions, etc go directly to the Perm. And Groovy (Grails even worser) constantly regenerating classes.
    • Too much "dynamic": If you look to Grails you see -> enhancements of Class -> regerneration of class -> recompile of class -> reloading class. That is the way the controllers are working.

    Groovy is cool as long as you do not look "under the hood" to see how that geeky magic is done.

    Not talking about backward compatibility of groovy libs.

    If you are looking for good installers:

    And if you are looking for something beyond junit:

  • @wlanboy said: - PermGenSpace -> Class definitions, etc go directly to the Perm. And Groovy (Grails even worser) constantly regenerating classes.

    Don't talk to me about Grails :) - even Hibernate/Spring annoys the heck out of me. It's all too bloated, but you have a point. Permgen might be an issue.

    @wlanboy said: If you are looking for good installers:

    Oh it's a web application and not that type of installer. I mean as in e.g. you start it up for the first time and getting users to do configurations, e.g. connect to a database or restore from backup type of installers.

    @wlanboy said: And if you are looking for something beyond junit:

    Just trying to be lazy. The main point of being a programmer is to reduce future workload. Doing more now (writing great software) to reduce the amount of work int he future.

    @wlanboy said: - Debugging -> You debug more Groovy code than your code (heavy filter list)

    Probably going to get shouted at this, but I rarely use the debugging. I can usually spot bugs just by looking at it. I've wrote so much code and so familiar with syntax/rules/etc that it's natural.

    @wlanboy said: Coding with Groovy is cool. But handling Groovy code is bad.

    Permgen annoys me the most. The rest not so much. I wonder if Indy has improved the situation though. I heard it has greatly. Groovy 2.1.0 that is. Any experience with it?

  • No experience with the newest version. My last version was 1.8.8. Maybe I will have a look at version 2.1.0.
    Please post your groovy experience after half an year. It would be interesting to see if it is usefull for installers.

  • @concerto49 said: Anyone do Groovy and/or Scala development here?

    I do mostly grails, but heavy on groovy scripts. Just speaking of groovy only, it makes code so much shorter and cleaner. Love it!

    One good thing about groovy is you can use so many Java api libraries out there, so you dont need to reinvent the wheel. Just focus on your logic

  • @jcaleb said: I do mostly grails, but heavy on groovy scripts. Just speaking of groovy only, it makes code so much shorter and cleaner. Love it!

    This is what I'm hoping for. Thanks for confirming.

    @wlanboy said: No experience with the newest version. My last version was 1.8.8. Maybe I will have a look at version 2.1.0.

    Yes, apparently there are major improvements. There's also a static compile feature, which might solve some of the dynamic class loading bloat.

Sign In or Register to comment.