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: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: robert_dewar@my-dejanews.com Subject: Re: Ada vs C++ vs Java Date: 1999/01/16 Message-ID: <77q4a2$d79$1@nnrp1.dejanews.com> X-Deja-AN: 433303577 References: <369C1F31.AE5AF7EF@concentric.net> <369CBD05.79D0@telusplanet.net> <369CBDA8.D3673C68@pwfl.com> <77np3q$e6h$1@nnrp1.dejanews.com> X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sat Jan 16 13:30:42 1999 GMT Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-01-16T00:00:00+00:00 List-Id: In article , mtobler@no-spam-ibm.net (Michael J. Tobler) wrote: > In article <77np3q$e6h$1@nnrp1.dejanews.com>, > robert_dewar@my-dejanews.com > says... > [snip] > > (as a matter of fact one of my PhD students, Carma > > McClure, > > who is now married to James Martin) wrote her thesis in > > this area in the mid 70's. > > My understanding is that you are a professor. (Correct me > if I'm rwong :) Half right and half wrong :-) I am a professor, but I also am president of a software company (that specializes in Ada), and I have written well over a million lines of delivered commercial code in many languages. > > > But proper COBOL style is very different from Pascal > > style, > > This kind of in-the-small top down refinement with nice > > names for sections of code makes well written COBOL > > easy > > to read, > > "Nice names" and well-written programs are not reserved > for COBOL programs. You can create a mess in any > language. COBOL doesnt force you to > write "well-written" applications. Or more maintainable > code. You make a general apple pie comment, but you seem to have missed the very specific technical comment I was making regarding giving names to small sections of code, something that is typical of COBOL style, and not of Pascal style. > > and by contrast the Algol (and hence Pascal, C, > > Ada, C++ etc) style of using nested if's is often much > > less clear. > > That's a matter of style. If you "nest" more than three > levels of "if-else" statements, then your logic needs to > be re-investigated. I find it odd that you lump Algol, > Pascal, C, Ada, C++ into the same group. Why is that? Because they are all derived more or less directly from Algol-60 in this respect, and all have much the same feel with respect to nested if's. Your (very reasonable for these languages) rule of not nesting more than three levels pretty much applies uniformly to all these languages. The point is that in COBOL, even nesting three levels would normally be considered very poor style. That's because the style of local refinement that it allows means that, unlike the case in say C, it is convenient to avoid *any* if nesting at all, and many COBOL programmers do avoid nesting (it is not uncommon for coding standards to forbid it). If you tried to forbid nested if's in C, you would create a horrible mess. > > I really miss this ability to define local procedures > > and use them easily in languages other than COBOL. Note > > that in languages like Pascal, the syntax for simple > > procedure definitions is far more verbose than in COBOL > > (where the syntactic definition overhead for a > > procedure is the name of the procedure and two > > periods), and worse, you have to > > declare the procedure before you use it, exactly wrong > > for this kind of called-only-once top-down-refinement > > approach. > > What it all boils down to is what you're comfortable > with. You should use the language that best fits the > project or problem at hand. Again, an applie pie statement that misses the very specific technical note I was making with regard to local refinements. Obviously no one chooses C vs COBOL on this issue, but such a choice would be made on all sorts of grounds. > I work on projects that may require three or four > implementation languages to arrive at the finished > product. Of course, in the academic world, you dont have > to concern yourself with that noise :) Well as I noted above, my very extensive programming experience is hardly of the academic variety. Yes, most large projects do require mixed languages. To make another technical point here, it is quite suprising that of the commonly used languages, only Ada makes an effort to accomodate this need in a portable manner. Someone once asked on the comp.lang.cobol group how to interface COBOL to C. The answer is that there is *no* portable way of doing this, just as there is no portable way of interfacing Fortran to C (here I am talking about direct interfacing, not interfacing via something like CORBA, or via ASCII files). I noted that the only portable way of interfacing from COBOL to C is to use Ada as an intermediary, since Ada does define COBOL to Ada interfacing and C to Ada interfacing (in both directions). Certainly mixed-language programming is important, and of course many of my large projects have involved that. The Realia COBOL compiler [now sold by Computer Associates] (for which I wrote the backend, optimizer, debugger and run-time library) was a mixture of COBOL and 8086 assembler. The GNAT compiler (www.gnat.com) that my company (Ada Core Technologies) supports and maintains is an example of a large Ada and C program (Ada for the front end, a mixture of Ada and C for the front-back-end interface, and C for the backend). So interfacing between languages and mixed-language programming is certainly familiar to me, although again I do not see what it has to do with the very specific point I was making (which was a reaction to someone thinking it was a good idea to import Pascal structuring techniques into COBOL). > > Now it maybe that you don't agree that this is a nice > > style and prefer the nested if's of C, but too bad! If > > you are writing COBOL (or any other language) part of > > your job is to learn the style that is considered > > standard and desirable in that language. > > True, but real programs dont hover around the structure > of nested if-else's - what's the hang up on if-else's??? "True" to the point I was making -- fine, that's the only thesis I was arguing! As for nested if-else's, since when is it a "hang up" in the field of programming language design to take a close look at one particular feature which is instructive. You seem to be taking my post as a general treatise on the differences between Pascal and COBOL. Of course it is nothing of the kind. I was just giving one interesting illustrative examples of the way in which COBOL style is very different from Pascal. There are of course (as you must know if you are an experienced COBOL programmer) dozens of other examples I could have chosen. > > Writing code that practioners in the language regard as > > "unusual" and judge to be the result of importing > > inappropriate foreign paradigms from other languages is > > the sign of a poor programmer. > > Not necessarily...it means that the programmer is > unfamiliar with the territory and doesnt have the proper > guidance to properly implement a solution. That usually > comes from "one-way-street" teachers and managers. Sorry, but for me, unfamiliarity and incorrect training make a poor programmer. If I hire a plumber and he is unfamiliar with what he is doing, and makes a mess as a result, he is a poor plumber. Saying someone is a poor programmer does not mean they are a bad person, or lack intelligence. It just means they lack competence in programming. This can indeed be the result of poor training. > > One of the great advantages of COBOL is that people who > > know and understand the language well tend to write in > > a very uniform style, so that people can easily read > > one another's code. If you ever encountered convoluted > > use of templates in C++, you will know what I mean by > > this failing to be the case in some other languages. > Believe me, I have seen "convoluted" COBOL, it is not > restricted to the "other" languages you list. Again, a general applie pie statement! Yes of course, but if you are really familiar with the typical worlds of commercial C++ and COBOL programming as I am, then I am surprised you do not agree there is a difference here. First COBOL is much more prescriptive than C++ when it comes to, e.g. layout, but it's more than that. There is typically one way of doing things in COBOL, where there may be many in C++, and in practice, COBOL style tends to be much more uniform.> > > Obviously you never really learned COBOL well, if you > > did not understand that importing Pascal style is NOT > > the right answer to anything. Consequently, your > > "Luckily" comment is not surprising, it is always > > frustrating to program in a language you do not > > understand! > Obviously, you never really learned C++ or C or other > languages you list to properly assess them. Better yet, > you dont understand that different languages require > different paradigms and thought processes. You can't > possibly compare COBOL to C++ or Java or Algol or Ada or > Modula-3.h Actually people compare languages all the time, this thread is an example. I actually know C++ and C well, and indeed I know many languages well and have used them in large commercial applications I have delivered. There are many comparison points that are of interest. Yes, of course it is the case that you think differently in different languages. That actually, if you read a little more carefully what I wrote, was the point! I was criticizing someone who felt that it was "the greatest complement" to have imported foreign Pascal thinking into COBOL. Such inappropriate importing of foreign style is a horribly frequent form of poor programming (a recent very common form of this is importing C style into C++, particularly easy to do, since C++ is more or less a superset -- the result is all sorts of junk low level thinking which is inappropriate in a C++ context). But if you are in the language design field as I am (I was chair of the Algol-68 maintenance committee for many years, I was one of the authors of the Ada 9x design document, and a member of the review team for Ada 9x, and have also played a major role in the development of IITRAN and SETL, as well as designing the SPITBOL dialect of SNOBOL4), then you definitely look for interesting points in various languages to understand if they are applicable in a design effort for some particular language. For the particular, very narrow, very specific, point that I was making in my post, which I think you have missed by interpreting it as some general statement, I think the local refinement notation of COBOL is quite interesting and could be applied to other languages. Indeed it has been, see Koster's CDL language, and the original design of SETL-1. See also Lambert Meerten's paper for the Novosibirsk meeting of IFIP WG2.1 that discusses this specific point, and the resulting design of the ABC language. > I understand what you're saying: that you cant apply > Pascal programming techniques to COBOL. Yup, that's the one point I was making!!! > At the same time, you cant put COBOL in the trophy > case and say other languages are inadequate. No one did that. I merely commented on one tiny little feature of COBOL that I find convenient and that I miss in other languages. There are of course many giant features, like recursion, that I miss in COBOL, compared to other languages! No trophy cases around here, although I tend to find that people in the programming language field know far too little about COBOL, and tend to dismiss it without knowing much about it, which is a pity, since it has a number of interesting ideas, some of which can be imported usefully into other languages. For an example of such importation, see the Information Systems Annex of Ada 95, which I helped to design. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own