HDTenEightyP/NetNews huggingface dataset:
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: If parallel ports are unidirectional, how can PostScript work?
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 23 Aug 1992 21:23:57 GMT

This brings up a question I've never had fully answered.  My introduction
to PostScript was via Macs, AppleTalk, and LaserWriters.  The documentation
for PostScript seemed to be very clear on one point: the interface to
a PostScript printer HAS to be bidirectional and HAS to pay attention to
what the printer sends back.  Otherwise errors can't be detected and
jobs will simply be aborted with no user cues as to what went wrong.  
Just as you CAN print SORT OF successfully on a printer that uses X/ON
X/OFF flow control without sensing the flow control characters -- if it
has a big buffer -- and the baud rate isn't too high -- and you don't
send escape sequences that make it do anything time-consuming, you CAN
print SORT OF successfully on a PS printer without reading what comes back
under normal conditions -- but, it seemed clear, and at the time Adobe
confirmed it, you could NEVER print RELIABLY that way.

Sure enough, when we tried to adapt the LaserWriters to the VAX, the
standard printer spooler stuff wasn't expecting anything back (except
X/ON X/OFF flow control), and we found we could SORTA print short to
medium-size jobs but would often experience undiagnosable stalls, resets,
etc. on long ones.

A few years go by.  I see PostScript printers on PC parallel ports.  And
I see them on LAN's.  I ask the PC people how the problem of reading the
feedback that comes back from the printer is handled.  They say: "Huh?
It's a printer.  It's output only. Nothing comes back."

Also, there are fair number of stalled and mysteriously aborted jobs.

So the question is: did I seriously misunderstand something?  Or is there,
in fact, a basic conflict between the design of PostScript and the design
of a) PC parallel ports, and b) PC LANs which is, in  fact, causing
problems that nobody is addressing?

I have YET to see a PostScript error reported in, say, a Windows dialog
box.  I have also yet to complete a printout of all of the 120-page
manual I'm working on in one piece (it always stalls around page 80 and I
always have to do two print jobs, one from page 1 to infinity, then a
second from page where-it-stalled to infinity)...


-- 
Daniel P. B. Smith
dpbsmith@world.std.com
Newsgroups: alt.folklore.computers,comp.unix.misc
From: hollombe@polymath.tti.com (The Polymath)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: The Cat Factory
Date: Thu, 27 Aug 1992 20:50:33 GMT

In article <1992Aug26.063534.14180@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
}In article <id.J2JS.8CD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

}>Jerry, I honestly have no idea what I've said that you're objecting to. Every
}>thing you've said simply reinforces my point: a programmer who doesn't know
}>a variety of languages, and who can't learn new ones quickly, is a poor sort
}>of programmer indeed. Whether he's an "assembly programmer", a "C programmer",
}>a "COBOL programmer", or whatever.
}>
}>BECAUSE the people who pay the piper call the tune.
}>
}>Are we in violent agreement, or am I missing something subtle here?
}
}I certainly don't have any disagreement with this statement, except for:
}
}The people who pay the piper may be being manipulated by people with their
}own agendas.  The wrong language may be being forced onto the job specification
}to the point of excluding legitimate alternatives.  I have seen this over the
}years done as a sleazy attempt to guarantee that contracts can only be
}fulfilled by certain "blessed" individuals/companies in certain specific
}situations that were clearly unethical, but it happens.

Good heavens.  It seems we're _all_ in violent agreement.  How ... er ...
boring. (-:

BTW, for historical reasons that were stupid in the first place, I'm
currently being forced to program in a vhll that is badly designed,
marginally maintained and barely adequate to the purpose.  This is what
happens when managers try to replace programmers with non-programmers.
(It didn't work, but the programmers are stuck with the result).

Related(?) anecdote:

I've heard of one defense contract where the DOD specified the code was to
be written in FORTRAN or assembler.  The contractor wanted to do it in
Pascal.  Resolution:  The program was written in Pascal.  When it was all
done and ready to be handed off, they turned on the assembly code printout
switch on the compiler and told the DOD the resulting output was the
source.

Your tax dollars at work ...

The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@polymath.tti.com)
Head Robot Wrangler at Citicorp                   Turn the rascals out!
3100 Ocean Park Blvd.   (310) 450-9111, x2483     No incumbents in '92!
Santa Monica, CA  90405
Newsgroups: alt.folklore.computers
From: smith@sctc.com (Rick Smith)
Subject: Re: An interesting book for the ASM vs. HLL argument
Organization: SCTC
Date: Wed, 2 Sep 1992 15:41:44 GMT

rfd@po.CWRU.Edu (Richard F. Drushel) writes about Sammet's classic book;

>	Sammet, Jean E. (1969).  Programming languages:  History
>and fundamentals.  Prentice-Hall (Englewood Cliffs, NJ).  785 pp.
>Library of Congress # 68-28110.

>	For all you COBOL-haters, Jean Sammet was chair of the
>committee responsible for writing the COBOL language specs.

Actually, one of several. Most people credit Grace Hopper's leadership
of the COBOL Short Range Task Force for the language as it appeared.

>... over 100 programming languages.  Most of these are dead by now, and
>in 1969 there was no C, Pascal, Modula2, or Ada.  But I still find
>the information fascinating.  For instance, at the very end of the
>book, Sammet cautiously tenders a few speculations about the future
>of programming languages.  Her guess was that FORTRAN and COBOL
>would probably survive, with FORTRAN on top, but that there was a
>chance that JOVIAL would conquer both of them.  JOVIAL was the big
>Air Force language into the late 1970s; what happened to it?  

JOVIAL was an Algol dialect. Pascal was based on Algol concepts, as
was C (via a less direct route).

I believe the thing that really fueled C and Pascal was that both
compilers were available in (relatively) portable implementations in
their own laguage. Wirth's original Pascal-in-Pascal was the basis for
most of the implementations (commercial or not) in the '70s. In
regards to C, educational institutions back then could get Unix source
code licenses for a song. Many did, and ported it to other hosts.  I
also remember some pointed rumors in the early 80s about various home
computer software houses that got started by pirating the Unix
portable C compiler and adapting it to run on Z80s and such.

Rick.
smith@sctc.com          arden hills, minnesota
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: alt.folklore.computers
Subject: Re: Apple ///
Date: 28 Aug 92 06:53:01 GMT
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Aug27.133948.14444@msuinfo.cl.msu.edu> witczak@frith.egr.msu.edu (Mark Witczak) writes:
>If you're having problems with the machine hiccuping (periodic software glitches),
>raise the machine about a foot off the floor and drop it. Repeat if necessary.

This method was also used by Tandem with the 6520 terminal (back in
the late 70s). I don't know if it was official, but it worked
-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers get mangled at backbone - reply to grog%lemis@Germany.EU.net
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Mon, 31 Aug 1992 05:24:23 GMT

In article <1992Aug27.212752.14772@news.uiowa.edu> dsiebert@icaen.uiowa.edu (Doug Siebert) writes:

>                                                              The reason is an
>outgrowth of the idea of mathematically "proving" programs correct.  Any code
>written with the traditional "structured" constructs can be mathematically
>proven correct, but if there is a GOTO in that code, forget it!

>                                                       Currently it is totally
>impractical to prove any but the tiniest programs correct, but it is possible
>that at some point a combination of new language designs and automation will
>make it feasible for reasonable-sized programs.

So, programs should *today* be written because *someday* *maybe* it might be
able to be done?  This is a *current reason* to restrict programming methods?

>
>However, I'm sure that purists like Mr. Lasner will still claim assembly is
>the best language and that writing provably correct programs in assembly is
>possible if you work hard enough at it :-)

If I'm a "purist" then what would you call the other people? :-)

cjl
Newsgroups: alt.folklore.computers
From: aeg03@rrz.uni-koeln.de (Jan T. Kim)
Subject: Re: You know you've been using X too long...
Organization: Regional Computing Center, University of Cologne, F. R. Germany
Date: Thu, 03 Sep 92 14:28:29 GMT

In <1992Aug30.132018.14433@geovision.gvc.com> pt@geovision.gvc.com (Paul Tomblin) writes:

>I think you've found what I've always found: I'm unable to come up with a
>better colour selection than the developer's defaults.  For instance, when I
>had a DecStation on my desk, I used the Mwm file that came with it, with
>only minor tweaking.  When I tried to get radical in changing the colours, I
>ended up with something that I hated even more than the defaults.  Now I've
>got a SPARC, I'm not even going to _try_ and change the open-windows
>defaults.

If you want to be able to find a better color  setting  than  the
default  one  of  a  system,  just  try  an Atari ST with a color
monitor.

Greetinx, Jan

 +- Jan Kim -- X.400:    S=kim;OU=vax;O=mpiz-koeln;P=mpg;A=dbp;C=de -+
 |             Internet: kim@vax.mpiz-koeln.mpg.dbp.de               |
 |                                                                   |
 *----=<  hierarchical systems are for files, not for humans  >=-----*
From: Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs)
Newsgroups: alt.folklore.computers
Subject: Branching in HLL vs. Assembler (was Re: The need for an asse
Date: 27 Aug 92 21:16:07 GMT
Organization: MIND LINK! - British Columbia, Canada

In article <1992Aug27.135129.24542@usenet.ins.cwru.edu> rfd@po.CWRU.Edu
(Richard F. Drushel) writes:

>        And what is a CALL subroutine but a hardware-implemented, special
>case of JP subroutine / do subroutine / JP back whence we came?

     Exactly!  A subroutine call is nothing more than a GOTO paired
with a "come from".  :-)  It reminds me of the heyday of the
Structured Programming revolution back in the '70s, when zealots
rallied behind Edsger Dijkstra and went on witch hunts against the
dreaded GOTO.  In COBOL shops across the land, GOTOs were ruthlessly
rooted out and replaced by PERFORMs.  But since COBOL wasn't
designed to work without GOTO, the results were often horrible.
You could still wind up with spaghetti code - it's just that you
now used double strands.

     At least newer languages allow you to write GOTOless code
without getting bent out of shape.

     My personal philosophy is to try to get rid of not GOTOs, but
labels instead.  This better encourages good program structure, and
minimizes not only GOTOs but wanton subroutine calls as well.  And
it works in any language, even assembly.

Charlie_Gibbs@mindlink.bc.ca
Elevator music brings me down.
Newsgroups: alt.folklore.computers
From: hollombe@polymath.tti.com (The Polymath)
Subject: Re: You know when you're hacking too long when...
Keywords: hacking
Organization: The Cat Factory
Date: Tue, 25 Aug 1992 19:55:42 GMT

In article <1992Aug24.132633.2501@NeoSoft.com> claird@NeoSoft.com (Cameron Laird) writes:
		       .
}Self-reporting of nerd behavior:  when I use
}a microwave oven, I make a point of setting
}it to such a time as 1:80 (one minute and
}eighty seconds).  You get the idea.

I always set mine to 4 seconds above the cooking time I want.  That's how
long it takes to warm up before it turns on the power.

The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@polymath.tti.com)
Head Robot Wrangler at Citicorp                   Turn the rascals out!
3100 Ocean Park Blvd.   (310) 450-9111, x2483     No incumbents in '92!
Santa Monica, CA  90405
From: jeffj@panix.com (Jeff Jonas)
Newsgroups: alt.folklore.computers
Subject: Re: SAGE
Summary: parts are also on display at IBM Kingston
Date: 1 Sep 92 04:06:57 GMT
Organization: Jeff's House of Electronic Parts

In article <3809.168.uupcb@ssr.com> dick.zeitlin%acc1bbs@ssr.com
	(Dick Zeitlin)  writes:
>PG> .The last SAGE was retired and declassified in 1983(!), and large chunks of
>  > .it are on display at the Computer Museum in Boston.  Well worth a visit.

There are parts of a SAGE system on display at the IBM Kingston
facility.  Some is in the lobby, some in the Historical Society display
with other machines that were produced at the IBM Kingston facility.
Such as Browning rifles during WWII,
IBM 360 consoles and core planes,
IBM timeclocks and even an IBM cheese slicer
(Dayton scale was one of the 3 companies that formed IBM).

I never got a copy of the IBM songbook (featuring "Ever Onward",
the IBM rally song) but it wsa display.

>I've got pieces from the SAGE system from McGuire AFB, which I think was
>the first SAGE.  Light Gun, assorted bits and pieces, and, most
>cherished, the "go button" from the Master Director's console.  (The
>safety-wired/covered button that says 'this is no drill!')

Ooooh, I'm jealous!
I only have pieces of the IBM 1130 I used in college and some of
an IBM 1620.  The emergency pull is the most desirable part since it
looks the same as on the mainframes (both IBM and Amdahl).
I pushed christmas lights in the front panel so it lights up again.
(of course, I was sure to have the 'wait' light illuminated).
I have a nice assortment of core memory from all the equipment
I got to pull apart in college.

- Jeffrey Jonas
jeffj@synsys.uucp

Jeff's core museum - admission 2 bits
Newsgroups: alt.folklore.computers,bit.listserv.win3-l,comp.os.ms-windows.apps,comp.os.ms-windows.misc
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 26 Aug 1992 16:19:51 GMT

alanb@sdl.mdcbbs.com (Alan Braggins) writes:

>>>>>> On Mon, 24 Aug 1992 20:34:11 GMT, jimf@centerline.com (Jim Frost) said:
>
>> ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>>>Nonsense. There are many (efficient!) things you can do in assembler
>>>but not in C. And I'm sure even the best optimizing compilers don't
>>>know all the tricks you can pull in assembler.
>>>- If I call any subroutine or function in C, a large set of registers
>>>  will be saved in some fashion, often unneccesarily.
>
>> False.  A good C compiler will never save a register it doesn't use.
>> Further, it will omit frame generation if a frame is unnecessary or do
>> any number of other function-calling optimizations.
>
>However, a human can also not save a register which _is_ used if he knows
>the function being called won't touch it. Whether this is worth the
>maintenence problems caused is another question...
>The few functions where it might be should probably be in the same compilation
>unit, in which case an optimiser could spot it.

It's been said before, but I'll say it again: ANYTHING that an assembly
language programmer can do, a compiler can do to, and probably does
already. If it doesn't yet, it may well do so tommorrow, and you only
have to improve the compiler ONCE and it will keep optimizing your
programs as long as you keep writing them.

In this particular case, there are LOTS of compilers that do global
register optimization (across multiple compilation units). What's more,
if you get the compiler to do it, then there is NO maintenance problem.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: alt.folklore.computers,alt.folklore.urban
From: hollombe@polymath.tti.com (The Polymath)
Subject: Re: flash pictures of the sunset
Organization: The Cat Factory
Date: Wed, 26 Aug 1992 19:27:37 GMT

In article <25723@dog.ee.lbl.gov> TWChan@lbl.gov (Terry Chan) writes:
}... Why is it
}when the airplane shakes a bit and the pilot announces that we're flying
}through some turbulence that people look out the window?  Do they
}expect to see speed bumps or something?

No, no, no.  We're checking the wings for loose rivets. (-:

The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@polymath.tti.com)
Head Robot Wrangler at Citicorp                   Turn the rascals out!
3100 Ocean Park Blvd.   (310) 450-9111, x2483     No incumbents in '92!
Santa Monica, CA  90405
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 1 Sep 1992 23:14:52 GMT

In article <samw.715295862@bucket> samw@bucket.rain.com (Sam Warden) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>>Don't knock a feature which is useful in the hands of a skilled person merely
>>because you don't use it or others who shouldn't do try and wind up using it
>>in a less-than-useful manner.
>
>>cjl
> 
>I think this is worth pulling out for special emphasis.  It sums up 
>anything I might have to say about assembly language, C, HLLs, GOTOs,
>the command line, GUIs, scalpels, or chainsaws.  :-)
> 
>I hereby stop following this thread.  The penguin on your television
>set will now explode.

Is that a penguin on the 'telly?

I guess, in the style of the phrase attributed to Harry Truman, his kitchen
got too hot. :-)

cj ("Give em Hell, Harry") l
From: ddb@tdkt.kksys.com (David Dyer-Bennet)
Sender: FredGate@tdkt.kksys.com
Newsgroups: alt.folklore.computers
Subject: The Need For An Assembler
Date: Mon, 24 Aug 1992 13:09:18 -0600

 SW> A chainsaw is the only tool anyone will ever need.
 SW> No! A scalpel is the only tool anyone will ever need!
 SW> Is not!
 SW> Is so!
 SW> (fight ensues)

Yes.  But which is which?

 * Origin: Terraboard, Mpls MN: Home of the SF echo (1:282/341.0)
Newsgroups: alt.folklore.computers
From: magnus@thep.lu.se (Magnus Olsson)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Organization: Theoretical Physics, Lund University, Sweden
Date: Tue, 1 Sep 1992 08:37:01 GMT

In article <1992Aug31.160756.23324@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <1992Aug28.221421.18061@ttinews.tti.com> hollombe@polymath.tti.com (The Polymath) writes:
>>
>>The problem isn't so much with the GOTO as with the lack of a COMEFROM.
>>
>>Suppose you're neck deep in the bowels of a multi-megabyte system and you
>>come across a label in the source code.  There could be any number of
>>GOTOs in the code that branch to that label.  Even if the original
>>programmer was kind enough to provide a comment listing them all (I've
>>only seen that once and I wrote it), figuring out which particular one
>>you're concerned about can be a nightmare. (In a language like BASIC the
>>problem is even worse since _every line_ can be the target of an arbitrary
>>number of GOTOs).
>
>a)	That's ludicrous since no code does a GOTO the middle of a module
>therefore the largest thing to worry about is the size of the module you
>are working on where the label exists.

With all respect for your great experience, have you ever programmed
in BASIC? In BASIC (I'm talking about real, honest-to-God, macho
interpreted BASIC, with one-character identifiers, and not one of
those wimpy, effeminate pseudo-Pascals marketed today), your whole
program is one big module, and you can jump literally *anywhere*. Of
course, you probably wouldn't be able to use those BASICs to write
multi-megabyte modules, but even a 64 K module can be pretty ard to
debug... 

For example, it was common practice among certain programmers to write
"clever" code like this (and this is just a simplified example, actual
code would probably look much worse):

1000 FOR I=1 TO 1000 
1010 REM do something here
1500 M=K
1510 NEXT
1600 RETURN
...

2000 GOSUB 9876

...

9876 IF J=K THEN 9900
9880 FOR M=1 TO 100
9890 GOTO 1500
9900 RETURN


Now, to quote one of the sacred annals of hackerdom (*), "put *that*
in Pascal's pipe and smoke it!"

(Note especially that the NEXT statement in line 1510 refers to
different control variables depending on from where the loop was
entered). 

(*): I'm of course referring to "Real Programmers don't Write Pascal".


Speaking of spaghetti code, one common reason for writing spaghetti
code was (is?) the lack of a line-renumbering utility in primitive
BASICs: suppose you had written something like

100 A=B
102 X=Y

and then realized you needed to fit another ten line of code between
lines 100 and 102? Well, of course you wrote something like

100 A=B
101 GOTO 1000
102 X=Y


1000 REM put extra code here
...
1100 GOTO 102


Horrible? Yes, of course, but the alternative (manually renumbering
maybe hundreds of lines) would be even worse.



Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<           
Internet: magnus@thep.lu.se     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q






Newsgroups: alt.folklore.computers
From: ben@ccbenj.technion.ac.il (Ben Pashkoff)
Subject: Re: Nonfiction Computer History Book List Wanted
Reply-To: ben@ccbenj.technion.ac.il (Ben Pashkoff)
Organization: Technion IIT, Haifa Israel
Date: Tue, 25 Aug 1992 07:15:58 GMT


There is also a very god history of AI, that encompasses most of the history of
Computing entitled Machines Who Think by McCorduck. The bibliography for this
book alone is worth reading.
I would also include Fumbling the Future by Smith, Douglas K.
--
________________________________________________________________________
|            Ben Pashkoff                 BEN@VMSA.TECHNION.AC.IL      |
|                                                                      |
| "There is nothing better for the body than silence." Pirke Avot 1:17 |
|______________________________________________________________________|
From: 9125113g@lux.latrobe.edu.au (Mitch Davis)
Newsgroups: alt.folklore.computers
Subject: Re: Coke machine at CMU
Date: 4 Sep 92 05:33:12 GMT
Organization: La Trobe University

In article <BtxJ98.Iw6@xcluud.sccsi.com> paul@xcluud.sccsi.com (Paul Hutmacher) writes:
>In article <87501@netnews.upenn.edu> jarnot@kin.lap.upenn.edu (Kevin J. Jarnot) writes:
>>I have recently heard of a Coke machine at CMU that is connected to the 
>>Internet.  Anyone have the whole story???
>
>I'd like the ip address so I could ftp a Coke or something.

From "The Hacker Test":

 > 0023 Have you ever wanted to download pizza?

I know what you mean...

Mitch.
Newsgroups: alt.folklore.computers
From: rogerj@aix.rpi.edu (Jeffrey C. Rogers)
Subject: Re: You know when you're hacking too long when...
Date: Wed, 26 Aug 1992 20:59:49 GMT

bwatson@nyx.cs.du.edu (bruce watson) writes:

>But at MacDonalds' you don't get a choice. The Big Mac comes only one way; 
>like it or not.

Actually, I think they will change the ingredients upon request (as I've
heard from friends who work there), but they don't advertise that fact.

Diversion

Newsgroups: alt.folklore.computers