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: 101deb,495b037244521cf3 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,22b2c05a8088bbb2 X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Leading zeros with Int_IO.Put()? Or another package? Date: 1996/11/22 Message-ID: <3295FCCA.77EA@lmtas.lmco.com>#1/1 X-Deja-AN: 198174190 references: <327FB8A3.745B@itg-sepg.logicon.com> <55ubsh$lh0$1@goanna.cs.rmit.edu.au> <56bi13$3pa$1@goanna.cs.rmit.edu.au> <328A0DDD.94B@lmtas.lmco.com> <56rgou$r4k$1@goanna.cs.rmit.edu.au> <56tjrh$4ak$1@goanna.cs.rmit.edu.au> <56trsm$f5a$1@goanna.cs.rmit.edu.au> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.pl1 x-mailer: Mozilla 2.02 (Macintosh; I; 68K) Date: 1996-11-22T00:00:00+00:00 List-Id: robin wrote: > >>>Ken Garlington writes: >>> >From the Introduction section of ISO/IEC 8652:1995: > >>> >"The need for languages that promote reliability and simplify maintenance >>> >is well established. Hence emphasis was placed on program readability over >>> >ease of writing." > > ---It is abundantly clear that it failed as to ease of writing. Ah! I see the problem now. You are misreading the above statement. Ease of READING is the design goal, not ease of WRITING. > Various postings suggested that the conversion could be done in up to > 82 lines of Ada code, whereas PL/I requires one simple line. As you probably know, this argument is easily refuted by someone writing a (bad) PL/I program that does the same function in 82 lines. The correct comparison, if you want to talk about ease of writing (and why would you, if you're a software engineer?) is the _smallest_ Ada implementation vs. the _smallest_ PL/I implementation, which is two Ada lines (or three shorter lines) vs. one PL/I line. By your criteria, of course, APL is a much better language than either Ada or PL/I. > >>No excuse for having everyone who wants to use such a facility > >>to have to write it. > > >*BUT THEY DON'T*. > > But they do, and there were various postings all giving different > ways to accomplish it in Ada. Whereas there was only one poster giving only one PL/I solution. Using the rhetoric of this thread, the greater flexibility of Ada over PL/I "cannot be refuted." (Troll language if there ever was any... :) > Now why would you bury a picture specification in a remote place from > the output statement that uses it? Going back to my business COBOL days, one possibility would be to specify a standard picture for: all currency values all tank quantity measurements etc. even though values of these types might be reported in different columns, etc. This would allow consistency between different output statements for the same type value. > >I note that Ada 95 makes it pretty easy to read a picture from a file, > >or compute on on the fly by some other method. > > A facility that's available in IBM's PL/I for OS/2, Windows 95/NT and > AIX. Does this mean that this feature is not available in other implementation of PL/I? I thought this was standard in all implementations of PL/I. > Thank you for proving the point! PL/I's > > put edit (d) (P'-999,999,999'); > > is a lot simpler. Not as simple as RPG, though. Now _there_ was a language that emphasized ease of writing! > P.S. Check out PL/I's drifting user-specifiable currency symbols etc > for picture editing. Great fun! Perhaps you could compare PL/I's version with Ada's and give us your opinion. See paragraph 15 of http://www.adahome.com/rm95/rm9x-F-03.html and paragraph 11 of http://www.adahome.com/rm95/rm9x-F-03-03.html to understand how Ada does it. -- LMTAS - "Our Brand Means Quality" For more info, see http://www.lmtas.com or http://www.lmco.com