[aosd-discuss] Orthogonality and the Don't Repeat Yourself Principle
costanza at iai.uni-bonn.de
Thu Jun 26 18:16:54 EDT 2003
Robin Green wrote:
> Interesting article here (especially for newcomers to AOSD)
> by the authors of "The Pragmatic Programmer: From Journeyman to Master":
> It covers two principles which I think are related to AOSD and Intentional
> 1. "DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."
This is also known as "once and only once". See
> 2. "The basic idea of orthogonality is that things that are not related conceptually should not be related in the system. Parts of the architecture that really have nothing to do with the other, such as the database and the UI, should not need to be changed together."
That's not breathtakingly new. Indeed, language research is about making
elements of your language orthogonal to each other, and that's really
the hard part.
> They also talk about code generators - unfortunately, without mentioning AOSD
> or reflection or any of the other alternatives to writing your own
> code generator from scratch. But I think it's clear that AOSD tools are an
> alternative, indeed a better alternative, in at least some cases. Indeed,
> I'd like to add a third fundamental principle of my own, which I think supports
> the idea of using more generic AOSD or intentional programming or reflection tools
> as opposed to writing code generators:
Hm, I don't think I completely understand you statement here. AOSD is
not about code generation - code generators are just one way to
implement AOSD. So I don't see in which way they are alternatives
because these two concepts are not on the same level.
Could you explain in more detail what you mean here?
> 3. "Green's Razor: Programming language keywords and syntax forms should not be
> multiplied beyond necessity, within a body of code." [*]
> So, rather than having a high-level domain specific
> language which is embedded into and translated into Java, and provides its own
> *arbitrarily* different arithmetic expression syntax, Java's own arithmetic expression
> forms should be used. Rather than inventing a new pointcut syntax, AspectJ should
> be used, unless there is something you need that AspectJ can't easily do.
> And rather than embedding SQL inside Java which in turn is
> embedded in JSP, a new language should be developed[**] which provides all of the
> functional advantages of all three languages - and more - without the messiness of
> having three different "levels", all with their own different syntax rules,
> "type system", expression syntax etc, and without the sometime-fragility and
> complexity of code generation via string substitution.
It seems to me that all of these things can be achieved with structural
macros, as provided by Lisp, Dylan, Maya or Java Syntactic Extender, for
example. Or do you think there's more to this?
Pascal Costanza University of Bonn
mailto:costanza at web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
More information about the discuss