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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-07 01:35:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!snoopy.risq.qc.ca!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3F5AE863.35C9D08@sympatico.ca> From: David Marceau X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-10mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 07 Sep 2003 04:12:19 -0400 NNTP-Posting-Host: 65.92.160.235 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1062922793 65.92.160.235 (Sun, 07 Sep 2003 04:19:53 EDT) NNTP-Posting-Date: Sun, 07 Sep 2003 04:19:53 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:42229 Date: 2003-09-07T04:12:19-04:00 List-Id: Hyman Rosen wrote: > > Russ wrote: > > First of all, Java forces everything into the "object-oriented" mold > > whether it fits or not. > > Not true. It's easy enough to make class methods be static, and then > you've got the equivalent of a package with variables and procedures, > if that's what you want. You can also declare your class methods to be > final and accomplish about the same thing. So there's no real forcing > of OOness. > > > it has no separately compiled specification files > > That can be programmed by using interfaces. Write your specifications > as interface classes, then write the implementations as implementing > the interfaces. Works fine. I beg to differ that it works fine just as is. The concept of the keyword "interface" is something that is highly documented and truly borrowed from the Microsoft COM/OLE methodology and probably .NET also. Interfaces are the way to separating the differences between versions of components. The suggested programming lifestyle of COM/OLE/.NET is if you need to change the behaviour of an existing interface for a component, then it is usually better actually to create a new interface and keep the old interface intact. This is very important for runtime compatibility of different versions of an application. The impacts of running an old application with new libaries swept underneith usually leads to havoc when old interfaces are not preserved. In fact I would imagine this is where the java developers borrowed the keyword interface because deep down in the Java Native Interface jni.h you can see remnants of the OLE/COM variant type structures embedded into the standard all-encompassing JObject. If you haven't read Inside OLE I suggest you do it for its perspective. There is a much good material in there considering versioned binaries and architecting forward version binary compatibility. The recipe you gave above is exactly the recipe for c++. In ada it is the case that when you build the app usually you have all the sources to your disposal so this isn't much of a concern is it? ;) In java however on more than one occasion I have had my infrastructure crumble underneith me because the RAD spiral development was spiralling like crazy. The interfaces and their behaviours were changing left right and center without prior notice and completely undocumented. One advantage over ada is that much deliberation is placed on thinking about the specification before implementing it. Lots of docs support the ada process usually. Java is somehow more like visual basic and more freestyle because it encourages you try a bunch of things on the fly without much consideration about the impact one's code has on other members in a team when reinserted into the source control system and also without any documentation to show for these changes. Changes like these would never happen if using ada because usually that assume you are using process/methodology that explicitly forces you to document what changes you have made. The way the dependencies are checked and built against with an ada compiler is still much better when dealing with lots of source IMHO. It's much to do with process also. When working with java it is almost as if one was encouraging freestyle methodology and when you write something is compiles successfully too easily. That said it doesn't guarantee that the java application will run... I must say the successful construction of an application not only lies on the language used but also on the methodology/process used. I like to refer to the methodology/process used as the "programming lifestyle" which all members of the team must adopt in order to the project to be a success. IMHO again Ada will probably succeed more because usually more deliberation is placed in programming lifestyle when using Ada. Not all programmers but there are many freestyle java /c++ coders out there but when they get together in a team IMHO it's just havoc. I have placed a lot of effort describing this "interface" feature here because it is among the most important features any language could have and to make work efficiently among team developers. Ada has their way of doing this stuff and IMHO it is again a better way ;> I won't waste my breath repeating the oodles of ada rationale docs. Cheers, David