Re: Separation of IF and Imp: process issue?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Darren says

<<I understand the rationale. I just disagree with it. :-)

My point was that since changing the spec means you have to go talk to
everyone concerned anyway, I don't see the advantage of putting it in
a separate file.>>

That's a very informal view of things, corresponding to a few people working
together without any kind of formal CM. In such an environment, word of
mouth can substitute for many things.

But in a managed environment, such as might correspond to a shop operating
at CMM level 3 at least, things need to be much more formal, and in particular
a CM system and procedures are at the heart of the methodology.

A fundamental point is that changes to specs must be handled far
differently from changes to bodies. I doubt you would see anyone trying
to register an ISO9000 procedure that said "talk to everyone if you
change a spec"!

Instead, there must be a very clear notion of who can change a spec, under
what conditions, and following what procedures, and these rules must be
embodied into the CM system, and will be quite different for specs and
bodies.

Yes, one can always imagine a CM system that is highly knowledgable about
the particular language you are using, and does all kinds of amazing things,
but in my experience, such speculations tend to be more in the category of
wishful thinking than in real use.

By separating the spec into a a file of its own, a CM system that is file
based can provide many of the required procedures WITHOUT particularly 
being language knowledgeable. For example, even if you are using a very
simple minded revision control system such as RCS as the center piece of
your CM system, you can set access control lists differently for specs
and bodies. Yes, yes, I know that many would not even consider RCS to
qualify as a CM system, but the point is that even with a very simple
minded tool you can get most of the effect you want. If you use a more
sophisticated tool, such as Continuus, Clearcase, or CVS, then you will
find there is still a basic model that the file is the unit of control,
and the separation of specs and bodies into separate files makes it far
easier to integrate Ada effectively into such tools.

It is remarkable to me that *no one* has responded to my request for actual
experiences in using Eiffel in such CM systems. If I asked the same questin
of the Ada community, I would find scads of replies (I know many of our
customers who are using these tools, and we ourselves at ACT depend on the
file orientation for our control internally).

Darrien says he disagrees with the rationale, but is this based on
experience? Darrien, have you worked with large Ada systems organized
in this manner? My experience is that virtually all of those who have
find this to be one of the really important advantages of Ada.

I often find that people who have never used a language feature don't
understand its utility. I would not look to a C programmer to understand
the importance of fixed-point built into a language, I would not look to
a Fortran programmer to understand the importance of type abstraction or
recursion, I would not look to an Ada programmer using a non-GC versoin
of Adda to understand the importance of GC, etc.

If you are using a tool which you find entirely satisfactory for your
purposes, it is natural to assume that any features it lacks cannot be
important (sometimes this attitude approaches fanaticism, especially in
the operating system area).

If you are an Eiffel programmer, and you see no possible advantages in
Ada, it can only be because you are insuffiently aware of Ada.

But on the other hand, if you are an Ada programmer, and you see no
possible advantages in Eiffel, it can only be because you are insuffiently
aware of Eiffel.

Actually this statement pretty much applies to any pair of languages, foir
example

If you are an Ada or Eiffel programmer and you see no possible advantages
in COBOL, it can only be because you are insuffiently aware of COBOL.

The last is more shocking to some, because so many people in the PL field
assume COBOL is junk without knowing anything about it, and without knowing
its important advantages!