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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hao!ico!rcd From: rcd@ico.UUCP (Dick Dunn) Newsgroups: comp.lang.ada Subject: Re: Ada Education and Training - Part 3 Message-ID: <1061@ico.UUCP> Date: Wed, 13-May-87 03:45:04 EDT Article-I.D.: ico.1061 Posted: Wed May 13 03:45:04 1987 Date-Received: Sat, 16-May-87 01:23:51 EDT References: <8705032025.AA28248@ucbvax.Berkeley.EDU> Summary: K&R was used as strawman; methodology confusion List-Id: In one part of a rather lengthy article, Edward Berard takes on Kernighan & Ritchie's _The_C_Programming_Language_. He was talking about an introductory text, so I'm not sure why he's picking on K&R, but he compares their book with Booch: > Kernighan and Ritchie (K&R) and Booch represent two very different > views on teaching programming. K&R stresses the age old thinking which > says that students of software must see, write, and execute code > before anything else will be meaningful. This is nothing more than an unthinking cheap attack on K&R. It would seem that Mr. Berard believes that K&R intends to teach programming simply because he thinks it ought to do so. However, if one manages to read as far as the fourth paragraph of the Preface, one finds: "This book is not an introductory programming manual; it assumes some familiarity with basic programming concepts..." Perhaps this was overlooked--after all, the Preface of a book may not be good reading (unless you want to know the purpose of the book:-), so let's have a look at the beginning of the "real" text. If we read as far as page 1 of "Chapter 0" we find the following terms used without prior definition: programming language, operating system, text-processing, data-base, characters, character strings, addresses, storage allocation, heap, garbage collection, file-access methods, single-thread control flow, coroutines I cannot, in my wildest dreams, imagine a normal neophyte being able to read this section...hell; he won't even be able to parse some of the sentences. It is not the case that K&R present the "programming first, thinking later" approach. They have set out to provide a ready introduction and reference for a particular programming language, and have succeeded in doing so. K&R have been set up. "We want an introductory text. We will label them an introductory text. Then we will demonstrate that they have failed." [Hey, look, the shop manual for my car doesn't provide spiritual guidance either.] A somewhat worse confusion over teaching "programming" (I would rather a less loaded term implying "the complete process of constructing functioning software") immediately follows in Berard's article: >...Booch, on the other hand, > stresses that students should know what they are doing before they > attempt to write code... The reality of teaching lies in between the code-first approach (mis- attributed to K&R, but it does exist elsewhere) and an approach which holds off the code until the concepts are ingrained...because the fact of the matter is that very few students can hang on to a substantial abstract framework without something concrete to which they can relate it. This is easy to observe in engineering and physical science undergraduate curricula. In the first year the students will be taking (let us say) calculus and some substantial classical physics which requires calculus. If the calculus courses follow a purely mathematical development of functions, series, limits, etc. without adequate illustration of the application of the concepts, the math instructors find that their students are learning calculus better--and faster--in their physics courses. (There are, of course, areas where it's hard to find the concrete materi- al--for example, some concepts in topology--but the production of software is not such an area.) I'm not going to argue that the coding should come first. That's not what I'm saying and it's not even in the back of my mind. It would be silly to teach that way...but it's equally silly to think that you can (let alone should) teach the concepts first and the programming later. That's as absurd (and antiquated) as the "waterfall model" of software lifecycle. Consider it an overreaction to the "code first" approach. It's all too simple: Teach the two together. Start developing the idea of a programming language and a programming environment as you develop the first concepts. By the time you've got enough concepts to think about interesting problems, you've also got enough concrete information to show what an actual solution to a simple problem might look like. And, I know it's heresy in this group where so many people think that there is One True Language, but you can use a couple of different programming languages to illustrate examples--if you're careful, that can prevent students getting hung up on one language. (This is somewhat how I was first taught. Perhaps the two languages were not the best choices--FORTRAN and BASIC--but hey, that was twenty-odd years ago, and it worked then.) Another way to look at what I'm saying: overemphasizing the coding is bad; ignoring it is just as bad. A little more from Berard's article: > Programming code is the "cocaine" of the software world. To many > programmers and managers it is all that matters... Replace "cocaine" with "currency". To many clients in the commercial world, the code is [almost!] all that matters, because they aren't interested in plans and studies except insofar as they help produce the end result, and they don't believe that they can sell specs-by-the-pound. The methodology is not the end product. >...While software is > being designed, managers wait nervously and the programmers/coders > wait impatiently... So get some good managers! Sheeeesh! As for the programmers/coders: If you divide your world into "those who design" and "those who implement the design" you have created a caste system. You have a social problem and you cannot solve it by waving methodology about. >...To an outsider this infatuation with code seems strange. One hears > from many sources that coding usually takes up only 10 to 15 percent > of the software life-cycle... This is a favorite litany of the methodology mavens...but if you think about it, it's only reasonable. Why is coding only 10-15%? Well, one set of reasons is that the code produced is so often late, inefficient, not robust, inscrutable, unadaptable, and nonportable. We spend the bulk of our time screwing around with code that's already written because it was lousy code in the first place...somehow I don't buy the idea that the solution is to improve our ability to screw around with the code! Couldn't we try just a little to reduce the need to screw around with it? If we had done a good job with the 10-15% of the work, a lot of the 85-90% remaining wouldn't have been necessary. A couple more comments from Berard: > 4) Software people have little faith in those concepts that come > before the coding phase. "How can anyone possibly describe > something which is not yet coded?", they reason... Rubbish. These aren't software people. > It seems that most people have not understood the intentions of the > U.S. Department of Defense (DoD) regarding the Ada effort. It is > better engineered software that is desired, not merely "FORTRAN > rewritten using the syntax and semantics of the Ada language." Too > much emphasis has been placed on a tool (Ada) and not on the task > (better software). I agree with this in a perverse sense: I do not understand it to be the intent of DoD to produce better engineered software instead of a new language. If that is what they desired, why did the requirements used in Ada development (the *man sequence) specify nitty details of syntax and semantics instead of focusing on requirements? Why did they spend a decade screwing around with a programming language before getting on to the environment? Berard is quite right that "too much emphasis has been placed on a tool...and not on the task..." - and the nature of the development of Ada is the best example of that misplaced emphasis. -- Dick Dunn {hao,nbires,cbosgd}!ico!rcd (NOT CSNET!) (303)449-2870 ...Nothing left to do but smile, smile, smile.