HDTenEightyP/NetNews huggingface dataset:
From: bjj@ecl.psu.edu (Bryan J. Jensen)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 20 Aug 92 00:56:06 GMT
Organization: Engineering Computer Lab, Pennsylvania State University

In article <1992Aug18.153447.3104@auto-trol.com>, davgot@auto-trol.com (David Gottner) writes:
> 
> This discussion comes up at least once a year in some newsgroup or another.
> Basically it's the old "C shouldn't be used because C code is buggier than
> other code"
> 
> This attitude IMHO is entirly incorrect.  It is easy to write hard to
> maintain, buggy, cryptic code in **any** language.  C, Ada, assembler,
> Pascal, you name the language.

Politically Correct applies to languages too I guess.  The democrats
would be proud of you.  You are claiming that no aspect of a language
affects code reliability.  So the ADA people were just wasting their time.

> In fact, assembler is notoriously harder to get things right.  I remember that
> when I was doing assembly programming, I would get even simple things wrong,
> like using BLE when I wanted BGT.  (especially on the 68000 where the
> comparison operation worked backwords)  In C I have never gotten a comparison
> operator wrong.

Oh good, this is more reasonable.  You point out, correctly, that the 68000's
reversal of compare (vs. subtract) is a source of bugs.  So why do you assert
that nothing in a high level language can impact on bugs?

If assembler is harder to write then HLL, then you're either user a processor
that really sucks, or you're writing a program that's best done in a HLL.
I find that I turn out assembler lines quicker then HLL lines, so it takes
about the same time to write code to perform a given function.
Newsgroups: alt.folklore.computers
From: naddy@rhrk.uni-kl.de (Christian Weisgerber)
Subject: Re: Colored Boxes .... useless. was "Hacker Test"
Organization: University of Kaiserslautern, Germany
Date: Fri, 14 Aug 1992 10:05:20 GMT

newton@iagu.itd.adelaide.edu.au (Mark Newton) writes:

>>Moral of this story:

        0 Don't get caught.

>>	1 Don't believe what's written in papers
>>	2 Don't tell people you're doing somthing illegal - they
>>	  might tell someone else.

>        3 Don't do something illegal.

-- 
Christian 'naddy' Weisgerber, Germany           naddy@rhrk.uni-kl.de
From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner)
Newsgroups: alt.folklore.computers
Subject: Re: Zuse Computers
Date: 21 Aug 92 09:29:51 GMT
Organization: DB and ES Subdivision, TU Vienna

From article <1hWJ1J#5f6hYNB7NDF93860Kc1cdDm6=esr@snark.thyrsus.com>, by esr@snark.thyrsus.com (Eric S. Raymond):
>> There is a paper by Bauer and Woessner (The Plankalkuel of Konrad
>> Zuse)

> A detail I think I remember about this design, BTW, is that it lacked a
> conditional primitive.  Loops, but no if-then.

I looked the paper up.  According to what they write, there was a
conditional statement (his word for statement was "plan component") in
the form of

condition -.> A

where A is supposed to have been an arbitary statement (the operator
was an arrow with a dot above or below it).  They don't say whether
this also included compound statements.  There was no else part.

-- 
Markus Stumptner                                mst@vexpert.dbai.tuwien.ac.at
University of Technology Vienna                 vexpert!mst@relay.eu.net
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst
From: Tim Phillips
Newsgroups: alt.folklore.computers
Subject: Musical Peripherals
Summary: Musical tape-drives
Date: 13 Aug 92 16:28:36 GMT
Organization: Bloomsbury Computing Consortium

The discussion on IBM1403 music reminds me of a time I worked at an IBM7090 site
with a large number of 729-model 4s. Someone had a program which would play
a selection of Christmas carols on the tape-drives. I don't know the details,
but I guess it was something to do with writing different length records on
the tape and getting the capstan idler to rattle back and forth at the
appropriate speed, so producing the note. (If anyone doesn't know, the
729 used the method of running the tape over an idler-pulley which was
driven by a solenoid and held the tape against the drive-capstan or the
brake, depending.) This program would use any, or all, of the drives,
depending on which were 'ready', so with 12 drives it made one hell of a sound.

(I could write scads more about 7090s and 1401s; IMHO the 7090 was a great
 machine, the 1401 a P.I.T.A.  :-) )
Newsgroups: alt.folklore.computers
From: hgz@cs5.informatik.uni-stuttgart.de (Hans-Georg Zipperer)
Subject: SAGE (was Re: Cathode ray memory)
Organization: Informatik, Uni Stuttgart, W. Germany
Date: Thu, 13 Aug 1992 09:12:59 GMT

In article <1992Aug05.175112.24849@bnr.uk> agc@bmdhh298.bnr.ca (Alan Carter) writes:
...
>I have seen a CRT arrangement in a microfiche production machine that
>had to produce very accurate, if tiny characters for microfilming. The
>electron beam was deflected through the appropriate hole in a plate
>half way along the CRT, which functioned as a stencil and 'cut out' the
>needed pattern. This is a refined version of the classic 'make a Maltese
>Cross' physics experiment. A second set of deflection yolks then picked
>up the beam and sent it where it was needed, where a slow phosphor kept
>it until the tiny screen was full and the photo could be taken. This
>dealt with character-at-a-time and removed the need for a character ROM
>in one swell foop, although the deflection yolk electronics were still
>hairy. This was in about 1977. 
...

Such a CRT is called a 'charactron tube' and was used since the fifties,
not only for microfilming / printing but also as a display. This display
needs no character generator, but it also needs no video memory, as the
picture is stored in the phosphor. In a time when memory was expensive and
complicated, this was a good way to get graphical output from a computer.

This thread leads me to my question: I recently found the Proceedings of
the Eastern Joint Computer Conference 1957 in our library. It contains
a paper on the Semi-Automatic Ground Environment system (SAGE), the air
defense system for the USA in the fifties / sixties. I was very impressed
with the performance of this system and tried to find more information,
but couldn't find any.

I know from the paper that the the area of the USA was divided in about
30 sectors. Each sector was controlled from a central computer. This
computer, the AN/FSQ-7, was a duplex system with 60 000 vacuum tubes and
8 K words of 6 us core memory. It was able to gather data from dozends of
radar stations, compare the position of detected aircraft with the flight
plans of the airlines, display the situation on dozends of consoles with
the above-mentioned charactron tubes, get input from the operators (with
a light pen, no less!) and to guide interceptors or missiles to the selected
targets. All this in real time, of course! The program to do all this was
75 000 instructions! Obviously it was written by Real Programmers. I seem
to remember from some other source that this system, vacuum tubes and all,
was in use until the end of the seventies.

Does anyone have more information on the AN/FSQ-7? Why was it used so long
(if this is really true)? Was the system really as good as it sounds?
-- 
  Hans-Georg Zipperer     Universit"at Stuttgart, Institut f"ur Informatik
  Tel. (0711) 7816-405    e-mail: zipperer@ifi.informatik.uni-stuttgart.de
Newsgroups: alt.folklore.computers
From: reeuwijk@dutentb.et.tudelft.nl (C. van Reeuwijk)
Subject: Re: Indentation
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Thu, 20 Aug 1992 12:36:28 GMT

In <7061@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:

>reeuwijk@dutentb.et.tudelft.nl (C. van Reeuwijk) writes:

>>The main reason is that indentation that was quite logical to me
>>was considered incorrect by Miranda, and this was one of the main
>>sources of coding errors. More generally, I consider layout-dependent
>>semantics revolting.

>I don't know the particulars of Miranda, so it may be that its
>off-side rule is revolting, but can you explain (without flaming) what
>you find so bad about layout-dependent semantics?  Personally, I find
>programs where the lay-out suggests a different grouping than the
>syntax revolting -- though by itself this isn't sufficient to make
>me think that the *languages* which allow this are revolting.

>Take that possibility away and you have one less way of making
>mistakes or confusing readers (see the annual obfuscated C code
>contest).

I guess the word revolting was a bit too strong. The main point is
that I consider layout simply as `the noise characters that the user
may insert to make the program code look nice'. This implies that the
semantics of a piece of source code should not depend on these noise
characters.  However, I agree that a program without or with incorrect
layout is difficult to read.

Nevertheless there are two problems with layout-dependent semantics
1. The language may enforce a certain layout style that may be
   illogical or ugly to some users. Remember that many of the different
   layout styles for C have fanatic advocates.
2. It potentially allows for coding errors through incorrect layout.

Possibly both problems can be resolved in a carefully designed language,
but IMHO it is not worth the effort. The advantages (a few errors through
misleading layout caught and perhaps a few less characters to type) do not
outweight the disadvantages (enforced layout style, restrictions on language
syntax to allow for layout interpretation, more difficult language
implementation).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
C. van Reeuwijk                  e-mail: reeuwijk@et.tudelft.nl
Delft University of Technology   Phone: +15-781429
Dep. of Electronic Engineering   Telefax: +15-785922
Mekelweg 4
2628 CD  Delft, The Netherlands
Newsgroups: alt.folklore.computers,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Xenix Support, FICC
Date: Sat, 15 Aug 1992 22:12:23 GMT

In article <1992Aug14.081326.24359@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> This gets to the heart of the matter: hll programmers depend on the compiler
> to do "magic" of various hues and colors for them; for most of them, they
> haven't a clue as to what's going on,

I take it you include Richard Stallman, Dennis Ritchie, Niclaus Wirth, and
myself in this. We all, so far as I know, typically write in high level
code by preference. Richard Stallman has written a rather good compiler,
Dennis Ritchie invented C, and Niclaus Wirth invented Pascal. I've written
in everything from raw bits to high-level dataflow languages, and implemented
compilers, interpreters, and assemblers... as well as safety critical code
with hard real;-time constraints in assembly and PL/M, and I always pick the
highest level language that will get the job done. Declaring onself an
"assembly programmer" and coding in assembly out of misplaced macho is
simply limiting your options and wasting your time.

Measure twice, code once.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: alt.folklore.computers,comp.unix.misc
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Favorite CPU
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 14 Aug 1992 05:44:35 GMT

In article <id.1N9S.MV7@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Aug8.175306.4732@ecl.psu.edu> bjj@ecl.psu.edu (Bryan J. Jensen) writes:
>> Most C programmers lack the ability or initiative to add optimizations
>> to their C compiler.  More important, how is the C programmer to know
>> that his executable is wretchedly optimized?
>
>It runs too slowly.

Considering the number of buggy C programs out there, how do you expect the
C programer to know if his program runs too slowly when apparently much of
the time he doesn't know if it even *does* run?

cjl
Newsgroups: alt.folklore.computers
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Dinosaurs again (was Re: 4 colors (was dinosaur horsepower))
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Thu, 13 Aug 1992 02:46:01 GMT

bobmon@sandshark.cs.indiana.edu (Bob Montante) writes:

>mcdonald@aries.scs.uiuc.edu (J. D. McDonald) <mcdonald.199@aries.scs.uiuc.edu> :
>| either IBM or the people who controlled them. One submitted "jobs"
>| to them that had to specify maximum amounts of memory to be used (no problem
>| for my jobs) and **maximum possible** times. This was a **BIG** problem!!

>In those days some academic programmers debugged code by almost-haphazard
>alterations, and detected infinite loops ex post facto, too...  on systems
>whose biggest paying customers just wanted to rerun lots of largish but
>predictable programs like payrolls that had priority to the management...

At the Ontario government, we had a long and checkered history of this sort
of thing.  (Most of the problems seem to stem back to an ancient decree that
one ministry, MGS (Government Services) had to own all the computers, so in
this building where everbody outside the machine room worked for MTC, the
guys behind the cipherlock were MGS employees, so they didn't really relate
to _our_ problems).

One thing (a little before my time) was the job submission cards
had time limits, memory limits (later memory _estimates_), they also had a
"due date".  The idea being that if you needed something by say
lunch time, it would sit there waiting at a low priority, but as time got
nearer to the due date, the priority would go up.  This was obviously meant
for something like reports that were needed by a certain time every week.
But then they let the programmers have access to thier own keypunch, instead
of having to submit everything, and being programmers, the first thing they
started doing was punching thier own job cards with a "due date" of 5
minutes in the future.  The operators were not pleased about this
circumvention of the priority system, and so withdrew the "due date"
feature, except for certain people.

MGS claimed that we were one of the few places in the world running
JES3, and they were having trouble getting good support, so they
dropped us back to JES2 about the same time we went to MVS/XA.  Rumour
had it that this excuse was bullshit, but they wanted to make all the
computers the same, and rather than change any JCL in MGS's own
computers, they made everybody else in all the other ministries
change.

-- 
Paul Tomblin, pt@geovision.gvc.com or {uunet,revcan}!geovision!pt
(This is not an official opinion of GeoVision Systems Inc.)
"If you can read this, you're not looking through the Hubble Space Telescope"
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: alt.folklore.computers
Subject: Re: Favorite CPU
Keywords: Burroughs, ALGOL, MCP
Date: 22 Aug 92 11:02:35 GMT
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <610@cpsolv.CPS.COM> rhg@cpsolv.CPS.COM (Richard H. Gumpertz) writes:
>In article <1992Aug07.212531.14134@allegro.com> sieler@allegro.com (Stan Sieler) writes:
>}One last thing...has there *ever* been another multi-processor machine that,
>}*while running*, could be "split" into two entirely independent machines,
>}and then rejoined?  We routinely did this with our dual CPU B7700 in the
>
>This was done routinely with Multics.  We took processors in and out all the
>time for running hardware PM and for testing new versions of the system.

The Tandem T/16 architecture allows several variations on this theme,
none of them, of course, sanctioned by Tandem: if you want, you can
split a running machine into two separate running machines, though you
need to be careful how you do it (like stuffing bits of processes into
a different CPU so they'll be left together; otherwise you could end
up with a split brain problem where both halves of the process think
they're alone in the world and spawn new backups).

In addition, we experimented a while back with the concept of a
`sliding reload' of the system: installing new software is the largest
cause of downtime in a fault-tolerant machine, and to my knowledge
nobody has come up with a good way of reducing it. Our idea, which
worked up to a point, was to take one CPU down, reload with a new
system image, take a second down, reload from the first, and so on
until the complete system was running on the new image.

The most obvious problem with this is that Guardian does not allocate
fixed numbers for system procedure calls - they are dynamically
allocated at sysgen time. This also necessitates a re-fixup of the
objects after a reload, which fortunately is done automatically the
first time the object is used after the reload. Unfortunately, our
sliding reload technique bypassed this.  After getting part of the way
through a sliding reload of a network backbone and discovering that
such simple entry pointsa READ and WRITE (yes, sorry, they shout) no
longer pointed to the same procedure, we decided to can the
experiments until we could persuade Development to come to an
agreement about the idea. We're still waiting (but not holding our
breath).

-- 
Greg Lehey                       | Tel: +49-6637-1488              
LEMIS                            | Fax: +49-6637-1489
Schellnhausen 2, W-6324 Feldatal, Germany
*** NOTE ***: Headers are mangled - reply to grog%lemis@Germany.EU.net
Newsgroups: alt.folklore.computers
From: tvv@tandem.com (Tom Van Vleck)
Subject: 1401
Reply-To: VanVleck_Tom@tandem.com
Organization: Tandem Computers, Inc.
Date: Thu, 13 Aug 1992 20:29:08 GMT

Tim Phillips writes:
|> (I could write scads more about 7090s and 1401s; IMHO the 7090 was a great
|>  machine, the 1401 a P.I.T.A.  :-) )

My opinion's different.  While I loved the 7094, I still think the
1401 was the last computer that Really Worked.  No smoke, no mirrors,
no suspension of disbelief required.  I mean, the 1401 did stuff you
could explain to your mom.  You could step it through the decoding of
instructions, watch it move characters, and so on. None of this
"operating system" stuff, no "libraries," nothing up its sleeve.

-- All together now:
-- "If the B-Field is longer than the A-field, an unequal compare will result."
Tom Van Vleck <vanvleck_tom@tandem.com>
Xref: sparky alt.folklore.computers:12665 comp.human-factors:1800 comp.misc:3259 comp.programming:2359
From: guido@cwi.nl (Guido van Rossum)
Newsgroups: alt.folklore.computers,comp.human-factors,comp.misc,comp.programming
Subject: Re: Indentation
Date: 17 Aug 92 20:44:15 GMT
Followup-To: alt.folklore.computers

reeuwijk@dutentb.et.tudelft.nl (C. van Reeuwijk) writes:

>The main reason is that indentation that was quite logical to me
>was considered incorrect by Miranda, and this was one of the main
>sources of coding errors. More generally, I consider layout-dependent
>semantics revolting.

I don't know the particulars of Miranda, so it may be that its
off-side rule is revolting, but can you explain (without flaming) what
you find so bad about layout-dependent semantics?  Personally, I find
programs where the lay-out suggests a different grouping than the
syntax revolting -- though by itself this isn't sufficient to make
me think that the *languages* which allow this are revolting.

Take that possibility away and you have one less way of making
mistakes or confusing readers (see the annual obfuscated C code
contest).

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Oooooooooh... the cat's eaten it!"
Newsgroups: alt.folklore.computers
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: Computers killing people? (WAS Re: 9 track data storage???)
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Thu, 20 Aug 1992 16:45:15 GMT

sem@mitre.org (Stan McQueen) writes:

>In article <1400@newsserver.cs.uwindsor.ca> oliver@cs.uwindsor.ca (Timothy Oliver) writes:
>> In article <1992Aug12.163016.11684@cbnews.cb.att.com> >
>lbd@cbnews.cb.att.com (linda.b.dunlap) writes: 
[UL about virii from printers - a variation of the old modem-virus thing]
>> No, it is NOT possible.  There are not data lines that go FROM the

>Surely, if I write a program that writes to a serial printer I can
>make that program do something other than reject the above signals.
>Are you saying that it is _impossible_ for the contractor that
>supplied the equipment and the programs to have written the programs
>to behave in any fashion other than the way you have described?

But now you are saying that as well as some sort of virus code in the
printer, there also has to be hidden code in the print driver or something
to upload this damaging code.  If that's the case, why not just put the
damaging code in the printer driver, rather than in the printer?

It seems _pretty_ far fetched to me.  I'd believe a virus in the Iraqi
language version of WordImPerfect before I'd believe a virus in
HP-PhaserJet.  (Printers on stun :-)

-- 
Paul Tomblin, pt@geovision.gvc.com
(This is not an official opinion/statement of GeoVision Systems Inc.)
"Ok dear, want me to call the bike shop and see if they'll sponsor your
mid-life crisis?" "Yeah.  Ask them if they'll upgrade my shifters, too"
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: alt.folklore.computers
Subject: Re: You know you've been hacking too long...
Date: 16 Aug 92 20:03:31 MDT
Organization: Utah State University

In article <77775@ut-emx.uucp>, cblandy@ccwf.cc.utexas.edu (Chris Blandy) writes:
> 
> There is another interesting phenomenon I have noticed with red color 
> persistance.  Look at your favorite LED clock/watch/etc at night and move your
> eyes slowly up-down/back-forth.  The numbers seem to actually move less than
> the clock itself!

Another fun thing to do is look at a CRT or LED while eating crunchy stuff.
Or get things vibrating in front of a CRT; I whacked some tweezers like a
tuning fork and held them in from of a TV one day.

Roger Ivie
ivie@cc.usu.edu
Newsgroups: alt.folklore.computers
From: lbd@cbnews.cb.att.com (linda.b.dunlap)
Subject: Re: Computers killing people?  (WAS Re: 9 track data storage???)
Organization: AT&T Network Systems - Columbus, Ohio
Date: Wed, 12 Aug 1992 16:30:16 GMT

In article <159e2pINN6ic@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
>
>And don't forget 100k (?) Iraquis. All that modern military stuff
>is computer-guided.
>
>--vadim

I remember hearing a rumor that printers sent to Iraq were programmed to
upload (something) into radar installations to give erroneous data.

First, is it possible?  Second, anyone else heard such a thing?
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: alt.folklore.computers
Subject: Re: Nonfiction Computer H
Date: 18 Aug 92 20:36:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

I(L> .My problem with computer history books is that they all seem to be about
   > .the _people_ involved. I want to learn about the _machines_.

"Computer Structures - Readings and Examples" by Bell and Newell.  Broad
spectrum review of a lot of machines.  Includes Whirlwind, Stretch,
LGP-30, etc.

        D/

 * OLX 2.2 * Dick.Zeitlin%acc1bbs@ssr.com
                            
Xref: sparky alt.folklore.computers:12885 comp.unix.misc:3333