RE: Recent BeanShell feature discussion

Hello Dave,

I honestly donft believe that having some nice "scripty" features 
compromises the goals you describe, especially given a "strict java" mode 
that can disable them.  If you donft like them, you can just use the 
"strict java" mode at your organization.

When properly thought through, things like list and map literals and named 
parameters can actually make code _more_ readable and easier to maintain.  
There is definitely a correlation between ease of comprehension and 
syntactic economies.  Do you find:

    people = ["dave", "pat", "dan"];

Difficult to read?  Does this increase maintenance pain in any way?

Obviously you can take this too far, but syntactic sugar can be a good thing 
when used in moderation and, as I said, you can always turn it off.

Adding some syntactic niceties to BeanShell would make the language more 
useful to many people and, if they can be disabled, hurt no-one.

Cheers,
Dan

-----Original Message-----
From: beanshell-developers-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
[mailto:beanshell-developers-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of David 
Fogel
Sent: Thursday, February 05, 2004 4:29 AM
To: Beanshell-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; 
Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Beanshell-dev] 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
_______________________________________________
Beanshell-developers mailing list
Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/beanshell-developers

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



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