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

[Miguel Pessoa Monteiro]

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

Impressive!


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

Well, some corageous people is already using AOP tools and languages on
real projects :-), most notably AspectJ. But I get you point.


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

If one must be really rigorous, no. But note that many reasearch work,
including thesis, justifies using AspectJ as a representative of AOP on
account of AspectJ being the most "mature" tool available.

> So, why exactly are you asking your question? Which answer best suits
> your question would depend on your motivation for asking, I guess.

It is due to something that I'm writing. I wanted to assess how reasonably
it would be to claim that AspectJ is currently the only mature enough
language to merit adoption by industry. I no longer propose to make that
claim. My thanks to all those that replied to my original post.


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

Cool!


Cheers,
Miguel


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

-- 
Miguel P. Monteiro          | cell phone +351 96 700 35 45
Departamento de Informática | Phone +351 21 294 8536 ext. 10708
Faculdade Ciências e Tecnol.| Fax: +351 21 294 8541
Universidade Nova de Lisboa | mmonteiro [at] di fct unl pt
2829-516 Caparica, PORTUGAL | URL: http://ctp.di.fct.unl.pt/~mpm