incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: ODF Command Line Tools -- Request for community feedback
Date Mon, 28 May 2012 19:21:30 GMT
On Thu, May 24, 2012 at 1:04 PM, Noah Tilton <noahktilton@gmail.com> wrote:
> Hello Rob et al.,
>

Hi -- sorry for the delayed response.  I was away from the office last week.

> Here is a proof-of-concept showing how one can use the ODF Toolkit with jruby:
>
> https://github.com/noah/odf-command-line-tools
>

Cool.  Adding odf-dev to this email as well as odf-users

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

I cloned the repository and I get an error:

~/odf-command-line-tools$ jruby lib/oclt.rb

lib/oclt.rb:3: cannot load Java class
org.odftoolkit.simple.TextDocument (NameError)

I'm not familiar with JRuby.  Do you know whether it works with Maven?
 That might help with dependency management,  Just specify the ODF
Toolkit as a dependency and it will be downloaded automatically and
added to the classpath.  Maven is the best thing that happened to Java
since garbage collection.

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

This sounds like a reasonable approach.  Thanks for the effort you
made to solicit feedback on the requirements.   I'm hoping if you take
a "release early and often" approach you can get more feedback as you
go.

You likely have greater understanding of Ruby than I do, so going down
this path means my mentoring will mainly be on the ODF and ODF Toolkit
side.  I'm OK with that if you are.

We should probably also agree on platform and version requirements.
JRuby 1.5?   1.6?  1.7 preview?    I assume we should run on Windows /
Mac / Linux.  Any other version considerations?  For example, does
JRuby pre-req a JDK version?

-Rob

> 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