From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/10 Message-ID: #1/1 X-Deja-AN: 271349289 References: <33E9ADE9.4709@flash.net> <5upe9k$7he@newshub.atmnet.net> <5utag9$o6s@newshub.atmnet.net> Organization: New York University Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: Darren says <> 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!