From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: Ammo-zilla Date: 1999/10/28 Message-ID: <3818B280.472FDBE5@averstar.com>#1/1 X-Deja-AN: 541786251 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-10-28T00:00:00+00:00 List-Id: Charles Hixson wrote: > > I am continually attracted to Ada, however: > The Ada approach to memory management reminds me of the PL/1 approach, > only simplified a bit. I suppose that you can say that it's better than > C++, but that's *REALLY* faint praise. There are a lot of details that > I don't fully understand, but this is one of Ada's weaker aspects. The > second is the syntax used in "object" declaration. Very clumsy. > > Now I *do* understand that the reason for this approach is (partially > the date of design but also) to allow statically linked programs to be > small enough for embedded systems, etc. And it is indeed necessary to > enable this. But the cost of a unified design of this nature is that, > e.g., garbage collection is eliminated from the language. (The syntax > is mainly due to early design.) I feel relativly certain that if the > language were to be designed today that many things would have been done > differently. That's an interesting question. I have on occasion since we finalized the Ada 95 design thought about how I might design a language if I could really start from scratch. After a huge amount of horsing around, I end up surprisingly close to where Ada 95 is now. For example, you mention the "clumsy" syntax associated with object declarations. It is interesting to note that Haskell, one of the more elegant functional programming languages out there, has essentially the identical object approach as Ada 95, as does CLOS, common lisp object system. If you are used to the notion of an abstract data type, defined by a type and a set of operations, and then you decide you want to support extensibility of abstract data types, then you end up at something very much like Ada 95, Haskell, or CLOS, with the "operation(operand, operand, ...)" or "operand operand" or "object := operation(operand, operand,...)" syntax familiar from theoretical mathematics and logic. If you instead focus on updating objects as the primary operations of interest, then you end up with the . syntax. In some ways, the Ada 95 syntax is more sympathetic with the "value-oriented" (i.e. functional) way of thinking than the "object-oriented" (i.e. side-effecting) way of thinking. The net effect, in any case, is that you can more easily write in a "functional" style in Ada 95 where there is less use of heap-resident read/write objects, and more use of values (rather than objects) of an abstract type being passed around, assigned, declared, etc. One interesting side note -- because Ada is a multi-tasking language, the objects that are designed to retain read/write global state need some kind of synchronization/protection. For such objects (tasks and protected objects), the object.operation(...) syntax is intentionally chosen, because there is clearly a special role played by the "target" task or protected object. By contrast, for value-oriented operations like set union, the symmetrical syntax of "union(set1, set2)" seems far more intuitive than "set1.union(set2)", and the symmetrical syntax is used for such operations in Ada. Speaking from experience of using Java, although the object.operation(...) syntax can be convenient sometimes, surprisingly often I find conceptual operations for which there are at least two conceptual operands, generally of different types/classes, that are just as appropriate (or perhaps, just as inappropriate) as the "prefix" operand in the object.operation(...) syntax. Generally, I suppose the distinction is between operations whose primary role is to update some operand (in which case, it makes sense to be identified specially), versus those operations that create some output given two or more inputs, in which case it is arbitrary which of the inputs ends up being put "out front" in the object.operation(...) syntax. As usual in all such discussions, your mileage may vary... > David Botton wrote: > > > > Now that's an interesting comment, because to me C++ and Ada > > > are identical in this particular department, can you explain > > > why you think Ada is better wrt memory leaks? > > > > As a result of the excellent design of Ada, I use far more static > > allocation then dynamic resulting in less chance of memory leaks. Of > > course once you start playing with the heap its all about personal > > programmer discipline. > > > > David Botton -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA