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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-07 11:48:31 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: jimmaureenrogers@worldnet.att.net (Jim Rogers) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died) Date: 7 May 2003 11:48:30 -0700 Organization: http://groups.google.com/ Message-ID: <82347202.0305071048.5266d157@posting.google.com> References: <9fa75d42.0304230424.10612b1a@posting.google.com> <254c16a.0305011035.13133e8d@posting.google.com> <9fa75d42.0305011727.5eae0222@posting.google.com> <9fa75d42.0305020516.bdba239@posting.google.com> <82347202.0305021418.4719da45@posting.google.com> <9fa75d42.0305060521.400f1d80@posting.google.com> <82347202.0305061103.2ddd98e4@posting.google.com> <9fa75d42.0305070504.6866e7a3@posting.google.com> NNTP-Posting-Host: 209.194.156.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1052333311 26467 127.0.0.1 (7 May 2003 18:48:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 7 May 2003 18:48:31 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63260 comp.object:62918 comp.lang.ada:37038 misc.misc:13997 Date: 2003-05-07T18:48:31+00:00 List-Id: softeng3456@netscape.net (soft-eng) wrote in message news:<9fa75d42.0305070504.6866e7a3@posting.google.com>... > jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0305061103.2ddd98e4@posting.google.com>... > > > C was built to satisfy the requirements of Bell Laboratories. > > Ah, I see. You have no experience with actual > research environments! > > That's not work it works. Bell Labs did not come > up with something like "now this set of research engineers > will design a language, as per this set of requirements". > Research labs can't get very many useful results that way. > > Ken Thompson in fact started working on developing a > Fortran compiler for his project's needs, but > didn't like it and instead ended up creating a > language called "B", based upon something > called "BCPL". Ken Thompson may not have had a formal requirements document, but he did have a clear understanding of his project's needs. Designing a language to satisfy a set of needs is the same as designing a language to satisfy a set of requirements. Requirements are a formal notation of needs. It is clear that Ken Thompson had determined a set of needs not met by the compiler or language his team was originally using, or considering. It was those needs that provided the motivation to develop another language. Even in a research environment you must be able to justify your use of time. You are not paid to act without reason or motivation. > > People at Bell Labs liked "B", and started using it. It > picked up direction and momentum, and with some work > from Dennis Ritchie, ended up as as "NB" (new "B") > and then "C". Even "C" didn't start off in any > kind of stable form. There were many early changes > and revisions. The set of requirements changed during the development of the language. This is standard on most software projects. > > In fact, that may have been the major underlying > strength of C -- it was designed by people who > were also using it. They *had* to make it usable. > (As opposed to Ichbiah, who *had* to make it impressive > to a committee.) In fact, the languages B and C were > so evolution driven that they did not have a chicken-and-egg > problem of compilers-and-language variety. From the > early stages, the languages had compilers written in > themselves! If you are doing something complex enough > like writing a compiler in a language you are designing, you > will of course end up making the language usable. There are several ways to arrive at a final set of project requirements. One way is to start with a short list of requirements, and then refine those requirements in response to a set of prototype development efforts. Another way is to study and analyze the requirements in a formal process. The goal of this approach is to produce a more stable set of requirements before project design and implementation begin. Both approaches are subject to feature creap. In the case of C, the set of language features was "specified" by a committee consisting of the first users of the language. In the case of Ada the set of language features was "specified" by a committee consisting of software experts from many domains, including military, industry, and academia. The processes to create C and Ada were different. Both efforts resulted in usable languages. > > So all future users of "C" found it usable, rather > than impressive. And when you have to get actual > projects done in a short time, theoretical considerations > weigh little in the end, actual usability looms large. Ada was not designed to be impressive. It was designed to meet a set of requirements. During the development of the requirements that eventually lead to the creation of Ada, existing languages were evaluated in an effort to find a language satisfying those requirements. C did not meet the requirements. This does not label C as deficient. It only states that C does not meet the requirements developed by the team that eventually generated the requirements satisfied by Ada. > > Giving people a set of requirements and saying > "now go design a perfect language" is the > opposite of how such things evolve naturally. I would state that differently. I would say that giving people a set of requirements and then charging them with developing a language satisfying those requirements is the way you work when you contract the work to an outside developer. The approach taken by Mr Thompson and Mr Ritchie is one frequently used for internal development. This is what the people at Hewlett-Packard company called "next bench" development. You look over at the engineer at the next work bench, see him or her struggling with a technical problem, and design a solution for that problem. Jim Rogers