rosalia@reed.UUCP (Mark Galassi) (06/11/85)
In article <494@bonnie.UUCP> spf@bonnie.UUCP (Steve Frysinger) writes: >> .... This is what the Ada people >> need to drive through their skulls: we don't want another COBOL or >> Pascal! (No personal offence to "Ada people".) >> >> Mark Galassi >> ...!tektronix!reed!rosalia >> {These views are mine and should be everybody else's :-) } Since then Steve has written me a couple of letters, showing that he understands that C has more raw power and that the reasons for preferring Ada are managerial (large projects with many poeple require a language oriented towards tyranny rather than anarchy). This does confirm that nobody will program in Ada for the joy of it, but rather as a chore. My deep respect for Steve, but a couple of things need correcting: > >Just for the record, on my DEC PRO 350 (a PDP-11/23 running RSX-11M) >the code generated by the Pascal compiler has consistently been 50-100% >FASTER than the code generated by Whitesmith's C compiler. ** Use the DECUS C compiler (public domain), it performs better than other compilers on RSX and RT-11. >The point is this: C is not necessarily more efficient than Pascal (or >Ada, etc). The quality of the compiler and run-time system is where >it's at. While I'm not in love with either Ada or C, the argument I >read on the net sounds more like defense of the familiar (C) against >the unknown (Ada), which is not a very open-minded frame of mind for >people in a high-tech, fast-paced industry. >Steve Frysinger ** what is more open-minded than programming because it is enjoyable rather than a duty? I have also seen projects for which C presented portability, and many people could modify the code and understand it. Microsoft develops all its applications in C, as do many other high- powered companies. Some programs for bank use have been written in C and were amazingly efficient (the programmers probably hated it :-) ). My code always passes lint checks with the "-b" and other tight options. >Why would I waste my time expressing anybody's opinions but my own? ** you wouldn't waste time if they all agreed with you. :-) Mark Galassi ...!tektronix!reed!rosalia
rjh@calmasd.UUCP (Bob Hofkin) (06/14/85)
In article <186@harvard.ARPA> macrakis@harvard.ARPA writes: >Why must we have flaming on net.lang? Discussing programming languages is similar to discussing religion. > Look up unchecked_conversion and the >rest of chapter 13 in Ada. You can straightforwardly do random pointer >operations etc. in Ada when you need to. Look up Chapter 13 features in valid, production-quality Ada compilers. Compiler writers claim Chapter 13 is "optional" because the ACVC doesn't test that stuff. Folks at AVO seem to agree. [Had to get that in!] > Can't we avoid this sort of offensive and pointless mudslinging? What, ruin the fun? Truth often comes out under such circumstances.
keith@telesoft.UUCP (Keith Shillington @seventh) (06/14/85)
(Mark Galassi) and (Steve Frysinger) write: >>> .... This is what the Ada people >>> need to drive through their skulls: we don't want another COBOL or >>> Pascal! (No personal offence to "Ada people".) >>> >>> {These views are mine and should be everybody else's :-) } >Since then Steve has written me a couple of letters, showing that he >understands that C has more raw power and that the reasons for preferring >Ada are managerial (large projects with many poeple require >a language oriented towards tyranny rather than anarchy). This does >confirm that nobody will program in Ada for the joy of it, but rather >as a chore. > ... etc. Growl. I have been programming in Ada for 4 years now. Pascal for 6 before that. C on and off for the entire time. 1: Ada is NOT Pascal. It may look similar to the novice, but the languages are significantly different. Just like Pascal looks like C to the semi-novice, and we all know the languages are radically different. (...and it certainly isn't COBOL, give me a break!) 2: Programming in structured, highly typed languages is an incredible joy, I don't have to worry about making weird semantic errors; the compiler will point them out to me. I can be highly expressive, and have a hope in Hades that someone else might understand my code without studying it for weeks. 3: I agree that C has immense raw power; so do most assemblers. In fact, for writing drivers and the like (given that I don't as of yet have a full-on-complete-with-all-the-hooks-and-switches-Ada-Compiler to play with) C is the language of choice. I would counter to the claims of C's conciseness with APL. I would counter to the claims of flexibility with LISP. And I counter to programming joy with Ada. I don't mean to offend, I mean to inform. Keith Allan Shillington Instructor in the structured languages: Pascal and Ada.
macrakis@harvard.ARPA (06/16/85)
It is certainly true that many current Ada compilers do not implement useful Chapter 13 features, but since the most basic one, unchecked_conversion, is so simple to implement (you just turn off type checking!), I believe most compilers have it. This is the main thing you need to do C-like low-level pointer manipulations.
ee163acp@sdcc13.UUCP (DARIN JOHNSON) (06/16/85)
In article <192@harvard.ARPA>, macrakis@harvard.ARPA writes: > It is certainly true that many current Ada compilers do not implement > useful Chapter 13 features, but since the most basic one, > unchecked_conversion, is so simple to implement (you just turn off > type checking!), I believe most compilers have it. This is the main > thing you need to do C-like low-level pointer manipulations. Ok, let's say C programmers start to use Ada. In fact, there will be quite a few of them. Wouldn't it be silly if they all tended to but unchecked_conversion at the start of all their programs. Then when they wanted to make distributions, they would remove it (sort of a lint type check). What if they went on later to suggest to some standards committee that untyped_conversion should be the default, and there should be a flag with 'type_checking_on' in later versions (of which there will be next to none). Think about it. I don't want to. Darin Johnson
friesen@psivax.UUCP (Stanley Friesen) (06/17/85)
In article <453@calmasd.UUCP> rjh@calmasd.UUCP (Bob Hofkin) writes: >In article <186@harvard.ARPA> macrakis@harvard.ARPA writes: >> Look up unchecked_conversion and the >>rest of chapter 13 in Ada. You can straightforwardly do random pointer >>operations etc. in Ada when you need to. > >Look up Chapter 13 features in valid, production-quality Ada >compilers. Compiler writers claim Chapter 13 is "optional" because >the ACVC doesn't test that stuff. Folks at AVO seem to agree. [Had >to get that in!] > Oh, GREAT! I finally find out Ada has a really useful, flexible feature, that would make it useful for my kind of work, and I am told it is *optional*. I certainly *hope* *some* compilers use chapter 13, since I would hate to use an Ada without those features. -- Sarima (Stanley Friesen) {trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
lwall@sdcrdcf.UUCP (Larry Wall) (06/18/85)
In article <511@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > Oh, GREAT! I finally find out Ada has a really useful, > flexible feature, that would make it useful for my kind of work, > and I am told it is *optional*. I certainly *hope* *some* compilers > use chapter 13, since I would hate to use an Ada without those > features. Chapter 13 is not optional. It does contain two features that are explicitly labeled as optional: machine code insertion, and interfacing to other languages. Which only makes sense, considering some machines may not have other languages, and some machines claim to not have machine code. Some of the other features may have implementation-dependent restrictions but are not labeled as optional. In particular, representation specifications and unchecked conversion are not optional. While it is impossible for the ACVC to test implementation dependent features, I understand that at least one compiler has been "failed" for ignoring rep specs. It'll be easy enough to avoid buying a compiler with missing or brain-damaged features--all such differences must be documented in Appendix F of the manual that comes with the compiler, and if that's inaccurate the supplier of the compiler is in hot water with AJPO. I believe the Verdix compiler has most of the Chapter 13 features already, though I haven't used it myself. Yet. Larry "Ada isn't too complex--some people are just too simple" Wall {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
jans@mako.UUCP (Jan Steinman) (06/19/85)
In article <266@sdcc13.UUCP> ee163acp@sdcc13.UUCP (DARIN JOHNSON) writes: >In article <192@harvard.ARPA>, macrakis@harvard.ARPA writes: >>It is certainly true that many current Ada compilers do not implement useful >>Chapter 13 features, but since the most basic one, unchecked_conversion, is >>so simple to implement (you just turn off type checking!), I believe most >>compilers have it. This is the main thing you need to do C-like low-level >>pointer manipulations. > >...Wouldn't it be silly if they all tended to but unchecked_conversion at the >start of all their programs. Then when they wanted to make distributions, >they would remove it... You really missed the point. If they simply removed the pragma, the code probably fail to compile if they were doing anything funny. It is true that allocation and type checking costs, so in time or space critical code, the way to do it is to do all the debugging and testing with the checks on, and then add the pragmas (for performance reasons) before shipping. How many times during debugging has your only indication of anything wrong was "memory fault, core dumped"? Wouldn't it be much nicer to see "range of variable i exceeded in procedure Array_Access"? -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
rjh@calmasd.UUCP (Bob Hofkin) (06/20/85)
In article <192@harvard.ARPA> macrakis@harvard.UUCP (Stavros macrakis) writes: >unchecked_conversion... is the main >thing you need to do C-like low-level pointer manipulations. Assuming a flat address space, and pointer size == integer size. Or assuming the code won't be ported.