mfeldman@seas.gwu.edu (Michael Feldman) (03/25/91)
DRAFT ADA 9X TRANSITION PLAN FEBRUARY 1991 Prepared by Christine Anderson Ada 9X Project Office PREFACE The purpose of this document is to specify a plan for transition- ing from Ada 83 (ANSI/MIL-STD-1815A) to Ada 9X (ANSI/MIL-STD- 1815B). This document is being released in draft form for the purpose of public review. Please send your comments to me by 1 May via one of the following means. Postal Mail: Chris Anderson WL/MNAG Eglin AFB FL 32542-5434 e-mail: anderson@uv4.eglin.af.mil FAX: 904-882-2095 Attn: Chris Anderson WL/MNAG Thank you for your help. CHRISTINE M. ANDERSON Ada 9X Project Office DRAFT ADA 9X TRANSITION PLAN February 1991 1. INTRODUCTION The purpose of this document is to specify a plan for transition- ing from Ada 83 (ANSI/MIL-STD-1815A) to Ada 9X (ANSI/MIL-STD- 1815B). It is intended that these specifications will not replace existing policy but rather supplement it. While recommendations in this document are intended for use by Department of Defense policy makers, they may also be useful to other organizations that must develop policies for transitioning to Ada 9X. The objective of the transition strategy is to expedite the realiza- tion of Ada 9X benefits while minimizing disruption to the Ada infrastructure (e.g., programmers, programs, tools, vendors, training, educators, etc.). 1.1 BACKGROUND The goal of the Department of Defense (DOD) sponsored Ada 9X Project is to revise Ada 83 (ANSI/MIL-STD-1815A) to reflect current essential requirements with minimum negative impact and maximum positive impact to the Ada community. From the very beginning of the Project in October 1988, the focus has been on meeting user needs and the focus of the transition strategy is no exception. All users (managers, programmers, vendors, educators, and authors) must be carefully considered when developing the transition strategy. Each has specific needs sometimes at odds with the others. While it may be desirable from the managers' and programmers' perspective to have the revised language features available immediately, such expectations can not be met. Vendors need sufficient time to upgrade their products to the revised standard, while simultaneously supporting the needs of on-going Ada 83 projects. Educators and authors also need time to assim- ilate changes into curricula and text books. Thus, just as the change to the language itself must achieve a delicate balance between change and stability, so the transition strategy must carefully balance hurrying Ada 9X to the market and slowing the transition pace enough to minimize disruption to the existing infrastructure and to facilitate a gradual evolution to the revised standard. The Ada 9X transition strategy is organized according to repre- sentative segments of the Ada community: managers, programmers, vendors, educators/authors. 2. MANAGERS When it comes time to transition to Ada 9X, managers will obvi- ously be concerned with when to require the use of Ada 9X on new and existing projects. 2.1 NEW PROJECTS The use of Ada 9X (ANSI/MIL-STD-1815B) shall be specified for all projects starting immediately after Ada 9X is an approved ANSI/MIL Standard. If the program manager determines there are no satisfactory Ada 9X compilers available, then Ada 83 (ANSI/MIL-STD-1815A) shall be used. Waivers/exceptions for not using Ada (Ada 9X or Ada 83) apply as before as directed by the governing agency. 2.2 EXISTING PROJECTS For existing Ada 83 (ANSI/MIL-STD-1815A) or non-Ada projects, transitioning to Ada 9X (ANSI/MIL-1815B) shall occur if one or more of the following conditions is met. Note, "transitioning" herein means added/modified software must be in Ada; it does not mean existing software must be redesigned in Ada. (a) The Program Manager/Principal Investigator determines that Ada 9X brings necessary/desirable functionality to the project. (b) A major project upgrade (i.e., 33% addition/change of code) is planned and less than five years has elapsed since Ada 9X was approved by ANSI. If there are no suitable Ada 9X (ANSI/MIL-STD-1815B) compilers available for the host/target combination then Ada 83 (ANSI/MIL-STD-1815A) shall be the lan- guage of choice. Waivers/exceptions to not use Ada (Ada 9X or Ada 83) apply as directed by the governing agency. (c) A major project upgrade (i.e., 33% addition/change of code) is planned and five or more years has elapsed since Ada 9X (ANSI/MIL-STD-1815B) was approved. Waivers/exceptions to not use Ada 9X apply as directed by the governing agency. In cases where the project stays with Ada 83, validated or "project validated" Ada 83 compilers must be used for delivery of operational software (see section 4.4.1 and the Ada Joint Program Office Ada Compiler Validation Procedures document. 2.3 MANAGERS WORKSHOP In order to help managers transition to Ada 9X there will be an Ada 9X Managers Workshop just prior to ANSI/MIL approval (approx- imately March 1993). Transition issues and strategies will be discussed. 3. PROGRAMMERS 3.1 ADA 9X PROGRAMMERS GUIDE In order to help programmers transition to Ada 9X an "Ada 9X Programmers Guide" will be developed. This guide will highlight the changes between Ada 9X and Ada 83 chapter by chapter and discuss programming strategies utilizing new features. Any incompatibilities between Ada 9X and Ada 83 will also be noted and straight-forward modifications to Ada 83 code will be provid- ed for transformation to equivalent legal Ada 9X code. Suggested Ada 83 coding practices to make the transition to Ada 9X easier will also be discussed for those programmers continuing to use Ada 83 on existing projects. 3.2 FREE EDUCATIONAL ADA 9X COMPILATION SYSTEM In the interest of introducing students to the many benefits of Ada at minimal cost, an extremely user-friendly Ada 9X compila- tion system, consisting of a compiler, library system, linker, run-time system and debugger for commonly available platforms (e.g., SUN/UNIX or PC/DOS), will be developed for educational purposes. This system will be made available to accredited universities free of charge. Some level of maintenance is envi- sioned. Since this system is for educational purposes only, and there is no intent to compete with industry but rather to stimu- late the market, it may be that certain features of the language are not supported; however validation of implemented features will be required. It is intended that the developer be solicited through a Broad Area Announcement in FY 92. Ideally, proven off- the-shelf tools shall be the basis of this system. 4. VENDORS Vendors supply the necessary user support tools. Vendor products must not only meet user needs but their compilers must also pass validation tests, the Ada Compiler Validation Capability (ACVC), designed to check for conformance to the language standard. The current ACVC process, just as the language, requires minor ad- justments occasionally to better serve the Ada community. To ease the transition impact to vendors, the Ada 9X transition strategy includes vendor workshops; a revised ACVC test suite; a revised ACVC test suite release schedule; and adjustments to the ACVC policy and review process. 4.1 VENDOR WORKSHOPS During the Ada 9X revision process, several Vendor Workshops will be conducted. The purpose of these workshops will be to allow vendors to closely track the revision and to provide feedback to Ada 9X Teams regarding implementability. 4.2 ACVC TEST SUITE REVISION The Ada Joint Program Office has directed the freeze of the current Ada 83 test suite, ACVC 1.11. Under the Ada 9X Project, one more release for Ada 83 will be issued, ACVC 1.11X which will be based on ACVC 1.11 and draft ACVC 1.12 (which was never offi- cially released). ACVC 1.11X will remove Ada 83/Ada 9X incompat- ibilities, and will attempt to increase the focus on expected usage of the language. Accordingly, the ACVC 1.11X will contain approximately 135,000 LOC counting semi-colons (about 3000 tests); a reduction of about 25% from the current level of 187,650 LOC (about 4000 tests). This reduction in size and increased focus on expected usage reflects a change in testing philosophy based on seven years of experience in using the ACVC. The original testing philosophy was to expose compiler errors, whether or not an error was likely to be encountered by users or would have been considered a significant defect by programmers. The new, usage-based testing philosophy is to focus on potential non-conformities that would impair the actual use of the lan- guage. The change of testing philosophy is intended to enable vendors to expend more effort on quality improvements of interest to their customers while ensuring that Ada compilers, as used in practice, still conform to the standard. The first Ada 9X ACVC test suite will be ACVC 2.0 which will add approximately 400 tests (about 26,000 LOC representing 50% Ada 9X test objective coverage). The second ACVC test suite will be ACVC 2.1 which will add approximately 400 more test (about 26,000 LOC representing the remaining 50% Ada 9X test objective cover- age). Furthermore, continued growth of the ACVC test suite will be prohibited. Tests may be modified/added/deleted but a fixed ceiling of approximately 3800 tests (187,000 LOC) will be estab- lished. The increased focus on usage and the prohibition of continued growth is expected to provide vendors with more time to concen- trate on meeting users special requirements for optimization and high quality tools. 4.3 ACVC RELEASE SCHEDULE The following schedule describes the ACVC test availability dates (the start date when a new ACVC test suite is available for public review and comment), the ACVC official release date (the start date a vendor can validate under a new ACVC test suite), the ACVC test expiration dates (the end date a vendor can validate a compiler under that ACVC test suite), and the ACVC certificate expiration dates (the date validation certificates cease to be valid). In Use In Use Certificate ACVC Available (Start Date) (End Date) (Exp. Date) 1.11 15 Jul 89 1 Dec 89 1 Jun 92 1 Mar 93 *1.11X 1 Mar 92 1 Mar 92 1 Sep 93 1 Sep 94 2.0 1 Mar 93 1 Sep 93 1 Mar 95 1 Mar 96 2.1 1 Sep 94 1 Mar 95 * ACVC 1.11X will be released for validation with no further public review since it is based on ACVC 1.11 and draft ACVC 1.12. 4.4 ACVC POLICY Validation of Ada 9X compilers will be required as for Ada 83 compilers. However, in the spirit of a gradual transition, cer- tain concessions are being made that allow, for a limited time, validation of Ada 9X compilers that do not implement all Ada 9X features yet. The general policy of not permitting supersets beyond Ada 9X will remain in effect. (For more information see the Ada Compiler Validation Procedures document available from the Ada Joint Program Office.) 4.4.1 ACVC 1.11X Vendors will be able to start validating Ada 9X features under ACVC 1.11X, as soon as Ada 9X is approved by ANSI, listing Ada 9X features (above Ada 83 features) included in the compiler in Appendix F. Only Ada 9X features may be added; non-conforming functionality is prohibited and will result in non-validated status. Although the end-use date for ACVC 1.11X is 1 Sep 93, vendors whose customers wish to continue to use Ada 83 and to continue to check the conformity of their compilers may do so by seeking "project validation." Ada Validation Facilities will continue to offer project validation under ACVC 1.11X after ACVC 2.0 is issued and will produce Validation Summary Reports; howev- er validation certificates will not be issued. For the Project Office that does not want to upgrade to Ada 9X, this approach offers an acceptable option to ensure conformance to Ada 83. 4.4.2 ACVC 2.0 Vendors validating under ACVC 2.0 will be allowed to support less than full Ada 9X functionality (i.e., approximately 50% Ada 9X test objective coverage will be included in ACVC 2.0); however they must list Ada 9X features supported in the compiler in Appendix F. As a minimum, the compiler must support features included in ACVC 2.0. 4.5 ACVC REVIEW PROCESS The current ACVC review process already includes a six month review period but intense efforts to solicit vendor review are lacking. The review process will include workshops at the start of a review period to solicit vendor response on a more personal basis with ACVC test suite developers explaining test objectives, tests, and rationale. Furthermore, a new expert reviewers group will be established. This group, the ACVC Reviewers, will consist of approximately eight world-class Ada experts composed of vendors, application users, and language interpreters. This group will have a chair and will participate with the Ada Validation Office (AVO), the Ada Maintenance Organization (AMO) and the Ada Validation Facility (AVF) Managers in the ACVC process. Furthermore, the ACVC Reviewers will review ACVC test objectives and tests prior to each public review period. ___________ __________ __________ l Ada BOARD l --- l AJPO l ---l ISO WG9 l l __________l l__________l l_________ l l _______l________ l l l l l l ______ ______ ___________ l AVO l l AMO l l ACVC l l_____l l_____l l REVIEWERSl l l l _________l l l ______ _______ l AVFs l l ACVC l l_____ l l TEAM l l______l 5. EDUCATORS/AUTHORS During the Ada 9X revision process, a workshop will be conducted for educators and authors to present changes to the language as they may impact current Ada curricula and text books. Suggested teaching aids such as illustrative programming examples will be offered. 6. DISTRIBUTION The language reference manual and rationale document for Ada 9X will be made available to the general public at low cost as for Ada 83. They will be available in electronic and hard copy form. Permission will be freely granted to copy either document in its entirety without alteration or as altered by (1) adding text that is clearly marked as an insertion; (2) shading or highlighting existing text; or (3) deleting examples. 7. MAINTENANCE 7.1 ON-GOING MAINTENENCE A body of language experts ( the Ada Rapporteur Group [ARG] and the Uniformity Rapporteur Group [URG] working as part of ISO- IEC/JTC1/SC22/WG9) has been the authority on interpreting the Ada 83 standard in cases of ambiguities and resolving contradictions in the standard. It is envisioned that this process will contin- ue, with essentially an unaltered charter, to perform these maintenance activities for the Ada 9X standard. It is also envi- sioned that a very close connection will exist between ISO WG9 and the Ada validation process. Specifically the Ada Maintenance Organization (AMO), the ACVC Team and the ACVC Reviewers shall ensure that ISO WG9 language interpretations are reflected in ACVC tests (either by adding or removing tests). Furthermore, the Ada Validation Office (AVO) shall ensure that test disputes are passed to ISO WG9 in a timely and appropriate manner so that they may be considered in the interpretation process. 7.2 NEXT REVISION/REAFFIRMATION The AJPO as the ANSI agent for Ada 9X will monitor the status of Ada usage and determine at the five year anniversary of the standard if reaffirmation/revision is in order, and initiate appropriate action as necessary. 8. ASSOCIATED/SECONDARY STANDARDS The existence of Ada 9X associated/secondary standards will play a vital role in the successful transition to Ada 9X. It is envisioned that ISO WG-9 will hasten the development of these standards to the maximum extent possible.
jls@rutabaga.Rational.COM (Jim Showalter) (03/26/91)
> 3.2 FREE EDUCATIONAL ADA 9X COMPILATION SYSTEM > > Since this system is for educational purposes only, and > there is no intent to compete with industry but rather to stimu- > late the market, it may be that certain features of the language > are not supported; Bad idea, bad precedent. One of the great selling points of Ada over any other language is that it IS a standard. Introducing dialects, ESPECIALLY in an educational system, is regressive. Either teach Ada or don't teach Ada, but by all means don't teach "sort-of" Ada. > The original testing philosophy was to expose compiler errors, Seems like a good idea. Why depart from this philosophy now? If it aint broken, don't fix it. > whether or not an error was likely to be encountered by users or > would have been considered a significant defect by programmers. > The new, usage-based testing philosophy is to focus on potential > non-conformities that would impair the actual use of the lan- > guage. How does one guess ahead of time which particular compiler bugs will be "significant" in the eyes of a programmer? Personally, I view ALL bugs as an evil thing that must be stamped out. I would not like having to choose which bugs I wanted to live with and which bugs I wanted fixed. I want them ALL fixed. That's the whole POINT of validation. > Furthermore, continued growth of the ACVC test suite will be > prohibited. WHY? Why set an artificial ceiling on the number of tests? The number of tests should be exactly equal to the number required to ensure validation, no more, no less. This seems elementary--who is pushing to limit the number of tests? > Tests may be modified/added/deleted but a fixed > ceiling of approximately 3800 tests (187,000 LOC) will be estab- > lished. While this might be a great idea for laws, it stinks for testing compilers. If you are limited to 3800 tests and there are 3801 things that can be wrong with a compiler, you are guaranteeing that one bug will be visited upon all Ada users. > The increased focus on usage and the prohibition of continued > growth is expected to provide vendors with more time to concen- > trate on meeting users special requirements for optimization and > high quality tools. I would rephrase this to read "The prohibition of continued growth [of the tests] is expected to provide vendors with a shortcut to achieving validation at the expense of the Ada user community". -- ***** 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."
mfeldman@seas.gwu.edu (Michael Feldman) (03/26/91)
In article <jls.669955177@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >> 3.2 FREE EDUCATIONAL ADA 9X COMPILATION SYSTEM >> >> Since this system is for educational purposes only, and >> there is no intent to compete with industry but rather to stimu- >> late the market, it may be that certain features of the language >> are not supported; > >Bad idea, bad precedent. One of the great selling points of Ada over >any other language is that it IS a standard. Introducing dialects, >ESPECIALLY in an educational system, is regressive. Either teach Ada >or don't teach Ada, but by all means don't teach "sort-of" Ada. > I couldn't agree more with your basic idea. However, industry folks should realize that in the university world we don't teach languages, we teach concepts and the languages are just means to the end (this is especially true at the undergraduate level). Just because we teach Ada using spiraled subsets of the language doesn't mean we only teach "sort-of" Ada. I keep meeting industry guys who are so far removed from what we do that they sincerely believe we can start with a first semester freshman and teach all of Ada in one semester. They oughta go back and imagine themselves before they ever write a program. I am definitely opposed to a dialect being supported in this educational system. On the other hand, while everyone sat around and waited, we at GW and elsewhere taught _hundreds_ of students Ada, from 1983 on, using TeleSoft's interim system, which (you may recall) did not support generics or task types (though it supported named tasks decently well), and surely didn't support chapter 13. An educational Ada system "for the masses" (that is, the first two years of undergraduate education) need not support chapter 13, in my opinion (indeed many validation suites went by before chapter 13 was even required!). As far as Ada83 is concerned, this is the only omission I would tolerate. Leaving out tasking or generics is stupid and unnecessary, though. An Ada system in the nature of a modernized Ada/Ed (batch translator/ interpreter) or Arcturus (Basic- or APL-like on-the-fly interpreter) would be a real boon, especially if its performance were acceptable and if it were _really_ free, not requiring the insufferable hassle of dealing with the glacial speed and stodginess of NTIS distribution. The biggest problem I have with most Ada83 systems is that they were designed for industry, not for education. As such, the payoff from them comes with large(r) projects, not the little ones freshmen do. The nice thing about Arcturus is that performance, within its capacity limits, is directly proportional to program size. Perceived performance of commercial compilers is, for student-sized projects, nearly O(1), with a much-too-high constant. Politically incorrect though it may be for me to say this, I also am indifferent as to whether this system will be validated (as opposed to passing most of the ACVC tests). My recurring nightmare is that the government will end up funding another ALS or AIE which, by the time the cautious bureaucrats allow its release, will have long since been overtaken by events. RAPID PROTOTYPING is what this oughta be about. AJPO: get something out there _quickly_ and don't be afraid to let us have premature stuff to play with. We're smart guys and we can work around the deficiencies. And for Heaven's sake, let us in the universities have the source code, RIGHT FROM THE START, so we can "add value." Thanks for starting a debate on this, Jim. This is gonna be fun. Mike Feldman
vestal@SRC.Honeywell.COM (Steve Vestal) (03/27/91)
In article <2926@sparko.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: > AJPO: get something out there _quickly_ and don't be afraid to let us have > premature stuff to play with. We're smart guys and we can work around the > deficiencies. And for Heaven's sake, let us in the universities > have the source code, RIGHT FROM THE START, so we can "add value." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I second this recommendation; if the RFP were done carefully, this might at least approximate the mythical, long-sought-after "gnu Ada." The draft transition plan says this compilation system will be developed for educational use by accredited universities. I am curious to know exactly what restrictions the government is contemplating. Does educational use include research use, or use by other accredited educational institutions? It would be nice if this were available for both educational and research use by a broad range of individuals and organizations. Steve Vestal Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 Phone: (612) 782-7049 Internet: vestal@src.honeywell.com
mfeldman@seas.gwu.edu (Michael Feldman) (03/27/91)
In article <1991Mar26.173818.4429@src.honeywell.com> vestal@SRC.Honeywell.COM (Steve Vestal) writes: > >I second this recommendation; if the RFP were done carefully, this might at >least approximate the mythical, long-sought-after "gnu Ada." Yeah. I wonder if an RFP is the right way to go. Should the government fund this thing, or just facilitate? Is there a middle ground? > >The draft transition plan says this compilation system will be developed for >educational use by accredited universities. I am curious to know exactly what >restrictions the government is contemplating. Does educational use include >research use, or use by other accredited educational institutions? It would >be nice if this were available for both educational and research use by a >broad range of individuals and organizations. Interesting question. I'm reading tea leaves here, but I wonder if they meant to exclude, for example, private companies using it for in-house training or research. "Educational purposes" generally includes academic- type research, which is inextricably tied to upper-level teaching anyway, especially in the computing field. Threse restrictions are indicative of the government's floundering around so as not to violate a "don't compete with the private sector" ideology. Does anyone remember that the government - DARPA, if I recall - funded the development of Berkeley Unix? At the time, universities could get copies - including source code - virtually free (distribution fee of about $300.). Industry didn't get into Berkeley Unix until one of its developers, Bill Joy, finished his doctorate and founded Sun Microsystems. And we all know the rest of that story. If I'm not mistaken, DARPA _still_ funds Berkeley Unix development, even though Unix is now a roaring commercial success. The government funding _created_ the industry. In the case of Ada, provision - by whatever means - of an EDUCATION-ORIENTED Ada system would increase the size of the pie by producing thousands of Ada-literate college graduates. Hey - Rational, Alsys, TeleSoft, Verdix, Tartan, Meridian! If you guys would develop an EDUCATION-ORIENTED Ada system, you could sell it to us. But none of you are interested. The nearest approximation is OpenAda, but it's education-oriented only in that its price is low enough. (Well, OK, the HyperText LRM helps too). If you don't wanna build stuff we can REALLY use, at least get out of the way so that Uncle Sam can. Quit kvetching about him competing with you. You don't want to develop it, or you would've done it years ago. Yo AJPO! Don't be so cautious. Go talk to the folks down the street at DARPA and ask them how it worked with Unix. See if I'm right. Mike Feldman
jncs@uno.edu (03/27/91)
In article <2926@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes: >In article <jls.669955177@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>> 3.2 FREE EDUCATIONAL ADA 9X COMPILATION SYSTEM >>> >>> Since this system is for educational purposes only, and >>> there is no intent to compete with industry but rather to stimu- >>> late the market, it may be that certain features of the language >>> are not supported; >> >>Bad idea, bad precedent. One of the great selling points of Ada over >>any other language is that it IS a standard. Introducing dialects, >>ESPECIALLY in an educational system, is regressive. Either teach Ada >>or don't teach Ada, but by all means don't teach "sort-of" Ada. >> >I couldn't agree more with your basic idea. However, industry folks should >realize that in the university world we don't teach languages, we teach >concepts and the languages are just means to the end (this is especially I could not agree more with MF. In university environments a language is just that, a tool. We do not tailor curricula around specific languages. We do it around concepts, and methodologies which we see have strong transfer value to specific tasks undergraduates will end up doing in the "real world". Pascal was a great expirience from which we learned much (both educators and practitioners). If we are denied a subset of a language, we are denied the oportunity we could have to experiment with new concepts and methodologies, which we eventually we must face when the whole language is completely hammered out, released and compilers become available. Let's recall that we can find a subset of Ada similar to Pascal. Besides the language, and the comercially strong compilers, we NEED to develop the appropriate methodology and teaching tools for it; thus the sooner you give me a flavor of the language, the sooner I get to think of appropriate methodologies both for programming in it in particular and for developing systems in general. >I am definitely opposed to a dialect being supported in this educational >system. On the other hand, while everyone sat around and waited, we >at GW and elsewhere taught _hundreds_ of students Ada, from 1983 on, >using TeleSoft's interim system, which (you may recall) did not support >generics or task types (though it supported named tasks decently well), >and surely didn't support chapter 13. I rather do without chapter 13, than with a language that allows me to teach development of systems via the modelling and implementation of ADT's. Coming back to Pascal, this department at Univ of New Orleans taught Pascal in spring of 74 using a poorly implemented interpreter imported from Europe. I'm sure it must have felt great, in spite of the quality of the interpreter, as since then and until 1984, Pascal was taught to cs students. I must add that at that date we adopted Ada and used the Telesoft version mentioned above. >AJPO: get something out there _quickly_ and don't be afraid to let us have >premature stuff to play with. We're smart guys and we can work around the >deficiencies. And for Heaven's sake, let us in the universities have >the source code, RIGHT FROM THE START, so we can "add value." ditto. With respect to the industry perception of what we do in the classrooms, it has always been a source of much grief. They want me to teach my students COBOL and as much as I and the students can endure. CS students in my school are not required to take COBOL; also, we only teach on course of COBOL. In several occassions, students have told me that they were passed by recruiters for other students from others schools in town because they had 2 or more courses in COBOL!!! May I say more? Jaime Nino
jls@rutabaga.Rational.COM (Jim Showalter) (03/27/91)
>I couldn't agree more with your basic idea. However, industry folks should >realize that in the university world we don't teach languages, we teach >concepts and the languages are just means to the end (this is especially >true at the undergraduate level). Just because we teach Ada using spiraled >subsets of the language doesn't mean we only teach "sort-of" Ada. I think we're in violent agreement here, actually. When I teach Ada, I also teach using a spiral approach (what other method IS there?). I just don't want to see subset Ada blessed by the validation office. If you want to teach a subset, fine: but do it with a real Ada compiler. >I keep >meeting industry guys who are so far removed from what we do that they >sincerely believe we can start with a first semester freshman and teach >all of Ada in one semester. They oughta go back and imagine themselves >before they ever write a program. I am currently teaching a bright but scarcely computer-literate individual Ada as his first programming language. We are currently a month into the experiment, and he is quite capable with control structures, subprograms, types, subtypes, private types, selectors/constructors/iterators, and generics. I'll admit that sometimes I get asked interesting questions (like, try explaining sometime why a formal is CALLED a formal...), but all in all I think the experiment has been a resounding success--and we've got two months left. >The biggest problem I have with most Ada83 systems is that they were >designed for industry, not for education. As such, the payoff from them >comes with large(r) projects, not the little ones freshmen do. Agreed, but only partially. I think any software engineering student benefits from the orthogonal (well, MOSTLY orthogonal) syntax/semantics of the language, the type model, spec/body separation, and private types: with these you can attack 90% of the language-caused problems that beset projects of any size. >The >nice thing about Arcturus is that performance, within its capacity limits, >is directly proportional to program size. Perceived performance of >commercial compilers is, for student-sized projects, nearly O(1), >with a much-too-high constant. We have an effective batch compilation rate of 150KSLOC/minute. Is that fast enough? :-) [gotta LOVE incremental compilation] >My recurring nightmare is that the >government will end up funding another ALS or AIE which, by the time the >cautious bureaucrats allow its release, will have long since been overtaken >by events. RAPID PROTOTYPING is what this oughta be about. Violent agreement here! ALS = infinite resource sink -- ***** 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."
jls@rutabaga.Rational.COM (Jim Showalter) (03/28/91)
mfeldman@seas.gwu.edu (Michael Feldman) writes:
%Hey - Rational, Alsys, TeleSoft, Verdix, Tartan, Meridian! If you guys would
%develop an EDUCATION-ORIENTED Ada system, you could sell it to us. But
%none of you are interested.
Not so fast--we're working on it.
--
***** DISCLAIMER: The opinions expressed herein are my own, except in
the realm of software engineering, in which case I've borrowed
them from incredibly smart people.
dd@sei.cmu.edu (Dennis Doubleday) (03/28/91)
jls@rutabaga.Rational.COM (Jim Showalter) writes: >mfeldman@seas.gwu.edu (Michael Feldman) writes: >%Hey - Rational, Alsys, TeleSoft, Verdix, Tartan, Meridian! If you guys would >%develop an EDUCATION-ORIENTED Ada system, you could sell it to us. But >%none of you are interested. > >Not so fast--we're working on it. Is it going to include a 95% educational discount on the R1000? :-) -- Dennis Doubleday (dd@sei.cmu.edu) _ /| Software Engineering Institute \'o.O' Carnegie Mellon University ACK! PTHFT! =(___)= Pittsburgh, PA 15213 (412)268-5873 U
jls@rutabaga.Rational.COM (Jim Showalter) (03/29/91)
>Is it going to include a 95% educational discount on the R1000? :-)
We have already reduced the cost an order of magnitude (base 10) over
the last couple of years, and we're planning to do it again. It is
unfortunate that so many people still have the idea that an R1000 is
unaffordable, because in many cases it is now appropriate even for
smaller projects and educational institutions. Check us out.
--
***** DISCLAIMER: The opinions expressed herein are my own, except in
the realm of software engineering, in which case I've borrowed
them from incredibly smart people.
mfeldman@seas.gwu.edu (Michael Feldman) (03/29/91)
In article <23311@as0c.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes: -jls@rutabaga.Rational.COM (Jim Showalter) writes: --mfeldman@seas.gwu.edu (Michael Feldman) writes: --%Hey - Rational, Alsys, TeleSoft, Verdix, Tartan, Meridian! If you guys would --%develop an EDUCATION-ORIENTED Ada system, you could sell it to us. But --%none of you are interested. -- --Not so fast--we're working on it. - -Is it going to include a 95% educational discount on the R1000? :-) - Dream on. Mike Feldman
jls@rutabaga.Rational.COM (Jim Showalter) (03/30/91)
>-Is it going to include a 95% educational discount on the R1000? :-) >- >Dream on. Sigh. Check my post in response to this. We've reduced the price by an order of magnitude (base 10) in the last few years, and we're working to do it again. Stop dreaming and check out the facts. -- ***** DISCLAIMER: The opinions expressed herein are my own, except in the realm of software engineering, in which case I've borrowed them from incredibly smart people.
rreid@ecst.csuchico.edu (Ralph Reid III) (03/31/91)
(many comments about ADA subsets deleted) As a student who needs a senior project, I am currently writing my own ADA class. Considering my experiences learning other languages, I would prefer to work with a fully usable compiler whenever possible. The compilers I will be writing programs on (once the project is approved) will be fully functional compilers; not subset compilers. I may not use every language feature during a class, but when the class is finished, the compilers will still be there for me to play/work with on my own. Of course, if major chages are about to take place in the ADA language, I believe something should be distributed as quickly as possible, with the condition that once a final working compiler has been developed, it will be distributed to replace the partial ones. Different compilers operate differently, and if an instructor is worried about students getting bogged down with the compiler operation, perhaps using tools already available on the computer can be used to simplify matters. If some parts of a language are too complicated for the students' ability, then perhaps libraries can be built which mask some of the more complex language features during the earlier portions of the class (this technique seems especially feasible with ADA). I have decided to use more than one compiler for my project because I have discovered that getting used to working in a different programming environment is often more difficult than learning a new language. compiler for this project is that I have found -- Ralph. SAAC member. ARS: N6BNO Compuserve: 72250.3521@compuserve.com email: rreid@cscihp.ecst.csuchico.edu