From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fc52c633190162e0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr17.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <1172144043.746296.44680@m58g2000cwm.googlegroups.com> <1172161751.573558.24140@h3g2000cwc.googlegroups.com> <546qkhF1tr7dtU1@mid.individual.net> <5ZULh.48$YL5.40@newssvr29.news.prodigy.net> Subject: Re: why learn C? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Response Message-ID: <4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net> NNTP-Posting-Host: 70.134.112.39 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr17.news.prodigy.net 1174499328 ST000 70.134.112.39 (Wed, 21 Mar 2007 13:48:48 EDT) NNTP-Posting-Date: Wed, 21 Mar 2007 13:48:48 EDT Organization: AT&T http://yahoo.sbc.com X-UserInfo1: Q[RGW^WETZSMB_DX]BCBNWX@RJ_XPDLMN@GZ_GYO^ZUDUWYAKVUOPCW[ML\JXUCKVFDYZKBMSFX^OMSAFNTINTDDMVW[X\THOPXZRVOCJTUTPC\_JSBVX\KAOTBAJBVMZTYAKMNLDI_MFDSSOLXINH__FS^\WQGHGI^C@E[A_CF\AQLDQ\BTMPLDFNVUQ_VM Date: Wed, 21 Mar 2007 10:48:45 -0800 Xref: g2news1.google.com comp.lang.ada:14575 Date: 2007-03-21T10:48:45-08:00 List-Id: "Maciej Sobczak" wrote in message news:etqp42$4g6$1@cernne03.cern.ch... > adaworks@sbcglobal.net wrote: > >> Unlike the C family of languages, > > I presume you mean C, C++, D, Java, C#. > Actually, D and C# seem a little better than the others you named. In fact, there are some features of C# I quite like, especially when one compares Java. > > Tha last time I made case-sensitivity error the compiler helped me. > But C/C++/Java compilers are not consistent in this respect, and one would be foolish to rely on them for that. > >> wrong order of arguments to parameters > > I can do this error in Ada quite easily. > Unless you use named association and avoid the use of predefined types. > > Yes, there are named parameters in Ada. And structures with named components > in other languages. > This is not even an option in C/C++/Java/ or other of the C family. > > Please provide an example of code where improper spacing leads to extensive > debugging. > Another responder dealt with this. > >> missing curly-braces, > > The last time I missed the curly brace the compiler told me that. > It is not the absence of a single curly-brace, but the occasional absence of a pair of them that sometimes leads to long and entertaining sessions of debugging. This would not happen in Ada. > > (for the sake of this discussion let's forget about the fact that in any > self-respecting programmer's editor missing curly-brace is plain impossible, > because braces are part of text formatting rules) > As noted, the problem is not a single missing curly brace. Further, misplacement of a curly-brace can also be highly entertaining. Units in Ada, including declare blocks (which ought to be used minimally) have the option of being named. I use this option consistently. I don't have that option in any of the C family of languages. > >> and the plethora of language "features" that plague those who have >> chosen to use any member of the C family of languages. > > Any language (from any family) older than one version has "features". > And some have more "features" than others. > >> It has always seemed rather odd to me that people who are as intelligent >> as programmers, rarely question the silliness of using tools such as C >> and C++ for serious work. > > Maybe because they are intelligent and can reasonably balance pros and cons of > various technology choices. > I rather think not. With all the advantages of Ada over the C family of languages, it simply makes no sense to choose one of those languages for any reason other than their availability. It is somewhat like going to a fast-food restaurant instead of a restaurant where one would get better quality food. The fast food restaurants are quite popular, but they are not especially beneficial froma dietary perspective. > >> They simply take for granted that the kind >> of errors that are so common in those languages are somehow akin to >> the laws of nature. > > That's a good point and indeed a significant fraction of the community takes > errors as part of the game. But I wouldn't attribute it only to the language > choice (although that's an important factor indeed), also to the massive > approach to education ("learn programming in 24 hours now!"). > Teach millions to program in Ada and you get tons of crappy code. > I take your point. No language by itself can eliminate stupidity. However, choosing good tools can make a difference. Ada is not the right tool for everything. I like some of the languages such as Python and Ruby that have recently come on the scene. However, those languages are not suitable for every kind of problem. We always want to choose the right tool for the right job. This discussion centers around the idea of debugging. Even crappy Ada is less likely to lead to the onerous level of debugging found in C or C++. >> Java inherits many of those same properties and is not much better. > > True. > >> It is taken as an article of faith that programming >> involves heavy use of debuggers. > > Not necessarily. The advocates of test-driven development (TDD for short) > openly say good bye to debuggers, at least in blogs. > I am quite aware of TDD. I am not a fan. While many of the claims of the TDD advocates have some virtue, it is a fact that not all errors in a program can be detected through testing. Further, as Dijkstra notes, "We can test for the presence of errors, but not for their absence." TDD can be a good technique for augmenting the correctness of a design and its implementation, but it is no substitute for other methods. Reliance on TDD exclusively seems a bit foolhardy, just as reliance on type-safety alone, inspection alone, exception handling alone, or any of the other popular approaches to software dependability. > Too many TDD advocates seem to reject the importance of developing rigorous software requirements prior to beginning the programming process. The notion that the tests are the requirements is naive, at best. This might work for smaller software projects where the domain is well-understood, but it is not appropriate for large-scale software systems where dependability is life or mission critical. > >> Ada is a programming language that makes it easier to focus on the design >> before dealing with the details of that design. > > Yes, but Ada is not unique here. In C++ or Java you can do a lot of design > before actual implementation starts. > The design of Java fails to encourage good design. This is, in part, due to the tight relationship between all of its parts within a single library and compilation unit. C++, while supporting a model of separate compilation, does not support it well. The relationship between the specification and the implementation in C++ is sloppy, at best. > >> Then, Ada makes it easier to ensure that the details conform to the design. > > Yes, but Ada is not unique here. There are differences in what is the scope > and precision of design expression, of course, and this is where Ada shines. > But conformance between the details and the design (specs) is ensured in every > static language. > Well, this is not the case unless one jumps through a lot of hoops to make sure it is. It is certainly not the case in C++. Consider the requirement for #IFNDEF and other bits of fluff that a C++ programmer must provide to ensure that all the pieces are where they ought to be. Ada provides the developer with options that make it much more likely that everything will snap together as expected. It gives more of an engineering flavor of the design and development process. While it is true that an Ada developer need not use the options that provide this capability, those options are not even available in C, C++, Java, D, or C#. If I have a torque wrench available and fail to use it, the twisting of the head from the bolt is my fault. If, however, I use the torque wrench correctly, I have a greater chance of doing the job right. Ada is like a torque wrench in software. I can measure the level of torque more easily than I can simply using any old long handled wrench. C and C++ are like a long-handled wrench. I can do the job, but I have little hope of getting it right, and I don't know I've gotten it wrong until it breaks. That is one of things I find so fascinating about modern programming: that programmers take for granted that they cannnot know how good their program is until something breaks. With Ada (and also with Eiffel), one can know much more about what might break, can prevent such breakage before it happens, and can set the limits for breakages so they are less probable at testing time and deployment time. > >> I wonder why that is such a difficult concept for so many. > > It isn't. Only the tradeoffs change. > >> It always amazes me that someone would choose an error-prone >> programming language such as C++ and expect error-free programs. > > It always amazes me that someone would choose a language that has no > measurable user base such as Ada and expect to build a successful team. > Again. I would rather eat at a good restaurant than at a popular fast-food restaurant, even though such restaurants are not as abudant. > > The missing user base is one of two major problems that prevent me from > starting an Ada project, whether at work or in my free time. > The other is the lack of *free* Ada compiler on one of my target platforms > (LynxOS). > One must live with the limitations imposed. If there is no compiler for the platform, the choices are not as happy. Also, as I noted earlier, Ada is not the only good tool and is not the right tool in every case. However, from my perspective, C++ ought to be the tool of last resort. > > "There are just two kinds of languages: the ones everybody complains about and > the ones nobody uses." - Bjarne Stroustrup. > Dr. Stroustrup did a remarkable design within a boundary that imposed a lot of restrictions that, even he admits, were not ideal. Given the constraints at the time C++ was designed, no one can fault him or criticize him for his work. It was brilliant. However, I am reminded of a TV show called McGiver where the hero, also highly intelligent and innovative, was able to invent solutions with a minimum of resources at hand. Even the most brilliant of minds, when constrained by an context that limits the options for a design, will produce a solution that is less than ideal. The Pythagoreans fell short of their goal of making "number" the universal foundation for an enduring religion. They simply did not have everything they needed to make that happen. Renes Descartre could not quite bring himself to recognize negative coordinates. Many brilliant people over the millennia have made significant contributions within the constraints of their environment and context. C++ was a brilliant piece of design. It is just not good enough when one considers the other options currently available. Richard Riehle