Of course, I think that Groovy is it's own killer app. I mean what's
not to like? Portable scripting language that can easily interact with
(or be embedded into) Java. That rocks! Let's not forget just what a
gem that Groovy is in it's own right.
> just to collect some ideas for a killer application I want to start this
> thread here. There was some discussion about groovy needing something
> like that. Well I think grails will be such an application but ideas are
> most welcome. Personally I think that writing a buildsystem in groovy
> would not only let groovy nefit from it, and it would not only improve
> groovy's abilities as shell scripting language, it would also be a
> possibility to make a clean build script for groovy. It's just and idea
> as any other idea you maybe have and should write in this thread ;)
> ybe blackdrag
Great thread idea Jochen , I was going to put this on the six reasons thread but here is more suitable.
Athough I don't know what the killer app is I have some opinions on what things could be:
Firts if we look at ruby's popularity it's ROR that made it for ruby which isn't a killer app, rather a killer framework. I think they have set the tone for all scripting languages on the web. I think Grails will be great here, but it will just be ROR for Groovy and not groovy's killer app/framework.
I think we should also forget scripting due to it's reliance on the JVM unacceptable in many cases.
Where groovy has it's advantage is in it's Java base, here it is on it's home ground, and thus this is likely to hint towards it's iller app. (On a side point it would be great if it could also be ported to .net).
Thus we should look at where Java has been successful as to clues where groovy could be. Here i think the coporate and enterprise markets are definitely strongholds with Microsoft tools and .net following closely behind.
So maybe groovy's killer app is in this space. ROR is in the general web space but not the corporate/enterprise space, this is where groovy could really shine.
More clues : I think things like grash, simplified soap/web services, builders, simple sql etc.. may make working in the entreprise much simpler (particularly if we can simplify J2EE into groovy). If we can combine this with the 'Agile' features groovy offers could make it a enterprise/corporate killer framework/app/builder.
It would be good if we could create a killer agile building ide around groovy to deal with the refactoring, building and glueing in the enterprise/java environment. A system that revolutionises the speed and simplicity with which we can create corporate web interfaces/guis and process business logic.
Imagine an IDE with grash built in, being able to manipulate live J2EE objects in memory, or distributed systems without taking them down etc..
I think their is a real opportunity here.
Anyone else share this idea, groovy could be the ultimate business supe glue and uber agile bussiness process tool ? wht do you think?
- Grails is a bit more than just ROR for Java.
- Grails fully runs on the J2EE infrastructure which makes it a good
candidate for use in the corporate IT / enterprise space
- Grails builds on Java frameworks that have a good reputation in
the J2EE world (Spring, Hibernate, JSP, ...)
- Grails can easily integrate all the self-made Java stuff that
one finds in corporate IT departments, protecting investments
made to day
From: Babelex [mailto:[hidden email]]
Sent: Samstag, 10. Dezember 2005 18:29
Where groovy has it's advantage is in it's Java base, here it is on it's
home ground, and thus this is likely to hint towards it's iller app.
>> LOL! ;-))
Certainly Grails can be one of thecorner stone of Groovy.
I've also thought of another corner stone, ie RAD RCP. The idea behind
is to be able able to develop quickly and in an intuitive manner a RCP
This one should be made uppon the eclipse RCP framework to benefit of
the huge work already made, but in a more friendly manner...
The current way of doing an RCP application in Eclipse is :
* create a PDE project
* fill the build.xml file in order to define the eclipse extensions
(views, perspectives, actions, ...)
* create the application classes
* launch the application for testing
It is often painful, errorprone, and so on...
The way I suggest should be to develop the RCP application "in live" :
* we open a blank RCP application
* we add dynamically in the menubar new menus ...This is done directly
in the application by using a predefined menu "add menu"
* we add dynamically a perspective , a view, and so on... , by the same
* we add behaviour by writing code in the menu actions...
* once tested, the RCP application code "a la eclipse" is generated back.
The development lifecycle is considerably shorten... We can concentrate
on the domain model after prototyping the application...
On 14/12/05, Xavier Méhaut <[hidden email]> wrote:
> yes of course :) It was just to know if it could be interesting to use
> radrails as a basis for developping an eclipse envrinment for Grails by
> mimics radrails features...if they are interesting
It was too funny asking a question about radrails totally unrelated to
Groovy, so I couldn't resist asking you if you were not on the wrong
I hope you don't mind.
Next time, make sure you expand a little your email.
Having some advanced IDE support for Groovy, as well as for Grails is
very important, and we'll certainly look into that, and see what
others do too.
Btw, for Grails related questions, ideas, suggestions, bugs, whatever,
there are Grails related lists you can subscribe to: