Everything

Responding to Gerardvignes...

I've been looking at Aspect Oriented Programming (AOP - weaving or
runtime) and Attribute Oriented Programming (@OP - directives or
attributes use to mark up code).

I wonder if either of these trends can justify being touted as the
next generation of software development?

I can't speak to @OP because I don't know much about it. However, I would be skeptical about any approach involving markups at the design level. Markup languages were very popular in the '50s and '60s. But they were largely abandoned in the '70s because they tend to be difficult to maintain.

AOP, OTOH, is very useful. For example, it is commonly employed in transformation engines that do full code generation from OOA models. For example, relationships are treated as generic, cross-cutting concerns in the transformation rules. [Interestingly, they are actually implemented in the target code like markup fragments overlaid on base object code; but one does not have to maintain the target code in translation environments. B-)]

While quite useful, I don't see AOP as a paradigm shift. Rather I see it as a complimentary evolution of OO techniques, rather like design patterns.


Structured Design was a great step forward.

Object Oriented has been an even greater step forward.

I believe that the next major innovation in software development will
have to address separation of concerns and it will contine to demand
more from pre-processors, compilers and runtime environments.

I am biased, but I believe translation is the next logical paradigm shift for the industry. When I started out there was virtually no automation; my first program was on a plugboard -- direct 1s and 0s into the hardware -- part of a programer's job description was changing vacuum tubes. 3GLs were an academic curiosity and BAL was the Silver Bullet to solve the Software Crisis.

We have seen a steady evolution of automation in the decades since. The first major paradigm shift was from BAL to 3GLs (amid much kicking an screaming about how 3GLs sacrificed too much control). Specific niches like CRUD/USER processing have carried automation very nearly to the 4GL level, as in RAD IDEs. We are also flooded with WYSIWYG UI or web site builders and other specialized tools to provide high levels of automation. Many core IT domains are addressed with OTS commercial software packages that are tailored parametrically. Round-trip tools are providing steadily increasing amounts of automatic code generation beyond just header files and body stubs.

However, the entire computing space is very rigorously defined in mathematical terms. So it may be very complex, but it is also quite deterministic. As a result the entire computing space is subject to automation; it is basically just an engineering problem in search of resources.

Translation tools were providing 100% code generation from OOA models in the early '80s. Alas, it took until the late '90s for the engineering to provide competitive optimization for nonfunctional requirements because the optimization problems faced were much broader than those faced by 3GL compilers. However, today there are several translation tools on the market that can provide decent optimization for general purpose computing. Basically only three things stand in the way of general acceptance of 4GL development:

(1) Translation requires a sea change in the way software is developed. Everything from configuration management to testing changes. That sort of fundamental change is spelled R-I-S-K by managers. This is currently the primary bar to general acceptance of translation.

(2) Transformation engines are not cheap. They are quite complex and vendors need to recapture their investment. So we have a Catch-22: the current market is too small so vendors need to charge Big Bucks, but the cost impedes market expansion.

(3) Transformation engines do what one says, not what one meant. So the OOA models need to be created with a methodological rigor that one does not usually associate with traditional OOA. For example, to qualify as a 4GL it must be possible to implement the model unambiguously in /any/ computing environment (synchronous, asynchronous, concurrent, distributed, etc.). So all of the translation methodologies employ state machines and an asynchronous behavior communication model in the OOA because that is the most general description of behavior. Not too many developers outside of R-T/E have that skill set, so there is a learning curve.

There was similar resistance to 3GLs over BAL. However, the benefits in things like productivity and reliability are far greater between 3GL/4GL that they were for 2GL/3GL for today's mega-applications. For example, refactoring code for maintainability sucks up substantial resources. But that problem only exists at the 3GL level due to physical coupling in the 3GLs and their type systems. Thus no refactoring is necessary at the OOA level. Not to mention the benefits of only needing to focus on the functional requirements while the transformation engine deals with the nonfunctional requirements. Or the fact that the 4GL is roughly an order of magnitude more compact in describing the solution. So the paradigm shift is inevitable; it just a question of time.

[Several years ago in a conference keynote address Ivar Jacobson predicted that within a decade 3GL programmers would be as rare as Assembly programmers today. He was a bit off in the timing, but not the inevitability. Note that many large software houses (IBM, Mentor, CA, Telelogics, etc.) have been buying translation tool vendors to create a market position. (There are only two independent translation vendors left who have been around for a decade of more.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Enhanced Unicode support for "Go" tools
    ... > Programmers in the Assembly arena... ... that the Japanese don't just program but almost take things "too ... translation kind of missed the target there a little...it ... computer markets like that then a skill that could "bridge the ...
    (alt.lang.asm)
  • Re: Translation
    ... programmers who program only in VB lack nearly all the basics of programming. ... VB is not a programmign language, so the translation from UML ... one runs exactly the same test suite for functional requirements against the executable as one runs against the OOA model; ... The answer to the second question is that problems still need to be solved; the developers just solve them at a much higher level of abstraction. ...
    (comp.object)
  • international excel issues
    ... Creating an excel-document using automation seems to be a national dependent process ... it works to create the document using my program on a computer with an english installation of excel. ... But not if the installation language is swedish. ... People that claims that you always can use the english translation and it will ...
    (microsoft.public.office.developer.automation)
  • international excel issues
    ... Creating an excel-document using automation seems to be a national dependent process ... it works to create the document using my program on a computer with an english installation of excel. ... But not if the installation language is swedish. ... People that claims that you always can use the english translation and it will ...
    (microsoft.public.excel.programming)
  • Re: Advantages of C++ over C - request for information
    ... > Kamil Burzynski wrote: ... > programmers) would have us believe. ... Can you hurt yourself (and ... Translation: "I can write bad code in any language." ...
    (comp.lang.cpp)