Re: BeanShell alternatives (was Re: Status of projectand adding 1.5 generics)

On Dec 10, 2008, at 2:12 PM, David A. Lee wrote:

> I talked with my partner today and we decided to stay with BeanShell.
> We've been using it for several years in production and it would be  
> difficult to extract,
> and there's no compelling reason to change except the "FUD" of it  
> being "not supported".
> That's still a concern but not big enough to cause us to want to  
> toss it.
> We have the source and the know-how if we need to spot-fix  
> something ...
> In fact even today I'm integrating in BSH support to our other  
> product line under the philosophy that sharing the same technology  
> across products is a good thing.
>
> So not only is BSH alive and well ... but its being continued in new  
> projects .. atleast in my shop.

I think that will be the defacto case here. Rather than "switch" we  
will probably just tend towards supporting a variety of scripting  
languages. Which one should be the canonical one for training,  
documentation, and other work is another question but doesn't really  
affect what we'll need to do regarding BeanShell.

> Given that I would LOVE some kind of semi-active semi-official  
> handover of the codebase to dedicated maintainers, and volunteer to  
> be one of them.
> the beanshell2 google fork is a good thing, I have contributed to it  
> in the past, but I think its goals are different then what I  
> suggest.  I suggest a fork who's #1 main goal is stability and  
> minimum changes.  Bug fixes only ... and MAYBE a path towards new  
> java syntax support ... but not new features, and heavily focused on  
> maintaining legacy use.  I think thats a fundamentally different  
> goal then a "new and better beanshell" which is also a good goal ...  
> but not the one I'm most interested in personally.   To achieve this  
> goal I suspect will require some kind of "committee" so that no  
> individual is tempted to make changes without consensus or  
> oversight.  Of course that slows things down and is inefficient ...  
> but then that's the point.

I completely agree.

I think we need:
1) official website with version control and project management
2) one or more official leaders
3) a near-term stable release based on the latest beta
4) clean pedigree

Is Pat reading this? I certainly don't want to discount his work so  
far, lock him out, or force a coup. My impression is that he has good  
intentions and not enough time (much like all of us I suspect).

Partner Software and I can offer:
1) our own fixes (vararg support, 1.5-style exception chaining,  
support for parse-once-run-many)
2) developer resources (I've been programming in Java for 11+ years,  
we have three other full-time Java programmers, and it's the  
foundation of our platform)
3) testing and release management resources
4) web sites (we use DreamHost for the most part, though one of the  
standard "foundry" sites might be more appropriate)
5) physical facilities in Athens, GA - we have a good relationship  
with area hotels and have meeting rooms etc.
6) some funding

I am willing to provide leadership but I am extremely busy and may not  
be the best choice.

The quantity of resources provided will be dictated by enlightened  
self interest. We don't expect financial compensation but we do have a  
business to run so can't drop everything to focus on BeanShell issues.  
If we do decide to move our attention to another language then our  
interest in BeanShell will be largely to ensure legacy support.

What I want from BeanShell is:
1) ability to parse JLS-compliant Java source
2) ability to parse a variant of Java that is very close to JLS- 
compliant Java, but that allows:
* loosely typed variables
* procedural-style programming (code that's not in an explicit method  
and methods that aren't in an explicit class)
* "shell" style terminal usage
3) stability
4) performance

Porting back and forth from BeanShell to Java should consist of little  
more than putting the code in proper methods and classes and assigning  
types to all variables. Porting from Java to BeanShell should be a non- 
issue; I think BeanShell should be able to parse Java directly. It's  
pretty close already.

I like a little syntactic sugar - especially multiline strings - but I  
think if you add much of that stuff then you end up with Groovy so why  
go that route? I think the topic is worth debating, though. Embedding  
variables in strings, multiline strings, etc. are all very useful in a  
scripting language. However it does detract from the ease of porting  
back to Java.

Regardless I think BeanShell should have a clear vision and niche. It  
won't be perfect for all uses, or make everyone happy no matter what  
we pile on.


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/