DOCJMENITATION IN THE 4 th GENERATION If I hear one more guy say, 'I've got a fourth generation programming package; you've never seen a n y t h i n g like it before,' i'm going to throw up. Yes, it's crude, but so are these entrepreneurs. FOurth generation languages have been around l o n g e n o u g h f o r t h e r e t o be b i b l i o g r a p h i e s 1 conferences, and maybe hundreds of a r t i c l e s about them. ACM'85 is d e v o t e d to the challenges of F i f t h Generation--this assumes that fourth generation is no sweatl It's about time we documentation types made a statement about fourth generation documentation. We should confess to the w o r l d that we haven't had our heads in unseemly places while all of this has been going on. In fact, we are aware of some special problems relating to fourth generation s o f t w a r e w h i c h can be o v e r c o m e , in p a r t by b e t t e r documentation ( o n - l i n e or hard-copy as you p r e f e r , mes amis). Ned Chapin has observed ten d i s t i n c t i v e characteristics of program n ~ a i n t e n a n c e r e l a t i n g to f o u r t h g e n e r a t i o n languages. From the documentation specialists' view, the interesting ones are: 2. Short fourth-generation language programs less than 45 lines of source code long in t o t a l are usually f a s t e r , sometimes easier, but rarely cheaper to maintain than a functionally equivalent implementation in a third-generation report w r i t e r , r e p o r t g e n e r a t o r , f i l e maintenance, or data base access or inquiry language. Three t h i r d - g e n e r a t i o n examples are RPG, MARK-IV, and Easyt rieve. 3. The d e f a u l t s , e x p l i c i t and i m p l i c i t , and t h e t a c i t assumptions made in using a fourth-generation language are more trouble-some [ s i c ] in maintenance than in development. They sometimes block what appears at f i r s t as a 'clean' way of g e t t i n g the computer to do sonething. Chapin goes on to comment: A t t h i s e a r l y and s t i l l formative stage in the life of fourth-generation languages, i t is probably premature to attach too much importance to the ten o b s e r v a t i o n s . The vendors of the f o u r t h - g e n e r a t i o n languages may change the c h a r a c t e r i s t i c s of t h e i r products enough to alter the observations. Users may change t h e i r manner of use enough to alter the observations .... His f i n a l c o n c l u s i o n is t h a t w h i l e f o u r t h generation languages w i l l make program development faster and less expensive, they may make maintenance much more expensive. To those of us in dcx::urnentation these remarks present a challenge. Documentation, in one of its many uses, is a prime assistance in maintenance. Is there a way of getting programmers inside a f o u r t h generation language f a s t e r , t h e r e b y c u t t i n g the maintenance costs? Can we have our cake and eat it too? Such unfashionable documents as design specifications can provide a n a r r a t i v e t h a t doesn't a l l o w a programmer to f o r g e t some of the "implicit, and ...tacit assumptions' may help to m i t i g a t e e r r o r s in p r o g r a m m i n g amendments. Programming code w i t h good comments (perhaps edited by a s p e c i a l i s t ) , can warn the m a i n t a i n e r of t r a p s laid by interrupting certain flows of c o n t r o l between screens. A maintenance programmer's kit can describe any wizardry and magic tools used by the designers t h a t w i l l be u t t e r l y destroyed by the entrance of trolls upon the scene. CHAIRMANS CORNER Documentation has programmers. They about i t . Taking think how h o r r i b l e outl a l w a y s been seen as a nuisance by hate to do it; they even hate to t h i n k out the garbage is also a nuisance, but l i f e would be i f no one ever took it There are certain f a c t i o n s w i t h i n the f o u r t h generation p r o g r a m m i n g crowd who believe that the existence of these languages eliminates design documents. One simply dummies up screens, shows them to the user, and gets his budget a l l o c a t i o n to the p r o g r a m m i n g p r o j e c t without having to w r i t e anything much resembling a human tongue. This is a misuse of any programming language. The problem w i t h fourth generation program maintenance is less the language than the programmers who will not admit that documentation is s t i l l necessary. D(x:umentation is a way of sharing information w i t h people, and there are s t i l l some programmers who believe that they only have to share their lives w i t h machines. It's sad to admit, but the vice president of finance is going to get them converted in the end. 1 see Alan L. T h a r p , ' T h e Impact of Fourth Generation Programming Languages' in SIGCSE Bulletin xvi, 2 (June, 1984), p. 37, which contains a b i b l i o g r a p h y i n c l u d i n g a bibliography. 2 Ned Chapin 'Software Maintance w i t h Fourth-Generation Languages' in ACM Software Engineering Notes ix, 1 (lan 1984), p. 41. EDITORIAL GUIDELINES The editor strongly urges all contributors to submit copy that can be pasted into the newsletter pages directly. The standard format for this publication is either: 8.5 by ii pages with two column format (I0 pitch font preferred) and with an adequate gutter between columns (4 spaces minimum), OR copy to paste up on ACM publication layout sheets with text that is 42 characters wide using a i0 pitch font. Paper should be opaque and the characters dark and readable (no dot matrix printers please). For those who choose the 42 character column method, remember that these pages will be I~_4~.G9~ for printing.

/lp/association-for-computing-machinery/chairman-s-corner-NW8GPSQUDJ