Java scripting language poll

[pat eyler]

Since I'm a glutton for punishment, I thought I'd go
ahead and post this here as well. If you're a user/fan
of JRuby feel free to go vote it up>

http://www.manageability.org/polls/favorite_java_scripting_language

If you're not a JRuby user/fan ... what's wrong with you? ;^)

 

[David Vallner]

--------------enig48915C356F25C5CB78E82203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Since I'm a glutton for punishment, I thought I'd go
ahead and post this here as well. If you're a user/fan
of JRuby feel free to go vote it up>
=20
http://www.manageability.org/polls/favorite_java_scripting_language
=20
If you're not a JRuby user/fan ... what's wrong with you? ;^)
=20

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.

Wishing no ill fortune to the JRuby folks, I voted for BeanShell on that
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 change
(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?).

JRuby has its place, but IMO not really in Java development per se -
more along the lines of doing Ruby development while being able to
leverage Java-only libraries. If it only delivers that, the project has
very high value. It's a somewhat subtle distinction, but until now, the
latter wasn't an itch I needed scratching, so it's also not where my
vote is going.

David Vallner
(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.)


--------------enig48915C356F25C5CB78E82203
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)

iD8DBQFFVbvay6MhrS8astoRAg59AJsGF2fKFW6/gjj4S5+ZFcxEl1bv2wCeLfVr
1g4crEWvFcfyFREuj156DnE=
=QOx+
-----END PGP SIGNATURE-----

--------------enig48915C356F25C5CB78E82203--

 

[Charles Oliver Nutter]

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.

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 past
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).

Wishing no ill fortune to the JRuby folks, I voted for BeanShell on that
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 change
(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?).

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 them
at the VM level. That will help everyone, including those poor pure Java
devs out there.

JRuby has its place, but IMO not really in Java development per se -
more along the lines of doing Ruby development while being able to
leverage Java-only libraries. If it only delivers that, the project has
very high value. It's a somewhat subtle distinction, but until now, the
latter wasn't an itch I needed scratching, so it's also not where my
vote is going.

I think it may be better to think about JRuby not in terms of Java, but
in terms of an alternative VM for Ruby. You may not need a VM as
feature-complete as the JVM. You may not need a VM at all. But if you
do, and you want things like native, parallel threading, advanced memory
management and garbage collection, high-speed asynchronous IO, and a
bazillion libraries, maybe Ruby on the JVM is the right choice. You
really don't have to touch a line of Java code to get the benefit.

David Vallner
(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.)

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.

 

[David Vallner]

--------------enig103E43B740AB45182CF965DC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=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.

=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.

=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--