comp.lang.ada
 help / color / mirror / Atom feed
From: jmartin@oahu.cs.ucla.edu (Jay Martin)
Subject: Re: "Subtract C, add Ada"
Date: 8 Jan 1995 00:04:28 -0800
Date: 1995-01-08T00:04:28-08:00	[thread overview]
Message-ID: <3eo6ac$nen@oahu.cs.ucla.edu> (raw)
In-Reply-To: 3ei0uk$9s2@gnat.cs.nyu.edu

>From: dewar@cs.nyu.edu (Robert Dewar)

>>"Where is C sucks, Ada rules"

>I'll tell you where, in inappropriate posts to comp.lang.ada, that's where!
>John's papres are excellently presented, and I think giving them more of a
>langauge wars slant would be a big mistake. Yes, if you read the papers
>you will get an important message if you are not deaf, but the critical
>issue here is not simple us vs them language comparisons.

To start I'll quote from an paper abstract that I included below:

  The selection of a convenient programming language is one of the most
  important decisions to be made prior to the implementation of any software
  project and it may greatly affect its development and maintenance costs.


I am just a crackpot, but I think it is reasonable that some people
somewhere on this planet should be studying the efficiency of
software construction, programming language design and the
interaction between the two.  Unfortunately, I don't see anybody
doing it.  Industry doesn't have the time (I can just see efficiency
studies from Microsoft saying MSDOS is 100X easier to learn than the
Mac) which leaves academia.  But from what I have seen Computer
Science has declared the field "not worthy of study" and there is no
other academic field that can do the work (There doesn't seem that
very many Software Engineering departments around).  I believe that
this is because of some vain effort at scientifization of the field
(Physics Envy).  Language comparisons involve heated debate and
instead of putting up with chaos the Computer Science field has just
punted on the whole subject. "Can't we all just get along?", "We will
just agree to disagree" and other efforts to sweep these important
issues under a rug has made Computer Science pretty
worthless/spine-less. Computer Scientists seem to have declared
programming,etc as trivial and not worthy of their concern.  How can
we expect them to be motivated to learn about and then teach the
latest in programming, language understanding and design.  Its really
not their field, why should they give a rats ass.  The legions of
incompetent college graduage programmers are the result.  Who will
answer the "The Fundamental Question of Computer Science":  "Which
tool/language should I use?".


Maybe Computer Science should just stop teaching programming since it
really doesn't have much do with the field.  Maybe Computer Science
needs to be destroyed, yeah we can shove architecture into
EE/Computer Engineering,  Theory/Algorithms/Analysis into Applied
Math/Operations Research, AI into Cignus-X1 (a black hole) (no loss),
Networking into a new telecommunications field, Databases into
Novell(etc).  Since no one studies software systems/programming
languages, the destruction of CS is complete.

More constructively, maybe all Computer Science professors should be
required to be certified Software Engineers participating in
continuing education seminars and the requirement to have be part of
a non-trivial software projects that uses state of the art software
techniques every few years (with their programming reviewed). 

>John's papres are excellently presented, and I think giving them more of a
>langauge wars slant would be a big mistake. Yes, if you read the papers
>you will get an important message if you are not deaf, but the critical
>issue here is not simple us vs them language comparisons.

Going back to my point. No one is spending any effort doing reasonable
language comparison studies, thus all discussions comparing
languages/tools are called "religious", "inappropriate", "language
wars".  "Language comparisons are religions due to the absence of
studies, thus doing studies on language comparison is religious"
(circular logic). I understand why Prof McCormick can't be too
aggressive in declaring Ada the winner over C in a study or make
language comparison the centerstone of a paper.  The Computer Science
community and others will stone him to death for blaspheme.  I am
just saddened that one of the few people on the planet that may have
language comparison data can't make it widely available in a highly
visable way. 

I leave you with the abstracts to all the recent articles on language
comparisons I could find by searching a reference database:

Jay


--------------------------------------------------------------------
-- Wiener, R.
      Comparing OOP languages.
    IN:  Object EXPO Europe Conference Proceedings. (Object EXPO Europe
    Conference Proceedings, London, UK, 12-16 July 1993). New York, NY, USA:
    SIGS Publications, 1993. p. 7-8.
      Pub type:  Practical.

Abstract: Summary form only given. The author critically examines and compares
     significant features of C++, Smalltalk, and Eiffel. There are three broad
     areas that are used as the basis for comparison: software development
     issues, technical issues, and performance issues. Under software
     development issues, a comparison is made regarding how easy it is to map
     object-oriented design to each language. Under technical issues, each
     language is compared with respect to static versus dynamic type checking,
     early versus late binding, and support for generic classes. Under
     performance issues, each language is compared in terms of size and speed
     for some typical code and compilation speed, if appropriate.

-- Cullyer, W.J.; Wickmann, B.A.
       The choice of computer languages for use in safety-critical systems.
     Software Engineering Journal, March 1991, vol.6, (no.2):51-8.
       Pub type:  Practical.

Abstract: The paper reviews the choice of computer language for use in
     safety-critical systems. The advice given reflects both civil and military
     requirements. A comparison is made between assembly-level languages, the
     language C, CORAL 66, Pascal, Modula-2 and Ada. It is concluded that a
     well defined sub-language is essential for use in safety-critical
     projects, and a guide is provided for project managers and designers on
     the characteristics which such a subset should possess.

-- Plauger, P.J.
      Programming language guessing games.
    Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):16-22.
      Pub type:  General or Review.

Abstract: For all its promise, C++ is, unequivocally, a complex language-and
     history has not been kind to complex programming languages. Three that
     spring to mind are PL/I, Algol 68, and Ada. Each is a product of a
     different decade and a different (potential) user community, but each has
     followed a similar trajectory. So where does that leave C++? If it's
     following the inevitable fate of complex languages, then it's arguably
     still in the 'rising tide' stage. We can trust that its popularity and
     importance are both still growing. But we can also trust that it will not
     be the programming language of choice in the year 2000.

-- Floyd, M.
      Comparing object-oriented languages.
    Dr. Dobb's Journal, Oct. 1993, vol.18, (no.11):104-18.
      Pub type:  Practical.

Abstract: In this article, a number of programmers were invited to implement a
     simple linked-list class in their favorite objected-oriented language. The
     linked-list was chosen because it's widely used and understood, making it
     easier to compare how different languages approach a given problem. This,
     in effect, allows the code to speak for itself. To this end, one can
     examine and compare approaches in C++, Smalltalk, Eiffel, Sather,
     Objective-C, Parasol, Beta, Turbo Pascal, C+@, Liana, Ada, and Drool.


-- Wild, F.H., III.
      A comparison of experiences with the maintenance of object-oriented
    systems: Ada vs. C++.
    IN:  Proceedings TRI-Ada '90. (Proceedings TRI-Ada '90, Baltimore, MD, USA,
    3-7 Dec. 1990). New York, NY, USA: ACM, 1990. p. 66-73.
      Pub type:  Practical.

Abstract: A discussion is given on the relative ease with which systems are
     maintained using the mechanisms supported by Ada versus those supported by
     C++. The author opens with a discussion of significant aspects of
     object-oriented development, followed by comments about relevant support
     mechanisms supplied by each language. Qualitative comments are used freely
     regarding issues of object inter-relationship complexities, object
     construction and reuse paradigms, readability aspects, and others.

-- Overview of US Air Force report 'Ada and C++: a business case analysis'.
    Ada Information Clearinghouse Newsletter, Sept. 1991, vol.9, (no.3):22-6.
      Pub type:  Practical.

Abstract: On July 9, 1991, the US Air Force released to the public a report of
     a business-case study they had conducted to determine under what
     circumstances a waiver to DoD's Ada requirement might be warranted in
     order to allow the use of C++, particularly in DoD's corporate information
     management (CIM) program. The report is titled, 'Ada and C++: A Business
     Case Analysis.' An overview is given of the study.

-- Campbell, R.A.; Jones, S.; Cottle, R.
       A comparison of object oriented simulation languages.
     IN:  Cooperation. 1990 ACM Eighteenth Annual Computer Science Conference
     Proceedings. (Cooperation. 1990 ACM Eighteenth Annual Computer Science
     Conference Proceedings, Washington, DC, USA, 20-22 Feb. 1990). New York,
     NY, USA: ACM, 1990. p. 412.
       Pub type:  Practical.

Abstract: A network computer system was simulated as a single server queuing
     system using several computer languages including two object oriented
     languages. An initial simulation using Smalltalk-V was implemented on a
     Macintosh II microcomputer. A procedure oriented Pascal program was then
     implemented on the Mac II machine. A HP Vectra PC was then used to
     implement the same problem in Pascal, with and without an object oriented
     option on Turbo Pascal 5.5. The programming was performed by two
     undergraduate computer science students with considerable programming
     experience, but who were using object oriented concepts for the first
     time. Both students found that using an object oriented system in a
     programming environment supplied by Smalltalk V was a little different
     than programming in a procedure oriented language such as Pascal. Once
     they became familiar with the Smalltalk environment, they both felt that
     they would prefer to develop simulation systems in Smalltalk.

-- Yatim, D.; Sygenda, S.A.
       Performance comparison between C and Modula-2 in the context of gate
     level, table driven concurrent fault simulation.
     IN:  Proceedings of the 1990 Summer Computer Simulation Conference.
     (Proceedings of the 1990 Summer Computer Simulation Conference, Calgary,
     Alta., Canada, 16-18 July 1990). Edited by: Svrcek, B.; McRae, J. San
     Diego, CA, USA: SCS, 1990. p. 116-22.
       Pub type:  Practical.

Abstract: The selection of a convenient programming language is one of the most
     important decisions to be made prior to the implementation of any software
     project and it may greatly affect its development and maintenance costs.
     The authors compare two popular general-purpose programming languages, C
     and Modula-2, in the context of: gate level, table driven, concurrent
     fault simulation in a time sharing multi-user environment. Both static and
     dynamic software metrics are considered.

-- English, J.
      Object-oriented programming and Ada 9X: what can we learn from C++?.
    IN:  ADA: towards maturity. Edited by: Collingbourne, L. Amsterdam,
    Netherlands: IOS Press, 1993. p. 71-94.
      Pub type:  Practical.

Abstract: One of the most important new features proposed for Ada 9X is the
     inclusion of support for object-oriented programming. C++ is a descendant
     of C which supports object-oriented programming and which is now
     established as one of the major object-oriented languages. Like Ada 9X,
     C++ is a development of an existing procedural language which imposes the
     need for it to provide backward compatibility. Unlike Ada 9X, C++ has been
     available now for a number of years and a great deal of experience of its
     usefulness in practice has been acquired. This paper presents a comparison
     of the features of Ada 9X and C++ which are intended to support
     object-oriented programming. It examines the object-oriented features of
     C++ and considers whether the features proposed for Ada 9X can provide the
     expressive power of C++ while at the same time avoiding the complexities
     arising from C++'s incremental evolution. In addition, it describes some
     of the problems encountered with C++ in practice and explains how the
     practical lessons learnt from C++ might be applied to the future use of
     Ada 9X.



-- Sakkinen, M.
      The darker side of C++ revisited.
    Structured Programming, 1992, vol.13, (no.4):155-77.
      Pub type:  Bibliography; Practical.

Abstract: The C++ language is to a high degree a faithful follower of Simula as
     an object-oriented language geared more toward software engineering than
     exploratory programming. The author highlights several of its noteworthy
     good ideas. Like Simula, C++ is designed to be a general-purpose
     procedural language and not 'purely' object-oriented; this is not counted
     as a mortal sin. However, taking the weakly typed and weakly structured
     language C as a base has become an irremediable handicap. Low-level
     concerns have also caused at least one crucial flaw in the object-oriented
     properties of C++. These basic defects have not changed since the author
     first explored the darker side four years ago (M. Sakinnen, 1988). Most,
     although not all, of the numerous features and facilities that have since
     been added to the language are obvious improvements. At the same time,
     they have increased the complexity of C++ so that it is now easily
     comparable to Ada. (Some new features are suggested, nevertheless.) It
     would be regrettable indeed if C++ became the de facto standard of
     object-oriented programming, but this danger looks imminent today.

-- Rosen, J.P.
      What orientation should Ada objects take?.
    Communications of the ACM, Nov. 1992, vol.35, (no.11):71-6.
      Pub type:  Practical.

Abstract: Ada has often been blamed for not being really object oriented, in
     the sense that it provides only static inheritance (through derived
     types), but not a full inheritance mechanism. The 9X revision of the Ada
     standard will introduce inheritance into Ada, but not in the same ways as
     pure OOLs; Ada opponents will certainly take this opportunity to claim
     that the magic label object oriented still does not apply to Ada. The
     author discusses various forms of object orientation and how they apply to
     Ada, and sees how the new features of Ada 9X will impact the design of Ada
     programs. He addresses the issue only from the point of view of a language
     that is directed toward software engineering. He compares Ada mainly to
     two challengers C++ because it is a language that is currently attracting
     considerable attention, and Eiffel because it is a language that has
     specifically been designed to embody the concepts of inheritance in a
     software engineering approach.

-- McCracken, D.D.
      Programming languages in the computer science curriculum. (Twenty-Third
      SIGCSE Technical Symposium on Computer Science Education, Kansas City,
      MO, USA, 5-6 March 1992).
    SIGCSE Bulletin, March 1992, vol.24, (no.1):1-4.
      Pub type:  General or Review.

Abstract: It is important that students understand several programming
     paradigms: imperative (procedural), functional, logic, concurrent,
     object-oriented, fetch/execute machine level. The author discusses some
     programming languages which he feels should be taught in the computer
     science curriculum. These include Pascal, Modula-2, Ada, C, C++ and
     Scheme. He considers their current use in schools.

-- Tang, L.S.
      A CPU scheduling simulation from structured programming to
      object-oriented design. (Twenty-Third SIGCSE Technical Symposium on
      Computer Science Education, Kansas City, MO, USA, 5-6 March 1992).
    SIGCSE Bulletin, March 1992, vol.24, (no.1):129-33.
      Pub type:  Practical.

Abstract: Object-oriented programming has become increasingly popular. The
     author presents a CPU scheduling simulation project that he feels can
     convince students of the benefits of object-oriented design and spur their
     interest. He describes the project and discusses its solutions in three
     levels of abstraction: structured programming using Pascal, object-based
     programming using Ada, and object-oriented programming using C++. He
     presents his experiences in this assignment and explains why the
     object-oriented design is the best approach. This is intended to serve as
     a case study in an object-oriented language course or a programming
     languages course.

-- Harbison, S.
      Safe programming with Modula-3.
    Dr. Dobb's Journal, Oct. 1992, vol.17, (no.10):88-96, 126-7.
      Pub type:  Practical; Product Review (1985- ).

Abstract: Modula-3 is a full-featured language for software engineering and
     object-oriented programming. Feature-for-feature, Modula-3 is on a par
     with Ada and C++, but avoids complexity by simplifying individual features
     like inheritance and generics. Furthermore, Modula-3 is less of a moving
     target because it already has features only now being added to those other
     languages.

-- Bohm, W.; Browne, J.C.; Forslund, D.W.; Goforth, A.; and others.
      Politically incorrect languages for supercomputing-a panel discussion.
    IN:  Proceedings. Supercomputing '92. (Cat. No.92CH3216-9). (Proceedings.
    Supercomputing '92. (Cat. No.92CH3216-9), Minneapolis, MN, USA, 16-20 Nov.
    1992). Los Alamitos, CA, USA: IEEE Comput. Soc. Press, 1992. p. 704-6.
      Pub type:  General or Review; Practical.

Abstract: It is pointed out that the set of languages used to program
     supercomputers has evolved from hand-coded assembler and partially
     vectorized Fortran to include such diverse possibilities as C++, Sisal,
     and even Ada. It is noted that proponents of these languages are often
     fanatical in their support, attempting to share the obvious advantages of
     a particular language with their skeptical colleagues. This paper brings
     together a diverse group of supercomputer and parallel programming experts
     to advocate and debate the merits of several current and emerging
     programming languages and paradigms being used in the supercomputing
     arena. The intent of the panel is not to arrive at a determination of
     'best', but to expand the awareness of the audience that there is a new
     generation of programming languages and techniques emerging that is
     applicable to the supercomputing domain.

-- Baker, H.G.
      Object-oriented programming in Ada83-genericity rehabilitated.
    Ada Letters, Nov.-Dec. 1991, vol.11, (no.9):116-27.
      Pub type:  Practical.

Abstract: A scheme for single-inheritance object-oriented programming in Ada83
     is presented in which many methods are determined at compile time using
     'generic' subprogram overloading. Unlike previous schemes for
     object-oriented programming in Ada83, which rely exclusively on derived
     types for inheritance, the scheme utilizes both derived types and generic
     units, and hence is more powerful. In particular, inheritance schemes
     based on derived types cannot handle the C++ concept of 'virtual
     function', while this scheme determines many of these methods at compile
     time. The results call into question B. Meyer's (1986) conclusions
     regarding the weakness of generic units.



  reply	other threads:[~1995-01-08  8:04 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-12-30 16:06 "Subtract C, add Ada" Mitch Gart
1995-01-03 19:04 ` whiting_ms@corning.com (Matt Whiting)
1995-01-05  4:31   ` Michael Feldman
1995-01-04 21:40 ` Fred McCall
1995-01-05  4:30   ` Richard Pattis
1995-01-05 16:07   ` Kevin Weise
1995-01-06 13:06   ` Jahn Rentmeister
1995-01-06 16:47     ` Laurent Gasser
1995-01-06 17:29       ` David Weller
1995-01-06 17:30         ` David Weller
1995-01-10 18:28       ` Bob Kitzberger
1995-01-06 23:36   ` Kenneth Almquist
1995-01-04 22:45 ` Jay M. Martin
1995-01-05  4:37   ` Michael Feldman
1995-01-05 18:08     ` Jay Martin
1995-01-05 23:56       ` Robert Dewar
1995-01-08  8:04         ` Jay Martin [this message]
1995-01-06  0:07       ` Michael M. Bishop
1995-01-10 21:30         ` Jay Martin
     [not found] <3etund$hnr@miranda.gmrc.gecm.com>
1995-01-12  9:56 ` Erik Svensson
1995-01-12 14:44 ` Norman H. Cohen
1995-01-13  1:51 ` David O'Brien
1995-01-13 12:38   ` Laurent Gasser
1995-01-13 20:53     ` John DiCamillo
     [not found]       ` <3f8fnf$c8p@gamma.ois.com>
1995-01-16 11:02         ` Matt Kennel
     [not found]         ` <milodD2IFpG.329@netcom.com>
1995-01-17 21:39           ` R. William Beckwith
     [not found]       ` <3fa11q$sdh@gnat.cs.nyu.edu>
1995-01-16 20:20         ` David Moore
1995-01-14  0:24     ` David O'Brien
1995-01-20  4:43     ` Samuel Mize
1995-01-21 20:28       ` David O'Brien
1995-01-22 21:12         ` Robert Dewar
1995-01-23 18:35         ` Norman H. Cohen
1995-01-23 19:18         ` John Cosby - The Coz
1995-01-24 14:11         ` Samuel Mize
1995-01-14 10:37   ` Keith Thompson
     [not found]     ` <3fcjgt$b0v@cronkite.seas.gwu.edu>
1995-01-16 18:47       ` Robert Dewar
     [not found]   ` <D2It0r.4rp@inmet.camb.inmet.com>
1995-01-17 14:11     ` Norman H. Cohen
     [not found] <3fdcoi$chn@miranda.gmrc.gecm.com>
1995-01-20  5:01 ` Samuel Mize
1995-01-20 22:07   ` Garlington KE
1995-01-24  5:02     ` R_Tim_Coslet
     [not found] <3fgphd$sc3@rational.rational.com>
1995-01-20  5:51 ` RonaldS60
1995-02-07 13:55   ` Robert C. Soong
  -- strict thread matches above, loose matches on Subject: below --
1995-01-20  9:33 R.A.L Williams
1995-01-20 10:20 R.A.L Williams
1995-01-20 13:22 ` Renaud HEBERT
1995-01-24  3:35   ` David Moore
1995-01-25  5:38     ` Robert Dewar
1995-01-28 16:35     ` Jules
1995-01-29  8:06       ` Matt Kennel
1995-01-30  5:31       ` Michael Feldman
1995-01-31 22:22         ` David O'Brien
1995-01-24 20:23   ` N. Mellor
1995-01-25  8:50     ` Robb Nebbe
1995-01-25 14:19     ` John Volan
1995-01-26  5:07     ` Samuel Mize
1995-01-26 18:51       ` Mark A Biggar
1995-01-21 15:18 ` Robert Dewar
1995-01-21 21:03 ` David O'Brien
1995-01-23  3:09   ` Jay Martin
1995-01-23 12:50     ` Andrew McConnell
1995-01-24  0:54     ` Matt Kennel
1995-01-25 17:03       ` Norman H. Cohen
1995-01-26  1:13         ` Dr. Richard Botting
1995-01-26 14:32         ` Anders Juul Munch
1995-01-24  0:17   ` Bob Kitzberger
1995-01-23 20:46 ` Robert Firth
1995-01-24 14:25   ` Samuel Mize
1995-01-25  7:27     ` David O'Brien
1995-01-25 12:14     ` Robert A Duff
1995-01-25  5:57   ` David O'Brien
     [not found]     ` <3g9rf0$71k@Starbase.NeoSoft.COM>
1995-01-28 21:08       ` David O'Brien
1995-01-31 18:07         ` Samuel Mize
1995-02-01 10:23         ` Samuel Mize
1995-01-30  0:24     ` Mark S. Hathaway
1995-01-31  3:30       ` Jay Martin
1995-02-01 13:25         ` Jesper Kaagaard
1995-01-23  8:49 R.A.L Williams
1995-01-25 23:18 ` Charles H. Sampson
1995-01-31  9:34 R.A.L Williams
1995-02-01 16:45 ` Charles H. Sampson
     [not found] <3gsr0e$oin@miranda.gmrc.gecm.com>
1995-02-07 16:58 ` Mark S. Hathaway
1995-02-08  7:39   ` Travis C. Porco
1995-02-08 16:07     ` Fred J. McCall
1995-02-08 21:30       ` Garlington KE
1995-02-10 13:49 R.A.L Williams
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox