[GR-Jug] [J2EE or PHP]

[jgerrits at ci.grand-rapids.mi.us]

I felt that I needed to respond, so here goes.

Before I get started though, I want to point out that the original question was related to web apps, PHP vs. JEE.  I only brought up command-line based scripting because of the recent experience I've had with Groovy.

>Groovy: Groovy seems like re-inventing the wheel to me, especially when
>we already have mature (which Groovy is not) scripting languages like
>BeanShell and Javascript (Rhino).  The disclaimer is that I've never
>used Groovy, but many of the people I've talked to have expressed
>serious reservations about it.

I totally understand where you're coming from and I too have issues with using software/programming languages when they haven't yet even reached 1.0. I haven't used either BeanShell or Rhino yet so I'm not sure how they work with servlets or JSPs - we are talking about web apps.

>The feeling I got was that a bunch of people jumped on the bandwagon at
>the beginning, they implemented some whiz-bang features, but no one
>bothered creating a solid core.  Consequently work slowed to a crawl as
>the whiz-bang aspect faded because no one wanted to take on the
>boring-but-necessary parts of creating a language.  Does anyone know
>what the current state of the Groovy project is?  Is there still a
>healthy amount of activity and progress towards a final 1.0?

As far as Groovy is concerned, it's alive and kicking.  Hell, it was mentioned in 6 different sessions at JavaOne (http://glaforge.free.fr/weblog/index.php?itemid=172).  It's even a spec and has its own JSR (http://jcp.org/en/jsr/detail?id=241).  So far it's currently on track as far as the roadmap is concerned (http://docs.codehaus.org/display/GROOVY/Roadmap) though it might be delayed due to the issues that Codehaus has been having lately.

>I know that Dave Brondsema did an evaluation of various scripting
>languages in the Java world awhile back, so I'd be curious to hear his
>perspective...
>
>One final word: I'm much more skeptical about running scripting
>languages inside the JVM.  Problems: the overhead of the JVM (primarily
>memory),

Is this really an issue with web apps?  Or for that matter even command-line scripting?  All scripting languages are usually interpreted as far as I know and would have the same type of overhead.  Java 5 and 6 are light years ahead of their predecessors when it comes to speed and memory usuage so this becomes even less of an issue.

>lagtime behind the "real" scripting language, minor deviations
>in functionality, etc.

True, for those that I copying functionality like JRuby but not for Rhino or Groovy.

>I see scripting in the JVM as a nice tool in the
>box for existing Java apps, but not as a replacement for the native
>scripting environments.

If Groovy or BeanShell or Rhino was preinstalled, would that make them "native"? :)

>If I'm writing a Rails app, it's going to be
>running in native Ruby served up via WebBrick or FastCGI.  I don't want
>the headache of dealing with "well I found instructions for doing it
>this way, but JRuby hasn't implemented that yet [or: it works
>differently]."  I have enough of that stuff running a Mac (both with PC
>and Linux software) :-)

Totally agree with you.  I would never develop a Rails app _hoping_ it would run on JRuby.  Even the JRuby guys would say that.  But what I'm saying is that if the scripting language is _mature/nearly mature_, why not leverage the architecture you already have installed.  If you're running Tomcat or Geronimo or even WebSphere, you can write a simple web app with Groovy in the same amount of time as PHP, and package and deploy it even faster (I love app servers and WARs).  Also, most corporate developers don't have the influence to persuade IT management to convert their architecture.

>If I'm evaluating what language to use at the beginning of a project,
>I'm still going to lean towards scripting languages outside of the JVM
>for lighterweight work.

See my previous response.

>The primary practical use of scripting within
>the JVM (as I see it) is in providing easy extension points for app
>functionality.  Example: using Python scripting to extend the
>functionality of WinCVS.

And this will always be the case with any scripting language, though this would only be the case for desktop style apps.  But even so, with the new features coming down the pipe, writing full-blown apps with scripting languages that run on the JVM is a reality.  People write desktop apps with Ruby, Perl and Python all the time - why wouldn't you do the same for scripts on the JVM? (see GroovySWT module)

Ok, time for a breather.  I hope I didn't come across as a Groovy fanatic, I'm just sick of writing Perl :)

JG