* Another important feature of Ada @ 2000-11-15 3:32 James Rogers 2000-11-15 0:00 ` mjsilva ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: James Rogers @ 2000-11-15 3:32 UTC (permalink / raw) I have been following a thread between comp.lang.eiffel and comp.lang.c++.moderated. The thread is boiling down to a discussion of the virtues and vices of separating interface from implementation. The points being made against sepration of interface and implementation focus on a concept that duplication of code is BAD, and separation of interface and implementation requires some duplication of code. The points being made in favor of separation of interface and implementation are that separation more fully supports the needs of large scale software development teams. C++ supports this separation by means of the #include syntax inherited from C. Of course, the problem with the #include syntax is that it does not enforce the separation of interface and implementation. As in many other features of C/C++, this is left up to the discipline of the software developer. It is interesting that Ada has been cited as being possibly the perfect example of a language fully supporting and enfocing the separation of interface and implementation through the use of Ada bodies and specifications. Eiffel programmers feel separation of interface and implemenation is not beneficial because large Eiffel programs have been constructed without this feature. This is like saying that we do not need to have hammers in our toolbox. Any sufficiently large wrench can be used as a hammer with success. It is also possible that those same Eiffel programmers have never actually tried to produce large scale software, but only know of someone who has. This would naturally lead to the assumption that no particular problems were encountered due to a lack of separation of interface and implementation. Jim Rogers Colorado Springs, Colorado ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 3:32 Another important feature of Ada James Rogers @ 2000-11-15 0:00 ` mjsilva 2000-11-15 0:00 ` Brian Rogoff 2000-11-15 0:00 ` Mark T ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: mjsilva @ 2000-11-15 0:00 UTC (permalink / raw) In article <3A12041B.BCFD8CA0@worldnet.att.net>, James Rogers <jimmaureenrogers@worldnet.att.net> wrote: > I have been following a thread between comp.lang.eiffel and > comp.lang.c++.moderated. The thread is boiling down to a discussion of > the virtues and vices of separating interface from implementation. > > The points being made against sepration of interface and implementation > focus on a concept that duplication of code is BAD, and separation > of interface and implementation requires some duplication of code. I wonder how it could be otherwise? >... > Eiffel programmers feel separation of interface and implemenation is > not beneficial because large Eiffel programs have been constructed > without this feature. I would expect Eiffel programmers of all people to appreciate that an interface is a form of contract! Mike Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` mjsilva @ 2000-11-15 0:00 ` Brian Rogoff 2000-11-17 0:00 ` Scott Ingram 0 siblings, 1 reply; 23+ messages in thread From: Brian Rogoff @ 2000-11-15 0:00 UTC (permalink / raw) On Wed, 15 Nov 2000 mjsilva@my-deja.com wrote: > In article <3A12041B.BCFD8CA0@worldnet.att.net>, > James Rogers <jimmaureenrogers@worldnet.att.net> wrote: > > I have been following a thread between comp.lang.eiffel and > > comp.lang.c++.moderated. The thread is boiling down to a discussion of > > the virtues and vices of separating interface from implementation. > > > > The points being made against sepration of interface and > implementation > > focus on a concept that duplication of code is BAD, and separation > > of interface and implementation requires some duplication of code. > > I wonder how it could be otherwise? In Ocaml, the interface file contains ony the type signature of functions in the implementation file, and there is no need to repeat the type information again in the implementation file. So admittedly there is some duplication (the name of a function) but much less than in Ada. There is actually no need to right a .mli file (equivalent to a .ads in GNAT) for each .ml (= .adb) unless you want to restrict what is visible or provide the ability for others to compile without the full implementation. However, this duplication has never been a significant issue for me in Ada, or even C (my C code is very Ada-like) so I often wonder why people whine about this so much. I did a bit of programming in Sather and Eiffel a while ago and I have to admit that while there are lots of nice features in those languages I prefer Ada, and this separation, redundancy and all, plays a large part in that preference. -- Brian ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` Brian Rogoff @ 2000-11-17 0:00 ` Scott Ingram 0 siblings, 0 replies; 23+ messages in thread From: Scott Ingram @ 2000-11-17 0:00 UTC (permalink / raw) Brian Rogoff wrote: > Ada, or even C (my C code is very Ada-like) so I often wonder why people During a break at SIGAda 2000, a small group of us got a chuckle out of the fact that our C code looks suspiciously like Ada :-) -- Scott Ingram Vice-Chair, Baltimore SIGAda Sonar Processing and Analysis Laboratory Johns Hopkins University Applied Physics Laboratory ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 3:32 Another important feature of Ada James Rogers 2000-11-15 0:00 ` mjsilva @ 2000-11-15 0:00 ` Mark T 2000-11-15 0:00 ` Tucker Taft 2000-11-19 0:00 ` Lao Xiao Hai 2000-11-20 0:00 ` Michel Gauthier 3 siblings, 1 reply; 23+ messages in thread From: Mark T @ 2000-11-15 0:00 UTC (permalink / raw) > C++ supports this separation by means of the #include syntax inherited > from C. Of course, the problem with the #include syntax is that it > does not enforce the separation of interface and implementation. As > in many other features of C/C++, this is left up to the discipline of > the software developer. > > It is interesting that Ada has been cited as being possibly the perfect > example of a language fully supporting and enfocing the separation of > interface and implementation through the use of Ada bodies and > specifications. > I do more C programming than Ada, but until I learned Ada I did not fully appreciate "programming to an interface". I think it is one of the best ways to get users of your modules to ignore the inner workings and utilize the blackbox specification. When you have a 100,000 lines of code everbody on the project can't be an expert on every LOC. The small amount of subroutine name duplication doesn't seem to be much of problem versus the benefit gained. On the other hand, the interface specification should fully point out any limitations, etc, a "contract" needs to be fully defined for usage of that module. (Sometimes programmers like to bury this info in the implementation). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` Mark T @ 2000-11-15 0:00 ` Tucker Taft 2000-11-15 0:00 ` Ed Falis 2000-11-15 0:00 ` Laurent Guerby 0 siblings, 2 replies; 23+ messages in thread From: Tucker Taft @ 2000-11-15 0:00 UTC (permalink / raw) I also believe strongly in the value of separating interface and implementation. Whenever I discuss this issue, I generally fall back on the analogy of a legal contract, where it would be frightening to have to ask the company working for you to give you "today's contract," which they will extract from the current work in progress. This is essentially the story in Java and Eiffel with classes, where there is no separate spec, but you can extract the "contract" from the implementation. Of course, Java has "interfaces" and Eiffel has "deferred classes," but there is a lot of code which is not just implementing one of these, and all of that code has no physically separate "contract" defining what it does. Not cool in my view. From anecdotal experience, the fact that Ada has separate package specs is very helpful in getting developers to focus on the notion of an interface. With Java, that seems to be getting lost again. -Tucker Taft stt@averstar.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` Tucker Taft @ 2000-11-15 0:00 ` Ed Falis 2000-11-17 0:00 ` Jean-Pierre Rosen 2000-11-15 0:00 ` Laurent Guerby 1 sibling, 1 reply; 23+ messages in thread From: Ed Falis @ 2000-11-15 0:00 UTC (permalink / raw) Well, I'm going to be a bit heretical here, having done a little Eiffel programming and a lot of Ada programming. DbC in conjunction with the tool-enabled extraction of interfaces, and the use of deferred classes, more than makes up for the lack of physical separation. The "little" Eiffel I did was several thousand lines of a GUI tool. It worked rather nicely. In the end, it strikes me as a wash, since I can do more or less the same in Ada as Eiffel DbC using asserts and (in the case of gnat, pragma debug to provide inherited contracts and overrides). The Eiffel DbC capabilities take less work to accomplish the same end. The Eiffel ability to present only the interface in the IDE is less work than separately writing specs and bodies. And fully deferred classes handle the pragmatic need for control of interfaces separate from implementations by different stakeholders. Both languages accomplish similar goals, and it seems a matter of taste as to which to prefer. These languages have more in common than most. - Ed Tucker Taft wrote: > I also believe strongly in the value of separating interface and > implementation. > > Whenever I discuss this issue, I generally fall back on the analogy of > a legal contract, where it would be frightening to have to ask the > company working > for you to give you "today's contract," which they will extract from > the current work in progress. > > This is essentially the story in Java and Eiffel with classes, > where there is no separate spec, but you can > extract the "contract" from the implementation. Of course, Java has > "interfaces" and Eiffel has "deferred classes," but there is a lot of > code which is not just implementing one of these, and all of that > code has no physically separate "contract" defining what it does. > > Not cool in my view. > > From anecdotal experience, the fact that Ada has separate package > specs > is very helpful in getting developers to focus on the notion of an > interface. With Java, that seems to be getting lost again. > > -Tucker Taft stt@averstar.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` Ed Falis @ 2000-11-17 0:00 ` Jean-Pierre Rosen 2000-11-18 0:00 ` Ed Falis 0 siblings, 1 reply; 23+ messages in thread From: Jean-Pierre Rosen @ 2000-11-17 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1399 bytes --] "Ed Falis" <efalis@mediaone.net> a �crit dans le message news: PM000376263FFF6F15@Dogen.ne.mediaone.net... > In the end, it strikes me as a wash, since I can do more or less the > same in Ada as Eiffel DbC using asserts and (in the case of gnat, pragma > debug to provide inherited contracts and overrides). The Eiffel DbC > capabilities take less work to accomplish the same end. The Eiffel > ability to present only the interface in the IDE is less work than > separately writing specs and bodies. And fully deferred classes handle > the pragmatic need for control of interfaces separate from > implementations by different stakeholders. Both languages accomplish > similar goals, and it seems a matter of taste as to which to prefer. > These languages have more in common than most. > The importance of separating specs from bodies is *not* the ability to view them separatly, which can be accomplished with a tool as you note. It is the ability to compile the spec, and compile users of the spec before even thinking about the implementation. Therefore you can check the spec, and check that the spec matches the needs without being influenced by implementation constraints (which often leads to over-specification). -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-17 0:00 ` Jean-Pierre Rosen @ 2000-11-18 0:00 ` Ed Falis 2000-11-18 0:00 ` Karel Thoenissen 2000-11-18 0:00 ` pete 0 siblings, 2 replies; 23+ messages in thread From: Ed Falis @ 2000-11-18 0:00 UTC (permalink / raw) Jean-Pierre Rosen wrote: > The importance of separating specs from bodies is *not* the ability to > view them separatly, which can be accomplished with a tool as > you note. It is the ability to compile the spec, and compile users of > the spec before even thinking about the implementation. > Therefore you can check the spec, and check that the spec matches the > needs without being influenced by implementation constraints > (which often leads to over-specification). Yes, I should have mentioned that this is easily (and often) done in Eiffel using completely deferred classes with assertions. A deferred class is similar to an abstract tagged type in a package. I agree with your point about the value of being able to compile against unimplemented specs - it's always been one of my favorite aspects of Ada. But the same effect can be achieved otherwise. - Ed ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-18 0:00 ` Ed Falis @ 2000-11-18 0:00 ` Karel Thoenissen 2000-11-18 0:00 ` pete 1 sibling, 0 replies; 23+ messages in thread From: Karel Thoenissen @ 2000-11-18 0:00 UTC (permalink / raw) Ed Falis schreef: > Jean-Pierre Rosen wrote: > > > The importance of separating specs from bodies is *not* the ability to > > view them separatly, which can be accomplished with a tool as > > you note. It is the ability to compile the spec, and compile users of > > the spec before even thinking about the implementation. > > Therefore you can check the spec, and check that the spec matches the > > needs without being influenced by implementation constraints > > (which often leads to over-specification). > > Yes, I should have mentioned that this is easily (and often) done in > Eiffel using completely deferred classes with assertions. A deferred > class is similar to an abstract tagged type in a package. > > I agree with your point about the value of being able to compile against > unimplemented specs - it's always been one of my favorite aspects of > Ada. But the same effect can be achieved otherwise. > > - Ed True, but at the cost of doubling the number of classes in the hierarchy and spilling the name space. -- Groeten, Karel Th�nissen ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-18 0:00 ` Ed Falis 2000-11-18 0:00 ` Karel Thoenissen @ 2000-11-18 0:00 ` pete 2000-11-19 0:00 ` Jean-Pierre Rosen 2000-11-19 0:00 ` James Rogers 1 sibling, 2 replies; 23+ messages in thread From: pete @ 2000-11-18 0:00 UTC (permalink / raw) In article <PM0003765BB967CEAE@Dogen.ne.mediaone.net>, Ed says... > >I agree with your point about the value of being able to compile against >unimplemented specs - it's always been one of my favorite aspects of >Ada. But the same effect can be achieved otherwise. not sure that compiling against unimplemented specs is that important. after all, you are just checking compiler syntax errors, and checking against any mismatched types. And you can do that in almost any other language. In Java for example using interfaces, and in C++ using pure virtual functions. And in practice, it is only after running the program against the actual implementation that one finds for sure if the interface is the right one, also many times the interface is changed as development goes on. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-18 0:00 ` pete @ 2000-11-19 0:00 ` Jean-Pierre Rosen 2000-11-19 0:00 ` James Rogers 1 sibling, 0 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2000-11-19 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2196 bytes --] "pete@nospam" <pete_member@newsguy.com> a �crit dans le message news: 8v78bm01p5t@drn.newsguy.com... > not sure that compiling against unimplemented specs is that important. > after all, you are just checking compiler syntax errors, and checking > against any mismatched types. And you can do that in almost any > other language. In Java for example using interfaces, and in C++ using > pure virtual functions. Sure, a compiler only detects violation of language rules - which in Ada goes far further than just syntax. Now; if you just use Ada like any low level language like Java, (i.e. you use only integer and other machine types), then it won't bring you much. If you really use all the expressive power of Ada to really model your domain problem, then you'll find that quite often, an error in your analysis will show up as an error when you compile or use your spec. That's certainly how it works for me. (Was qualifying Java "low level language" a troll ? Well, Java is AFAIK the only language that makes it explicit in its definition that it can run only on one single machine, and whose basic semantic model is totally dependant on the behaviour of that machine. The fact that this machine can be emulated on other machines is irrelevant). > And in practice, it is only after running the program against the > actual implementation that one finds for sure if the interface is > the right one, also many times the interface is changed as development > goes on. > This is exactly what we try to avoid, and may mean that maybe you just didn't use Ada to the full extent of its expressive power. Sure, an interface is never perfect right from the start, but the requirements dictate the interface, and you don't need any body to check that. Note also that the separation of specs and body make it extremely convenient to first develop a prototype body just to check dynamic semantic, then provide the actual implementation. Since you don't duplicate the spec, you are sure that the prototype and the actual match. -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-18 0:00 ` pete 2000-11-19 0:00 ` Jean-Pierre Rosen @ 2000-11-19 0:00 ` James Rogers 2000-11-19 0:00 ` David Starner 2000-11-19 0:00 ` Ray Blaak 1 sibling, 2 replies; 23+ messages in thread From: James Rogers @ 2000-11-19 0:00 UTC (permalink / raw) "pete@nospam" wrote: > > In article <PM0003765BB967CEAE@Dogen.ne.mediaone.net>, Ed says... > > > > >I agree with your point about the value of being able to compile against > >unimplemented specs - it's always been one of my favorite aspects of > >Ada. But the same effect can be achieved otherwise. > > not sure that compiling against unimplemented specs is that important. > after all, you are just checking compiler syntax errors, and checking > against any mismatched types. And you can do that in almost any > other language. In Java for example using interfaces, and in C++ using > pure virtual functions. Java's interfaces are not a good example of a tool for separating interface from implementation because they are a special case for the language. It is impossible to define a Java interface such that the interface defines all the public, default, and protected members (data and methods) defined in every class implementing that interface. Java classes can inherit from exactly one class, either one explicitly declared with an "extends" clause, or implicitly extending the Object class. At the same time a Java class may implement any number of interfaces. The term any number maps pretty closely to the Ada Natural subtype. Given that a class does not need to implement any interface, how can interfaces be a solution to the complete separation of interface and implementation. Given that any class implementing an interface extends some other class, and may implement several interfaces, how can a Java interface be a solution to this problem? It cannot. Pure virtual functions are similar to Ada abstract subprograms. This is not the technique commonly used in C++ to separate interface from implementation. The commonly used technique is the preprocessor. The interface is commonly defined in the C++ header files, while the implementation is defined in the C++ source files (.cpp or .C files). The problem with using C++ header files is that the C++ language has no restriction upon the contents of a header file. It is possible to mix interface and implementation in a header file. Only programmer discipline can prevent such a mixing. > And in practice, it is only after running the program against the > actual implementation that one finds for sure if the interface is > the right one, also many times the interface is changed as development > goes on. > This of course reveals a process problem in several development projects. The reason for changing interfaces is most often because insufficient analysis and design work was done before beginning implementation. The only time I have seen it necessary to change the interface definitions has been when new requirements are levied on the project after analysis and design is complete. This, again, is a process problem. The separation of interface and implementation is still useful in this case as it allows the design team to clearly identify the current design problems and develop design alternatives. Many times the interfaces do not need to be changed. Instead, some new packages may be needed. Note that performance issues have no impact upon the separtation of interface and implementation since they are handled purely in the implementation. Jim Rogers Colorado Springs, Colorado ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-19 0:00 ` James Rogers @ 2000-11-19 0:00 ` David Starner 2000-11-19 0:00 ` Ray Blaak 1 sibling, 0 replies; 23+ messages in thread From: David Starner @ 2000-11-19 0:00 UTC (permalink / raw) On Sun, 19 Nov 2000 20:24:27 GMT, James Rogers wrote: >This of course reveals a process problem in several development >projects. The reason for changing interfaces is most often because >insufficient analysis and design work was done before beginning >implementation. The only time I have seen it necessary to change the >interface definitions has been when new requirements are levied on the >project after analysis and design is complete. This, again, is a >process problem. It depends on your system. If you're building something like the air traffic control system someone was talking about, with a clear design and only maintaince updates, then, yes, it's a process problem. But Linux's original design goals (runs on 386, works for Linus) differ enormously from the current requirements. To blame Linus Torvalds for that is basically to blame him for not being omniscient. Likewise with Windows ("the average user couldn't care less whether we support TCP/IP") and Netscape ("like anyone's going to use a mail reader that comes with their web browser"). -- David Starner - dstarner98@aasaa.ofe.org http://dvdeug.dhis.org As centuries of pulp novels and late-night Christian broadcasting have taught us, anything we don't understand can be used for the purposes of Evil. -- Kenneth Hite, Suppressed Transmissions ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-19 0:00 ` James Rogers 2000-11-19 0:00 ` David Starner @ 2000-11-19 0:00 ` Ray Blaak 2000-11-20 2:39 ` Robert Dewar 2000-11-20 7:47 ` Ehud Lamm 1 sibling, 2 replies; 23+ messages in thread From: Ray Blaak @ 2000-11-19 0:00 UTC (permalink / raw) James Rogers <jimmaureenrogers@worldnet.att.net> writes: > "pete@nospam" wrote: > > And in practice, it is only after running the program against the > > actual implementation that one finds for sure if the interface is > > the right one, also many times the interface is changed as development > > goes on. > > This of course reveals a process problem in several development > projects. The reason for changing interfaces is most often because > insufficient analysis and design work was done before beginning > implementation. The only time I have seen it necessary to change the > interface definitions has been when new requirements are levied on the > project after analysis and design is complete. This, again, is a > process problem. So says the official dogma. It sounds good on paper, but in my experience almost all interfaces need some modification after coding starts and people can actually start using it. I suppose you could say that I am unfortunate enough to have always worked on projects with process problems, but I don't think so. The need for modifications happen even on rabidly paranoid air traffic control projects whose process (I think) is excellent. Certainly the major design aspects of an interface should have been worked out in advance, but the details due to language and environment can drive usage patterns in particular ways that the designers simply cannot forsee until coding (e.g. "oh wow! this 3rd party library expects to be able to cache its data; I guess our data items need to be able to be cacheable across threads after all"). Instead, it is better to always expect change, and to struture your designs and abstractions so that they can readily be augmented, reimplemented, etc. New requirements always happen. Unexpected gotchas always get you. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-19 0:00 ` Ray Blaak @ 2000-11-20 2:39 ` Robert Dewar 2000-11-20 7:43 ` Ehud Lamm 2000-11-21 0:00 ` Ray Blaak 2000-11-20 7:47 ` Ehud Lamm 1 sibling, 2 replies; 23+ messages in thread From: Robert Dewar @ 2000-11-20 2:39 UTC (permalink / raw) In article <u66ljih85.fsf@infomatch.com>, Ray Blaak <blaak@infomatch.com> wrote: > It sounds good on paper, but in my experience almost all > interfaces need some modification after coding starts and > people can actually start using it. That's too pessimistic in the opposite direction. Whether interfaces can remain stable depends on several things: 1. The quality and effort of work to design the interfaces 2. How well defined the project is 3. How well organized the project is 4. Cohesiveness of the team doing the work Certainly I can give a counter example. In the mid 70's I did a real time operating system, PD/FMS for Incoterm/Honeywell. Itwas roughly similar to say the VxWorks kernel, with a complete set of tools (assemblers, linkers, file system including full indexed files, system utilities, editor, shells etc) to support program development. The entire system was approximately half a million lines of assembly language, including comments, and it was perhaps half comments. The way I proceeded was first to write the entire programmers reference manual for the kernel with full details of all callings sequences for thread scheduling etc, and the full users manual for the program development system. These manuals were edited into something very close to the final form in which they were delivered to customers, with discussion on details *before a single line of code was written*, and the only changes were very minor (mostly style editing) from then to the final release. The system was quite successful and was used in some 10,000 sites. My favorite note was from one person who some years later was forced to switch from PD/FMS to Unix, and was complaining that it seemed a big step backwards :-) Of course it helps to have a one person project, since it is easier to keep everything under control and organized, but I think this same discipline can be applied to many other projects. I would agree you can't achieve it with all projects, but it is a legitimate and reasonably goal, and it is giving up too easily to decide that it will fail in "almost all" cases. Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-20 2:39 ` Robert Dewar @ 2000-11-20 7:43 ` Ehud Lamm 2000-11-21 0:00 ` Ray Blaak 1 sibling, 0 replies; 23+ messages in thread From: Ehud Lamm @ 2000-11-20 7:43 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> wrote in message news:8va2tf$c9l$1@nnrp1.deja.com... > In article <u66ljih85.fsf@infomatch.com>, > Ray Blaak <blaak@infomatch.com> wrote: > > > It sounds good on paper, but in my experience almost all > > interfaces need some modification after coding starts and > > people can actually start using it. > > That's too pessimistic in the opposite direction. Whether > interfaces can remain stable depends on several things: > [snip] > > Certainly I can give a counter example. In the mid 70's I > did a real time operating system, PD/FMS for Incoterm/Honeywell. > Itwas roughly similar to say the VxWorks kernel, with a complete > set of tools (assemblers, linkers, file system including full > indexed files, system utilities, editor, shells etc) to support > program development. [snip] > > The way I proceeded was first to write the entire programmers > reference manual for the kernel with full details of all > callings sequences for thread scheduling etc, and the full > users manual for the program development system. These manuals > were edited into something very close to the final form in which > they were delivered to customers, with discussion on details > *before a single line of code was written*, and the only changes > were very minor (mostly style editing) from then to the final > release. This reminds my of Brook's discussion of OS/360 in the "The Mythical Man-Month." I totally agree with the approach you describe. One thing I think important to consider is that there are several levels of interfaces inside a (complex) SW system. I am still not sure that they are all really in the same family, aside from the very general trait of being interfaces. Some interface, as we all know, are between two internal components. Indeed, one thing I find problematic for some students is realizing that even if a component is internal, it had better be documented (at least in a cursory way), and seperated from the code using it (even if there is currently one user). Why am I belaboring all of this? Becuase the "low level" internal interfaces are usually those that people tend to think can be changed (sometimes each day...), and they are usually those that seem not to be documented. Survey: How many sw projects that use stacks, document their "stack" interface (assume these stacks are invisible to users)? Not that I am saying this is good SE. But we should realize this happens, even in pretty well organized projects (not the best, but many good projects). I am wonderring about enhancing the support for different levels of interfaces. My gut feeling is that the current state of the art in language design is not there yet. (Of course, as you example shows, you can do it all - and well - in assembly language). -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== Me! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-20 2:39 ` Robert Dewar 2000-11-20 7:43 ` Ehud Lamm @ 2000-11-21 0:00 ` Ray Blaak 2000-11-21 0:00 ` Robert Dewar 1 sibling, 1 reply; 23+ messages in thread From: Ray Blaak @ 2000-11-21 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > I would agree you can't achieve it with all projects, but it is > a legitimate and reasonably goal, and it is giving up too easily > to decide that it will fail in "almost all" cases. Certainly you should try very hard to get things correct right up front. What I object to, however, is the idea that changes that happen once coding starts is necessarily a sign of process problems. It very well could be, but not necessarily so. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-21 0:00 ` Ray Blaak @ 2000-11-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 23+ messages in thread From: Robert Dewar @ 2000-11-21 0:00 UTC (permalink / raw) In article <u8zqd19xu.fsf@infomatch.com>, Ray Blaak <blaak@infomatch.com> wrote: > What I object to, however, is the idea that changes that > happen once coding starts is necessarily a sign of process > problems. It very well could be, but not necessarily so. Indeed -- if the customer changes their minds about what they want, if all you can do is to refuse to adapt and mutter something about "process problems", you are hardly being responsive :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-19 0:00 ` Ray Blaak 2000-11-20 2:39 ` Robert Dewar @ 2000-11-20 7:47 ` Ehud Lamm 1 sibling, 0 replies; 23+ messages in thread From: Ehud Lamm @ 2000-11-20 7:47 UTC (permalink / raw) Ray Blaak <blaak@infomatch.com> wrote in message news:u66ljih85.fsf@infomatch.com... > Instead, it is better to always expect change, and to struture your designs > and abstractions so that they can readily be augmented, reimplemented, etc. > I agree. Expect change, but try to avoid the need for it. You can achieve both goals. -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== Me! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 0:00 ` Tucker Taft 2000-11-15 0:00 ` Ed Falis @ 2000-11-15 0:00 ` Laurent Guerby 1 sibling, 0 replies; 23+ messages in thread From: Laurent Guerby @ 2000-11-15 0:00 UTC (permalink / raw) Tucker Taft <stt@averstar.com> writes: > I also believe strongly in the value of separating interface and > implementation. [...] This is essentially the story in Java and > Eiffel with classes, where there is no separate spec, but you can > extract the "contract" from the implementation. [...] The Ada way is of course write the spec and have a tool build a dummy implementation for it (C-c o under your favourite editor or gnatstub with your favourite free compiler ;-). -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 3:32 Another important feature of Ada James Rogers 2000-11-15 0:00 ` mjsilva 2000-11-15 0:00 ` Mark T @ 2000-11-19 0:00 ` Lao Xiao Hai 2000-11-20 0:00 ` Michel Gauthier 3 siblings, 0 replies; 23+ messages in thread From: Lao Xiao Hai @ 2000-11-19 0:00 UTC (permalink / raw) James Rogers wrote: > I have been following a thread between comp.lang.eiffel and > comp.lang.c++.moderated. The thread is boiling down to a discussion of > the virtues and vices of separating interface from implementation. > > The points being made against sepration of interface and implementation > focus on a concept that duplication of code is BAD, and separation > of interface and implementation requires some duplication of code. First, I like much of the Eiffel language design and would like to see Ada adopt a few of its features. Second, I prefer the Ada model of physically separating the interface from the implementation. In reliability theory, there is a notion of parallel redundancy that is often introduced to improve the chances of a correct result. I see Ada compilation model as somewhat analogous to the parallel redundancy practice. On large-scale software development projects, where more than one person is engaged in developing the code, this redundancy serves as an additional level of checking between specification and implementation. While this same effect can be achieved, to some extent in Eiffel, and to a much lessor extent in C++, Ada is unique in its enforcement. Ada does not even allow implementation code in the specification. The other languages mentioned do permit it. C++ even requires implementation code in the class definition under some silly circumstances We are dealing here with programmers, most of whom are endowed with a certain measure of humanity. With human programmers, if something can be done it will be. This includes succumbing to the temptation to start implementing algorithmic code too early in the process. I am as guilty as anyone else of thinking about how I plan to solve a problem before fully considering what problem I am trying to solve. Separating the specification from the implementation presents a simple but effective obstacle to premature implementation. Ada, as readers of this forum understand, even allows us to defer implementations to small separately compiled subunits which, in-turn, provide excellent opportunities for controlling dependencies, as well as focusing longer on the "what" before getting involved in the "how.". Eiffel programmers will retort that they can do the same thing. I agree, they can. However, being able to do something and doing it are two different things. Ada requires the separation. The argument about duplication of code is not very convincing. Are we looking for ways to make coding easier or are we looking for a language design that enforces a higher level of discipline in the software engineering process? Richard Riehle ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Another important feature of Ada 2000-11-15 3:32 Another important feature of Ada James Rogers ` (2 preceding siblings ...) 2000-11-19 0:00 ` Lao Xiao Hai @ 2000-11-20 0:00 ` Michel Gauthier 3 siblings, 0 replies; 23+ messages in thread From: Michel Gauthier @ 2000-11-20 0:00 UTC (permalink / raw) In article <3A12041B.BCFD8CA0@worldnet.att.net>, James Rogers <jimmaureenrogers@worldnet.att.net> wrote: >> I have been following a thread between comp.lang.eiffel and >> comp.lang.c++.moderated. The thread is boiling down to a discussion of >> the virtues and vices of separating interface from implementation. >> >> [...] I might have missed some reply, but I am surprised that nobody have written about teams working in parallel for using and coding after a common 'contract' has been accepted. Is there some industrial comments about this idea ? ---------- ---------- ---------- ---------- Michel Gauthier / Laboratoire d'informatique 83, rue d'Isle / F-87000 Limoges telephone +33 555 43 69 73 fax +33 555 43 69 77 ---------- ---------- ---------- ---------- Nous n'etions pas dans la langueur, nous ne sombrons pas dans l'allegresse. ---------- ---------- ---------- ---------- ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2000-11-21 0:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-15 3:32 Another important feature of Ada James Rogers 2000-11-15 0:00 ` mjsilva 2000-11-15 0:00 ` Brian Rogoff 2000-11-17 0:00 ` Scott Ingram 2000-11-15 0:00 ` Mark T 2000-11-15 0:00 ` Tucker Taft 2000-11-15 0:00 ` Ed Falis 2000-11-17 0:00 ` Jean-Pierre Rosen 2000-11-18 0:00 ` Ed Falis 2000-11-18 0:00 ` Karel Thoenissen 2000-11-18 0:00 ` pete 2000-11-19 0:00 ` Jean-Pierre Rosen 2000-11-19 0:00 ` James Rogers 2000-11-19 0:00 ` David Starner 2000-11-19 0:00 ` Ray Blaak 2000-11-20 2:39 ` Robert Dewar 2000-11-20 7:43 ` Ehud Lamm 2000-11-21 0:00 ` Ray Blaak 2000-11-21 0:00 ` Robert Dewar 2000-11-20 7:47 ` Ehud Lamm 2000-11-15 0:00 ` Laurent Guerby 2000-11-19 0:00 ` Lao Xiao Hai 2000-11-20 0:00 ` Michel Gauthier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox