Ed Burnette: "With its uncluttered design, mature code base, small size, well defined semantics, dynamic language features, and JSR 274, BeanShell looks way groovier than Groovy."
My sentiments exactly.
Update: My response to
Graeme (originally posted in his comments):
You're kidding yourself if you think there's a fundamental difference between BeanShell and Groovy. They solve the same problems. Labeling one "scripting" and the other "dynamic" (dynamically typed?) doesn't change the fact that they really only differ in what syntax sugar they support.
BeanShell supports scripting language like functions (i.e. working with files, etc.), but that's a feature, not a definition of the framework. Any other differences boil down to implementation details.
I personally prefer BeanShell's conservative evolution approach to Groovy's attempt to include everything including the kitchen sink. I seriously doubt Groovy's long term viability and ability to evolve and maintain backward compatibility.
The fact that you haven't provided any examples of BeanShell syntax sugar leads me to believe you don't know much about it. If I didn't know better I'd think that BeanShell was little more than a Java interpreter after reading your post.
11 Comments:
Graeme isn't as familiar with BeanShell or its future direction as he thinks he is.
There are no fundamental differences between Groovy and BeanShell--they are both dynamic languages with similar architectures. To indicate otherwise or say that BeanShell isn't "dynamic" or that it doesn't provide benefit beyond prototyping is disingenuous.
The key differentiator between BeanShell and Groovy is syntax sugar. Groovy does have a few more bells and whistles in this area (Graeme mentioned closures for one).
BeanShell has taken a conservative approach and may not have every syntax sweet (yet), but Groovy has blazed ahead building in everything but the kitchen sink. Consequently, it is collapsing under the pressure of the resulting complexity.
The future is much brighter for BeanShell.
Ok ill bite.
No fundamental differences?
How about :
builders,
gstrings,
groovyjdk,
.....
.....
and most of all closures.
Ive used both languages extensively. I wish Groovy has Beanshell's robustness and Beanshell had Groovy's features. It only takes however a simple glance as the respective activity levels of the two communities (does Beanshell even have a community anymore given the posting level?) to see Groovy is far more likely to reach utopia first.
By "fundamental differences" I mean they aren't apples and oranges. They have different features (as you've pointed out), but you can still compare and contrast them. They aren't so different that they don't compete, contrary to Graeme's claims. Trying to differentiate them by calling one a "scripting" language and the other "dynamic" is meaningless.
Bob, I've responded to you comment on my blog. It saddens me that you are so bitter about this and not more constructive in posting articles about BeanShell (which I really like and use often btw).
There ARE fundamental differences and if you can't see that I'm afraid you need some 101 classes in a dynamic language like Ruby for example.
I'm not bitter at all--please don't make this personal. But I think your argument stinks worse than Groovy. ;)
If you think closures (which BeanShell can support in the future) qualify as a fundamental difference and there's some category of "dynamic languages" that BeanShell doesn't fit into, then I can't debate your argument because it make no sense.
Gilad Bracha: "That’s dynamically typed languages - not the increasingly common horrible misnomer dynamic languages (as opposed to static languages, where nothing moves, like hieroglyphics, perhaps?)." (http://blogs.sun.com/roller/page/gbracha?entry=invokedynamic)
Oh excellent you've cheered up! ;)
You're mistaken unfortunately and clearly didn't read my whole post, I never said closures are what makes dynamic I said that it is the way the groovy dispatches methods through its MetaClass which does.
The combination of closures, builders and meta class is what makes Groovy so powerful, clearly BeanShell can implement these features too, but then it would also have go for a more complex architectural design and a larger jar file.
Nice quote, see how he talks about groovy, perl and python.. all truely dynamic languages unlike BeanShell ;)
OK... Actually, BeanShell does support meta methods which can be used to implement DSLs:
http://tinyurl.com/l4vhv
Yes but only for instance methods and without closures and builders this is not enough to create useful DSLs unfortunately. See the response on my blog.
So now the ability to create DSLs defines a "dynamic language?" Response on your blog: http://graemerocher.blogspot.com/2006/03/groovy-beanshell-dynamic-vs-scripting.html#c114183637174794022
No its the sum of all the features that languages such as groovy, python, perl and ruby provide and that BeanShell (as of this writing, maybe one day it will) does not provide. What it does provide is a very useful language to script the Java language.
I wanted to have an extension language for an Android application and I definitely choose BeanShell!
I just took the BeanShell core sources and everything is working well. Its compressed size is less than 150K and it do the job. I can call all my Java classes without any mapping work.
Post a Comment
<< Home