From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: Wed, 8 Sep 93 15:38:52 EDT From: stt@dsd.camb.inmet.com (Tucker Taft) Subject: Re: 30 Years Message-ID: <9309081938.AA17353@dsd.camb.inmet.com> List-Id: > > In article <9308251529.AA07664@manta.nosc.mil> > > mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes: > > > . . . > > >Because I believe Ada cannot always be used cost-effectively for small > > >or short projects (using my definition of a project), I do advocate > > >that more appropriate languages be used for small or short projects > > >where they are more cost-effective. > > . . . As I see it, this language should have > > >multiple formality levels. High formality would be required for huge > > >systems. Informality would be allowed for throwaway programs. > > >In-between systems would need to conform to some intermediate formality > > >levels. > In article stt@inmet.com > (Tucker Taft) writes: > > > I guess I don't understand this concept of "formality" at all. > > . . . In article <9309081721.AA18798@manta.nosc.mil> mshapiro@manta.nosc.mil (Michael D Shapiro) writes: > As I look in my American Heritage Dictionary, one of the standards for > American English, I can see why there could be some confusion over my > use of "formal" or "formality." It has several definitions. I mean to > use the term in much same the way that one speaks of multiple formality > levels in the American English language. > . . . > That's what I mean by the formality level of a language. You can use a > programming language like C in a very formal manner or in a highly > informal manner. Some years ago, when I was doing product development > in C on the PC, I wanted a formal level. I used Gimpel's PC-Lint with > a certain set of options and was not satisfied the code could be > released until the utility produced no warnings. On the other hand, > I've thrown together quicky C code at a very informal level. It did > the job I needed, but I might get many warnings from PC-Lint or the > compiler. I didn't care because I didn't intend to use the code again. > (If I did need to dredge it up, I could always run it through PC-Lint > to tell me the probable bad points.) For this reason, I think of C as > a wide-level language. The language, with add-on tools, has high-level > formality when I need it and low-level when I want it. C++ started as > an extension to C and seems to support an even wider level of > formality. I see you are defining formality in terms of the kinds of compile-time checks that "Lint" performs. First of all, essentially everything that Lint requires is also required by C++ (and ANSI C). In particular, in C++ you must have a "prototype" for a function before you call it. Furthermore, there are strict rules w.r.t. implicit conversions between types in C++. You seem to be saying that if a project is sufficiently "short" then you don't really care that your types don't match up when you call a function, or that you mistakenly forgot a "break" statement on a C/C++ switch arm. It is a bit hard to believe that the time you save by being this sloppy pays off except in creating debugging headaches or total lack of faith in the result of executing the program, presuming it produces any results at all. In any case, if you are talking about the requirement to have types match up in function calls as "excessive formality" then I think we are on different wavelengths, and it is probably not worth trying to convince one another any further. On the other hand, I would agree with you that there do exist languages that make it easier to program a small program quickly. These tend to be interpreter-oriented, dynamically typed languages like SmallTalk or CLOS. However, it is not really the dynamic typing that makes the big difference. The big difference is that most interpreter-oriented systems seem to come with a huge library of reusable code (e.g. the "Collection" classes of SmallTalk, the standard CLOS library, etc.). Dynamic typing is admittedly convenient when trying to write certain kinds of polymorphic algorithms, though statically typed languages can come close to the same flexibility through the provision of generics/templates and inheritance, while providing much stronger static correctness guarantees. These static correctness checks make debugging and maintenance so much easier, that even for a very small program, the modest loss of flexibility is often rapidly paid back. In addition, the required declarations often make the program easier to read and understand. > I believe Ada's acceptance problem is that it requires a high level of > formality all the time. It assumes every program must be written in > maintainable style. People become uncomfortable when they must work at > that level of formality all the time. So they reject Ada, even though > they probably should use it some of the time. Is this your conjecture, or is it based on some actual experience with Ada? One can write quick and dirty programs in Ada. If portability and maintainability are not the issue, then one can use the predefined numeric types Integer and Float, anonymous array types, etc., and quickly write a program that essentially mimics any C program that actually works. Here is an example of a quick and dirty Ada program: with Text_IO; use Text_IO; procedure Print_Squares is begin for I in 1..100 loop Put_Line(Integer'Image(I) & " squared = " & Integer'Image(I**2)); end loop; end Print_Squares; It is interesting to note that in C, one would actually have to explicitly declare the variable "I" since a for-loop in C doesn't implicitly declare the loop index. > Okay, that's the way I use "formal" -- "following or adhering to > accepted forms, conventions, or regulations." . . . It is true that the culture of Ada tends to encourage programmers to think in terms of defining reusable packages with well-defined interfaces, but it certainly doesn't require that. Some OOP languages do force all code to be part of some "class." In Ada, the style of putting all substantial code inside an appropriate package develops naturally in any big project, but small projects can stick with a loose collection of stand-alone subprograms should they so choose. If anything, compared to some newer OOP languages, Ada is less "formal" in that it doesn't force all projects to embrace a package/object-oriented paradigm (though most Ada projects do). There are plenty of things to argue about when it comes to the relative merits of various languages, but it seems odd to use the excuse that Ada is "overly formal" to justify not using it. In any case, if you really believe Ada is overly formal, you should at least be more specific -- talk about things like parameter type mismatch, missing "break" statements, or whatever it is that Lint catches that you prefer to have uncaught in your "small projects." > Michael D. Shapiro, Ph.D. e-mail: mshapiro@nosc.mil > NCCOSC RDT&E Division (NRaD) Code 411 San Diego CA 92152-7560 S. Tucker Taft stt@inmet.com Intermetrics, Inc. Cambridge, MA 02138