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=2.6 required=5.0 tests=BAYES_40,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!princeton!siemens!gypsy!balcer From: balcer@gypsy.siemens-rtl (Marc J Balcer) Newsgroups: comp.lang.ada Subject: Ada, "Software Fantasyland," and Quick Courses Summary: No "royal road to Ada." Ada isn't "just another language." Message-ID: <6660@siemens.UUCP> Date: 15 Feb 89 18:54:35 GMT Sender: news@siemens.UUCP Reply-To: balcer@gypsy.siemens.com (Marc J Balcer) Organization: Siemens RTL, Princeton NJ References: List-Id: Two articles today caught my interest, giving me an opportunity to let loose some frustrations. In the Spring '88 and Fall '88 semesters, I taught an "Ada Programming Language" course at a small college. This was a rather popular course; as one student put it, "I can put Ada on my resume. Now I can get a job with ." The official prerequisites for the course included only one semester of Pascal programming. I told the students that they really needed CS2 (Advanced Pascal) and Data Structures as well; I did not intend to spend 3 lectures explaining what arrays, records, and pointers were. Nor did I want students who thought a "big program" was anything over 50 lines long. When I first taught the course, a local DoD contractor sent about 15 of its people to "take the course and learn Ada." I had been assured that all of these people were "experienced programmers and software managers." However I soon learned that the depth of experience for most of them was assembly languages and CMS-2 on a single project. Most had learned programming while in the service, or had been "promoted" from computer operations. Not only were many unfamilar with high-level languages, I had to justify structured programming! Strong typing was something to be defeated. (Was I naive for making assumptions about their background?) (And the Army still recruits people by promising to teach them "computer programming.") Not only that, but the "Ada myths" were rampant. Example: "We can't use Ada because you can't AND and OR bit fields (integers)." I asked, "What kind of problem are you trying to solve?" (The problem they had could be solved easily with a record type and a rep clause.) However, they had spent their entire careers focused on the machine-level rather than the problem-level. But the worst part is that few, if any, of the software managers had any background in "modern software engineering principles" (other than contempt for the people who practiced them). Ed Berard is right: nearly all of them felt forced to use Ada. For them, the programming assignments were sheer torture (many hadn't coded anything in years). There was little appreciation for style and structure---all that mattered was that the program worked on the test data. These people seemed to be learning Ada in a vacuum. Most had never heard of ACM, none were aware of SIGADA, SEI, STARS, APSE, and such. They were unaware of any "Ada mentors" in their company. Upper management seemed to believe that they could simply buy a compiler, throw copies of the LRM at the engineers, and expect them to be coding Ada the next week. After all, it's "just another language, right?" ADA IS NOT "JUST ANOTHER LANGUAGE." Many of the features of Ada make no sense to a programmer who is unaware of, and not motivated toward the concepts of structured programming, modularity, information hiding, object-oriented design, .... I could go on and on. There seems to be no end to the desire for "quick Ada" courses. (Maybe I should have left it misspelled -- "quack Ada.") However, there's a BIG difference between exposure to the language and competence in it. Although I had learned structured programming (in Pascal) from the beginning, and had practiced (and taught) "good software engineering principles" for 7 years, it took two more years of working full-time on an Ada project to develop a minimal competence in the language---to learn "how to do it the Ada way." Stricter qualifications are needed, but I object to the establishment of a specific "competency exam" for software engineers. (No one suggested it, but...) The field is still too dynamic. Too much is changing. To establish a fixed criteria would lock in certain practices and make them very difficult to change. At the worst, any examination would be little more than a trivia quiz. I'll conclude with a few questions: 1. How much re-educating of DoD software enginners is necessary BEFORE teaching Ada? In other words, should we be teaching software engineering fundamentals first? What's the most effective way to do this? 2. How long does it take to properly re-educate a generic software engineer into an Ada developer? Can the cost be recovered? 3. Where does Ada fit into the college curriculum? How can we educate students in good software engineering, not just give them "Ada" on their resumes? 4. What qualifications (read "experience working on Ada projects") should be required for those teaching Ada? 5. Can some of these efforts lead to an expansion of the Ada base beyond DoD and DoD contractors into other industries? --------------------------------------------------------------------------- Marc J. Balcer [balcer@gypsy.siemens.com] Siemens Research Center, 755 College Road East, Princeton, NJ 08540 (609) 734-6531 ---------------------------------------------------------------------------