[aosd-discuss] AOP languages mature enough to used in industry

[Stephan Herrmann]

On May 16, 2007, at 10:46 AM, Miguel Pessoa Monteiro wrote:
> I'm looking for true programming languages. As far as I know, CaesarJ,
> Eos, JasCo, ObjectTeams/Java (and many others) qualify. The problem is,
> some of those (all?) are still at the proof-of-concept stage.
In my announcement of version 1.0.0 of the Object Teams Development Tooling (OTDT)
I mentioned some reasons why we claim that we definitely left the proof-of-concept stage.
(attaching the announcement for your convenience). 
Judge for yourself.

> People from industry would be reluctant to depend on them.
They _have_ to be reluctant to depend on _anything_ new. 

> I'm not aware of a clear definition of "mature language", so that's why I
> talked about adoption by independent developers from industry.
Adoption gives a hint at assumed maturity. It doesn't prove anything ;-)
Industry has adopted weird languages and technologies at some point or other.
On the other hand, most research projects are not very good in marketing.
So the relationship between maturity and adoption remains as vague as any
other definition of "mature language", am I wrong?

So, why exactly are you asking your question? Which answer best suits your question
would depend on your motivation for asking, I guess.
 
> Admitedly, it is not an easy thing for a language to reach a level of
> maturity beyond that - just think of what it takes to turn AJDT into a
> superset of JDT for eclipse.
Exactly that has been the focus of our work on the OTDT for quite a while now.
Answering Dean Wampler's comment:
>[DW] Yes, and unfortunately, it wouldn't make sense for researchers to  
>[DW] build tools to the caliber of Eclipse's JDT, for example.
Yes, but _extending_ the JDT is in fact doable. Even more so, since
Object Teams can be _used_ for this task ;-)

> I'm conjecturing that it may be relatively "easy" for some kinds of
> languages (e.g. extentions to dynamic languages such as aspectPHP and
> AspectR) to reach that point. Again, I could be wrong, hence my original
> post.
If your post was intended to simply back this conjecture: yes you're certainly right
that some maturity can be achieved a lot _faster_ using a dynamic language.
That's why our first language prototypes for Object Teams where based on Lua
and Ruby (the first was done in two days, roughly, the second was a master's
project, see our AOSD'03 paper). 
After first experiments we switched to Java because some things we wanted to do 
don't fit well into the world of dynamic languages, notably: static analysis of all kind.
The OT/J compiler supports 208 distinct diagnostics (errors/warnings), signaling
wrong or problematic usage of Object Teams constructs (one reason for wanting
this is to aid developers learning the language).
I wouldn't know how to give such detailed diagnostics for a dynamic language.
(Maybe Pascal will teach me ;-) . Has, e.g., anybody ever written a type checker
for family polymorphism for any dynamic language?)

Don't get me wrong, IF you are happy with a dynamic language, then you will
certainly be faster in extending your language and IDE.

For Object Teams we decided for a more static way (yet supporting dynamic
aspects at several levels!), and we did invest efforts in making our tool mature.
However, this was not an easy road, and researchers doing new projects should 
actually think twice before extending Java, because the price to invest is high!

best,
Stephan

-- 
--------------------------------------------------------------------------
 Dr. Stephan Herrmann
 Organizing Chair of ECOOP 2007 (July 30 - August 3)
        http://2007.ecoop.org
 ----------------
 Technische Universität Berlin
 Software Engineering Research Group
 http://swt.cs.tu-berlin.de/~stephan
 phone: ++49 30 314 73174         
--------------------------------------------------------------------------
-------------- next part --------------
After years of hard work by numerous smart people,
it is my great pleasure to announce the

                        1.0.0 Release
                            of the
            Object Teams Development Tooling (OTDT)

             www.objectteams.org/distrib/otdt.html


During the last months polishing the tool has continuously focused on:

Completeness: We have invested efforts so that the tool can handle more
  than "text book examples", meaning that all features of ObjectTeams/Java
  can be freely combined with each other and with all existing features of
  the host language Java 5. A test suite of over 1800 OT/J programs just for
  testing compiler and runtime gives evidence of the result of our efforts.
  Together with the tool, also the exhaustive language definition is
  released as OTJLD version 1.0, see:
    http://www.objectteams.org/def/1.0

Convenience: The OTDT, which is based on the Eclipse JDT 3.2.2, supports and
  extends all those features that make the JDT special, like:
  - syntactic and semantic highlighting
  - structural views like outline, type hierarchy, and call hierarchy
  - code assist (completion and quick fixes) etc.
  As an example of how these features have been extended for Object Teams
  consider the call hierarchy: normally this view only shows control flows
  caused by method calls. The OTDT extends this concept to include control
  flows that are induced by aspect binding ("callin" and "callout" bindings).

A comprehensive list of features can be found at
    http://www.objectteams.org/distrib/features.html

One of the most successful applications of ObjectTeams/Java and the OTDT
is the OTDT itself: significant parts of this tool have been developed
as aspect plug-ins extending and adapting existing plug-ins of Eclipse
and its JDT. This is made possible by OT/Equinox, the integration of the
Object Teams runtime with the Equinox framework underlying Eclipse.
Using OT/Equinox for the design and implementation of the OTDT we succeeded
in developing numerous adaptations, mostly to the JDT UI, that otherwise would
only be possible by copying and modifying large amounts of existing code.
By contrast, the OT/Equinox based solutions are small and well maintainable.

The full spectrum of information can be found on our freshly designed 
web site:
    http://www.objectteams.org

We hope you like it,
the Object Teams team