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