Recent BeanShell feature discussion

Some thoughts on the recent discussion of BeanShell features and 
comparisons to various scripting languages:

Creating a simpler development environment for non-experts, or "java for 
the rest of us", is a fine goal for a software project, but I don't 
think it should be the goal of the BeanShell project.  Creating 
something "simple" isn't just about language syntax, it really requires 
all sorts of development environment hand-holding features, ones that 
express a simpler set of software building blocks.  It's just not in the 
same ballpark as a framework for interpreted java, or even a general 
scripting language.

Even making BeanShell a good tool for learning java is partially in 
conflict with the goal of being good at run-time source interpretation.  
Setting up the specific environment in which to execute a script, and 
then writing that script to execute correctly in that environment, is 
harder to get right than writing conventionally-compiled java code.  
Making it usable by people who don't understand java very well to begin 
with might be too much to ask of one framework.

Regarding the various "syntactic sugar" features of other scripting 
languages, such as lists/map syntax, javabean property-access syntax,  
operator overloading, and autoboxing, I tend to agree with the person 
who suggested that these features might be better provided by IDEs.  At 
most they should be optional features in BeanShell, ones that don't 
confound the problem of doing efficient source interpreting.

As an aside, I think language syntax conveniences need to be approached 
very cautiously.  Programming languages have a lot in common with 
regular spoken or written languages.  They need to have a structure that 
not only promotes the easy generation of statements by people, but also 
the easy parsing of those statements at a later time by people.  (Of 
course, programming languages have the additional goal of being easy to 
parse by software.)  Adding (even optional) syntactic shorthand to a 
language plays a dangerous game, and can end up making the resulting 
statements much more difficult to understand when read at a later time 
by people, so maintainability suffers.  This is one of the problems with 
evaluating languages based on the level of brevity or conciseness that 
can be achieved.

 From the intro to BeanShell, ( http://beanshell.org/intro.html ):

        BeanShell is a small, free, embeddable, Java source interpreter
        with object scripting language features, written in Java.
        [...]
        In short: BeanShell is a dynamically interpreted Java, plus some 
useful stuff.

I think this is a great goal for what BeanShell should be.  And I think 
that the "object scripting language features" should be a secondary 
goal, where the primary one is to get a super-solid, well specified, 
well documented, decently performing, Java Source Interpreter Framework 
for embedding in conventionally-compiled java software.  Non-embedded 
uses are fine, but I don't think BeanShell should focus its value 
proposition there, since other scripting languages (of which there are 
more than enough to go around) compete pretty well for stand-alone uses.

I think BeanShell's greatest potential lies in the following uses:
    - Bootstrapping and deploy-time configuration for conventional java 
applications.
    - Plug-in and extension implementations for conventional java 
applications.
    - Live, custom interaction with running (server-side) java applications
    - Writing unit tests for regular java software components.

These are all things which benefit directly from BeanShell being as 
close as possible to a strict super-set of java syntax.  This is where 
other scripting tools don't compete very well, and therefore represents 
the best place to focus energy, instead of putting effort into fancy 
syntax cleverness.

I think the most important area for future BeanShell work is expansion 
and formalization of the embedding framework- allowing embedders to 
specifying more exactly what the execution environment for a particular 
piece of interpreted source should be, in terms of classloader issues, 
security (which code can be called from the script), resource 
utilization, resource access, as well as how to manage re-loading of 
classes defined in scripts.

One other area I think might become important is to have, whether 
built-in or not, features around syntax-checking independent from 
execution.  For live shell use, this means stuff like auto-completion of 
symbols (which I gather there is some support for already?).  But it 
would also be great to have, for instance, an Eclipse or Idea plug-in 
for syntax-highlighting and checking in BeanShell scripts.  Obviously, 
because of scripting's dynamic nature, it couldn't be as strict as 
regular java source editing, but could give live typing feedback, and 
would greatly reduce the time-consuming consequences of typos in 
scripts.  (Especially since getting useful error reporting and stack 
traces is more difficult in a dynamic scripted environment, the more we 
can do to minimize errors the better).

Anyhow, I think BeanShell is great, and I'd hate to see it bogged down 
with trying to be like every other scripting language out there.

-David Fogel.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn