Mixing P/R philosophy with OO (within J2EE).

"topmind" <topmind{}technologist.com> wrote in message
news:1177791341.487380.145770{}n76g2000hsh.googleg roups.com...
>
> Find a way to repackage ADA in C-like syntax, and it might have a
> second life. (I am not saying that C-style syntax is good, only that
> it seems to "sell" better.)
>
It is a little more than syntax that keeps people away
from Ada (not all caps; not an acronym). The curly-brace
model is all too simplistic and fails to provide the option
for compile-time checking found in Ada.

Also, beyond syntax is program structure. Ada makes
a clear distinction between what functionality is to be
implemented, and the how of that implementation. This
separation, which can be approximated in very clumsy
ways in C++, encourages an engineering view of the
development cycle.

Richard Riehle

adaworks{}sbcglobal.net wrote:

> One of the things I most like about Ada is that it has
> the most effective model of dependency management
> of any language I have found.

> Java's dependency model is awful. C++ is not much
> better. Eiffel still includes everything in a single compilation
> unit. Modula-2 and Modula-3 are pretty good.

Modula-2 is the same as (old) Ada.
All publically accessable aspects are in a "DEFINITION" module M.
All implementation aspects relating to the DEFINITION module (public
and not) are in the "IMPLEMENTATION" module M.

If you want to define true ADTs (information hiding) , Modula-2 uses the
concept of "opaque" types (a type that is named but not defined in the
DEFINITION module) .

These concepts are key to separate compilation.


> The nice thing about Ada is the ability to move dependencies
> to the exact point in a design structure where they are needed,
> thereby eliminating any need to worry about the recompilation
> of a module, in most cases. Also, the compiler keeps track of
> all the dependencies. There is no need for all the silly #IFNDEF
> absurdities one finds in C++.

Even C (via affiliated tools such as make) can build dependency graphs akin
to those used by Ada and Modula-2. The problem with C is #include, which is
a OS file-based mechanism where the module being built is effectively a
textual transitive closure of all the modules depended on (hence the much
longer compile times when compared to a similarly structured system in Ada
or Modula-2) .

But this does not stop a C compiler from creating/holding module
'summaries' etc for build management, akin to what Ada and Modula-2 do.
Perhaps some C compilers already do so (I am ignorant as to what is done by
past/current C compilers) .


Regards,
Steven Perryman

"S Perryman" <q{}q.net> wrote in message news:f12261$44v$1{}aioe.org...
>
> Modula-2 is the same as (old) Ada.
> All publically accessable aspects are in a "DEFINITION" module M.
> All implementation aspects relating to the DEFINITION module (public
> and not) are in the "IMPLEMENTATION" module M.
>
> If you want to define true ADTs (information hiding) , Modula-2 uses the
> concept of "opaque" types (a type that is named but not defined in the
> DEFINITION module) .
>
> These concepts are key to separate compilation.
>
When programming in Ada, I frequently design with opaque types.
However, I also design those types so they are extensible when I
want to support future options for inheritance.
>
> Even C (via affiliated tools such as make) can build dependency graphs akin to
> those used by Ada and Modula-2. The problem with C is #include, which is a OS
> file-based mechanism where the module being built is effectively a
> textual transitive closure of all the modules depended on (hence the much
> longer compile times when compared to a similarly structured system in Ada
> or Modula-2) .
>
The #include is, as you note, an OS issue rather than one built in to
the design of the language. Ada takes this a little further than the
Modula language and lets the designer push dependencies all the
way down to separately compiled subprograms. At the same time,
the compiler checks the consistency of those dependencies including
the conformance of all the associated interfaces. For large-scale
software designs, this is no small advantage. When one considers
the additional capabilities for separate compilation, added to the Ada
95 version of Ada, it becomes clear that the structural (and architectural)
capabilities offered in Ada are notably superior to those in most other
programming languages.
>
> But this does not stop a C compiler from creating/holding module
> 'summaries' etc for build management, akin to what Ada and Modula-2 do.
> Perhaps some C compilers already do so (I am ignorant as to what is done by
> past/current C compilers) .
>
Actually, it does not stop anyone from trying to emulate the capabilities of
Ada and Modula. But such attempts are certainly feeble. Morever, they
are not inherent in the C or C++ language and therefore not portable, not
widely understood by users of those languages, and completely non-standard.
>
Ada is not perfect. Nor is Modula-2 (or Modula-3). I know these languages
(especially Ada) well enough to have my own criticisms of some things in their
design, but when it comes to dependency management, there is no existing
language as well-designed as Ada for solving that particular problem.

Richard Riehle

On Apr 29, 6:27 pm, <adawo...{}sbcglobal.net> wrote:

"S Perryman" <q...{}q.net> wrote in message news:f12261$44v
$1{}aioe.org...

>> Even C (via affiliated tools such as make) can build dependency graphs akin to
>> those used by Ada and Modula-2. The problem with C is #include, which is a OS
>> file-based mechanism where the module being built is effectively a
>> textual transitive closure of all the modules depended on (hence the much
>> longer compile times when compared to a similarly structured system in Ada
>> or Modula-2) .

>The #include is, as you note, an OS issue rather than one built in to
>the design of the language.

It is both IMHO.

The 'textual closure' that #include implies, can lead to poor compiler
impls repeatedly parsing the same src modules. Not having explicit
dependency
declaration (Module-M.Component1, IMPORT Component1 FROM Module-M etc)
means
much more work for a compiler in discerning the true nature of the
dependencies.


>Ada takes this a little further than the Modula language and lets the
>designer push dependencies all the way down to separately compiled subprograms.

The same as Modula-2.


>At the same time, the compiler checks the consistency of those dependencies
>including the conformance of all the associated interfaces.

The same as Modula-2.


>> But this does not stop a C compiler from creating/holding module
>> 'summaries' etc for build management, akin to what Ada and Modula-2 do.
>> Perhaps some C compilers already do so (I am ignorant as to what is done by
>> past/current C compilers) .

>Actually, it does not stop anyone from trying to emulate the capabilities of
>Ada and Modula. But such attempts are certainly feeble.

Feeble is the wrong word. More appropriate IMHO is "complex" .

A C compiler would have to do more work to discern the dependencies
that an
Ada/Modula-2 compiler sees explicitly (Module-M.Component1, IMPORT
Component1
FROM Module-M etc) . But the dependencies can be discerned.


>Morever, they are not inherent in the C or C++ language and therefore not
>portable

Build dependency management by a C compiler does not have to be
portable, or
standard. All this does is optimise the compilation process. It
doesn't
affect the generation of 'binary object' components etc.


>not widely understood by users of those languages

IMHO the users of C understand the problem of the very long
compilation
times they see (or have seen) as a result of the C model. Especially
if they
have used prog langs akin to Ada and Modula-2.


> and completely non-standard.

See above. Also, if someone has a good compiler, good for them. If the
src
code is built for the same target with a worse compiler, the build
process
may be much slower. But the end outcome is always the same (I
hope :-) ) .


Regards,
Steven Perryman