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 nor  can 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?"