Is Groovy just a syntax suger

[Amu mathi]

Is groovy a complete paradigm shift from the Java world or it is simply a syntax sugar coated over the bitter Java tablet.

I think unless an language owns its own runtime environment it cannot be called as a language.

[David Newton]

So JRuby, Scala, Groovy, SiSC, etc. aren't their own languages?!

IMO that view doesn't make any sense.

[Marco Ehrentreich]

I'd agree with David. The JVM (if you mean this with "environment") is a virtual machine which abstracts from your hardware and OS. And I think reusing libraries (like the JDK) from compatible languages like Java isn't something bad. Or what else did you have in mind with "environment"?

Marco

[Peter Ledbrook]

Is groovy a complete paradigm shift from the Java world or it is simply a syntax sugar coated over the bitter Java tablet.

Both. At first glance, Groovy looks like Java with a lot of added syntax sugar, but it is a fundamentally different beast because it is a dynamic language. Its support for closures also contributes to a very different feel to Java.

I think unless an language owns its own runtime environment it cannot be called as a language.

I completely disagree. A language owns its syntax and its semantics. The execution or runtime environment is irrelevant except in the case that the runtime environment may not support a language's structures in the most efficient way (think Scala on the JVM and the tail recursion hack).

Cheers,

Peter

[Amu mathi]

I like Groovy better than Java, as Groovy makes me feel more at home because its simple and elegant [ makes me more pythoish] further I need not strain myself over the heavy new Ruby language learning curve.... but on the downside

If we look at the facts without any prejudice...The day I compile my groovy code into Java the facade is gone, I am left again back to the old Java where I need to attend the strange Java exceptions and Java error messages.

In-fact debugging groovy at run-time is more difficult than debugging java as the groovy code is converted into incomprehensible byte code and one needs very in-depth knowledge of Java to understand the errors at run-time....

The fact that Runtime of Java is blissfully unaware of Groovy is not at all a advantage from programmer point of view, its advantage is from infrastructure and managerial convenience where the management can be comfortably unaware of groovy and the infrastructure can forget all about the existence of groovy.

To make groovy a complete and competitive language, I suppose we need to have new Groovy Virtual machine[GVM] which would be able to provide all the basic requirements for Groovy run time behavior and is optimized for groovy's groovish behavior.

Of-couse for backward compatibility the GVM can still continue to support Java such the existing Java byte code can still be used rather than discarded....

The idea is to make Groovy backward compatible with Java rather than trying to fit modern groovy into a obsolete Java virtual environment.

[Marco Ehrentreich]

Hi Amu,

I personally don't like dynamic languages, so I unfortunately don't have the same experience with Groovy than with Java. Because of this I'm not sure if I understand your complaints well enough to argue about this.

In any case I would say that there are at least three different things we're talking about. One thing is the language itself together with its syntax, grammar, best practices, patterns etc. The second thing is the implementation of the language which may be quite different under the hood if there ARE different implementations. The third problem I can see in your post is tool support which is doubtlessly very important today.

Having said that I think most of the problems and trouble you describe don't come from the language itself. No programming language is perfect for any problem and so is Groovy and any other, but it's surely not too bad. So I suspect that the main problems are related to the implementation and/or tool support. I don't know details about the implementation but I guess, as there are other successful languages running on the JVM like Scala, JRuby and others, the implementation could need some improvement. Tool support for dynamic languages is probably in general harder than for statically typed languages, but I'm no expert on this as well and I don't want to criticize existing solutions.

Anyway, I still don't think that a programming language needs it's own runtime environment to be a "real" language on its own. In fact you could even write your own compiler, virtual machine, interpreter etc. if you know the syntax and grammar. Ideally this shouldn't make a difference for existing programs if the specification of the language is strictly separated from possible implementations. Maybe in Groovy the existing implementation is just too tightly coupled to the JVM and Java features?!? Who knows...

Marco

[Pradeep bhatt]

In groovy I like closure and XmlSlurper. Amount of code reduces drastically using XmlSlurper. Ofcourse if XML is huge I have seen out of memory error occuring. You can reuse lot of your code using closure.

[chris webster]

Amu mathi wrote:The day I compile my groovy code into Java the facade is gone, I am left again back to the old Java where I need to attend the strange Java exceptions and Java error messages. In-fact debugging groovy at run-time is more difficult than debugging java as the groovy code is converted into incomprehensible byte code and one needs very in-depth knowledge of Java to understand the errors at run-time....

Sorry, Amu, but I disagree. Once your Groovy code is compiled down to bytecode, what does it matter how it got there, whether from Groovy or Java? The bytecode is the same either way. As for Java exceptions etc, well, ultimately Groovy/Grails are designed to run on the JVM, with lots of existing Java libraries, so of course the low-level error messages will be Java-style messages. Just as if you build a system on a Microsoft platform, you will get Microsoft exceptions (lots of them...), and so on. Although you could always try to code your application so it doesn't throw lots of low-level Java exceptions...

So it seems kind of pointless to complain because Groovy/Grails run on the JVM - that's one of their great advantages, after all. But if you don't want to run on the JVM (or take advantage of the huge amount of existing Java code/libraries etc), then of course you should pick a different platform/language for yourself.

[Vyas Sanzgiri]

Now seems we are getting off topic, but just to correct. Chris I do not think Amu does not like low-level error messages in Java style. I worked with Groovy on Grails and I got some cryptic error messages which I really cannot correct since it is with all these libraries Groovy Grails is built upon (which I do not know or lets say in this world I am not supposed to know) To keep fixing these errors or to get more info about these issues is what I call a technology to be more mature and proved.

Where I am going is - I want to use Groovy and Grails out of the box and debug the system code or keep raising issues.

[Gregg Bolinger]

Vyas Sanzgiri wrote:I worked with Groovy on Grails and I got some cryptic error messages which I really cannot correct since it is with all these libraries Groovy Grails is built upon (which I do not know or lets say in this world I am not supposed to know) To keep fixing these errors or to get more info about these issues is what I call a technology to be more mature and proved.

See, I'd say this is where the problem rests. I agree there are some cryptic error messages at time but when they are error messages that have to do with Hibernate and Spring (the 2 main techs grails is built on) you can't blame grails. Blame yourself for not taking the time to understand these technologies. I said in another thread, you need to understand what makes grails work to use it effectively and efficiently. With any mid-large sized project you're going to run into situations where you are going need to go lower than grails to accomplish some tasks. That's true with any framework. So you better have a firm understanding of the nuts and bolts at some point.

[Amu mathi]

Lets understand few things

when a framework or language is promoted... they are said to be cure for


* programmers [Java] are over worked and they needlessly focus on under-the-hood technology and not on business logic
* The programmer should have simple language /framework - he should focus on domain and not the technology.
* Enterprise programmers should focus on problem domain and not juggle with technology...
* Smart work - not hard work

But when the framework starts to leak... and when the programmer starts complaining the answer is

* You don't understand things under the hood...hard work learn more...don't leave early.... focus more on underlying technology


If I should learn about Hibernate and spring or JVM to work efficiently with Groovy or Grails, then I am better off working on them directly, further I can master and resolve issues in Spring/Hibernate only if I work, struggle with them over a period of time.

The problem is to understand and fix issues under the hood one need to be a master with that technology- which can be gained only if you fiddle with them for long enough.

Are we missing something

The point is in groovy is a great idea... but we are trying to fit it into the Java groove - that's like trying to adjust your leg to fit shoe, I suppose groovy to grow further should move beyond JVM and have its own elegant virtual machine.

[Marco Ehrentreich]

Hi Amu,

I understand what you're complaining about, but I still don't see how the said problems would be solved if Groovy/Grails wouldn't have any relationships to Java and the JVM.

Let's take the example with Hibernate. Persistence and O/R mappers are more or less complex because the problem is complex, too. Hibernate makes it already very easy to use databases without doing all by hand with SQL etc. But in my opinion it's almost impossible to find a solution for an existing problem which is much easier than the problem itself.

Grails does what I find very reasonable and tries to re-use existing technologies. Do you really think a pure Groovy based persistence framework would be that much easier to use? Without knowing any details about what's going on under the hood? Maybe some day there will be frameworks which can really abstract from everything going on inside them, but I think today this can't be completely achieved with any framework.

Marco

[chris webster]

Amu mathi wrote:Lets understand few things

If I should learn about Hibernate and spring or JVM to work efficiently with Groovy or Grails, then I am better off working on them directly, further I can master and resolve issues in Spring/Hibernate only if I work, struggle with them over a period of time.

The problem is to understand and fix issues under the hood one need to be a master with that technology- which can be gained only if you fiddle with them for long enough.

Are we missing something

The point is in groovy is a great idea... but we are trying to fit it into the Java groove - that's like trying to adjust your leg to fit shoe, I suppose groovy to grow further should move beyond JVM and have its own elegant virtual machine.

Hi Amu,

Groovy/Grails run in the JVM, which is one of their greatest advantages, because they allow you to take advantage of a huge existing codebase in Java and to integrate your Groovy/Grails apps easily with existing Java apps, and to use Java within your Groovy/Grails apps wherever you want. This is where Groovy/Grails has the advantage over e.g. Ruby/Rails (or even JRuby), because it is so easy for companies to integrate new Groovy/Grails applications with their existing massive investment in the Java platform.

And for many tasks, you will never need to worry about how it's working underneath, so Groovy/Grails should help you to do many things more easily/quickly/simply than in Java.

But sometimes there will be issues that require you to look under the hood e.g. integrating a Grails app with a legacy database using Hibernate. So yes, you will need to be able to work with Hibernate/Spring etc. But you would have to do that anyway if you used vanilla Java + Spring/Hibernate, only you'd have to do it all the time.

Anyway, Hib/Spring are very well documented, so when you do need to look at these, you should be able to find all the help you need. And if you still think this is too much work, maybe you need to think about your career choices, because if you stay in IT, you'll have to learn new tools/languages/platforms regularly for the rest of your working life. Why not learn to use Java and Groovy and so on, instead of only Java? Then pick the right tool for each job.

Your alternative is to re-build Groovy/Grails on a completely different platform. But then we lose all the advantages of 100% Java integration, plus we still have to learn a whole new platform to understand how your new Groovy-look-alike (let's call it Amuuvy!) works underneath. And somebody has to re-invent all the tools that already exist in Java, and make the new Amuuvy platform interoperable with Java, if we want it to take advantage of our existing investment in Java technology.

What's the point of doing this? After all, we already have good candidates for non-JVM "Amuuvy" - e.g. Ruby, Python etc. Who needs another one?

Best wishes,
Chris

[Amu mathi]

Dear Chris,

Good discussion, I suppose you have clarified may points, I certainly agree with you....

I tried re-reading Tate's beyond Java for few more iterations Here is what I think :-

The enterprise computing arena though not up for grabs, is certainly cracking...there is an urgent need for smaller saner framework and agile languages like groovy/Ruby.

But the problem is moving towards Ruby one needs completely dis-own the existing infrastructure and investment done on Java which includes huge code-base.

Thus the alternate is to use a agile language like groovy, which embraces existing Java seamlessly such that the investment in Java is not wasted.

Now Groovy to Java marriage can be done in two ways

Option1 :- Quicker smarter and faster way :- Provide Groovy as a compile time facade over Java change nothing under-neath - This helps groovy to get sold quickly, not much risk involved, easier to implement and jell with future versions of Java....

This is a best option used by C++ team initially to promote C++ over C where C++ is complied to C code....

But groovy cannot sustain using the facade for a long time... soon as projects grew complex and many different experiment are done in trenches, people will find they are slowly working more and more with Java than with Groovy... in-fact in the book beyond Java this is seen as a major draw-back of current groovy strategy...


Option2 :- To jump-start with option 1, but slowly and surely embrace Java frameworks and JVM and extend them to the dynamic needs of Groovy....

The first and fore most thing that needs to be done is to have Groovy virtual machine (GVM) which should be 100% compatible with Java but is Taylor made for groovishness providing better error handling and performance capabilities. of-course with the option of still supporting Java and its frameworks for quite sometime.

Thus I still think unless groovy moves towards its own implementation of embracing and extending Java, I think it will become one among the funny languages such as JRuby or Jython...It will posses no real threat to Ruby or RoR...

Of-course who is willing to branch the JVM code-base and work on implementing an GVM - as this takes time and effort is a question which I don't have any answer.

[Garrett Rowe]

I disagree with the assertion that since the language compiles down to JVM bytecode, it is essentially a Java facade. JVM bytecode and the Java language are related only in the fact that Java compiles down to JVM bytecode. The JVM is an amazing piece of software that has been highly tuned and optimized over the last 15 years. The bytecode that it runs is for the most part language independent. To just scrap Groovy's dependency on the JVM because of, well I'm not sure why really, would be a mistake. There are a number of languages other than Java and Groovy that compile down to JVM bytecode, including Scala (my favorite), Clojure, and Fan. To say that any of these languages are Java facades or syntactic sugar over the Java language is just incorrect.

[Gregg Bolinger]

Garrett Rowe wrote:I disagree with the assertion that since the language compiles down to JVM bytecode, it is essentially a Java facade. JVM bytecode and the Java language are related only in the fact that Java compiles down to JVM bytecode. The JVM is an amazing piece of software that has been highly tuned and optimized over the last 15 years. The bytecode that it runs is for the most part language independent. To just scrap Groovy's dependency on the JVM because of, well I'm not sure why really, would be a mistake. There are a number of languages other than Java and Groovy that compile down to JVM bytecode, including Scala (my favorite), Clojure, and Fan. To say that any of these languages are Java facades or syntactic sugar over the Java language is just incorrect.

I agree with this 99%. I think there is a little bit of a difference when we talk about Groovy and Scala, Fan, Clojure, etc. The difference I think is the purpose in which Groovy was created. Groovy was created to make Java easier and give Java developers language features that weren't going to make it into the Java language anytime soon. It is purposefully aimed at Java developers and purposefully similar to the Java language. So while I don't agree that Groovy is "just syntax sugar" I do believe you could say it is a facade or a nice wrapper on top of the Java language plus a whole lot more.

However, languages like Scala, for example, weren't created with the same purpose. The syntax isn't aimed at Java developers. And stating that Scala supports all your existing Java libraries might better be stated Scala supports all JVM compatible code/libraries. Because we're really talking about platform compatibility, not language compatibility.

[Pat Farrell]

chris webster wrote:Groovy/Grails run in the JVM, which is one of their greatest advantages, because they allow you to take advantage of a huge existing codebase in Java

What is true about Groovy is also true about Scala. Both are more modern languages that leverage the wonders of the JVM.

I don't have sufficient experience with either Scala or Groovy to compare them. I do have more than a decade with Java, and I believe that Java is not the solution for the future. The future will start with 4 or 8 cores and go up, and using Threads to synchronize stuff is just too hard.