Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!andromeda!argus!ken From: ken@argus.UUCP (Kenneth Ng) Newsgroups: comp.lang.misc Subject: Re: REXX ? As in Tyrannosuarus REXX ? Message-ID: <659@argus.UUCP> Date: Mon, 15-Dec-86 23:20:38 EST Article-I.D.: argus.659 Posted: Mon Dec 15 23:20:38 1986 Date-Received: Wed, 17-Dec-86 07:26:16 EST References: <1184@navajo.STANFORD.EDU> <637@argus.UUCP> <696@hoxna.UUCP> <973@cuuxb.UUCP> Organization: NJ Inst of Tech., Newark NJ Lines: 98 In article <973@cuuxb.UUCP>, mwm@cuuxb.UUCP (Marc W. Mengel) writes: > In article <649@argus.UUCP> ken@argus.UUCP writes: [edited comment from soc.singles on C, REXX, Ada] > First of all WHY WAS THIS IN SOC.SINGLES?!?!?! Because it came up in soc.singles in discussion of how to identify nerds, which doesn't belong in THIS group. >Yes C does not use strong type checking, and *some implementations* use single > pass linker for speed. I have never seen a standard C library routine that > did not perform as documented. What most people think of as inconsistencys > in C are mainly differences between C and other languages. While C does have >some inconsistencies which are mildly annoying, they are at worst only a minor >inconvenience. Of course, I cannot address what you might be considering as > inconsitent, since you didn't give any examples. I suspect the bulk of the linkers are one pass. If not, then why must I type in a command with tsort and a few other things in it when I put something into an archive? If you want a couple examples of C library functions doing something different: check out the timeout options on the read() function. Yes I know it is documented in the System 5 Interface Specifications. But it is NOT documented on the manual page, where it belongs. Check out the printf routine when printing hex integers which are supposed to be padded on a Waterloo compiler, it ignores the option. C does have some problems when you move a computation program from one machine to another and you get DIFFERENT results. About the inconsistencies: how about initializing characters with strings but other types with "{}" pairs? How come the maddening left to right, right to left, and partially hierarchical ordering of "*", "++" "+=" and the dozen other terms? I can't recall the exact thing I was asking about, it was over a year ago. I had asked someone who used to work at Bell Labs why part of C was done one way, and something else another. And he said: "You have to understand the order features were added to the language to understand it". I responded: "You mean they tweaked the compiler rather than made a consistent well ordered language." And he responded: "When you come down to it, yes." > > There are some *derivatives* of Pascal in which large systems have been written, > but even Pascal's author, Niklaus Wirth, says it was never intended to be used > for anything but a simple introductory language. > > Your comments on portability are interesting, yet a program that does machine > dependant things (such as an operating system kernel) will ALWAYS be machine > dependant, no matter how portable the language is. Therefore no language > which has constructs powerful enough to get down to the low level and bash > bits with the hardware is going to be perfectly portable. Neither C nor > Ada nor Modula2 norcan be portable > (in the sense that you can take ANY program and run it ANYwhere) unless it > prohibits doing machine-dependant things. The original Pascal definition > had this quality, but was also useless for things like writing operating > systems. You are missing one of the points of Ada. Ada helps minimize this by providing a consistent environment around it. Thus machine dependencies are somewhat confined to those writing the interface environment, not the ones writing in the application level. I think one of my points was confused. Obviously programs written at the level that actually interfaces with the hardware will be machine dependent. What I complain about is that application programs written on top of them should not have to worry about machine dependencies. > > Your poke about strong typing and maintainability is at best inflammatory > and in bad taste. I have seen beautiful, easy to read C code, and Pascal >that would curl your hair. Bad programmers can program poorly in any language, > and good programmers can program well in most. I haven't seen any haircurling Pascal yet, but I've seen some bad programs written in Pascal. I've also seen some good C code. But I find that helping others debug code written in C code for some reason always takes longer. Granted I've only used C for about 2 years, but I've used Pascal for about the same amount of time. About the poke about maintainability: unfortunately it is true because I know people who DO practice this where they work. I know someone who names his variables after Dutch cities (hardly mneumonic I'd say). I know some people who take PRIDE in writing the most incomprehensible code they can. Granted I also indulge in writing dense code if challenged to wrote "XXX" in the least number of lines. My 15 line Fortran game of life program comes to mind. But I'd never hand that program in for class or work, unless they were asking for the shortest program. > -- > Marc Mengel "All that is gold does not glitter > ...!ihnp4!cuuxb!mwm Not all those who wander are lost > The old that is strong does not whither > Deep roots are not reached by the frost" > -- J.R.R Tolkein -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet Gillian: "Are you sure you won't change your mind?" Spock: "What's wrong with the one I have?"