* Separate Compilation in Programming Languages @ 2008-02-22 17:35 adaworks 2008-02-22 17:52 ` Dirk Heinrichs ` (9 more replies) 0 siblings, 10 replies; 72+ messages in thread From: adaworks @ 2008-02-22 17:35 UTC (permalink / raw) Recently, I have been engaged in some conversations with colleagues about the value of separate compilation. This is one of my favorite features in Ada. In fact, as nearly as I can tell, none of the other popular languages includes this feature in as well-developed a form as Ada. Java has no separate compilation at all. Nor does Eiffel. C++ has a rather kludgy form that is sometimes worse than none at all. Modula includes a form of separate compilation, but requires opaque types. Older languages such as PL/I, COBOL, and Fortran are pretty useless in this respect. This morning, after an especially interesting argument about this feature and, "Why would anyone want to do such a thing?" style questions, I decided to approach this forum. What is your view of Ada-style separate compilation when compared to that in other languages? Do you find it useful in your own practice? Do you still use the "is separate" feature in a package body? For my own programs, I find it helpful as a way to manage dependencies when there are a lot of library units. Also, UML does not support a capability for modeling separate compilation, and that is a bit frustrating when trying to model a fine-grained design. If you wish, you may reply to my Naval Postgraduate School email: rdriehle@nps.edu or my personal email, laoxiaohai@juno.com . I rarely use this adaworks account for email anymore since I am no longer actively pursuing Ada consulting anymore. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks @ 2008-02-22 17:52 ` Dirk Heinrichs 2008-02-23 0:23 ` adaworks 2008-02-22 18:10 ` Ray Blaak ` (8 subsequent siblings) 9 siblings, 1 reply; 72+ messages in thread From: Dirk Heinrichs @ 2008-02-22 17:52 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > This morning, after an especially interesting argument about this feature > and, "Why would > anyone want to do such a thing?" style questions, I decided to approach > this > forum. What > is your view of Ada-style separate compilation when compared to that in > other languages? > Do you find it useful in your own practice? Do you still use the "is > separate" feature in > a package body? When put under version control, one can can easily track the development of functions, instead of files as is the case for most projects developed in C/C++, where the entire class is put in one large .cpp file. While it is doable in C/C++ as well, it can't be expressed in the language itself, which means that the compiler has no means of telling wether one .c file logically belongs to another or not. However, in either language it requires a bit of discipline from the developers. Bye... Dirk ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:52 ` Dirk Heinrichs @ 2008-02-23 0:23 ` adaworks 0 siblings, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-23 0:23 UTC (permalink / raw) "Dirk Heinrichs" <dirk.heinrichs@online.de> wrote in message news:fpn25e$du5$1@online.de... > adaworks@sbcglobal.net wrote: >> Do you find it useful in your own practice? Do you still use the "is >> separate" feature in >> a package body? DH> DH> When put under version control, one can can easily track the development of DH> functions, instead of files as is the case for most projects developed in DH> C/C++, where the entire class is put in one large .cpp file. DH> Yes. Version control is useful, even for Ada projects. However, version control does not solve the dependency issue. DH> DH> While it is doable in C/C++ as well, it can't be expressed in the language DH> itself, which means that the compiler has no means of telling wether one .c DH> file logically belongs to another or not. DH> DH> However, in either language it requires a bit of discipline from the DH> developers. DH> Agree. This is always much simpler in Ada than in other languages. There is question of whether it is an important enough distinction to make a difference when choosing a language for a large-scale software system. I know it was a very big issue on some of the early Ada projects such as BSY-2 which was originally designed without using Ada's dependency management via separate compilation. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks 2008-02-22 17:52 ` Dirk Heinrichs @ 2008-02-22 18:10 ` Ray Blaak 2008-02-22 23:53 ` adaworks 2008-02-22 18:18 ` Niklas Holsti ` (7 subsequent siblings) 9 siblings, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-22 18:10 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > Java has no separate compilation at all. Of course it does. It has no explicit syntax dedicated to describing separate compilation, but it doesn't need it. It is quite straightforward to make separate libraries, etc. It's just that the closure is implicit, but it works well in practice since the compiler tells you if it can't find anything missing. You can still get the benefits of separate compilation by simply having reasonable subsystems (i.e. packages), proper information hiding and the like. Java build environments seem pretty decent with compiling only what is needed. It's like the problem is not really relevant with Java. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 18:10 ` Ray Blaak @ 2008-02-22 23:53 ` adaworks 2008-02-23 1:40 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-22 23:53 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:ur6f4x3o3.fsf@STRIPCAPStelus.net... > > <adaworks@sbcglobal.net> writes: >> Java has no separate compilation at all. > > Of course it does. It has no explicit syntax dedicated to describing separate > compilation, but it doesn't need it. It is quite straightforward to make > separate libraries, etc. > The issue is about dependencies. When the class definition and the class implementation are in the same file, any dependent units will have to be compiled when there is a change in that file. I don't see any capability for managing this kind of dependency in Java. > It's just that the closure is implicit, but it works well in practice since > the compiler tells you if it can't find anything missing. > > You can still get the benefits of separate compilation by simply having > reasonable subsystems (i.e. packages), proper information hiding and the > like. Java build environments seem pretty decent with compiling only what is > needed. > > It's like the problem is not really relevant with Java. > > -- > Cheers, The Rhythm is around me, > The Rhythm has control. > Ray Blaak The Rhythm is inside me, > rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 23:53 ` adaworks @ 2008-02-23 1:40 ` Ray Blaak 2008-02-23 7:29 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-23 1:40 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > The issue is about dependencies. When the class definition and the > class implementation are in the same file, any dependent units will > have to be compiled when there is a change in that file. I don't > see any capability for managing this kind of dependency in Java. In practice it's not an issue. Compilation is cheap. But there is a way to manage explicit dependencies: express the public facing APIs in terms of interfaces with implementation classes that truly hide the actual implementation. This gives a strict separation that gives you the control you were looking for. Whether that is as convenient or not as Ada is another debate. The issue is simply not that serious, partially due to Java's dynamic loading abilities. I can drop a new version in of my library JAR in somewhere, and if the public API signatures have not actually changed I do not in fact need to recompile. In practice however, you do, because it's easy and it catches any unexpected API changes. But one was still doing "separate compilation". -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 1:40 ` Ray Blaak @ 2008-02-23 7:29 ` adaworks 2008-02-23 18:42 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-23 7:29 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:ur6f4sb5l.fsf@STRIPCAPStelus.net... > <adaworks@sbcglobal.net> writes: >> The issue is about dependencies. When the class definition and the >> class implementation are in the same file, any dependent units will >> have to be compiled when there is a change in that file. I don't >> see any capability for managing this kind of dependency in Java. > RB> In practice it's not an issue. Compilation is cheap. RB> For small software systems this might be true. However, for large systems this is not true. I am thinking in terms of software projects that require over a million lines of source code and a lot of library units where the dependencies are significant. For systems of this magnitude, where many different programmers are working on the project, compilation is not cheap. RB> RB> But there is a way to manage explicit dependencies: express the public facing RB> APIs in terms of interfaces with implementation classes that truly hide the RB> actual implementation. RB> I considered Interfaces. They appear, at first glance, to be a solution. However, they fall short of what we are seeking here. Once the Interface is implemented, the rest of the software still depends on that implementation and there is no model of separate compilation at that point where one can separate the specification from the implementation. The dependency becomes bound to the implementation of the Interface not to the Interface abstraction. RB> RB> This gives a strict separation that gives you the control you were looking RB> for.Whether that is as convenient or not as Ada is another debate. RB> It is not a matter of convenience. It simply falls short. RB> RB> The issue is simply not that serious, partially due to Java's dynamic loading RB> abilities. I can drop a new version in of my library JAR in somewhere, and if RB> the public API signatures have not actually changed I do not in fact need to RB> recompile. RB> RB> In practice however, you do, because it's easy and it catches any unexpected RB> API changes. But one was still doing "separate compilation". RB> But not managing dependencies very well. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 7:29 ` adaworks @ 2008-02-23 18:42 ` Ray Blaak 0 siblings, 0 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-23 18:42 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > > But there is a way to manage explicit dependencies: express the public > > facing APIs in terms of interfaces with implementation classes that truly > > hide the actual implementation. > > I considered Interfaces. They appear, at first glance, to be a solution. > However, they fall short of what we are seeking here. Once the Interface is > implemented, the rest of the software still depends on that implementation > and there is no model of separate compilation at that point where one can > separate the specification from the implementation. The dependency becomes > bound to the implementation of the Interface not to the Interface > abstraction. I don't understand what you mean. The rest of the software explicitly does not depend on that implementation. That is the point of using an interface. I have made such interface-based APIs, and would tend to build API clients with only the public API present. The implementation would be loaded at run time. The client could not ever be effected by implementation changes; it could not even see the implementation. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks 2008-02-22 17:52 ` Dirk Heinrichs 2008-02-22 18:10 ` Ray Blaak @ 2008-02-22 18:18 ` Niklas Holsti 2008-02-23 0:14 ` adaworks 2008-02-23 12:37 ` Dirk Heinrichs 2008-02-22 19:11 ` Dmitry A. Kazakov ` (6 subsequent siblings) 9 siblings, 2 replies; 72+ messages in thread From: Niklas Holsti @ 2008-02-22 18:18 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > Recently, I have been engaged in some conversations with colleagues > about the value of separate compilation. ... > What is your view of Ada-style separate compilation when compared to > that in other languages? The Ada way, and especially the source-based library system as used in GNAT and relatives, is the best form of separate (modular) compilation that I've ever used. My experience includes various implementations of Algol, Pascal, Fortran, Cobol, C, and C++, but not very much Java. > Do you find it useful in your own practice? I find it hard to imagine programming *without* separate compilation of modules, except with special super-fast (poorly optimizing) compilers of the "Turbo" variety. > Do you still use the "is separate" feature in a package body? I never use it. My subprograms are rarely long enough to make it useful (given that there is no compilation-speed advantage under GNAT), and I seldom use nested packages. Separate version tracking per subprogram (as mentioned by Dirk Heinrichs) could be an advantage, but I would prefer to get this from a subprogram-aware version control system, without the proliferation of source files that "separate" causes. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 18:18 ` Niklas Holsti @ 2008-02-23 0:14 ` adaworks 2008-02-23 7:23 ` Niklas Holsti 2008-02-23 12:27 ` Georg Bauhaus 2008-02-23 12:37 ` Dirk Heinrichs 1 sibling, 2 replies; 72+ messages in thread From: adaworks @ 2008-02-23 0:14 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:47bf11df$0$14990$4f793bc4@news.tdc.fi... > adaworks@sbcglobal.net wrote: > >> Do you still use the "is separate" feature in a package body? > > I never use it. My subprograms are rarely long enough to make it useful (given > that there is no compilation-speed advantage under GNAT), and I seldom use > nested packages. > Thanks. The issue is not compilation speed, nor even size of the source code. Rather, the real benefit of Ada's separate compilation model is the management of dependencies. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 0:14 ` adaworks @ 2008-02-23 7:23 ` Niklas Holsti 2008-02-23 7:31 ` Niklas Holsti 2008-02-23 12:27 ` Georg Bauhaus 1 sibling, 1 reply; 72+ messages in thread From: Niklas Holsti @ 2008-02-23 7:23 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:47bf11df$0$14990$4f793bc4@news.tdc.fi... > >>adaworks@sbcglobal.net wrote: >> >> >>>Do you still use the "is separate" feature in a package body? >> >>I never use it. My subprograms are rarely long enough to make it useful (given >>that there is no compilation-speed advantage under GNAT), and I seldom use >>nested packages. >> > > Thanks. The issue is not compilation speed, nor even size of the > source code. Rather, the real benefit of Ada's separate compilation > model is the management of dependencies. I understand this point -- in theory. In practice, although I do worry about dependencies in general, I haven't seen cases where "is separate" would have been very useful, in my opinion. True, often only some parts (subprograms) of a large package body depend on some given other package, and other parts do not, but it is rare for this selective dependency to apply to only one subprogram in the package. If there are, say, three subprograms in package A that depend on package B, and I make these three subprograms "separate" to remove the "with B" clause from A, I now have three "with B" clauses in three different source-code files, instead of the one clause in the body of A. The dependencies are more specific, good, but also there are more dependencies (and more source-code files), not so good. By YMMV. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 7:23 ` Niklas Holsti @ 2008-02-23 7:31 ` Niklas Holsti 2008-02-23 16:00 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Niklas Holsti @ 2008-02-23 7:31 UTC (permalink / raw) Replying to my own post in order to add a remark: Niklas Holsti wrote: > adaworks@sbcglobal.net wrote: > >> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message >> news:47bf11df$0$14990$4f793bc4@news.tdc.fi... >> >>> adaworks@sbcglobal.net wrote: >>> >>> >>>> Do you still use the "is separate" feature in a package body? >>> >>> >>> I never use it. My subprograms are rarely long enough to make it >>> useful (given that there is no compilation-speed advantage under >>> GNAT), and I seldom use nested packages. >>> >> >> Thanks. The issue is not compilation speed, nor even size of the >> source code. Rather, the real benefit of Ada's separate compilation >> model is the management of dependencies. > > > I understand this point -- in theory. In practice, although I do worry > about dependencies in general, I haven't seen cases where "is separate" > would have been very useful, in my opinion. What I often do instead is to divide the original package, which contains parts with very different dependencies, into a parent and one or more children, according to some logical criterion from the clients' point of view. I find that this often also sorts out the dependencies in the bodies, reducing the advantage of splitting the bodies into "is separate" parts. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 7:31 ` Niklas Holsti @ 2008-02-23 16:00 ` adaworks 0 siblings, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-23 16:00 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:47bfc7b5$0$21890$4f793bc4@news.tdc.fi... > Replying to my own post in order to add a remark: > What I often do instead is to divide the original package, which contains > parts with very different dependencies, into a parent and one or more > children, according to some logical criterion from the clients' point of view. > I find that this often also sorts out the dependencies in the bodies, reducing > the advantage of splitting the bodies into "is separate" parts. > This is an excellent solution. However, I still prefer to design so my dependencies are, as often as possible, at the package body or separate subprogram level as possible. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 0:14 ` adaworks 2008-02-23 7:23 ` Niklas Holsti @ 2008-02-23 12:27 ` Georg Bauhaus 1 sibling, 0 replies; 72+ messages in thread From: Georg Bauhaus @ 2008-02-23 12:27 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:47bf11df$0$14990$4f793bc4@news.tdc.fi... >> adaworks@sbcglobal.net wrote: >> >>> Do you still use the "is separate" feature in a package body? >> I never use it. My subprograms are rarely long enough to make it useful (given >> that there is no compilation-speed advantage under GNAT), and I seldom use >> nested packages. >> > Thanks. The issue is not compilation speed, nor even size of the > source code. Rather, the real benefit of Ada's separate compilation > model is the management of dependencies. I like separate subprograms or separate package bodies not only because of dependency management, but also because they allow a kind of source code organization not available without separation. It is about distraction and separation of concerns. Given that Ada has nesting, I can make all things local to where they are used. Much like I can do using FPLs' let expressions (as in Scheme or ML) or where clauses (as in Haskell). But I don't have to "clutter the listing" between "is" and "begin" with full implementation details that only disturb linear reading. It's like saying, "I'll leave the details out for the moment", or, "I'll talk about the implementation later". Still the subp profile or package interface have been mentioned. That is, the reader has enough information in order to follow the program text. function sqrt_iter(guess, x: Number) return Number is function improve(guessed: Number) return Number is separate; -- another number approximating sqrt_iter'Result function good_enough(guessed: Number) return Boolean is begin return abs (guessed * guessed - x) < 0.001; end; begin -- sqrt_iter if good_enough(guess) then return guess; else return sqrt_iter(improve(guess), x); end if; end sqrt_iter; ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 18:18 ` Niklas Holsti 2008-02-23 0:14 ` adaworks @ 2008-02-23 12:37 ` Dirk Heinrichs 2008-02-23 13:03 ` Niklas Holsti 1 sibling, 1 reply; 72+ messages in thread From: Dirk Heinrichs @ 2008-02-23 12:37 UTC (permalink / raw) Niklas Holsti wrote: > Separate version tracking per subprogram (as mentioned by Dirk > Heinrichs) could be an advantage, but I would prefer to get this > from a subprogram-aware version control system, without the > proliferation of source files that "separate" causes. The only problem is that there is no subprogram-aware version control system today. (My main job is doing SCM, btw., so I know what I'm talking about.) And IMHO there doesn't need to be one. It would have to know the syntax of the program's language(s) to find out when particular subprograms change so that it can raise their versions. That's next to impossible because people always want to put something under version control which is written exactly in the single one language the system isn't aware of. So the solution is to keep putting just files under version control, and if each of those files represent exactly one subprogram, your version control _is_ (sort of) subprogram-aware, but still language independant. Bye... Dirk ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 12:37 ` Dirk Heinrichs @ 2008-02-23 13:03 ` Niklas Holsti 0 siblings, 0 replies; 72+ messages in thread From: Niklas Holsti @ 2008-02-23 13:03 UTC (permalink / raw) Dirk Heinrichs wrote: > Niklas Holsti wrote: > > >>Separate version tracking per subprogram (as mentioned by Dirk >>Heinrichs) could be an advantage, but I would prefer to get this >>from a subprogram-aware version control system, without the >>proliferation of source files that "separate" causes. > > > The only problem is that there is no subprogram-aware version control system > today. (My main job is doing SCM, btw., so I know what I'm talking about.) Agreed. (I did say I *would* prefer it, not that I *can* do it :-) Several years ago I implemented something of the sort, by writing some scripts to chop version "diff" reports per Ada subprogram, using fairly simple patterns to match the start and end of subprograms (greatly helped by a coding rule that forbade nested subprograms). The result showed version history per subprogram, and I found it very useful, especially for maintaining unit tests. > And IMHO there doesn't need to be one. It would have to know the syntax of > the program's language(s) to find out when particular subprograms change so > that it can raise their versions. That's next to impossible because people > always want to put something under version control which is written exactly > in the single one language the system isn't aware of. Well, it is a little like syntax coloring in editors, isn't it? Editors do it for the major languages, but not for every little language someone has invented. I admit that it is harder to identify subprogram boundaries than tokens and keywords, of course, and then there is the nesting problem. > So the solution is to keep putting just files under version control, and if > each of those files represent exactly one subprogram, your version control > _is_ (sort of) subprogram-aware, but still language independant. At the cost of a great number of files, and some language-specific means to combine the files into a program (eg. "is separate" for Ada). Ugh. Perhaps something could be done with a language-specific intermediate tool, similar to "gnatchop", that would mediate between the view that I want (one file per package, but version history per subprogram, or other segment of a file) and the view of the version control system. But in my context, the need is not so great. I'm just day-dreaming. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (2 preceding siblings ...) 2008-02-22 18:18 ` Niklas Holsti @ 2008-02-22 19:11 ` Dmitry A. Kazakov 2008-02-23 0:16 ` adaworks 2008-02-22 19:33 ` Larry Kilgallen ` (5 subsequent siblings) 9 siblings, 1 reply; 72+ messages in thread From: Dmitry A. Kazakov @ 2008-02-22 19:11 UTC (permalink / raw) On Fri, 22 Feb 2008 17:35:33 GMT, adaworks@sbcglobal.net wrote: > What > is your view of Ada-style separate compilation when compared to that in other > languages? It is the best I know, but still problematic when it comes to DLLs and distributed stuff. > Do you find it useful in your own practice? Do you still use the "is separate" > feature in a package body? I do but not very often. One problem is that GNAT's implementation of is quite intolerant to errors in separate bodies. So you cannot have an independent design - compile loop for them. Splitting things into smaller filers after having designed them is no more actual in these days of IDEs. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 19:11 ` Dmitry A. Kazakov @ 2008-02-23 0:16 ` adaworks 0 siblings, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-23 0:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:19aoco1bwcscs$.v4o2kd01gbw6.dlg@40tude.net... > On Fri, 22 Feb 2008 17:35:33 GMT, adaworks@sbcglobal.net wrote: > >> Do you find it useful in your own practice? Do you still use the "is >> separate" >> feature in a package body? > > I do but not very often. One problem is that GNAT's implementation of is > quite intolerant to errors in separate bodies. So you cannot have an > independent design - compile loop for them. Splitting things into smaller > filers after having designed them is no more actual in these days of IDEs. > Agreed. This is an issue with the implementation, not with the language. Not all compilers are GNAT. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (3 preceding siblings ...) 2008-02-22 19:11 ` Dmitry A. Kazakov @ 2008-02-22 19:33 ` Larry Kilgallen 2008-02-22 20:47 ` Simon Wright ` (4 subsequent siblings) 9 siblings, 0 replies; 72+ messages in thread From: Larry Kilgallen @ 2008-02-22 19:33 UTC (permalink / raw) In article <FJDvj.10151$0o7.9092@newssvr13.news.prodigy.net>, <adaworks@sbcglobal.net> writes: > Recently, I have been engaged in some conversations with colleagues about the > value of > separate compilation. This is one of my favorite features in Ada. In fact, > as nearly as > I can tell, none of the other popular languages includes this feature in as > well-developed > a form as Ada. Java has no separate compilation at all. Nor does Eiffel. > C++ has a > rather kludgy form that is sometimes worse than none at all. Modula includes > a form > of separate compilation, but requires opaque types. Older languages such as > PL/I, > COBOL, and Fortran are pretty useless in this respect. VMS Pascal has support for separate compilation, with data types coming from one or more common source files and correspondence between compilations checked at link time. I do not know how many of those features come from the latest Pascal Standard. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (4 preceding siblings ...) 2008-02-22 19:33 ` Larry Kilgallen @ 2008-02-22 20:47 ` Simon Wright 2008-02-22 21:27 ` Robert A Duff ` (3 subsequent siblings) 9 siblings, 0 replies; 72+ messages in thread From: Simon Wright @ 2008-02-22 20:47 UTC (permalink / raw) We use separates to keep (re)generated package specs and bodies well away from the handwritten parts --having had some bad experiences with Rose/Ada (special --begin-handwritten, --end-handwritten comments and lots of opportunities for confusion). Also sometimes useful for AUnit testing -- put the test case into a package whose body is separate. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (5 preceding siblings ...) 2008-02-22 20:47 ` Simon Wright @ 2008-02-22 21:27 ` Robert A Duff 2008-02-23 0:12 ` adaworks 2008-02-22 22:16 ` Jeffrey R. Carter ` (2 subsequent siblings) 9 siblings, 1 reply; 72+ messages in thread From: Robert A Duff @ 2008-02-22 21:27 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > Recently, I have been engaged in some conversations with colleagues > about the value of separate compilation. This is one of my favorite > features in Ada. In fact, as nearly as I can tell, none of the other > popular languages includes this feature in as well-developed a form as > Ada. Java has no separate compilation at all. Nor does Eiffel. C++ > has a rather kludgy form that is sometimes worse than none at all. > Modula includes a form of separate compilation, but requires opaque > types. Older languages such as PL/I, COBOL, and Fortran are pretty > useless in this respect. Please define what you mean by "separate compilation". My definition is that you can store parts of the program in separate source files, and compile each source file separately from other source files. You can compile parts of incomplete programs. In that sense, all of the above-mentioned languages (or language implementations in common use) have it. So I'm puzzled by your statement to the contrary. I've also heard the term "independent compilation" used for the above, with "separate compilation" meaning that in addition, whatever type checking is done within a single compilation unit should be done across separately compiled units. In that sense, Ada, Eiffel, Modula-2, and Java still have separate compilation. C and C++ do too, sort of, if you rely on taking care with include files. Still puzzled. By the way, Eiffel compilers typically use incremental compilation, which if implemented well, is strictly superior to separate compilation on a file-by-file basis. - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 21:27 ` Robert A Duff @ 2008-02-23 0:12 ` adaworks 2008-02-23 10:28 ` framefritti ` (2 more replies) 0 siblings, 3 replies; 72+ messages in thread From: adaworks @ 2008-02-23 0:12 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccr6f4y94q.fsf@shell01.TheWorld.com... > > Please define what you mean by "separate compilation". > I knew my original post would stimulate some discussion. You are correct that some form of separate compilation is available in most languages. My concern is dependency management. I will give an example in source code. with X, Y, Z, Q, R, S; -- a set of library units on which we are dependent package A is -- a package specification -- types and methods for this package end A; At this point, everything that is dependent on this specification is also dependent on the library units on which A is dependent. In Ada, we can move those dependencies to the package body. So, we have: package A is -- a package specification -- types and methods for this package end A; with X, Y, Z, Q, R, S; -- only body is dependent on these package body A is -- a package specification -- implementation of package A end A; By moving the dependencies to the package body, the specification is dependency free, as are all of the library units that become dependent on it. Further, if we use the "is separate" feature, we can push those dependencies even further down into the implementation, not something any of the other languages do very well. I don't think this is possible in Java, Eiffel, or C#. It is only possible in C++ by using the #include in the CPP file, and that is error-prone. As noted by someone else, an automated configuration control software can be of help in this regard, but it is not built into the language as it is with Ada. > RD> By the way, Eiffel compilers typically use incremental compilation, RD> which if implemented well, is strictly superior to separate RD> compilation on a file-by-file basis. But it still does not seem to solve the dependency issue as cleanly as Ada does. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 0:12 ` adaworks @ 2008-02-23 10:28 ` framefritti 2008-02-23 12:45 ` Dirk Heinrichs 2008-02-23 15:16 ` Robert A Duff 2 siblings, 0 replies; 72+ messages in thread From: framefritti @ 2008-02-23 10:28 UTC (permalink / raw) On 23 Feb, 01:12, <adawo...@sbcglobal.net> wrote: > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote in messagenews:wccr6f4y94q.fsf@shell01.TheWorld.com... > > > Please define what you mean by "separate compilation". > > I knew my original post would stimulate some discussion. You are > correct that some form of separate compilation is available in most > languages. > > My concern is dependency management. I will give an example in source > code. (snip) > But it still does not seem to solve the dependency issue as cleanly as > Ada does. Actually, I *love* the way Ada manages the dependencies between packages. The headache-inducing Makefiles used in some large C projects of mine are a (bad) memory nowdays... ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 0:12 ` adaworks 2008-02-23 10:28 ` framefritti @ 2008-02-23 12:45 ` Dirk Heinrichs 2008-02-23 15:16 ` Robert A Duff 2 siblings, 0 replies; 72+ messages in thread From: Dirk Heinrichs @ 2008-02-23 12:45 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > My concern is dependency management. I will give an example in source > code. > > with X, Y, Z, Q, R, S; -- a set of library units on which we are > dependent package A is -- a package specification > > -- types and methods for this package > > end A; > > At this point, everything that is dependent on this specification is also > dependent on the library units on which A is dependent. In Ada, we > can move those dependencies to the package body. So, we have: > > package A is -- a package specification > > -- types and methods for this package > > end A; > > with X, Y, Z, Q, R, S; -- only body is dependent on these > package body A is -- a package specification > > -- implementation of package A > > end A; > > By moving the dependencies to the package body, the specification > is dependency free, as are all of the library units that become > dependent on it. Further, if we use the "is separate" feature, > we can push those dependencies even further down into the > implementation, not something any of the other languages > do very well. Maybe I misunderstood something, but isn't it so that (with gnat) when A.adb is recompiled, it sort of "includes" the subunits and compiles them as well, which means that internally, the compiler handles them all as one entity? If this is true, then it doesn't matter wether the dependencies are moved into the subunits or not. However, even if it doesn't make a difference for the compiler, it can still make a difference for the reader/maintainer of the code. Bye... Dirk ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 0:12 ` adaworks 2008-02-23 10:28 ` framefritti 2008-02-23 12:45 ` Dirk Heinrichs @ 2008-02-23 15:16 ` Robert A Duff 2008-02-23 16:47 ` adaworks 2 siblings, 1 reply; 72+ messages in thread From: Robert A Duff @ 2008-02-23 15:16 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > My concern is dependency management. OK, but I still don't fully understand what you're getting at. You said elsewhere in this thread that you are NOT concerned with recompilation costs. That's good -- recompilation cost should primarily be an implementation concern. I'm guessing that your point has nothing to do with "compilation" at all, separate or otherwise. It has to do with the organization of the program into separate source files -- specifically separation of spec and body (interface and implementation, to use more language-neutral terms). Right? >...I will give an example in source > code. > > with X, Y, Z, Q, R, S; -- a set of library units on which we are dependent > package A is -- a package specification > > -- types and methods for this package > > end A; > > At this point, everything that is dependent on this specification is also > dependent on the library units on which A is dependent. In Ada, we > can move those dependencies to the package body. So, we have: > > package A is -- a package specification > > -- types and methods for this package > > end A; > > with X, Y, Z, Q, R, S; -- only body is dependent on these > package body A is -- a package specification > > -- implementation of package A > > end A; > > By moving the dependencies to the package body, the specification > is dependency free, as are all of the library units that become > dependent on it. OK, so you like having textually separate spec and body, as do I. But what specific advantages are you talking about in this thread? Readability? That is, when looking at a client of A, you don't need to worry about X,Y,...S. This is good, but it's got little to do with separate compilation. Source modification? A change in X could introduce a bug into a client of A -- so there really _is_ a dependency in that sense. One advantage of Ada over some languages (e.g. C) is that the implementation can know what source files are part of each program, by following the with clauses. I really hate having to write a make file that lists out all the .o files that need to be linked together -- Ada allows that to be completely automated (that's what gnatmake does). Something else? Note that Ada requires some implementation details to appear in the package spec -- namely, the stuff that goes in the private part, plus the with clauses needed by that private part. That's ugly, IMHO. >...Further, if we use the "is separate" feature, > we can push those dependencies even further down into the > implementation, not something any of the other languages > do very well. Shrug. I don't use "is separate" much. Child packages are almost always better, because you can separate the spec _and_ the body, and because the parent need not know about the child. Child packages provide the same advantage of being able to "push down" the dependencies. > I don't think this is possible in Java, Eiffel, or C#. It's possible using interfaces. Clients of an interface do not depend on classes that implement the interface, any more than clients of an Ada package spec depend on its body. You suggested otherwise elsewhere in this thread, but I think you're wrong, or else I'm misunderstanding what you mean by "depend". Interfaces are more flexible than spec/body in that they allow multiple "bodies". And of course Ada 2005 has interfaces. Note that an interface will typically be declared in a package spec with no corresponding body. >...It is only possible > in C++ by using the #include in the CPP file, and that is error-prone. I agree that #include is a kludge. > As noted by someone else, an automated configuration control > software can be of help in this regard, but it is not built into the > language as it is with Ada. >> > RD> By the way, Eiffel compilers typically use incremental compilation, > RD> which if implemented well, is strictly superior to separate > RD> compilation on a file-by-file basis. > > But it still does not seem to solve the dependency issue as cleanly as > Ada does. Eiffel has separate specs and bodies -- except that the spec is automatically generated from the body, rather than being written by hand. I prefer to consider the spec to be a source file in its own right, as in Ada, but it's not _that_ different from Eiffel. - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 15:16 ` Robert A Duff @ 2008-02-23 16:47 ` adaworks 2008-02-23 18:47 ` Ray Blaak 2008-02-23 20:46 ` Robert A Duff 0 siblings, 2 replies; 72+ messages in thread From: adaworks @ 2008-02-23 16:47 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc63wfpus7.fsf@shell01.TheWorld.com... > <adaworks@sbcglobal.net> writes: > >> My concern is dependency management. > > OK, but I still don't fully understand what you're getting at. > You said elsewhere in this thread that you are NOT concerned with > recompilation costs. That's good -- recompilation cost should > primarily be an implementation concern. > Sometimes recompilation costs are important. This is true for very large software systems where one does not want to recompile the entire system for one change somewhere way down in a function within one package body. > I'm guessing that your point has nothing to do with "compilation" at > all, separate or otherwise. It has to do with the organization of the > program into separate source files -- specifically separation of spec > and body (interface and implementation, to use more language-neutral > terms). Right? > Right. My primary concern, in this discussion,is with dependency management. > > OK, so you like having textually separate spec and body, > as do I. But what specific advantages are you talking > about in this thread? > > Readability? That is, when looking at a client of A, you don't > need to worry about X,Y,...S. This is good, but it's got little to do > with separate compilation. > In my view, it does. The less code I have to look at to make a change or to understand the code, the better. Granted, this does not always work as well as I might like, but it frequently is of value. > Source modification? A change in X could introduce a bug > into a client of A -- so there really _is_ a dependency > in that sense. > However, the dependency is at the iimplementation level, not at the specification level. > One advantage of Ada over some languages (e.g. C) is that the > implementation can know what source files are part of each program, > by following the with clauses. I really hate having to write a make > file that lists out all the .o files that need to be linked together -- > Ada allows that to be completely automated (that's what gnatmake does). > Well, Yes. If, in one of my separately compiled subprograms within a package body Q, uses a depth-search routine from a parent package specification K, and we decide to use the breadth-search instead, there is no need to alter any part of the package specification of Q. It remains stable. This becomes an architectural issue, as well. The more stable my architecture when a change is made to some element of that architecture, the better for my overall design. > Something else? > > Note that Ada requires some implementation details to appear in the > package spec -- namely, the stuff that goes in the private part, plus > the with clauses needed by that private part. That's ugly, IMHO. > Modula-2 solved that problem through the use of opaque types. I often code opaque types in Ada using access types. This eliminates any dependencies at the specification level, in many cases. As you know, the private part of a package was a compromise that allows separate compilation. We can even create a tagged type as an opaque type, thereby hiding any implementation details and still making that type extensible. This was difficult in Modula-2, so the designers of Modula-3 also had to make some compromises. Engineering is always about trade-offs between conflicting solutions. Java certainly has its share of trade-offs. > > Shrug. I don't use "is separate" much. Child packages are almost > always better, because you can separate the spec _and_ the body, > and because the parent need not know about the child. Child packages > provide the same advantage of being able to "push down" the > dependencies. > I did not mention Child packages, but you are certainly correct that they are a powerful contributing solution to this issue. In particular, private children are a great benefit. However, in very large software systems, a million SLOC or more, "is separate" continues to play an important role. As noted earlier, specifications should be an architectural concern, and the more stable an architecture, the better. Implementation should be dependent on architecture, not the other way around. When I want to change the upholstery in my car, I don't want to have to alter the architecture of that car. I don't want the performance of the car to depend on whether I choose Zebra seat covers or chartreuse trim on green Naugahyde. >> I don't think this is possible in Java, Eiffel, or C#. > > It's possible using interfaces. Clients of an interface do not depend > on classes that implement the interface, any more than clients of an Ada > package spec depend on its body. You suggested otherwise elsewhere in > this thread, but I think you're wrong, or else I'm misunderstanding what > you mean by "depend". > > Interfaces are more flexible than spec/body in that they allow multiple > "bodies". And of course Ada 2005 has interfaces. Note that an > interface will typically be declared in a package spec with no > corresponding body. > Even with an interface, a la Java, once the interface is implemented, the children dependent on that unit will be dependent on the implementaion, not on the interface. And Java still has no way of separating the specification of that implementing class from its implementation. In another forum (comp.lang.programming) someone submitted an example to show how interfaces would solve this problem, but the example did not separate interface from implementation.. > > Eiffel has separate specs and bodies -- except that the spec is > automatically generated from the body, rather than being written by > hand. I prefer to consider the spec to be a source file in its own > right, as in Ada, but it's not _that_ different from Eiffel. > Yes. In Ada, the specification is most certainly a separate source file. As noted earlier, the specifications and the relatioships between specifications, represent the overall architecture of the software system. I'll take another look at Eiffel, a language design I do admire, and examine this in more detail. However, at my present understanding, the implementation and specification do not present the same independence one finds in Ada. Perhaps someone will post an example. Thanks for your details reply. Richard ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 16:47 ` adaworks @ 2008-02-23 18:47 ` Ray Blaak 2008-02-24 7:40 ` adaworks 2008-02-23 20:46 ` Robert A Duff 1 sibling, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-23 18:47 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > Even with an interface, a la Java, once the interface is implemented, the > children dependent on that unit will be dependent on the implementaion, > not on the interface. This is not true. I can show you code if you are interested. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 18:47 ` Ray Blaak @ 2008-02-24 7:40 ` adaworks 2008-02-24 9:42 ` Ray Blaak 2008-02-24 17:26 ` Robert A Duff 0 siblings, 2 replies; 72+ messages in thread From: adaworks @ 2008-02-24 7:40 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:u3arjcxx3.fsf@STRIPCAPStelus.net... > <adaworks@sbcglobal.net> writes: >> Even with an interface, a la Java, once the interface is implemented, the >> children dependent on that unit will be dependent on the implementaion, >> not on the interface. > > This is not true. I can show you code if you are interested. > I think I was not clear. When a specification (interface, package specification, etc.) remains stable, the implementation is not as much of a factor as changes in the specification. When one specification is dependent on another, a change to the parent specification will require recompiling all of the dependent specifications. When the effect of the specification is deferred to the implementation level, none of the other specifications should have to be compiled. This is quite easy to do in Ada. When the dependencies are deferred to the implementation module (an Ada package body) a change to a parent specification requires only that body to be recompiled. When the specification is at the level of another specification, and a change is made to a higher level unit, everything needs to be recompiled. I think this is as true of Java as it is of Ada. The only difference is that Ada allows one to defer the dependency to the package body. This does not seem to be true of Java. I hope I am more clear. If not, perhaps someone can state it more clearly than I since it is a pretty simple idea. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 7:40 ` adaworks @ 2008-02-24 9:42 ` Ray Blaak 2008-02-24 20:41 ` adaworks 2008-02-24 17:26 ` Robert A Duff 1 sibling, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-24 9:42 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > When the dependencies are deferred to the implementation module (an Ada > package body) a change to a parent specification requires only that body to > be recompiled. When the specification is at the level of another > specification, and a change is made to a higher level unit, everything needs > to be recompiled. No, not necessarily. It is quite possible that the only an implementation was client of the changed spec, and that the change's effects do not perculate out. That is, the change is not transitive. > I think this is as true of Java as it is of Ada. The only difference is > that Ada allows one to defer the dependency to the package body. This does > not seem to be true of Java. The deferral to a package body is precisely equivalent to the deferral to another implementation class. The implementation class is (or can be) private, hidden in exactly the same way the body of a package is. That is what allows Java interfaces to serve as equivalent controls for separate compilation as Ada's package bodies. Mind you, they're not necessarily as convenient, mind you, but I am objecting only to the notion that Java does not support separate compilation. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 9:42 ` Ray Blaak @ 2008-02-24 20:41 ` adaworks 2008-02-25 2:37 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-24 20:41 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:ulk5a8zcu.fsf@STRIPCAPStelus.net... > <adaworks@sbcglobal.net> writes: >> When the dependencies are deferred to the implementation module (an Ada >> package body) a change to a parent specification requires only that body to >> be recompiled. When the specification is at the level of another >> specification, and a change is made to a higher level unit, everything needs >> to be recompiled. > > No, not necessarily. It is quite possible that the only an implementation was > client of the changed spec, and that the change's effects do not perculate > out. That is, the change is not transitive. > Absolutely true, and confirmation of my original point. We want to defer dependencies to the implementation whenever possible so those changes do not "percolate" throughout the rest of the architecture. >> I think this is as true of Java as it is of Ada. The only difference is >> that Ada allows one to defer the dependency to the package body. This does >> not seem to be true of Java. > Agree. It certainly does not seem to be true of Java. > The deferral to a package body is precisely equivalent to the deferral to > another implementation class. The implementation class is (or can be) private, > hidden in exactly the same way the body of a package is. > > That is what allows Java interfaces to serve as equivalent controls for > separate compilation as Ada's package bodies. Mind you, they're not > necessarily as convenient, mind you, but I am objecting only to the notion > that Java does not support separate compilation. > Java's notion of separate compilation is not evil. However, it does fall short of what can be done in Ada. Interfaces, while such a good idea in Java that they have been adopted by Ada, do not solve the dependency issue and do not provide the capabilities for architectural integrity possible in Ada. An implementation of an Interface (in Java) is still tightly bound to its specification, and any change of that implementation will carry forward. It is true that the Interface specification remains unchanged, and that is a good thing. However, if any part of the Interface specification changes, every other unit dependent on that specification will also have to be recompiled. In the Ada model, where I defer the dependency on that Interface to the body of the dependent package, I need not recompile the specification of the dependent package. Rather, I can compile only the body, leaving the rest of my architecture intact. I'm not sure why this is such a difficult idea. It is probably because I am not expressing it with sufficient skill. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 20:41 ` adaworks @ 2008-02-25 2:37 ` Ray Blaak 2008-02-25 7:06 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-25 2:37 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > An implementation of an Interface (in Java) is still tightly bound to > its specification, and any change of that implementation will carry forward. But of course. And that is exactly analogous a change to an Ada package spec impacting the package body. > It is true that the Interface specification remains unchanged, and that is a > good thing. However, if any part of the Interface specification changes, > every other unit dependent on that specification will also have to be > recompiled. Again, exactly the same as changing an Ada package spec. > In the Ada model, where I defer the dependency on that > Interface to the body of the dependent package, I need not recompile the > specification of the dependent package. Rather, I can compile only the > body, leaving the rest of my architecture intact. Recompiling a file does not imply the need to imply client files if the public signatures have not changed. Most IDEs can handle this. Also, recompiling an implementation class will not cause a recompilation of the interface clients at all, since they do not even (necessarily) see the implemetation in the first place. Again, exactly analogous to an Ada package body needing to be recompiled. Ada's separation of spec and body is what allows you to do this. A Java interface and its implementation class is an analogous separation. > I'm not sure why this is such a difficult idea. It is probably because I am > not expressing it with sufficient skill. Well, as politely as possible, I submit that it is not about the skill, but that I think you are mistaken. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 2:37 ` Ray Blaak @ 2008-02-25 7:06 ` adaworks 2008-02-25 13:12 ` Robert A Duff 2008-02-25 17:44 ` Ray Blaak 0 siblings, 2 replies; 72+ messages in thread From: adaworks @ 2008-02-25 7:06 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:uy799dama.fsf@STRIPCAPStelus.net... > <adaworks@sbcglobal.net> writes: > >> An implementation of an Interface (in Java) is still tightly bound to >> its specification, and any change of that implementation will carry forward. > > But of course. And that is exactly analogous a change to an Ada package spec > impacting the package body. > >> It is true that the Interface specification remains unchanged, and that is a >> good thing. However, if any part of the Interface specification changes, >> every other unit dependent on that specification will also have to be >> recompiled. > > Again, exactly the same as changing an Ada package spec. > Only when dependencies are at the specification level. But, in Ada we can defer the dependency to the package body. In Java you cannot defer that dependency. A dependent unit, when the specification changes is combined with its implementation. Therefore, every dependent specification must also be compiled. As noted below, we can defer the dependency in Ada to the package body. There is nothing analogous to this in Java. >> In the Ada model, where I defer the dependency on that >> Interface to the body of the dependent package, I need not recompile the >> specification of the dependent package. Rather, I can compile only the >> body, leaving the rest of my architecture intact. > > Recompiling a file does not imply the need to imply client files if the > public signatures have not changed. Most IDEs can handle this. > Exactly my point. If the public signatures do not change, there is no need for recompilation. When the public signature does change, the entire dependent architecture goes out of phase. If, however, that public signature change is isolated to the the implementation files, the separately compiled package body (as it is in Ada) the architecture remains intact. In Java, all public signatures, including implementations, are dependent on parent public signatures. There is no way to separate them. When one changes, everything dependent on that one change is also changed. In Ada, we move the dependency to the pacakge body so changes to a specification has no effect on the Ada specification, thereby preserving architectural integrity. This is not possible, as nearly as I can tell from all the examples given to me so far, in Java. > Also, recompiling an implementation class will not cause a recompilation of > the interface clients at all, since they do not even (necessarily) see the > implemetation in the first place. > > Again, exactly analogous to an Ada package body needing to be > recompiled. Ada's separation of spec and body is what allows you to do this. A > Java interface and its implementation class is an analogous separation. > >> I'm not sure why this is such a difficult idea. It is probably because I am >> not expressing it with sufficient skill. > > Well, as politely as possible, I submit that it is not about the skill, but > that I think you are mistaken. > Perhaps. But I still don't see how one can defer the dependency of a Java signature to the implementation of the Java class and prevent the need for recompiling the entire architecture when the signature of a parent class changes. The ripple effect through the entire chain of dependencies when one of those signatures changes is almost certain to be affected by such a change of signature. If Java can somehow accomodate that change automatically, it must be some kind of magic that is not immediately apparent, even to the Java developers I know. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 7:06 ` adaworks @ 2008-02-25 13:12 ` Robert A Duff 2008-02-25 17:44 ` Ray Blaak 1 sibling, 0 replies; 72+ messages in thread From: Robert A Duff @ 2008-02-25 13:12 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > Perhaps. But I still don't see how one can defer the dependency of a > Java signature to the implementation of the Java class and prevent > the need for recompiling the entire architecture when the signature of > a parent class changes. The ripple effect through the entire chain > of dependencies when one of those signatures changes is almost > certain to be affected by such a change of signature. I think perhaps what you are missing is that in Java, you can use the same "trick" all along the chain. (The "trick" illustrated by the examples I showed.) E.g., in Ada, you are advocating something like this: E spec (no with's) E body (says "with D") D spec (no with's) D body (says "with C") C spec (no with's) C body (says "with B") B spec (no with's) B body (says "with A") A spec (no with's) A body (no with's) ...to the extent possible, pushing with's into bodies. So if, say, B spec changes, you need to recompile B body and C body, but not (down the chain) D or E. Here, we have 10 source files. The analogous thing with interfaces is: E interface (no with's) E.Implementation (says "with D") D interface (no with's) D.Implementation (says "with C") C interface (no with's) C.Implementation (says "with B") B interface (no with's) B.Implementation (says "with A") A interface (no with's) A.Implementation (no with's) In Ada, each "implementation" is a spec and a body, whereas in Java it's just one class file -- but that's irrelevant. In Ada, we have 15 source files (5 of which are empty or nearly so), but in Java, only 10, as in the previous Ada case. If you change B interface, you have to recompile B.Implementation (spec and body) and C.Implementation (spec and body), but not anything down the chain (D/E). Note that in this method, there are no dependences on the Implementation packages, or very few. Clients such as C.Implementation do NOT say "with B.Implementation"! (I'm ignoring private parts and generics, which throw a monkey wrench into the works.) >...If Java can > somehow accomodate that change automatically, ... Ah, maybe that's the problem. No, it's not automatic. In Java, you have to choose to split out all those interfaces, all down the chain. And you have to take care to make every implementation class depend on interfaces, rather than other implementations. A simpler structure is: E (says "with D") D (says "with C") C (says "with B") B (says "with A") A (no with's) (except Java doesn't call it "with"). In this simpler structure, you do indeed have the ripple effect you're worried about. >...it must be some > kind of magic that is not immediately apparent, even to the Java > developers I know. It's not magic! It requires effort. It is perhaps easier in Ada. But I think the "trick" (or "technique") is well known among Java programmers. - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 7:06 ` adaworks 2008-02-25 13:12 ` Robert A Duff @ 2008-02-25 17:44 ` Ray Blaak 2008-02-25 22:16 ` Ray Blaak ` (2 more replies) 1 sibling, 3 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-25 17:44 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > But, in Ada we can defer the dependency to the package body. In Java you > cannot defer that dependency. A dependent unit, when the specification > changes is combined with its implementation. Therefore, every dependent > specification must also be compiled. As noted below, we can defer the > dependency in Ada to the package body. There is nothing analogous to this > in Java. This is simply false. I am starting to think that *I* don't have the sufficient communication skills. There is a fundamental disconnect here. Consider this Ada situation: Client C ------> Package P spec | | P body When P's spec changes, both C and P's body need to be recompiled. When only P's body changes, C is unaffected. Consider this Java situation: Client C ------> interface P_Spec | | class P_Body implements P When P_Spec changes, both C and P_Body need to be recompiled. When only P_Body changes, C is unaffected, P_Spec is unaffected. I don't know how else to say it more clearly. Note that if anyone is referring to P_Body then they will be affected, but the idea is that one takes the care so the clients only use P_Spec. This takes effort and discipline, making things less convenient than Ada, but the ability to have the separation is there in the Java language. > Perhaps. But I still don't see how one can defer the dependency of a > Java signature to the implementation of the Java class and prevent > the need for recompiling the entire architecture when the signature of > a parent class changes. Maybe the disconnect is here. Are you talking about how spec changes ripple down, or are you talking about how body changes ripple down? Spec changes affect clients and bodies, both in Java in Ada. Body (implementation) do not affect clients that only refer to the spec, both in Java and Ada. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 17:44 ` Ray Blaak @ 2008-02-25 22:16 ` Ray Blaak 2008-02-26 5:10 ` John W. Kennedy 2008-02-26 7:11 ` adaworks 2008-02-26 7:06 ` adaworks 2008-02-26 11:42 ` Alex R. Mosteo 2 siblings, 2 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-25 22:16 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > > Perhaps. But I still don't see how one can defer the dependency of a > > Java signature to the implementation of the Java class and prevent > > the need for recompiling the entire architecture when the signature of > > a parent class changes. > > Maybe the disconnect is here. Are you talking about how spec changes ripple > down, or are you talking about how body changes ripple down? Spec changes > affect clients and bodies, both in Java in Ada. Body (implementation) do not > affect clients that only refer to the spec, both in Java and Ada. It also occurs to me to wonder if you were assuming the Java interface and implementation are in the same file. If so, the issues you say would indeed happen. But usually the interface and its implementations are in separate files, as per the usual Java rule of one class per file. That separation is what allows Java to have separate compilation. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 22:16 ` Ray Blaak @ 2008-02-26 5:10 ` John W. Kennedy 2008-02-26 19:08 ` Ray Blaak 2008-02-26 7:11 ` adaworks 1 sibling, 1 reply; 72+ messages in thread From: John W. Kennedy @ 2008-02-26 5:10 UTC (permalink / raw) Ray Blaak wrote: > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: >>> Perhaps. But I still don't see how one can defer the dependency of a >>> Java signature to the implementation of the Java class and prevent >>> the need for recompiling the entire architecture when the signature of >>> a parent class changes. >> Maybe the disconnect is here. Are you talking about how spec changes ripple >> down, or are you talking about how body changes ripple down? Spec changes >> affect clients and bodies, both in Java in Ada. Body (implementation) do not >> affect clients that only refer to the spec, both in Java and Ada. > > It also occurs to me to wonder if you were assuming the Java interface and > implementation are in the same file. If so, the issues you say would indeed > happen. > > But usually the interface and its implementations are in separate files, as > per the usual Java rule of one class per file. That separation is what allows > Java to have separate compilation. Actually, this doesn't accomplish as much as you wish, in practice, as it will eventually be necessary to have a constructor for the real class, or else a static factory method. -- John W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 5:10 ` John W. Kennedy @ 2008-02-26 19:08 ` Ray Blaak 0 siblings, 0 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-26 19:08 UTC (permalink / raw) "John W. Kennedy" <jwkenne@attglobal.net> writes: > Actually, this doesn't accomplish as much as you wish, in practice, as it will > eventually be necessary to have a constructor for the real class, or else a > static factory method. That is true. There are ways around this. The simplest way is to have a factory class that is dynamically loaded by some other startup class that client code does not see. That way clients are never affected by the implementation classes. interface IWidgetFactory { // Root client API methods: public IWidget createWidget(blah, blah) {...} ... } class WidgetFactoryAccess { static private IWidgetFactory instance = null; static public IWidgetFactory getInstance() {return instance;} // Called by start up logic. static public void register(IWidgetFactory f) {instance = f;} } You can also do tricks like dynamically loading the implementation class at runtime from some environment-specified jar. That way there are also no compilation dependencies. Again, all this takes effort and discipline. For larger applications, one also needs to take the trouble to control the subsystem layering, since a good orthogonal design actually improves compilation times when the dependencies are minimized. This kind of thing is easier in Ada. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 22:16 ` Ray Blaak 2008-02-26 5:10 ` John W. Kennedy @ 2008-02-26 7:11 ` adaworks 2008-02-26 13:38 ` Stephen Leake 2008-02-26 19:13 ` Ray Blaak 1 sibling, 2 replies; 72+ messages in thread From: adaworks @ 2008-02-26 7:11 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:ulk58of6r.fsf@STRIPCAPStelus.net... > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: >> > Perhaps. But I still don't see how one can defer the dependency of a >> > Java signature to the implementation of the Java class and prevent >> > the need for recompiling the entire architecture when the signature of >> > a parent class changes. >> >> Maybe the disconnect is here. Are you talking about how spec changes ripple >> down, or are you talking about how body changes ripple down? Spec changes >> affect clients and bodies, both in Java in Ada. Body (implementation) do not >> affect clients that only refer to the spec, both in Java and Ada. > > It also occurs to me to wonder if you were assuming the Java interface and > implementation are in the same file. If so, the issues you say would indeed > happen. > > But usually the interface and its implementations are in separate files, as > per the usual Java rule of one class per file. That separation is what allows > Java to have separate compilation. > But only for Interface-based designs. Further, the implementation of the Interface, with its extended signature is in the same file with the algorithmic code. This is significantly different from how we design in Ada where the implementation code (package body) is kept separate from the specification. Also, if the signature of the Interface changes, everything dependent on that signature will also have to change. And everything dependent on that Interface implementation will have to change. The ripple-effect will occur since most of a Java design is not based on Interfaces, and that is the problem with inability to defer dependencies as we can in Ada. Richard Riehle > -- > Cheers, The Rhythm is around me, > The Rhythm has control. > Ray Blaak The Rhythm is inside me, > rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 7:11 ` adaworks @ 2008-02-26 13:38 ` Stephen Leake 2008-02-26 14:56 ` adaworks 2008-02-26 19:13 ` Ray Blaak 1 sibling, 1 reply; 72+ messages in thread From: Stephen Leake @ 2008-02-26 13:38 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > The ripple-effect will occur > since most of a Java design is not based on Interfaces, This is a description of a common Java _practice_, not a requirement of the Java _language_. So, as others have said, keeping the interface specification separate from the implementation is _easier_, and possibly more common, in Ada. But it is also _possible_ in Java. -- -- Stephe ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 13:38 ` Stephen Leake @ 2008-02-26 14:56 ` adaworks 2008-02-26 19:15 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-26 14:56 UTC (permalink / raw) "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message news:uprujvnv4.fsf@stephe-leake.org... > <adaworks@sbcglobal.net> writes: > >> The ripple-effect will occur >> since most of a Java design is not based on Interfaces, > > This is a description of a common Java _practice_, not a requirement > of the Java _language_. > > So, as others have said, keeping the interface specification separate > from the implementation is _easier_, and possibly more common, in Ada. > But it is also _possible_ in Java. > But, as Mr. Kennedy notes in a separate contribution to this thread, "Actually, this doesn't accomplish as much as you wish, in practice, as it will eventually be necessary to have a constructor for the real class, or else a static factory method." Until I began this conversation, and after doing additional research, I was unaware of just how bad the situation with Java was. The more I examined this issue, with that additional research, it became clear that Ada's model is even better than I had realized. All the protestations in favor of Java simply fail to square with the reality of Java practice. Richard Riehle > -- > -- Stephe ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 14:56 ` adaworks @ 2008-02-26 19:15 ` Ray Blaak 0 siblings, 0 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-26 19:15 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > But, as Mr. Kennedy notes in a separate contribution to this > thread, > > "Actually, this doesn't accomplish as much as you wish, in practice, as > it will eventually be necessary to have a constructor for the real > class, or else a static factory method." I have addressed this question in another post. There are perfectly adequate work arounds. Ada does dependency control better, but it is perfectly possible in Java, and I make use of these techniques myself. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 7:11 ` adaworks 2008-02-26 13:38 ` Stephen Leake @ 2008-02-26 19:13 ` Ray Blaak 2008-02-26 21:25 ` Ray Blaak 1 sibling, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-26 19:13 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > > But usually the interface and its implementations are in separate files, as > > per the usual Java rule of one class per file. That separation is what allows > > Java to have separate compilation. > > > But only for Interface-based designs. Well yes. The point is only that it is possible in Java, the denial of which is what I was objecting to. Furthermore, interface designs are indeed done in practice when necessary precisely since they address the situations when dependencies need to be controlled. > Further, the implementation of the Interface, with its extended signature is > in the same file with the algorithmic code. Actually no. This is highly unusual. The vast majority of implementation classes would reside in different files from their inferfaces. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 19:13 ` Ray Blaak @ 2008-02-26 21:25 ` Ray Blaak 2008-02-27 1:15 ` Robert A Duff 0 siblings, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-26 21:25 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > <adaworks@sbcglobal.net> writes: > > Further, the implementation of the Interface, with its extended signature is > > in the same file with the algorithmic code. > > Actually no. This is highly unusual. The vast majority of implementation > classes would reside in different files from their inferfaces. I think I misread this. Yes, or course, the implementation contains the algorithmic code. That is the point. But clients need not see this class, and thus are not impacted by changes to it. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 21:25 ` Ray Blaak @ 2008-02-27 1:15 ` Robert A Duff 0 siblings, 0 replies; 72+ messages in thread From: Robert A Duff @ 2008-02-27 1:15 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: >> <adaworks@sbcglobal.net> writes: >> > Further, the implementation of the Interface, with its extended signature is >> > in the same file with the algorithmic code. >> >> Actually no. This is highly unusual. The vast majority of implementation >> classes would reside in different files from their inferfaces. > > I think I misread this. Yes, or course, the implementation contains the > algorithmic code. That is the point. But clients need not see this class, and > thus are not impacted by changes to it. I initially misread it the same way you did, I think ("the interface is in the same file as...") but on second reading, I see Richard is correct -- "the IMPLEMENTATION OF the interface WITH ITS EXTENDED SIGNATURE is in the same file as...", here emphasized. I agree, though, that "clients need not see this class...". - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 17:44 ` Ray Blaak 2008-02-25 22:16 ` Ray Blaak @ 2008-02-26 7:06 ` adaworks 2008-02-26 11:42 ` Alex R. Mosteo 2 siblings, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-26 7:06 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:uprulnd6u.fsf@STRIPCAPStelus.net... > > Maybe the disconnect is here. Are you talking about how spec changes ripple > down, or are you talking about how body changes ripple down? Spec changes > affect clients and bodies, both in Java in Ada. Body (implementation) do not > affect clients that only refer to the spec, both in Java and Ada. > That is, indeed, the disconnect. When a specification changes, the effect will ripple downward. This is not true of Ada when with clause for the a package is deferred to the package body. When the with clause is at the package specification, the effect certainly does ripple downward. With the exception of the Interface model, in Java, all signature changes occur at a level which will have that ripple effect. In some circumstances, an Interface will alleviate this concern. However, Interfaces are only a small part of the story when designing with Java. So, most Java designs will incur a penalty for this inability to separate the specification (the signature) from the implementation, thereby deferring dependencies to the package body as we can do in Ada. Also, the dependency model in Java can lead to some strange behaviors, including circular dependencies. This is one reason why tools such as Ant, Maven, and Ivy have been invented -- to detect dependency problems that are so easily created with standard Java. Such problems have the potential of disrupting the software architecture and Java programmers realize they must be very careful about doing just that. So. Yes. There has been a disconnnect. In Ada, we can defer the dependencies to the package body, regardless of what kind of package we are designing -- with or without Interfaces. Java is much more limited in this regard. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 17:44 ` Ray Blaak 2008-02-25 22:16 ` Ray Blaak 2008-02-26 7:06 ` adaworks @ 2008-02-26 11:42 ` Alex R. Mosteo 2008-02-26 15:05 ` adaworks 2 siblings, 1 reply; 72+ messages in thread From: Alex R. Mosteo @ 2008-02-26 11:42 UTC (permalink / raw) Ray Blaak wrote: > <adaworks@sbcglobal.net> writes: >> But, in Ada we can defer the dependency to the package body. In Java you >> cannot defer that dependency. A dependent unit, when the specification >> changes is combined with its implementation. Therefore, every dependent >> specification must also be compiled. As noted below, we can defer the >> dependency in Ada to the package body. There is nothing analogous to this >> in Java. > > This is simply false. > > I am starting to think that *I* don't have the sufficient communication > skills. There is a fundamental disconnect here. > > Consider this Ada situation: > > Client C ------> Package P spec > | > | > P body > > When P's spec changes, both C and P's body need to be recompiled. > > When only P's body changes, C is unaffected. > > Consider this Java situation: > > Client C ------> interface P_Spec > | > | > class P_Body implements P > > When P_Spec changes, both C and P_Body need to be recompiled. > > When only P_Body changes, C is unaffected, P_Spec is unaffected. > > I don't know how else to say it more clearly. > > Note that if anyone is referring to P_Body then they will be affected, but the > idea is that one takes the care so the clients only use P_Spec. This takes > effort and discipline, making things less convenient than Ada, but the ability > to have the separation is there in the Java language. I'd go farther and say that proper OO programming practice stresses the fact that clients must operate on interfaces, and not on particular implementation classes. Yes, it takes discipline, but it is what is expected. (Or what I would expect?) Still, having used both Java and Ada, I find true that Ada, by forcing always the separation, helps in "indoctrinating" this into programmers. Specifications in Ada are a blessing. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 11:42 ` Alex R. Mosteo @ 2008-02-26 15:05 ` adaworks 2008-02-26 15:15 ` Alex R. Mosteo 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-26 15:05 UTC (permalink / raw) "Alex R. Mosteo" <amosteo@unizar.es> wrote in message news:62ic8uF230f4oU1@mid.individual.net... > > I'd go farther and say that proper OO programming practice stresses the > fact that clients must operate on interfaces, and not on particular > implementation classes. Yes, it takes discipline, but it is what is > expected. (Or what I would expect?) > The reality is that this practice is rare. Interfaces are not as abundant in Java programs as you might wish. > Still, having used both Java and Ada, I find true that Ada, by forcing > always the separation, helps in "indoctrinating" this into programmers. > Specifications in Ada are a blessing. Yes. Prior to the conversation in this thread, I was not as sure of that as I am now. It has become clear to me that the Ada model, based on the notion of compilation units, continues to be much better than the Java model where, in practice, dependency management on large-scale software systems can range from simply annoying to absolutely wrong. The argument from C++ programmers use to be, "We don't have such problems if we are careful ..." "... if we are good programmers ..." "... if we follow good practices ..." But the fact is that a language design needs to prevent "bad practices" and Ada tends to do that. When hundreds of messages appear on the Internet complaining about Java's dependency problems, this is an indication that the issue is not about programming practice, but about a deficiency in the design of the language. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 15:05 ` adaworks @ 2008-02-26 15:15 ` Alex R. Mosteo 0 siblings, 0 replies; 72+ messages in thread From: Alex R. Mosteo @ 2008-02-26 15:15 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > The argument from C++ programmers use to be, "We don't have > such problems if we are careful ..." "... if we are good programmers ..." > "... if we follow good practices ..." Of course C/C++ with the transitive, low level #include mechanism are even in a worse situation. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 7:40 ` adaworks 2008-02-24 9:42 ` Ray Blaak @ 2008-02-24 17:26 ` Robert A Duff 1 sibling, 0 replies; 72+ messages in thread From: Robert A Duff @ 2008-02-24 17:26 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: >... When the effect of the specification is deferred to the >implementation level, none of the other specifications should have to >be compiled. This is quite easy to do in Ada. Except for those pesky private parts. And generics. :-( - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 16:47 ` adaworks 2008-02-23 18:47 ` Ray Blaak @ 2008-02-23 20:46 ` Robert A Duff 2008-02-24 7:31 ` adaworks 1 sibling, 1 reply; 72+ messages in thread From: Robert A Duff @ 2008-02-23 20:46 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wcc63wfpus7.fsf@shell01.TheWorld.com... >> <adaworks@sbcglobal.net> writes: >> >>> My concern is dependency management. >> >> OK, but I still don't fully understand what you're getting at. >> You said elsewhere in this thread that you are NOT concerned with >> recompilation costs. That's good -- recompilation cost should >> primarily be an implementation concern. >> > Sometimes recompilation costs are important. Yes, of course. If the implementation can't recompile my entire program in less than 0.2 second, then it's too slow. Here, "too slow" means I wish it would be faster. ;-) But recompilation speed is primarily an implementation issue, although the language design can facilitate fast compilers. >...This is true for very > large software systems where one does not want to recompile the > entire system for one change somewhere way down in a function > within one package body. Sure, but a well-designed incremental compilation facility is strictly better than the usual Ada way of doing this. >> I'm guessing that your point has nothing to do with "compilation" at >> all, separate or otherwise. It has to do with the organization of the >> program into separate source files -- specifically separation of spec >> and body (interface and implementation, to use more language-neutral >> terms). Right? >> > Right. My primary concern, in this discussion,is with dependency management. > >> >> OK, so you like having textually separate spec and body, >> as do I. But what specific advantages are you talking >> about in this thread? >> >> Readability? That is, when looking at a client of A, you don't >> need to worry about X,Y,...S. This is good, but it's got little to do >> with separate compilation. >> > In my view, it does. The less code I have to look at to make a > change or to understand the code, the better. Granted, this does > not always work as well as I might like, but it frequently is of > value. I don't understand the above paragraph. You claim it DOES have to do with compilation, but then you talk about how much code you (a human) have to look at, which has nothing whatsoever to do with compilation. >> Source modification? A change in X could introduce a bug >> into a client of A -- so there really _is_ a dependency >> in that sense. >> > However, the dependency is at the iimplementation level, not at > the specification level. > >> One advantage of Ada over some languages (e.g. C) is that the >> implementation can know what source files are part of each program, >> by following the with clauses. I really hate having to write a make >> file that lists out all the .o files that need to be linked together -- >> Ada allows that to be completely automated (that's what gnatmake does). >> > Well, Yes. If, in one of my separately compiled subprograms within a > package body Q, uses a depth-search routine from a parent package > specification K, and we decide to use the breadth-search instead, there > is no need to alter any part of the package specification of Q. It remains > stable. > > This becomes an architectural issue, as well. The more stable my > architecture when a change is made to some element of that architecture, > the better for my overall design. > >> Something else? >> >> Note that Ada requires some implementation details to appear in the >> package spec -- namely, the stuff that goes in the private part, plus >> the with clauses needed by that private part. That's ugly, IMHO. >> > Modula-2 solved that problem through the use of opaque types. I > often code opaque types in Ada using access types. This eliminates > any dependencies at the specification level, in many cases. Right, but there's a huge disadvantage of Modula-2's opaque types, and the Ada equivalent using access types: namely, you now have to deal with heap management. >...As you > know, the private part of a package was a compromise that allows > separate compilation. A completely unnecessary compromise. This particular area of Ada (private parts) really is a mess, IMHO. > We can even create a tagged type as an opaque type, thereby hiding > any implementation details and still making that type extensible. This > was difficult in Modula-2, so the designers of Modula-3 also had to > make some compromises. Engineering is always about trade-offs > between conflicting solutions. Not always. Sometimes there's a way that's uniformly better than the alternatives. >...Java certainly has its share of trade-offs. >> >> Shrug. I don't use "is separate" much. Child packages are almost >> always better, because you can separate the spec _and_ the body, >> and because the parent need not know about the child. Child packages >> provide the same advantage of being able to "push down" the >> dependencies. >> > I did not mention Child packages, but you are certainly correct that they > are a powerful contributing solution to this issue. In particular, private > children are a great benefit. However, in very large software systems, > a million SLOC or more, "is separate" continues to play an important > role. I don't see why the size of the software has anything to do with subunits vs. child units. Subunits are occassionally useful, but child units are usually better (for large systems and small), and are never much worse. You can always change code that uses subunits to use child units instead, in a way that avoids changing any clients, at the cost of some annoying verbosity. >...As noted earlier, specifications should be an architectural concern, > and the more stable an architecture, the better. Implementation should > be dependent on architecture, not the other way around. > > When I want to change the upholstery in my car, I don't want to have to > alter the architecture of that car. I don't want the performance of the car > to depend on whether I choose Zebra seat covers or chartreuse trim > on green Naugahyde. > >>> I don't think this is possible in Java, Eiffel, or C#. >> >> It's possible using interfaces. Clients of an interface do not depend >> on classes that implement the interface, any more than clients of an Ada >> package spec depend on its body. You suggested otherwise elsewhere in >> this thread, but I think you're wrong, or else I'm misunderstanding what >> you mean by "depend". >> >> Interfaces are more flexible than spec/body in that they allow multiple >> "bodies". And of course Ada 2005 has interfaces. Note that an >> interface will typically be declared in a package spec with no >> corresponding body. >> > Even with an interface, a la Java, once the interface is implemented, the > children dependent on that unit will be dependent on the implementaion, > not on the interface. You said that before, and my response is as above: I think you're wrong, or else I'm misunderstanding what you mean by "depend". For example: package P1 is type Iface is interface; ... declare some abstract procedures ... end P1; package P2 is pragma Elaborate_Body; -- Note that this package spec can be entirely empty (except we -- need the pragma so we are allowed to have a body). -- So this package spec isn't defining any interface to -- anything at all! end P2; with P1; package body P2 is type Impl is new P1.Iface with ... ... override procedures ... ... end P2; -- No body for P1! Then the client can "with P1", and call operations on Iface objects without knowing anything about package P2 (neither spec nor body). There is no dependence of clients on P2 (unless I'm misunderstanding what you mean by "depend"). It works the same way in Java, which is not surprising, since Ada's interfaces were designed with Java interfaces in mind. >...And Java still has no way of separating the > specification of that implementing class from its implementation. ...which is irrelevant, since clients don't depend on that class. >...In > another forum (comp.lang.programming) someone submitted an > example to show how interfaces would solve this problem, but the > example did not separate interface from implementation.. > >> Eiffel has separate specs and bodies -- except that the spec is >> automatically generated from the body, rather than being written by >> hand. I prefer to consider the spec to be a source file in its own >> right, as in Ada, but it's not _that_ different from Eiffel. >> > Yes. In Ada, the specification is most certainly a separate source > file. As noted earlier, the specifications and the relatioships between > specifications, represent the overall architecture of the software > system. I'll take another look at Eiffel, a language design I do admire, > and examine this in more detail. However, at my present understanding, > the implementation and specification do not present the same independence > one finds in Ada. Perhaps someone will post an example. Eiffel doesn't have specs in the language. They're just pieces of text automatically generated by a separate tool. But they serve the same purpose as Ada's specs -- you can read them to understand the interface supported by a given class. > Thanks for your details reply. ...and thanks for an interesting discussion. > Richard - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 20:46 ` Robert A Duff @ 2008-02-24 7:31 ` adaworks 2008-02-24 17:20 ` Robert A Duff 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-24 7:31 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccbq679zah.fsf@shell01.TheWorld.com... In the example you provided (shown below) you did defer the with clause for the Package P1 to the package body of P2. This illustrates my point. If the specification for P1 changes, only the body for P2 needs to be compiled. Had the with clause been at the specification level for P2, and had the specification for P1 changed, the entire package would have had to be compiled. I think the same is true for Java. If the specification for the Interface is changed, everything needs to be recompiled. In Ada, by deferring the with clause to the package body, we only need to re-compile the body. So, I think your example actually supports my original assertion. The essential point is that changes in the specifications for a package (or a Java class) should not require re-compilation of the dependent specifications. Only the implementations should be dependent on other specifications. This has the effect of keeping the high-level architecture more stable. package P1 is type Iface is interface; ... declare some abstract procedures ... end P1; package P2 is pragma Elaborate_Body; -- Note that this package spec can be entirely empty (except we -- need the pragma so we are allowed to have a body). -- So this package spec isn't defining any interface to -- anything at all! end P2; with P1; package body P2 is type Impl is new P1.Iface with ... ... override procedures ... ... end P2; -- No body for P1! Then the client can "with P1", and call operations on Iface objects without knowing anything about package P2 (neither spec nor body). There is no dependence of clients on P2 (unless I'm misunderstanding what you mean by "depend"). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 7:31 ` adaworks @ 2008-02-24 17:20 ` Robert A Duff 2008-02-24 20:33 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Robert A Duff @ 2008-02-24 17:20 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wccbq679zah.fsf@shell01.TheWorld.com... > > In the example you provided (shown below) you did defer the with clause > for the Package P1 to the package body of P2. This illustrates my point. > If the specification for P1 changes, only the body for P2 needs to be compiled. > Had the with clause been at the specification level for P2, and had the > specification for P1 changed, the entire package would have had to be > compiled. Earlier, you said that this conversation was not about compilation costs, but now you seem quite interested in compilation costs. That's OK. So let's talk about compilation costs. ;-) I think you miss the point of my example (still shown below). Package P1 is the interface, and P2 is the implementation of that interface. P2 is NOT a client of P1, it's an implementation of P1! There are perhaps 37 clients of P1, not shown. The question is, if we modify the implementation (i.e. P2) do we need to recompile those 37 clients. The answer is "no". As you point out, if you change the interface, you have to recompile the implementation. That's true in my example. It's also true if the interface/implementation is split in the more traditional Ada way (spec/body). The issue of recompiling the spec of P2 is irrelevant, since it's empty! > I think the same is true for Java. If the specification for the Interface is > changed, everything needs to be recompiled. In Ada, by deferring the > with clause to the package body, we only need to re-compile the body. > > So, I think your example actually supports my original assertion. The > essential point is that changes in the specifications for a package (or > a Java class) should not require re-compilation of the dependent > specifications. Only the implementations should be dependent on > other specifications. This has the effect of keeping the high-level > architecture more stable. > > package P1 is > type Iface is interface; > ... declare some abstract procedures ... > end P1; > > package P2 is > pragma Elaborate_Body; > -- Note that this package spec can be entirely empty (except we > -- need the pragma so we are allowed to have a body). > -- So this package spec isn't defining any interface to > -- anything at all! > end P2; > > with P1; > package body P2 is > type Impl is new P1.Iface with ... > ... override procedures ... > ... > end P2; > > -- No body for P1! > > Then the client can "with P1", and call operations on Iface objects > without knowing anything about package P2 (neither spec nor body). > There is no dependence of clients on P2 (unless I'm misunderstanding > what you mean by "depend"). Let me try a more concrete example -- the trusty stack example. First, the traditional Ada way, using what you like to call "opaque" types: package Stacks is type Stack is private; procedure Push(...); ... private type Stack_Rec; type Stack is access Stack_Rec; end Stacks; package Stacks is type Stack_Rec is record ...; procedure Push(...) is begin ... end Push; ... end Stacks; If we change the implementation of the stacks abstraction (i.e. the body of package Stacks), we do not normally need to recompile the clients. We can accomplish the same thing with interfaces. I'll use a child package this time, just for fun: package Stacks is type Stack is interface; procedure Push(...) is abstract; ... end Stacks; package Stacks.Implementation is type Stack_Impl is new Stack with private; private type Stack_Impl is ...; overriding procedure Push(...); ... end Stacks.Implementation; package Stacks.Implementation is procedure Push(...) is begin ... end Push; ... end Stacks.Implementation; If we change the implementation of the stacks abstraction (i.e. the package Stacks.Implementation -- spec or body, it doesn't matter), we do not normally need to recompile the clients. Both ways of writing the stacks abstraction have the same property -- the 37 clients that say "with Stacks" do not need to be recompiled when we modify the implementation. The second example matches what is normally done in Java, except that in Java, we wouldn't split the implementation into two parts. Note that in the second example, that split has no value, since there are no clients of Stacks.Implementation. In fact, in some cases, we can choose to move all of the code from the spec of Stacks.Implementation to its body (as I did in my P1/P2 example), making the spec empty. (I'm glossing over the fact that there probably needs to be some sort of factory for creating stack objects, but that's not relevant to my point.) - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 17:20 ` Robert A Duff @ 2008-02-24 20:33 ` adaworks 2008-02-25 1:07 ` Robert A Duff 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-24 20:33 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccve4eff0d.fsf@shell01.TheWorld.com... > <adaworks@sbcglobal.net> writes: > >> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message >> news:wccbq679zah.fsf@shell01.TheWorld.com... >> >> In the example you provided (shown below) you did defer the with clause >> for the Package P1 to the package body of P2. This illustrates my point. >> If the specification for P1 changes, only the body for P2 needs to be >> compiled. >> Had the with clause been at the specification level for P2, and had the >> specification for P1 changed, the entire package would have had to be >> compiled. > > Earlier, you said that this conversation was not about compilation > costs, but now you seem quite interested in compilation costs. > That's OK. So let's talk about compilation costs. ;-) > Actually, it is not about compilation "cost." Rather, it is about architecture stability, where compilation does play a role. > I think you miss the point of my example (still shown below). > Package P1 is the interface, and P2 is the implementation > of that interface. P2 is NOT a client of P1, it's an > implementation of P1! > > There are perhaps 37 clients of P1, not shown. The question is, > if we modify the implementation (i.e. P2) do we need to recompile > those 37 clients. The answer is "no". > Yes. I agree. When we defer the implementation to the body, there is no need to recompile anything, unless the implementation is tightly bound to the specification. The architectural concern is when we recompile the specification. Any change to the specification will imply a change to everything dependent upon it. > As you point out, if you change the interface, you have to recompile the > implementation. That's true in my example. It's also true if > the interface/implementation is split in the more traditional > Ada way (spec/body). > This is not true in the traditional Ada way when the dependencies are deferred to the implementation level. When the specification is dependent on something that has changed, it is true. When the specification is not dependent on that change, the high-level architecture remains intact and does not need recompiling. > The issue of recompiling the spec of P2 is irrelevant, since it's empty! > In your example, you have deferred the dependency to the body of P2. So there is no need to recompile the spec for P2. However, if the with clause had been at the specification level of P2, and if the specification for P1 had changed, there is certainly a danger of an architectural problem if we did not recompile the specification and body for P2. > > Let me try a more concrete example -- the trusty stack example. > > First, the traditional Ada way, using what you like to call "opaque" > types: > Opaque type is not my name for this. It seems to be a commonly accepted term for the idiom. > package Stacks is > type Stack is private; > procedure Push(...); > ... > private > type Stack_Rec; > type Stack is access Stack_Rec; > end Stacks; > > package Stacks is > type Stack_Rec is record ...; > procedure Push(...) is > begin > ... > end Push; > ... > end Stacks; > > If we change the implementation of the stacks abstraction (i.e. the body > of package Stacks), we do not normally need to recompile the clients. > Correct. A change to the implementation does not require a recompilation. However, a change to the specification does. Also, in the example shown, you accidentally omitted the word "body" from the implementation unit. > We can accomplish the same thing with interfaces. I'll use a child > package this time, just for fun: > > package Stacks is > type Stack is interface; > procedure Push(...) is abstract; > ... > end Stacks; > > package Stacks.Implementation is > type Stack_Impl is new Stack with private; > private > type Stack_Impl is ...; > overriding procedure Push(...); > ... > end Stacks.Implementation; > > package Stacks.Implementation is > > procedure Push(...) is > begin > ... > end Push; > ... > end Stacks.Implementation; > > If we change the implementation of the stacks abstraction (i.e. the > package Stacks.Implementation -- spec or body, it doesn't matter), we do > not normally need to recompile the clients. > Note the inadventant omission of the word "body" in the example. I agree, we do not need to recompile the clients or dependent children if only the implementation has changed. This is exactly my point. When the scope clause (with clause) is deferred to the package body, the dependencies are also deferred to that level. When the dependencies are at the specification level, and some specification on which there is a dependency changes, the specification does have to be recompiled. This is the point of deferring with clauses to the body. It is not about recompilation costs. It is about preservatation of architectural integrity. When any parent unit changes, there should be as few other changes as possible, especially at the architectural level. If the entire architecture is characterized by with clauses at the specification level, then the entire architecture must be recompiled, and potentially evalutated to preserve that architecture's stability. > Both ways of writing the stacks abstraction have the same property -- > the 37 clients that say "with Stacks" do not need to be recompiled when > we modify the implementation. > Agree. It is not about modifying the implementation, in Ada. The package body is unlikely to have any dependency issues in Ada. > The second example matches what is normally done in Java, except that in > Java, we wouldn't split the implementation into two parts. Note that in > the second example, that split has no value, since there are no clients > of Stacks.Implementation. In fact, in some cases, we can choose to move > all of the code from the spec of Stacks.Implementation to its body (as I > did in my P1/P2 example), making the spec empty. > I don't think so. In you example, there are no dependencies. If there were, and if those dependencies were additional children, we could certainly have issues at the specification level. In your opaque type example, those dependencies are less severe if we provide appropriate query function to ensure the client (or child unit) can query the state of the elements of a type instance during its lifetime. Whenever one unit has an existing dependency on another, a change that affects that dependency needs to be addressed. While I admire the virtues of the Interface model in Java and Ada, the dependency concerns have not vanished with the introduction of Interfaces. An Interface requires an implementation. One of its virtues is that it can have multiple implementations. Each implementation will have its own identifier. If the specification for the Interface should change, everything dependent on that interface will also change. If that change could be deferred to the implementation of a dependent class instead of the class specification, that change would have less effect on the rest of the architecture. In Ada, this is usually pretty easy. In a separate reply, you mentioned generics. In most cases, there is no reason why a generic cannot be instantiated at the package body level. Further, I am not asserting that dependencies can always be deferred. One example of this is Ada.Finalization which must be with'ed at the package specification level. There are other examples. My contention is that the Ada model of dependency management is far superior to most other models for the preservation of architectural stability. Am I alone in this view? Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-24 20:33 ` adaworks @ 2008-02-25 1:07 ` Robert A Duff 2008-02-26 7:29 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Robert A Duff @ 2008-02-25 1:07 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > Yes. I agree. When we defer the implementation to the body, there is > no need to recompile anything, unless the implementation is tightly > bound to the specification. The architectural concern is when we > recompile the specification. Any change to the specification will > imply a change to everything dependent upon it. Right, but in Java, you can always move that dependence into an implementation of an interface, just like you can move that dependence down into a package body in Ada. > In your example, you have deferred the dependency to the body of P2. > So there is no need to recompile the spec for P2. However, if the with > clause had been at the specification level of P2, and if the specification > for P1 had changed, there is certainly a danger of an architectural > problem if we did not recompile the specification and body for P2. Yes, the spec of P2 would need to be recompiled in that case. I don't see why that's an "architectural problem". >> First, the traditional Ada way, using what you like to call "opaque" >> types: >> > Opaque type is not my name for this. It seems to be a commonly accepted > term for the idiom. Well, the only time I've heard "opaque type" is in the Modula-N context, and in cases where you have imported the term into the Ada context. The usual term for this is "stt access types" or "Taft Amendment types", named after their inventor. > Correct. A change to the implementation does not require a recompilation. > However, a change to the specification does. Also, in the example shown, > you accidentally omitted the word "body" from the implementation unit. Yes, thanks for pointing out that I forgot "body". >> If we change the implementation of the stacks abstraction (i.e. the >> package Stacks.Implementation -- spec or body, it doesn't matter), we do >> not normally need to recompile the clients. >> > Note the inadventant omission of the word "body" in the example. Another missing "body" -- thanks again. > I agree, we do not need to recompile the clients or dependent children > if only the implementation has changed. This is exactly my point. When > the scope clause (with clause) is deferred to the package body, the > dependencies are also deferred to that level. When the dependencies > are at the specification level, and some specification on which there is > a dependency changes, the specification does have to be recompiled. > This is the point of deferring with clauses to the body. Right. But the point of my example is that you can always defer the "with" to an implementation of an interface. > In a separate reply, you mentioned generics. In most cases, there is no > reason why a generic cannot be instantiated at the package body level. I don't agree with that. In my experience, when I declare a type T, I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to clients, that is done by generic instantiation. > My contention is that the Ada model of dependency management is far > superior to most other models for the preservation of architectural > stability. Am I alone in this view? I'm not entirely sure what you mean by "architectural stability" here, but I guess I'd agree if you changed "far superior" to "slightly more convenient". ;-) - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-25 1:07 ` Robert A Duff @ 2008-02-26 7:29 ` adaworks 2008-02-26 19:22 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-26 7:29 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccmyppg7yd.fsf@shell01.TheWorld.com... > <adaworks@sbcglobal.net> writes: > >> Yes. I agree. When we defer the implementation to the body, there is >> no need to recompile anything, unless the implementation is tightly >> bound to the specification. The architectural concern is when we >> recompile the specification. Any change to the specification will >> imply a change to everything dependent upon it. > > Right, but in Java, you can always move that dependence into an > implementation of an interface, just like you can move that dependence > down into a package body in Ada. > Even if this completely accurate, the vast majority of Java applications use only a small number of packages that consist of interfaces. The rest of the design does not use the Interface model. For those classes, in those packages, the dependency problem is not only possible but, after doing some additional research today, I find is fairly common. >> In your example, you have deferred the dependency to the body of P2. >> So there is no need to recompile the spec for P2. However, if the with >> clause had been at the specification level of P2, and if the specification >> for P1 had changed, there is certainly a danger of an architectural >> problem if we did not recompile the specification and body for P2. > > Yes, the spec of P2 would need to be recompiled in that case. > I don't see why that's an "architectural problem". > It is an architectural problem because, in Java, a corrupted dependency, something that apparently actually occurs in large-scale Java designs, is also going to corrupt the architecture of the software. As noted in a separate post, this problem has required the introduction of special dependency management tools such as Ivy, Maven, and Ant -- and these tools are not yet able to detect all the problems though they are getting better. Every software entity has an architecture, planned or ad hoc. One of the more important aspects of an architecture is to take every action possible to reduce or manage dependencies between the artifacts of that architecture. The separate compilation model of Ada does that better than most other languages. Modula has some virtues in this respect. However, the research I have been doing on Java leads me to believe that the language has significant weaknesses in architectural stability for large-scale systems. There are quite a few articles on the Internet describing these problems.. > > Right. But the point of my example is that you can always defer the > "with" to an implementation of an interface. > Even if we allow for the benefit of the Interface in this situation, we have not dealt with the larger body of a Java program that is not built using Interfaces. >> In a separate reply, you mentioned generics. In most cases, there is no >> reason why a generic cannot be instantiated at the package body level. > > I don't agree with that. In my experience, when I declare a type T, > I often want a sequence-of-T, or mapping-of-T, or whatever, exposed to > clients, that is done by generic instantiation. > But that does not have to be instantiated at the package spec level. In many cases, the instantiation is possible, and preferred at the body level. Granted, we sometimes have to instantiate at the spec level, but not always. Java templates are usually instantiated at the specification level, and that most certainly introduces a level of dependency with system-wide effects. >> My contention is that the Ada model of dependency management is far >> superior to most other models for the preservation of architectural >> stability. Am I alone in this view? > > I'm not entirely sure what you mean by "architectural stability" here, > but I guess I'd agree if you changed "far superior" to "slightly more > convenient". ;-) > Architectural stability implies that, except under extraordinary circumstances, any change to some artifact of the architecture will have minimal impact on the rest of that architecture. This is one valuable property of Ada's ability to let us defer most of our dependencies to the lowest level of the design possible. This is not a property of Java, C++, or most other languages in current use today. Even incremental compilation falls a little short. Oh, and does Rational Apex still support incremental compilation in Ada? GNAT is not the only Ada environment around. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 7:29 ` adaworks @ 2008-02-26 19:22 ` Ray Blaak 2008-02-27 1:58 ` adaworks 0 siblings, 1 reply; 72+ messages in thread From: Ray Blaak @ 2008-02-26 19:22 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > It is an architectural problem because, in Java, a corrupted dependency, > something that apparently actually occurs in large-scale Java designs, > is also going to corrupt the architecture of the software. As noted in > a separate post, this problem has required the introduction of special > dependency management tools such as Ivy, Maven, and Ant -- and > these tools are not yet able to detect all the problems though they are > getting better. Does the existence of gnatmake indicate corrupted dependency management in Ada? Tools like Ant fill the same kind of role. > Architectural stability implies that, except under extraordinary > circumstances, any change to some artifact of the architecture will have > minimal impact on the rest of that architecture. This is one valuable > property of Ada's ability to let us defer most of our dependencies to the > lowest level of the design possible. This is not a property of Java, C++, > or most other languages in current use today. I program in a lot of languages, and I used to be heavily into Ada. I just do not encounter the problem in a serious way with the other languages. I easily agree that Ada is better at this, but in every language I use currently, there are always ways to readily control dependency and separate compilation issues. It's just not a problem in practice. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-26 19:22 ` Ray Blaak @ 2008-02-27 1:58 ` adaworks 2008-02-27 20:34 ` Ray Blaak 0 siblings, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-27 1:58 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:uhcfv5xql.fsf@STRIPCAPStelus.net... > > Does the existence of gnatmake indicate corrupted dependency management in > Ada? > No. It might indicate a problem with the GNAT implementation, but not with Ada. Not all Ada compilers are GNAT, and some handle this more easily. One of the issues for GNAT is that it depends on the GNU model. This is not true of Rational Apex, Aonix, or even the ICC compiler. > I program in a lot of languages, and I used to be heavily into Ada. I just do > not encounter the problem in a serious way with the other languages. > I also program in a lot of languages. I even program in Java sometimes. However, I have not programmed any large-scale programs in Java, as I have in Ada. Although you have certainly made your point that my original statement may have been too strong, this conversation has, as noted in another contribution, led me to do some research into this issue. What I have found is not encouraging. In fact, it is even a little horrifying. As Java programs get larger, the dependency problems become more and more messy. Over and over this is discussed by various forums on the Internet. Until I began researching this, I had not idea just how pervasive the problem was in Java. Apparently, for toy programs, and small projects this problem with Java does not manifest itself. However, as Java programs get larger, the programmers are required to do a lot of workarounds. Further, the compiler does not actually trap all the kinds of errors that can occur with dependency issues. Third-party tools are required to analyze these problems, and those third-party tools are not foolproof -- at least, not so far. > I easily agree that Ada is better at this, but in every language I use > currently, there are always ways to readily control dependency and separate > compilation issues. > This may be true in your practice, but there are hundreds of developers out there who are find this to be a real problem. As I see it right now, Ada continues to be a much better solution when a software architecture is large and needs to scale-up to even larger. The scary thing for me, now that I am in the DoD, is that so many contractors are naive about this issue and continue to insist on using Java for weapon systems development. In my view, based on this week's research, Java should not be used for safety-critical systems. There are too many possibilities for serious hidden problems based on these dependency issues. It is probably OK for Web solutions, but no one will accidentally get killed or maimed because of a corrupted Internet solution. Ooooops! I forgot about SOA where reusable components are integrated into safety-critical solutions. I guess it is better to be safe and not use it at all for any kind of software where life and limb could be at risk. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 1:58 ` adaworks @ 2008-02-27 20:34 ` Ray Blaak 2008-02-27 22:31 ` Robert A Duff 2008-02-29 6:10 ` adaworks 0 siblings, 2 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-27 20:34 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message > news:uhcfv5xql.fsf@STRIPCAPStelus.net... > > > > Does the existence of gnatmake indicate corrupted dependency management in > > Ada? > > > No. It might indicate a problem with the GNAT implementation, but not > with Ada. Not all Ada compilers are GNAT, and some handle this > more easily. One of the issues for GNAT is that it depends on > the GNU model. This is not true of Rational Apex, Aonix, or > even the ICC compiler. I guess what I object to here is the idea that tools like gnatmake or Ant indicate a problem at all. GNAT's library model lives on a different place on the tradeoff curve as compared to the other Ada vendors. It allows some problems to be avoided at the expense of suffering from other possible problems that the other Ada vendors do not. It is also pretty simple. So, if one considers gnatmake to be an essential part of the GNAT build system, then my view is that this how the build dependency problem is solved for GNAT. There is no problem with the implementation as such. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 20:34 ` Ray Blaak @ 2008-02-27 22:31 ` Robert A Duff 2008-02-27 23:35 ` Ray Blaak 2008-02-29 5:57 ` adaworks 2008-02-29 6:10 ` adaworks 1 sibling, 2 replies; 72+ messages in thread From: Robert A Duff @ 2008-02-27 22:31 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > <adaworks@sbcglobal.net> writes: >> "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message >> news:uhcfv5xql.fsf@STRIPCAPStelus.net... >> > >> > Does the existence of gnatmake indicate corrupted dependency management in >> > Ada? >> > >> No. It might indicate a problem with the GNAT implementation, but not >> with Ada. Not all Ada compilers are GNAT, and some handle this >> more easily. One of the issues for GNAT is that it depends on >> the GNU model. This is not true of Rational Apex, Aonix, or >> even the ICC compiler. > > I guess what I object to here is the idea that tools like gnatmake or Ant > indicate a problem at all. I agree. I'm completely mystified by Richard's assertion that the existence of gnatmake might indicate a problem with GNAT. Any decent Ada implementation comes with a tool that knows how to rebuild (what to recompile/relink/whatever, and in what order, if that matters) based on what source files changed. The fact that such a tool can exist is one thing that makes Ada better than (for example) C. What does the "GNU model" mean, by the way? > GNAT's library model lives on a different place on the tradeoff curve as > compared to the other Ada vendors. It allows some problems to be avoided at > the expense of suffering from other possible problems that the other Ada > vendors do not. What's the "suffering" you see here? - Bob ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 22:31 ` Robert A Duff @ 2008-02-27 23:35 ` Ray Blaak 2008-02-28 0:19 ` Randy Brukardt 2008-02-28 9:18 ` Georg Bauhaus 2008-02-29 5:57 ` adaworks 1 sibling, 2 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-27 23:35 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > > GNAT's library model lives on a different place on the tradeoff curve as > > compared to the other Ada vendors. It allows some problems to be avoided at > > the expense of suffering from other possible problems that the other Ada > > vendors do not. > > What's the "suffering" you see here? None myself. I am speaking theoretically. There must be *some* advantage to the library approaches the other vendors use, right? Right? :-) -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 23:35 ` Ray Blaak @ 2008-02-28 0:19 ` Randy Brukardt 2008-02-28 9:18 ` Georg Bauhaus 1 sibling, 0 replies; 72+ messages in thread From: Randy Brukardt @ 2008-02-28 0:19 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:uwsoq6khn.fsf@STRIPCAPStelus.net... > Robert A Duff <bobduff@shell01.TheWorld.com> writes: > > > GNAT's library model lives on a different place on the tradeoff curve as > > > compared to the other Ada vendors. It allows some problems to be avoided at > > > the expense of suffering from other possible problems that the other Ada > > > vendors do not. > > > > What's the "suffering" you see here? > > None myself. I am speaking theoretically. There must be *some* advantage to the > library approaches the other vendors use, right? Right? :-) At the user level, they all pretty much look the same. The differences between Gnatmake and Corder (in Janus/Ada) aren't that significant - both allow the building of a program and recompilation of any needed dependencies. The details of the implementation are quite different, of course, but that's not very relevant to using either compiler. And what I've seen about other compilers also are pretty similar (ignoring some "advanced capabilities" that hardly anyone would use). There are big differences in the tradeoffs at the implementation level, and those manifest themselves in terms of significant differences in compilation speed, memory footprint, and needed disk space. (Although with the massive disks and CPU speeds of today, those differences are much less important than they used to be). Randy. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 23:35 ` Ray Blaak 2008-02-28 0:19 ` Randy Brukardt @ 2008-02-28 9:18 ` Georg Bauhaus 1 sibling, 0 replies; 72+ messages in thread From: Georg Bauhaus @ 2008-02-28 9:18 UTC (permalink / raw) Ray Blaak wrote: > Robert A Duff <bobduff@shell01.TheWorld.com> writes: >>> GNAT's library model lives on a different place on the tradeoff curve as >>> compared to the other Ada vendors. It allows some problems to be avoided at >>> the expense of suffering from other possible problems that the other Ada >>> vendors do not. >> What's the "suffering" you see here? > > None myself. I am speaking theoretically. There must be *some* advantage to the > library approaches the other vendors use, right? Right? :-) E.g., gnatmake without gnatchop is incomplete. The GNAT compiler proper succeeds translating Ada programs when the source text is organized into one-file:one-unit. Or, maybe you'll have to create a number of specially named files in the presence of subunits. The advantages have been explained... Q: "What source files is the compilation system actually using?" The answer would probably have to be a detailed one in the GNAT case. For other compilers, it might be A: "Read the file that lists the units." GNAT's default model delegates source code organisation to the programmer, suggesting a suitable set of files. (The advantages have been explained...). This doesn't remove a need for tools that let you switch views of spec and body. Can you submit this Ada source program to just gnatmake? -- %< -- %< -- %< procedure Foo; -- Does nothing, really procedure Foo is begin null; end Foo; -- %< -- %< -- %< Perhaps gnatchop with gnatmake is be easier to implement than some other schemes. The advantages have been explained... But in the end, gnatchop + gnatmake is good enough. Just use the GNAT scheme for every Ada project. ;-) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 22:31 ` Robert A Duff 2008-02-27 23:35 ` Ray Blaak @ 2008-02-29 5:57 ` adaworks 2008-02-29 6:04 ` Ray Blaak 1 sibling, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-29 5:57 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccfxverpyo.fsf@shell01.TheWorld.com... > > I agree. I'm completely mystified by Richard's assertion that the > existence of gnatmake might indicate a problem with GNAT. Any decent > Ada implementation comes with a tool that knows how to rebuild (what to > recompile/relink/whatever, and in what order, if that matters) based on > what source files changed. The fact that such a tool can exist is one > thing that makes Ada better than (for example) C. > It was not my intention to suggest any problem with GNAT. I probably did not phrase my response to the question very well. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-29 5:57 ` adaworks @ 2008-02-29 6:04 ` Ray Blaak 2008-02-29 10:48 ` Alex R. Mosteo 2008-02-29 17:05 ` adaworks 0 siblings, 2 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-29 6:04 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message > news:wccfxverpyo.fsf@shell01.TheWorld.com... > > > > I agree. I'm completely mystified by Richard's assertion that the > > existence of gnatmake might indicate a problem with GNAT. Any decent > > Ada implementation comes with a tool that knows how to rebuild (what to > > recompile/relink/whatever, and in what order, if that matters) based on > > what source files changed. The fact that such a tool can exist is one > > thing that makes Ada better than (for example) C. > > > It was not my intention to suggest any problem with GNAT. I probably > did not phrase my response to the question very well. In the interests of keeping any controversy alive, if you accept the use of tools that help an Ada compiler know what to rebuild based on what source files have changed, how is the use of tools that help a Java compiler to do the same thing a sign of deficient dependency control? I.e. Ant. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-29 6:04 ` Ray Blaak @ 2008-02-29 10:48 ` Alex R. Mosteo 2008-02-29 17:05 ` adaworks 1 sibling, 0 replies; 72+ messages in thread From: Alex R. Mosteo @ 2008-02-29 10:48 UTC (permalink / raw) Ray Blaak wrote: > <adaworks@sbcglobal.net> writes: >> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message >> news:wccfxverpyo.fsf@shell01.TheWorld.com... >>> I agree. I'm completely mystified by Richard's assertion that the >>> existence of gnatmake might indicate a problem with GNAT. Any decent >>> Ada implementation comes with a tool that knows how to rebuild (what to >>> recompile/relink/whatever, and in what order, if that matters) based on >>> what source files changed. The fact that such a tool can exist is one >>> thing that makes Ada better than (for example) C. >>> >> It was not my intention to suggest any problem with GNAT. I probably >> did not phrase my response to the question very well. > > In the interests of keeping any controversy alive, if you accept the use of > tools that help an Ada compiler know what to rebuild based on what source > files have changed, how is the use of tools that help a Java compiler to do > the same thing a sign of deficient dependency control? I.e. Ant. I guess the difference here is that Ada mandates a consistent build environment, be it via some library or what gnat does, while with Java you must go out to look for extra tools explicitly, and the features of these extra tools are not clearly defined by the Java spec. But I'm jumping in late and could be wrong. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-29 6:04 ` Ray Blaak 2008-02-29 10:48 ` Alex R. Mosteo @ 2008-02-29 17:05 ` adaworks 2008-02-29 18:33 ` Ray Blaak 1 sibling, 1 reply; 72+ messages in thread From: adaworks @ 2008-02-29 17:05 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:ud4qgnvqt.fsf@STRIPCAPStelus.net... > > In the interests of keeping any controversy alive, if you accept the use of > tools that help an Ada compiler know what to rebuild based on what source > files have changed, how is the use of tools that help a Java compiler to do > the same thing a sign of deficient dependency control? I.e. Ant. > Tools are fine. Every programming language benefits from tools. As I noted in another post, there is no perfect programming language. However, the problems of Java are inherent in the language design. While we all know that C++ is a language that is error-prone, that is not what we would expected of Java. On the other hand, Ada is a more consistent design that does not have as many design flaws as Java, and certainly not nearly as many as C++. In the case of C++, the tools have never been enough. For Java, it turns out, the tools are also insufficient for ensuring that language-based problems are elmininated from an application design, especially when that application is a large-scale software system. My concern is the dependability of software systems embedded in the tools and weapons used by our military personnel. They go into battle, placing their lives on the line using the software tools we provide. I long ago realized that any decision to use C++ for these kinds of systems was irresponsible (unless C++ was reigned-in drastically, as it is on JSF). I did not, until recently, worry as much about Java. Now, with my recent investigation of Java, I have concluded that it is also fraught with problems that can (and apparently do) produce errors in software that are difficult to trace and even more difficult to predict. The more I examine the evidence about Java, the more I realize it is not dependable enough for the kind of systems where people's lives are at stake. Therefore, I will, as noted earlier, recommend against the use of Java for military systems where dependability is an issue, whenever I can. When we are required to apply engineering practices in the development of computer software, neither C++ nor Java are sufficiently well-designed to measure-up to a rigorous model of engineering. Ada also falls short in some respects, but is not as bad as the alternatives. SPARK certainly comes closer to satisfying engineering principles and practices. As of this moment, there is no language that satisfies engineering as well as we might like. But that does not justify using languages that are so flawed that an engineer cannot depend on them to actually behave in predictable ways. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-29 17:05 ` adaworks @ 2008-02-29 18:33 ` Ray Blaak 0 siblings, 0 replies; 72+ messages in thread From: Ray Blaak @ 2008-02-29 18:33 UTC (permalink / raw) <adaworks@sbcglobal.net> writes: > The more I examine the evidence about Java, the more I realize it is not > dependable enough for the kind of systems where people's lives are at > stake. Therefore, I will, as noted earlier, recommend against the use of > Java for military systems where dependability is an issue, whenever I can. > > When we are required to apply engineering practices in the development of > computer software, neither C++ nor Java are sufficiently well-designed to > measure-up to a rigorous model of engineering. Ada also falls short in some > respects, but is not as bad as the alternatives. SPARK certainly comes > closer to satisfying engineering principles and practices. As of this > moment, there is no language that satisfies engineering as well as we might > like. But that does not justify using languages that are so flawed that an > engineer cannot depend on them to actually behave in predictable ways. In spite of my rooting for Java with regards to dependency control, I basically agree with the position of preferring Ada for rigorous environments. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-27 20:34 ` Ray Blaak 2008-02-27 22:31 ` Robert A Duff @ 2008-02-29 6:10 ` adaworks 1 sibling, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-29 6:10 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:u1w6y87fd.fsf@STRIPCAPStelus.net... > > I guess what I object to here is the idea that tools like gnatmake or Ant > indicate a problem at all. > Both tools are needed, and I am not implying any problem with gnatmake. My issue is with Java and its many many many problems with dependency management. The tools available for Java are apparently incomplete and hundreds of developers are complaining about those problems. Further, I just read an article in IEEE Software by Charlie Kai describing some entertaining security problems in Java that simply do not exist in Ada. My concern is that Java is being used for software systems where our military personnel have their lives on the line, and the more I learn about Java, the more worried I am about that software. It is an OK language for small software systems where no one's life is at risk, but it apparently does not scale up well without the potential for a great many problems. Consequently, I will, whenever I can, recommend against using Java for military safety-critical software systems. Ada, although not perfect, continues to be the most appropriate foundation for safety-critical software development. It is, even with its minor flaws, less flawed than any of the alternatives. Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (6 preceding siblings ...) 2008-02-22 21:27 ` Robert A Duff @ 2008-02-22 22:16 ` Jeffrey R. Carter 2008-02-23 13:44 ` Brian Drummond 2008-02-25 7:53 ` Jean-Pierre Rosen 9 siblings, 0 replies; 72+ messages in thread From: Jeffrey R. Carter @ 2008-02-22 22:16 UTC (permalink / raw) adaworks@sbcglobal.net wrote: > > This morning, after an especially interesting argument about this feature and, > "Why would > anyone want to do such a thing?" style questions, I decided to approach this > forum. What > is your view of Ada-style separate compilation when compared to that in other > languages? > Do you find it useful in your own practice? Do you still use the "is separate" > feature in > a package body? For my own programs, I find it helpful as a way to manage > dependencies > when there are a lot of library units. Also, UML does not support a capability > for modeling > separate compilation, and that is a bit frustrating when trying to model a > fine-grained design. I find the separation of spec and body very useful, especially for programming in groups by setting detailed design decisions in code-crete as pkg specs. I find many of the features of Ada packages useful in representing the implementation of a good design. I primarily use body stubs to reduce the size of large pkgs. -- Jeff Carter "Help! Help! I'm being repressed!" Monty Python & the Holy Grail 67 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (7 preceding siblings ...) 2008-02-22 22:16 ` Jeffrey R. Carter @ 2008-02-23 13:44 ` Brian Drummond 2008-02-23 17:19 ` adaworks 2008-02-25 7:53 ` Jean-Pierre Rosen 9 siblings, 1 reply; 72+ messages in thread From: Brian Drummond @ 2008-02-23 13:44 UTC (permalink / raw) On Fri, 22 Feb 2008 17:35:33 GMT, <adaworks@sbcglobal.net> wrote: >Recently, I have been engaged in some conversations with colleagues about the >value of >separate compilation. This is one of my favorite features in Ada. In fact, >as nearly as >I can tell, none of the other popular languages includes this feature in as >well-developed >a form as Ada. One language which does have an equivalent mechanism (perhaps not surprisingly, given its origin), and in which a similar debate is currently active, is VHDL. There, the separation takes the form of the "component" specification, within the consumer of a component. The consumer can instantiate a "component", (similar to declaring a variable of a type defined separately) whose interface is guaranteed consistent with its use by the compiler - and at this stage, nothing is known about the implementation. Separately, the component is defined as an "entity", and implemented as an "architecture", which are again guaranteed consistent with each other during compilation. It is only at elaboration that an attempt is made to find an "entity" to match each "component" specification; if there are any failures to match, of course, elaboration fails with an error. But there is also a way to bypass separate compilation by direct entity instantiation, in which an entity specification is embedded in the consumer, in the place of the component specification. In this case, the matching entity must be found (already compiled and correct) for the consumer to compile. Interestingly, in comp.lang.vhdl, the concensus seems to be that direct instantiation is to be preferred where possible. (google comp.lang.vhdl for "direct entity instantiation" if you need more of the debate). Two reasons are usually mentioned: the component specification is just one more piece of code to write and maintain; (and VHDL is perceived as verbose enough without it), and forcing the entity/arch to compile concurrently with the consumer is perceived as catching any errors earlier (i.e. compile time vs elaboration). In other words, as said here for Java, compilation is cheap. >This morning, after an especially interesting argument about this feature and, >"Why would >anyone want to do such a thing?" style questions, I decided to approach this >forum. What >is your view of Ada-style separate compilation when compared to that in other >languages? >Do you find it useful in your own practice? I am out on a limb in still using components, and I'm not entirely clear why I do, other than mild personal preference, and because the toolset I use encourages it; it works perfectly well for me. Though I have occasionally had elaboration failures due to component mis-specification, they haven't caused any real headaches. I'm not clear why the theoretical advantages of separate compilation aren't seen as advantages in practice (in the VHDL world); the outspoken critics are respected consultants and trainers; possibly they are in one-man or small-team environments rather than million line projects. Possibly separate compilation was a big win when you had 8K of core and a drum store, but a bit less important nowadays? (coming back to "compilation is cheap" again) I'm in a one-man project environment myself, where I can't see a clear win for either side of the debate; separate compilation certainly doesn't impose significant drag, except where tool bugs prevent making good use of packages and libraries. But that's another issue... - Brian ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-23 13:44 ` Brian Drummond @ 2008-02-23 17:19 ` adaworks 0 siblings, 0 replies; 72+ messages in thread From: adaworks @ 2008-02-23 17:19 UTC (permalink / raw) "Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:q760s392l0g6klikofa4gs2ba4jiv1isf0@4ax.com... > > One language which does have an equivalent mechanism (perhaps not > surprisingly, > given its origin), and in which a similar debate is currently active, is VHDL. > I would like to know more about this debate. Could you provide some sources for review. You may send me an email at my office if you wish: rdriehle@nps.edu Thanks Richard Riehle ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Separate Compilation in Programming Languages 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks ` (8 preceding siblings ...) 2008-02-23 13:44 ` Brian Drummond @ 2008-02-25 7:53 ` Jean-Pierre Rosen 9 siblings, 0 replies; 72+ messages in thread From: Jean-Pierre Rosen @ 2008-02-25 7:53 UTC (permalink / raw) adaworks@sbcglobal.net a �crit : > What > is your view of Ada-style separate compilation when compared to that in other > languages? > Do you find it useful in your own practice? I think that the most useful feature is separate compilation of specs and bodies. When designing a module (a body), you can design the specifications of the modules that you will need to implement it (what I call an abstraction layer). Then you can compile your body against these specifications, and make sure you specs serve the intended purpose /before/ any implementation effort. You can even provide body stubs, and prototype your abstraction layer. With Ada's separate compilation features, you do not only design top-down, you can also code top-down. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2008-02-29 18:33 UTC | newest] Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-02-22 17:35 Separate Compilation in Programming Languages adaworks 2008-02-22 17:52 ` Dirk Heinrichs 2008-02-23 0:23 ` adaworks 2008-02-22 18:10 ` Ray Blaak 2008-02-22 23:53 ` adaworks 2008-02-23 1:40 ` Ray Blaak 2008-02-23 7:29 ` adaworks 2008-02-23 18:42 ` Ray Blaak 2008-02-22 18:18 ` Niklas Holsti 2008-02-23 0:14 ` adaworks 2008-02-23 7:23 ` Niklas Holsti 2008-02-23 7:31 ` Niklas Holsti 2008-02-23 16:00 ` adaworks 2008-02-23 12:27 ` Georg Bauhaus 2008-02-23 12:37 ` Dirk Heinrichs 2008-02-23 13:03 ` Niklas Holsti 2008-02-22 19:11 ` Dmitry A. Kazakov 2008-02-23 0:16 ` adaworks 2008-02-22 19:33 ` Larry Kilgallen 2008-02-22 20:47 ` Simon Wright 2008-02-22 21:27 ` Robert A Duff 2008-02-23 0:12 ` adaworks 2008-02-23 10:28 ` framefritti 2008-02-23 12:45 ` Dirk Heinrichs 2008-02-23 15:16 ` Robert A Duff 2008-02-23 16:47 ` adaworks 2008-02-23 18:47 ` Ray Blaak 2008-02-24 7:40 ` adaworks 2008-02-24 9:42 ` Ray Blaak 2008-02-24 20:41 ` adaworks 2008-02-25 2:37 ` Ray Blaak 2008-02-25 7:06 ` adaworks 2008-02-25 13:12 ` Robert A Duff 2008-02-25 17:44 ` Ray Blaak 2008-02-25 22:16 ` Ray Blaak 2008-02-26 5:10 ` John W. Kennedy 2008-02-26 19:08 ` Ray Blaak 2008-02-26 7:11 ` adaworks 2008-02-26 13:38 ` Stephen Leake 2008-02-26 14:56 ` adaworks 2008-02-26 19:15 ` Ray Blaak 2008-02-26 19:13 ` Ray Blaak 2008-02-26 21:25 ` Ray Blaak 2008-02-27 1:15 ` Robert A Duff 2008-02-26 7:06 ` adaworks 2008-02-26 11:42 ` Alex R. Mosteo 2008-02-26 15:05 ` adaworks 2008-02-26 15:15 ` Alex R. Mosteo 2008-02-24 17:26 ` Robert A Duff 2008-02-23 20:46 ` Robert A Duff 2008-02-24 7:31 ` adaworks 2008-02-24 17:20 ` Robert A Duff 2008-02-24 20:33 ` adaworks 2008-02-25 1:07 ` Robert A Duff 2008-02-26 7:29 ` adaworks 2008-02-26 19:22 ` Ray Blaak 2008-02-27 1:58 ` adaworks 2008-02-27 20:34 ` Ray Blaak 2008-02-27 22:31 ` Robert A Duff 2008-02-27 23:35 ` Ray Blaak 2008-02-28 0:19 ` Randy Brukardt 2008-02-28 9:18 ` Georg Bauhaus 2008-02-29 5:57 ` adaworks 2008-02-29 6:04 ` Ray Blaak 2008-02-29 10:48 ` Alex R. Mosteo 2008-02-29 17:05 ` adaworks 2008-02-29 18:33 ` Ray Blaak 2008-02-29 6:10 ` adaworks 2008-02-22 22:16 ` Jeffrey R. Carter 2008-02-23 13:44 ` Brian Drummond 2008-02-23 17:19 ` adaworks 2008-02-25 7:53 ` Jean-Pierre Rosen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox