Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!rehmi
From: rehmi@umcp-cs.UUCP
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <2169@umcp-cs.UUCP>
Date: Thu, 25-Aug-83 22:22:58 EDT
Article-I.D.: umcp-cs.2169
Posted: Thu Aug 25 22:22:58 1983
Date-Received: Sat, 27-Aug-83 17:08:45 EDT
References: <108@csd1.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 73

1) Don't you *dare* mention C within ten words of Pascal, Ada,
   or any other such structured, verbose crocks.

2) I have rarely had any difficulty in porting programs written in
   C across any forms of systems, in the way of i/o, and in fact in
   any other usual ways... The general problem seems to be foolish
   assumptions about the size, order, and meaning in the way
   variables are stored. But this usually occurs in systems-type
   hacks only, because at writing time you might not think it would
   be ported about. "Typical user" code (the latest aaai buzzword!)
   moves with practically no difficulty, easiness being proportional
   to the user's naivete about the underlying machine. Once you
   see the full system below you, you have to restrain yourself from
   bumming every microsecond you can.
   
3) Along with C, you practically always get a Un*x or Un*x-like
   system interface, and always a standard C library. Part of Un*x's
   win comes from the fact that it imposes no structure at all on
   files, and treats them as a seekable byte-stream. The structure
   that results is entirely up to the user and highly flexible. And
   since that structure (if any) is defined in the user's code, that
   means that it should port trivially. And it does. As I said, I
   shift lots of code among about 4 or 5 C's/Unixen all the time,
   and only once did the i/o part break in the port. This was
   because the i/o was being done on the raw disk file.

4) Which brings up another point. For the most part, you can treat
   terminals, printers, and all devices, even the network, as files.
   Of course, you get to send control messages to these special
   device files, with a mechanism separate from the actual i/o, but
   of a similar form. Fred Blonder around here even wrote a short
   (about 20 lines, I believe, when it came down to it)
   pseudo-device which would duplicate a file descriptor you already
   have open, when it was opened. The uses of this are usually when
   a program wants a file name, but you want to feed it input from
   a pipe. [He's umcp-cs!fred, if you want it].

5) Pascal does not map nicely onto any machine I have seen it
   implented on. In all my C's except the 6502 version, C hits it
   off with the underlying machine's architechture and instruction
   set very nicely. C produces tight, fast code.
   
I too once thought Pascal was the world's greatest language, and
thought that C was a hairy, unusable, unreadable language. But many,
if not all of Pascal's constructs are subsumed by C. This I found
out the hard way when my Lisp interpreter was due in 1.5 weeks. All
the poking I had done in Pascal (on bsd Unix, fairly friendly)
didn't work and was so verbose it was confusing to read. Verbose,
constrained, deterministic (Pascal is just a syntax table), and
very unfriendly are the best descriptors of this language. Who gives
a damn whether the array starts at 0, -5, 4 or 100? I am least
confused by having everything start at 0. And what if I want to get
the raw bytes to/from a file? In C, I just slurp some into a buffer
(whose address I can know and twiddle if I so choose). But in
Pascal, it becomes a trick to figure out how *this particular*
implementation will let you do that, if at all. It usually won't.

As for Lisp i/o, it isn't the greatest, but the Franz way of things
seems fine for the moment.

Go away, pascal!

		Not afraid to have an opinion, and back it up,

					-rehmi
-- 

By the fork, spoon, and exec of The Basfour.

Arpa:   rehmi.umcp-cs@udel-relay
Uucp:...!harpo!seismo!umcp-cs!rehmi
     ...!{allegra,brl-bmd}!umcp-cs!rehmi