rosalia@reed.UUCP (Mark Galassi) (06/02/85)
In article <11117@brl-tgr.ARPA> ron@BRL.ARPA (Ron Natalie) writes: >And if the people who wrote UNIX had done it in Ada, it wouldn't >be any better... It would probably not be better for readability (although I know many people who are very fluent in reading C hack), and it would certainly be much the worse for flexibility and speed. 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 :-) }
rosalia@tekig4.UUCP (Mark Galassi) (06/04/85)
In article <22700006@gypsy.UUCP> emery@gypsy.UUCP writes: > >for instance, consider looping through the characters of a string.... > > for (a_char = *str_ptr++, !a_char;) > > for char_index in a_string'length loop > a_char := a_string(char_index); > >Which do you understand better? > > Dave Emery > {princeton!ihnp4}!siemens!emery It is hard to understand what side the person here took, and what the "for ... " statement is supposed to mean. It certainly does not mean anything in C, but maybe he meant: while (!(a_char = *str_ptr++)) or for ( ; !(a_char = *str_ptr++); ) in which case it is a very normal, common and understandable C instruction. Much more readable than the stuff underneath. Mark Galassi ...!tektronix!reed!rosalia { These opinions are mine and should be everybody else's :-) }
spf@bonnie.UUCP (Steve Frysinger) (06/04/85)
> In article <11117@brl-tgr.ARPA> ron@BRL.ARPA (Ron Natalie) writes: > >And if the people who wrote UNIX had done it in Ada, it wouldn't > >be any better... > > It would probably not be better for readability (although I know many > people who are very fluent in reading C hack), and it would certainly > be much the worse for flexibility and speed. 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 :-) } 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. 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 Why would I waste my time expressing anybody's opinions but my own?
mangoe@umcp-cs.UUCP (Charley Wingate) (06/08/85)
In article <494@bonnie.UUCP> spf@bonnie.UUCP (Steve Frysinger) writes: >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. > >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. No, it seems to me that a very different point is indicated. About the only assumption Pascal makes about a machine is that characters are addressable individually. C, on the other hand, requires all sorts of features: all the incrementation and decrementation operators, pointers you can do math with, ASCII, and a couple of other things. This, not suprisingly, is very much like what a PDP-11 supplies. On other machines, however, these things must often be simulated, or the feature is more expensive; what you get is a language that contains a wierd PDP-11 assembler generating code for a different machine. Hence it's not suprising that the Pascal is much faster; consider the inefficiencies of C on a machine that is radically unlike a PDP-11, such as a Sperry or CDC machine! My gut reaction is that people are afraid of ADA because of the experience with PL/1. The only dialects of PL/1 that really saw much use away from IBM machines were the various systems languages (PL/S, PLUS, PLM, etc.), which were stripped of much of the high-overhead stuff and given primitives appropriate to a particular machine. DOD has already stated that it will not allow similar languages attached to ADA. Given the ongoing development of other, cheaper languages, I don't think ADA has much of a chance; the arrival of the first reasonable compiler for FORTRAN 8X will probably do it in. Charley Wingate umcp-cs!mangoe
spf@bonnie.UUCP (Steve Frysinger) (06/10/85)
> In article <494@bonnie.UUCP> spf@bonnie.UUCP (Steve Frysinger) writes: > > >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. > > > >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. > > No, it seems to me that a very different point is indicated. About the only > assumption Pascal makes about a machine is that characters are addressable > individually. C, on the other hand, requires all sorts of features: all the > incrementation and decrementation operators, pointers you can do math with, > ASCII, and a couple of other things. This, not suprisingly, is very much > like what a PDP-11 supplies. On other machines, however, these things must > often be simulated, or the feature is more expensive; what you get is a > language that contains a wierd PDP-11 assembler generating code for a > different machine. Hence it's not suprising that the Pascal is much faster; > consider the inefficiencies of C on a machine that is radically unlike a > PDP-11, such as a Sperry or CDC machine! > > My gut reaction is that people are afraid of ADA because of the experience > with PL/1. The only dialects of PL/1 that really saw much use away from IBM > machines were the various systems languages (PL/S, PLUS, PLM, etc.), which > were stripped of much of the high-overhead stuff and given primitives > appropriate to a particular machine. DOD has already stated that it will > not allow similar languages attached to ADA. Given the ongoing development > of other, cheaper languages, I don't think ADA has much of a chance; the > arrival of the first reasonable compiler for FORTRAN 8X will probably do it > in. > > Charley Wingate umcp-cs!mangoe If C is optimized for a PDP-11 architecture, why does it do WORSE on the PDP-11/23 than Pascal. Maybe I missed your logic somewhere...
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
mangoe@umcp-cs.UUCP (06/11/85)
For some reason, I didn't notice that the dec pro series is PDP-11 based. Therefore my observation must be muted to noting that C must emulate whatever UNIX facilities aren't provided in RSX-11. My criticism of C in general, however, still stands. Charley Wingate
david@ukma.UUCP (David Herron, NPR Lover) (06/12/85)
In article <496@bonnie.UUCP> spf@bonnie.UUCP (Steve Frysinger) writes: >> In article <494@bonnie.UUCP> spf@bonnie.UUCP (Steve Frysinger) writes: >> >> >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. ... >> ASCII, and a couple of other things. This, not suprisingly, is very much Sorry ... C does NOT require ASCII. I suggest you read the C Reference manual *real*closely* sometime(in the rear of K&R). It talks about C compilers for many different machines. Including IBM-370's. Also, '\n' does not mean ASCII LF. It means, "whatever is used as a line seperator". I know of 2 C compilers where it means something else. >If C is optimized for a PDP-11 architecture, why does it do WORSE on >the PDP-11/23 than Pascal. Maybe I missed your logic somewhere... Like somebody else said in the quoted posting (I editted it out). You can write a BAD compiler, or you can write a good compiler. If you're comparing the DECUS C compiler to (fr instance) OMSI pascal, the pascal compiler will of course come out worse. -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> --- or david%ukma.uucp@anl-mcs.arpa --- Or even anlams!ukma!david@ucbvax.arpa --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david "It's *Super*User* to the rescue!"
phil@amdcad.UUCP (Phil Ngai) (06/13/85)
In article <127@umcp-cs.UUCP> mangoe@umcp-cs.UUCP writes: >For some reason, I didn't notice that the dec pro series is PDP-11 based. >Therefore my observation must be muted to noting that C must emulate >whatever UNIX facilities aren't provided in RSX-11. <sarcasm for those who can't tell> Of course it is inefficient to emulate UNIX facilities in C. After all, the kernel is written in Basic. -- A man could get elected President by promising to put the phone company back together. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
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.
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.