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.1 required=5.0 tests=BAYES_40,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.object:2763 comp.lang.ada:4992 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.object,comp.lang.ada Subject: Re: ada-c++ productivity Keywords: Looking for a few lazy men Message-ID: Date: 18 Mar 91 02:12:01 GMT References: <11966@pasteur.Berkeley.EDU> <1991Mar15.224626.27077@aero.org> <1991Mar16.000624.2513@leland.Stanford.EDU> <1991Mar16.205228.4268@grebyn.com> Sender: news@Rational.COM Followup-To: comp.object List-Id: >Whether any realistic combination of events exists which could reduce >Pascal, C, or C++ programmers to this level of productivity is anybody's >guess; my own opinion is that most C programmers would require a bullet >through the brain to be brought to such a level. 1) If those Pascal, C, or C++ programmers were required to operate under DoD-Std-2167/A standards, their productivity would drop by two orders of magnitude automatically. This is not a language issue. 2) SLOC/day tends to decrease drastically as a function of complexity. Complexity depends on a number of factors, including sheer size, number of programmers, number of configurations, number of targets, number of hosts, number of languages, number of contractors, etc etc etc. I've been meaning to ask Mr. "I Live In The Real World" Holden this question for two years: how complex are the systems on which Mr. Holden works? If the answer is that he's working with three other guys in a garage writing device drivers for PC's, I'm sorry, but I'm really not very impressed--one should EXPECT high SLOC/day rates for what is, in essence a solved problem (e.g. programming in the small). It is programming in the large that is still a black art for most companies, and it is on such projects that low productivity rates are experienced. That Ada tends to be the language of choice on such projects should not be used against it when the rates are low--the REASON Ada is the language of choice is that other languages, including COBOL, FORTRAN, and C, are simply not up to the job. 3) I have personally contracted on a 4,000,000 SLOC C/C++ project that was lucky to achieve 3 lines a day, on a GOOD day. The programmers had not, as Mr. Holden claims, been shot in the head--they were just suffering the same liabilities as anybody else who is trying to build extremely large systems using a stone-knives-and-bearskins kind of technology and paradigm. 4) I am able to program in Pascal, C, C++, and Ada. Can Mr. Holden make the same claim, or does he damn Ada from, as I suspect is the case, a position of relative ignorance? He certainly SOUNDS ignorant. >The really comical thing about this is the way in which Ada gurus cite >"productivity" as the main advantage of Ada. Productivity rates range from no gain to order of magnitude gains. We have lots of success stories backed up by factual accounting data if Mr. Holden would care to read them. But I suspect he would find the truth inconvenient. -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."