incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Tilton <>
Subject Re: ODF Command Line Tools -- Request for community feedback
Date Wed, 16 May 2012 16:35:31 GMT
Hello All,

On Thu, May 10, 2012 at 5:00 AM, Rony G. Flatscher (Apache)
<> wrote:
> On 10.05.2012 08:06, Noah Tilton wrote:
> ... cut ...
>>> Some quick comments
>>> You might want to take a look at the Bean Scripting Framework, part of
>>> Apache Commons:
>>> "BSF permits any Java application to be implemented in part (or
>>> dynamically extended) by a language that is embedded within it. This
>>> is achieved by providing an API that permits calling scripting
>>> language engines from within Java, as well as an object registry that
>>> exposes Java objects to these scripting language engines."
>>> I wonder if it would be possible to use BSF to make the DSL approach easier?
>> Sure, the BSF is a good way to do embedding, although there are other
>> options, depending on the scripting language.  If we go the DSL route,
>> I guess a lot depends on which scripting language we choose and what
>> their community offers.  I like ruby, so my vote is for JRuby, any
>> takers?
> If contemplating of using BSF, then look at "javax.script". BSF 3.x is an opensource
> of "javax.script" (a.k.a. JSR-223), which makes this framework available to Java 1.4
and 1.5
> installations (javax.script got introduced with Java 1.6).
> Then, any Java-based (scripting) language like JRuby or any scripting language with a
Java interface
> like ooRexx can be immediately put to work to serve as the language to create scripts
that implement
> the flow of control. This probably implies that you actually would implement a "super-package"
> the ODF Toolkit which makes its functionality easier (?) available one way or the other.
(BSF2.x and
> JSR-223/BSF3.x scripting languages are already able to interact directly with the ODF
> ---rony

Setting aside the issue of implementation for the time being, I think
it would be useful to focus the discussion on the substance and style
of a useful and well-thought-out internal DSL.

Here is an excerpt from that illustrates some of the

Unlike a general-purpose language like Java, a DSL is fairly limited
in scope and capabilities; as the name suggests, DSLs are keenly
focused on a certain type of a problem or domain, and on expressing a
narrow set of solutions within the context of that limited scope. And
that's a good thing -- DSLs are simple and concise. ... The word
specific in DSL gives you the bounded context. It helps you keep
things relevant, focused, terse, and expressive.

Simplicity is critical to the success of a DSL. A person familiar with
the language's domain must easily understand it. ... The DSL you
create for them must be built on [users'] vocabulary, the terms they
use every day to communicate with their peers. You want them to use
the syntax you provide, but it should seem to them that they're merely
specifying some discrete rules. And they should be able to do so
without getting the impression that they are really programming or
even using some kind of a language.

Creating a good DSL is like cooking a nutritious meal; just like you
want kids to eat vegetables without realizing and fussing over them,
you want clients to use your DSL without worrying about its syntax.

Conciseness is another part of writing a good DSL, which means
choosing syntax that is both terse and expressive. Terseness within
reason makes your code easier to read and maintain. Expressiveness
helps to promote communication, understanding, and speed. For
instance, for someone who understands matrix multiplication,
matrixA.multiply(matrixB); is less expressive and concise than matrixA
* matrixB. The former involves calling functions and using
parentheses, and includes an intimidating semicolon. The latter is
already an expression that will be quite familiar.

Therefore, a good/useful DSL is terse, simple, and expressive.  It
utilizes users' vocabulary to describe the domain.

So my question to the list is, what kind of "nouns" and "verbs" should
be part of the language we are creating?  If you are an ODF Toolkit
user, what kind of language do you currently use, or would you feel
comfortable using, to describe your activities?




View raw message