From: David Vallner Date: 2006-11-12T06:00:09+09:00 Subject: Re: Java scripting language poll --------------enig103E43B740AB45182CF965DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charles Oliver Nutter wrote: > David Vallner wrote: >> The apparent popularity of Groovy disturbs me, for fear of overhyping >> and the fact I wish their JSR a speedy death. Then again, I don't give= >> much credit to blog polls, especially ones that are instant cues for a= >> programming language flamewar. Last time I remember, it was a certain >> Mr. Spolsky that was being accused of trolling for hits by doing more = or >> less that. >=20 > I expected Groovy to do well; in the past it's been the most "official"= > language (JSR process and all), it's been hyped quite a bit for the pas= t > couple years, and, well, it has a pretty good name. It's certainly not = a > language I'd ever want to use though, so I think the JRuby thing has > more potential (of course). >=20 The "officiality" is a marketing stunt, nothing more. At the time the JSR was submitted, it was pending several syntax changes, parser rewrites, and significant feature additions (read: creep). The shameless audacity of proposing that an unstable language without a track record become the "official" scripting language of the JVM I found disgusting. YMMV, but I'd much rather see either BeanShell (for the ease of adoption and similarity), or JRuby (for subjective reasons, being proven in its applications, and having an object model reasonably compatible with Java, just more manipulable). The fact Java 7 will with some probability introduce closures might make me withdraw support for the latter unless I see a way to make the JRuby ones compatible - this might end up to be not a problem, of course. >> Wishing no ill fortune to the JRuby folks, I voted for BeanShell on th= at >> one for rational reasons. The role I see for scripting the JVM is in >> things usually more people on the team and later maintainers will chan= ge >> (involved configuration, rules in business rule engines), and making >> those easily understood and modified by people you hire to work on a >> Java app (read: people who know mostly Java) is paramount. (If you >> wouldn't use a scripting language on a part of the app you expect to >> change often, where then?). >=20 > Fair enough...and I agree, if Ruby didn't exist I'd probably be using > Beanshell or Jython or SISC instead. In the end though I hope we can > really bring all languages up at the same time by better supporting the= m > at the VM level. That will help everyone, including those poor pure Jav= a > devs out there. >=20 True, though considering that scripting Java was an option for quite a while and remained more or less a niche activity makes me skeptical. Then again, I've already seen valid use-cases myself (Spring bean configuration, something similar in DWR) - bringing scripting back to its original purpose of glue between components. >> (Disclaimer: Anyone proposing anything but Java be used to actually >> implement some library / framework to be consumed by other people from= >> Java deserves being handled by the nearest rusty fork. I'm a >> multilanguage purist, keep to each its advantages.) >=20 > I don't necessarily agree that Ruby can't be used for such things...but= > I agree it's best targeted at tying such things together. >=20 The problem would be (apart from the usual performance considerations, those might be negligible depending on the role of the component) just how well that library would integrate with Java, with regards to being type-safe, securable, etc. Then again, my surrogate brain tells me JRuby can implement Java interfaces, so that might be an irrational concern that can be handled well instead. David Vallner --------------enig103E43B740AB45182CF965DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD8DBQFFVjn/y6MhrS8astoRAqJ2AJ9tqfrYWIq9/BP4ZLzUlv5lun7IYwCaAvvG xTo4NLCi4AW72Zz1DrFdYy4= =DxIG -----END PGP SIGNATURE----- --------------enig103E43B740AB45182CF965DC--