incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Tilton <noahktil...@gmail.com>
Subject Re: ODF Command Line Tools -- Request for community feedback
Date Thu, 24 May 2012 17:04:06 GMT
Hello Rob et al.,

Here is a proof-of-concept showing how one can use the ODF Toolkit with jruby:

https://github.com/noah/odf-command-line-tools

the relevant files are the README and the ruby code in ./lib.  If you
have jruby in your path, you should be able to run

% jruby lib/oclt.rb

And see that there is a file created in /tmp.

My plan is to start building out the OCLT project as an internal DSL
using jruby.  I think ruby is a good compromise as it integrates
nicely with the JVM and all of the existing Java code that is part of
the ODF Toolkit.  Ruby's syntax lends itself well to DSLs because of
its "minimally intrusive" syntax, and a number of language features
make it a natural choice.  I know ruby already, and it seems to be
popular in the scripting community.

If you have any questions/concerns about this approach or would like
me to spend more time in the feedback/research phase then please let
me know; otherwise it's off to the races.

Cheers,

On Mon, May 21, 2012 at 10:11 AM, Noah Tilton <noahktilton@gmail.com> wrote:
> On Wed, May 16, 2012 at 3:29 PM, Rob Weir <robweir@apache.org> wrote:
>> On Wed, May 16, 2012 at 12:35 PM, Noah Tilton <noahktilton@gmail.com> wrote:
>>
>> <snip>
>>
>> Good thoughts.
>>
>> Aside from the level of abstraction, and how it maps to the problem
>> domain, I think the style of language is another important components.
>>  For example,  even if you had a perfect API, if it is coupled with a
>> Haskell-like functional syntax, it will be an impediment to a
>> "power-user" who is familiar with only imperative languages.
>>
>> You can slice and dice it in many ways, but one way to think of the spectrum is:
>>
>> 1) end user programming == simple record and play-back macros,
>> spreadsheet functions
>>
>> 2) Power users, some web designers == simple imperative Javascript or
>> shell scriptsing. Can copy a routine to reuse and make simple
>> modifications to it.  Might read a programming book.
>>
>> 3) Application developers == a professional working with C#, maybe
>> Java, or another modern language.  Builds complete solutions from
>> existing parts, gluing them together where possible.  Focuses not on
>> the individual components, but on integrating the pieces with the
>> "business logic" that the custom requires.  Keeps up with the latest
>> trends and techniques.
>>
>> 4) System programmers == C/C++ programmer.
>>
>> Skills increase as you go up the spectrum, as does cost.  Aiming too
>> high makes a tool have a smaller audience.
>>
>> I think the ODF Toolkit today is at the app developer level in our
>> "Simple API".  But because it is in a Java syntax, that puts it out of
>> reach for level 2 developers.
>>
>>
>>> 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?
>>>
>>
>> One possible level is to look at what the developer at level 1 and 2
>> already knows.  They don't know ODF. But they know word processors and
>> spreadsheets and presentation graphics.  They know the abstractions of
>> an end user:   sheets, slides, paragraphs.  Their "verbs" are the
>> actions of the menu in their editors.
>
> That's an interesting way to think about it; reminds me of something I
> read a few months ago via hacker news:
> http://www.whattofix.com/blog/archives/2012/02/what-level-prog.php
>
>
>
>> -Rob
>>
>>
>>> Thanks,
>>>
>>> --
>>> Noah
>>>
>
>
>
> --
> Noah



-- 
Noah

Mime
View raw message