HDTenEightyP/NetNews huggingface dataset:
From: esr@snark.thyrsus.com (Eric S. Raymond)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 21 Aug 92 16:05:02 GMT
Back-References: <1992Aug21.012026.11684@news.columbia.edu>
Originator: tchrist@pixel.convex.com
X-Disclaimer: This message was written by a user at CONVEX ComputerCorp. The 
 opinions expressed are those of the user andnot necessarily those of CONVEX.

In <1992Aug21.005159.23792@news.eng.convex.com> Tom Christiansen wrote:
> What ridiculous, self-serving, patently false elitism!  There are
> innumerable programmers who write only in HLLs, get their jobs done, and
> go home.  If we were all forced to use assembler, much less programming
> would get done.  That's what compilers are for.

Well said, Tom.

For the record, here's at least one programmer fluent in several assemblers
who agrees with you.  I think there's some truth to Mr. Lasner's claim that
learning assembler *improves* one's HLL, but characterizing anyone who
doesn't know assembler at all as incompetent is absurd.
-- 
					Eric S. Raymond <esr@snark.thyrsus.com>
From: kolstad@cae.wisc.edu (Joel Kolstad)
Newsgroups: alt.folklore.computers
Subject: Re: Multiplex displays (Was Re: You know you've been hacking too long...)
Date: 13 Aug 92 21:30:51 GMT
Organization: U of Wisconsin-Madison College of Engineering

In article <13AUG199210483380@erin.caltech.edu> shoppa@erin.caltech.edu (TIM SHOPPA) writes:
>
>Another neat trick: take a multiplexed LED display and wave it back and forth
>rather quickly.  You'll see the digits, but not necessarily where you might
>usually expect them!

Yes, I built a microprocessor controled alarm clock for a friend and multiplexed
all the digits in order to save I/O pins and power.  It was lots of fun to
hold the clock and wave it up and down in front of your face. :-)

For my high school physics teacher, I made a thing to demonstrate this effect.
I took a long (3' or so) metal rod, and drilled holes for about 20 LEDs.  10
were red, 10 were green.  The red were wired to light with one polarily, and
the green for the opposite.  There was a pivot at the end of the rod that 
feed low voltage AC to the LEDs.  So, you'd take this thing and swing it
around and around and around and get neat little arcs of alternating red and
green.  Fun, fun...

I remember that Sears used to sell a toy that had one long row of LEDs.  It
was shaped like a sword; you'd punch in a message for it to display, and
wave this sword through the air, spelling out the message.  Neat idea!  Probably
not useful for more than a novelty, though.

						---Joel Kolstad
From: rh@smds.com (Richard Harter)
Newsgroups: alt.folklore.computers
Subject: Re: Indentation
Date: 20 Aug 92 04:48:57 GMT
Reply-To: rh@ishmael.UUCP (Richard Harter)
Organization: Software Maintenance & Development Systems, Inc.

In article <jimf.714149982@centerline.com> jimf@centerline.com (Jim Frost) writes:
>guido@cwi.nl (Guido van Rossum) writes:
>>but can you explain (without flaming) what
>>you find so bad about layout-dependent semantics?

>Scoping-by-indentation is probably ok so long as your scope nesting
>doesn't get too deep, but I think it'd get a bit tough to read if you
>have a line complex enough to extend beyond some number of characters
>(eg the width of your screen or printer).

These are good points.  What they really say is that languages which
use scoping-by-indentation have to have other features that support
scoping by indentation.  In particular the language should make it
easy and natural to avoid deep indentation levels and long complex
statements.  Whether one can pull this off depends both on language
features and on the domain of application.


-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Newsgroups: alt.folklore.computers,comp.unix.misc
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Mount Holyoke College
Date: Wed, 19 Aug 1992 18:08:49 GMT

In article <bqt.714224577@Minsk> bqt@Minsk.docs.uu.se (Johnny Billquist) writes:
>I can accept that some people doesn't like assembly language, that's ok.
>I can also accept that hll programmers are just as adept as assembly
>programmers. I cannot accept that a compiler would be smarter than a
>programmer. If you put more abstractions between you and the machine,
>you will have to accept that you get less control over what really happens.

A compiler isn't going to be "smarter" than an assembly language programmer,
but what it lacks in smarts it's going to more than make up in brainless,
methodical, unerring dedication to the task at hand -- the task of translating
a high-level language into a machine executable program.  I would submit to
you that brainless, methodical, unerring dedication is what is needed for 
that task, and in fact, that a compiler is better at it than even a very
smart human... the human may come up with a more clever, smaller, faster
translation, but it'll rarely be worth it, and unlike the compiler, the
human will make mistakes.

Now if you're going to say "write the program in assembly in the first
place," I'd have to point you to the difference between "writing code"
and "designing a program."  I tend to do the second, and if I do a really
good job at it, the code almost writes itself, because there will be a
nice, clean mappaing between the design in my head and a reasonably
high-level language.  The rest I'll delegate to my compiler.

(And, btw., I've debugged enough C programms with a low-level debugger
that generally know pretty well what kind of code my compiler is going
to generate for any given C statement... and I still never have the
urge to improve on it.)
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: alt.folklore.computers
Subject: Re: SAGE
Date: 16 Aug 1992 04:35:58 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


I have a favorite metaphor for SAGE and a lot of other systems: the model
railroad.

A model railroad is a project that can consume any amount of money and
creative effort to build, and is a lot of fun to operate and watch in
operation, but performs no real-world useful function.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

Xref: sparky alt.folklore.computers:12890 alt.folklore.science:3086
From: betsys@cs.umb.edu (Elizabeth Schwartz)
Newsgroups: alt.folklore.computers,alt.folklore.science
Subject: LED's and special effects
Date: 21 Aug 92 23:01:39 GMT
Distribution: alt
Organization: University of Massachusetts at Boston

Speaking of strange effects using red LED's, there's an artist who
makes a very interesting "light sculpture" by playing on this. 

The device is an LED strip about a meter or two long, mounted on a
pole several meters high. The strip is about the size of those little
signs that scroll words using LED's, and flickers at a fast rate. If
you look at it out of the corner of your eye, moving your head
rapidly, the LED afterimages somehow "paint" a picture in the air. The
display cycled through several different pictures.

  There was one of these things on display for First Night, Boston's
New Year's Eve celebration, several years in a row. It was great fun
to see the crowd of people shaking their heads, trying to "see the
elephant." Not everyone could see the pictures and people didnt'
always see the same pictures...

  Anyone out here seen one of these things, or know the theory behind
it? 

Betsy

PS crossposted to alt.folklore.science
--
System Administrator                  Internet: betsys@cs.umb.edu
MACS Dept, UMass/Boston               BITNET:ESCHWARTZ%UMBSKY.DNET@NS.UMB.EDU
100 Morrissy Blvd                     Staccato signals
Boston, MA 02125-3393                      of constant information....
Newsgroups: alt.folklore.computers
Subject: Re: Why do we have _both_ "EDITOR" and "VISUAL" shell variables
From: cwes1@cs.aukuni.ac.nz (Clare West)
Date: Mon, 17 Aug 1992 12:42:20 GMT
Organization: Dept of CompSci, U of Auckland

rbthomas@frogpond.rutgers.edu (Rick Thomas) writes:
>
>lear@dartagnan.rutgers.edu (eliot lear) writes...
>>
>>Yes, this is something I never understood about BSD.  Perhaps there
>>is some historical value in having both VISUAL and EDITOR.  
>
>Yes, something historical...  (A faraway look came into the old man's
>rheumy eyes, as he settles down in his place by the fire...)

[much deleted]

>And so, as a legacy of that time, to remind us that it was not always
>as it is today, we have "EDITOR" for use with hard-copy terminals, and
>"VISUAL" for use with video terminals.

And this provision of two editors is *still* useful today. If I want
to edit a mail message to make *one* trivial change do I really want
to start up EMACS? NO! I start up vi. On the other hand I much prefer
EMACS so for anything more so I endure the start up overheads. And
then again I'm using different terminals all the time and some of them
don't support EMACS (don't ask why not just accept it) whereas vi will
let you do something on just about anything.

end ramble

-- 
Oh, why didn't I listen when they said "Never do a   |  cwes1@cs.aukuni.ac.nz 
 masters and try to have a life at the same time"?   |  clare west
                 BigSis to Chris, Eric and Kristiina
                    Official Welcomer of the RFA
From: fstuart@eng.auburn.edu (Frank Stuart)
Newsgroups: alt.folklore.computers
Subject: Re: Bogosort
Date: 14 Aug 92 00:16:44 GMT
Organization: Auburn University Engineering

In article <4698@blue.cis.pitt.edu.UUCP> jgh1+@pitt.edu (John G Hardie) writes:
>
>I've never been able to come up with a worse algorithm than Bogosort
>(and I've tried).  It's incredible.  A quick calculation (assuming that 

I've never found a better algorithm than bogosort for best case as its
best case is always O(1) (when it 'guesses' right on the first try).  :>

This doesn't make me want to user bogosort; rather it makes me suspcious of
big O comparisons!

Isn't there a provably best (or at least better than most) algorithm out there
that no one uses because when you go to implement it, the constants overwhelm
it?


Frank Stuart           |   Slower traffic keep right.  |  Don't Panic
fstuart@eng.auburn.edu |   MMMMMmmmmm lutefisk.        |  Never moon a werewolf
Xref: sparky alt.folklore.computers:12940 alt.religion.computers:517
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 23 Aug 1992 17:13:39 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

In article <STEVEV.92Aug22195049@miser.uoregon.edu> stevev@miser.uoregon.edu (Steve VanDevender) writes:
>In article <1992Aug23.010444.29042@uwm.edu>
>markh@csd4.csd.uwm.edu (Hunk) writes:
>   The Halting problem related to Turing Machines, and there is
>   no such thing as a Turing Machine.
>
>The only reason there isn't such a thing as an ideal Turing
>machine is that an ideal Turing machine has infinite storage.
>Any digital computer is functionally equivalent to a Turing
>machine with a finite storage tape.  Therefore the halting
>problem still applies to digital computers.  If you write a
>purported halting problem solver for a digital computer, I can
>give you a program that it can't decide the halting status of.

Add "in a time lesser than O(2**capacity of all memory in bits /
machine clock frequency)".

Mark Hunk is right. Finding halting programs on machines with limited
memory is surprisingly simple. Take two identical machines and have one of
them to run at exactly half speed. Then add a device comparing states of
those two machines (all memory bits and all registers (including hidden ones).

Now, load the program to both machines (the comparator will indicate
that states are the same) and start them simultaneously. If your comparator
will ever show 1 then your program will loop forever.

Software implementation is trivial as well, though comparing states
can be, er, real pain. A clever designer could compare only *changed*
registers and memory locations. I guess that such a "halt detector" can
be implemented with overhead not exceeding 1:20 on any real machine.

Please note that the program in question should input nothing (or input
data should be included in the tested program).

Anyway, it is easy to write an endless program which has extremely long
loop (example: incrementing a LONG integer), but still it's halting
property will be detected in some finite time.

--vadim
Newsgroups: alt.folklore.computers
From: dpipes@spica.srg (Dave Pipes x4552)
Subject: Re: SAGE
Organization: just me
Date: Thu, 20 Aug 92 18:11:23 GMT
Followup-To: alt.folklore.computers

In article <16klveINNgj4@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (Jim Haynes) writes:
>
>I have a favorite metaphor for SAGE and a lot of other systems: the model
>railroad.
>
>A model railroad is a project that can consume any amount of money and
>creative effort to build, and is a lot of fun to operate and watch in
>operation, but performs no real-world useful function.

Other than those of calming the builder and impressing others...Not 
unreasonable traits in a strategic weapons control system, I'd say :-).

>-- 
>haynes@cats.ucsc.edu
>haynes@cats.bitnet

David Pipes
robear@digex.com

Xref: sparky alt.folklore.computers:12771 comp.unix.misc:3296
From: bryan@wupost.wustl.edu (bryan o'connor)
Newsgroups: alt.folklore.computers
Subject: Nonfiction Computer History Book List Wanted
Date: 17 Aug 1992 00:45:49 -0500
Organization: Washington University in Saint Louis, MO USA
NNTP-Posting-Host: wupost.wustl.edu

I'm looking for good NONFICTION books about computer history.
(ENIAC to present)

Examples (that I have read):
  Hackers (s.levy)
  Soul of a New Machine [about Data General] (t.kidder)
  Cyberpunk [kevin ??/pengo/rtm] (k.hafner/j.m?)
  the Cuckoos Egg (c.stoll)
  Hard Drive [about Bill Gates] (?)
  Accidental Empires [about Silicon Valley] (r.x.cringley)
  the Devouring Fungus (?)

More examples (what I am looking for)  [Comments anyone?]
  Blue Magic [about IBM pc] (j.chposky/t.leonsis)
  Fumbling the Future [about Xerox Parc] (d.smith/r.alexander)
  Programmers at Work (s.lammers)

Any other good books?  I'm compiling a list.  Send me email with a
description of the book, I will summarize with a list..

thanks,
--bryan
From: aki@cruzio.santa-cruz.ca.us
Newsgroups: alt.folklore.computers
Subject: Re: Computers killing people?  (WAS Re: 9 track data storage???)
Date: Fri, 21 Aug 92 10:29:06 PDT
Reply-To: aki@cruzio.santa-cruz.ca.us

In article <SEM.92Aug19100401@sunny.mitre.org>, 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: 
> 
> >> 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?
> So how do data transfer cables that use the parallel port work?  How
> about add-on hard disk drives for laptop computers that likewise use
> the parallel port?
> 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?
> 


YES, but it sounds so absurd to put the virus into the PRINTER!  Just
think about this.  The virus can't get from the printer into the CPU
_UNLESS_ there is specific software at the CPU end waiting for it,
reading it,  and finally executing it.  There just ain't _any_ piece
of code _anywhere_ to do that;  not with a PRINTER attached anyway.
So the only way for the virus to get from the printer to the CPU is
to modify system code and add a fairly complicated data transfer
system into some piece of software that runs on the CPU and reads the
virus in.   BUT WHY would anyone bother?? If you have your hands on
any program running in the CPU;  why would you put the virus in the
printer?? WHY?   Any program has a zillion places where you can hide
a virus,  cloack it and run when you feel like it.  Nobody needs a
_printer_ for that!

Now my guess is that this printer-virus thing comes from a cubicle
at the CIA or from an overworked newspaper editor who was pi**ed at
not being given the chance to fly to the Gulf to watch the war.
Any takers?

Aki.
-- 
/  Phone: 408-662 9664   Fax: 662 9676  |  "Aki" pronounced: Ah-Key. I know  \ 
\  125 Searidge Ct #D, Aptos, CA 95003  |  what I'm doing most of the time.  /
From: phil@zorch.SF-Bay.ORG (Phil Gustafson)
Newsgroups: alt.folklore.computers
Subject: Re: Early Programable calculators.
Date: 16 Aug 92 15:15:28 GMT
Organization: Famed Parquet Floor

In article <1992Aug16.073512.24453@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <Bt1KyJ.3yE@zorch.SF-Bay.ORG> phil@zorch.SF-Bay.ORG (Phil Gustafson) writes:
>>
>>Mathatron lived in the former Waltham Watch factory building in Waltham,
>>MA.
>
>Say, wasn't that where chocolate-chip cookies were invented?
>
That would be the Toll House in Wollaston, MA.

phil
-- 
|play: phil@zorch.SF-Bay.ORG; {ames|pyramid|vsi1}!zorch!phil                |
|work: (Under Construction)              | Phil Gustafson                   |
| "Never give up!  Never!  Never!  Never!"                                  |
|                                          H. Ross Perot, 1992              |
Newsgroups: alt.folklore.computers
From: tls@panix.com (Thor Lancelot Simon)
Subject: Re: Hacker Test
Date: Thu, 13 Aug 1992 07:22:17 GMT
Organization: PANIX Public Access Unix & Internet, NYC

In article <BsqyEF.FCx@ux1.cso.uiuc.edu> lemson@ux1.cso.uiuc.edu (David Lemson) writes:
>spc@pineal.sci.fau.edu (Sean 'Captain Napalm' Conner) writes:
>>BLOTTO:		Aparently, it can cut phone service off for an entire area 
>If I remember right, blotto box was the one that hooked up either
>120V or 220V from your power company line into the phone line...is

Through a Tesla coil, I believe.  I think the original author of that scheme
was an acquaintance of mine at the time, incidentally.  What a silly,
destructive thing to do. 

-- 
Thor Lancelot Simon	 tls@panix.COM
  "Oh, you have wounded me!  I have very few prejudices, actually.  The
biggest problem is that I am intolerant of fools.  That is why I have
such a low tolerance level for Libertarians."  -- Jim McMaster
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Mon, 17 Aug 1992 04:52:07 GMT

In article <1992Aug16.201123.58191@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>In article <1992Aug15.215427.5726@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>> 
>> a. Non-code can't have any bugs in it.
>
>I'll disagree with this one. When's the last time you had to fix a bug by
>_removing_ code. Obviously, most bugs are in the code that isn't there...
>
>Roger Ivie
>ivie@cc.usu.edu

This sorta skirts the issue, but I have fixed some (other people's) code that
was wrong because it had a typo of the current line accidentally repeated so
you got two copies, and it mattered, and another case where there were two
lines commented out with a line in front saying to uncomment only one.  Neither
were set so it didn't work, yet no errors.

The second type is avoidable if you put in constraining conditionals that
force errors when the constraints are exceeded.  In this case, a bunch of
conditionals are used to force exactly one parameter to be set to one while
the rest are zero.  Merely add all of the parameters up and complain if
the sum is different from 0001 with an error-producing line.  Also, to be
picky, ensure that all of them are positive (two's complement assumed!) so
they can't be cancelling out.  (There aren't enough of them to overflow!)

So, this is a case where you have to remove code to get it to work because
there is too much code, and the second is where you have to remove a
comment, although in the process some code is created.


The PDP-12 LAP6-DIAL operating system supports a quirky conditional:

ASMSKP N

where N is the number of source lines (*not source statements!) to ignore if 
the condition succeeds.  (This example is unconditional, but there are
arithmetic and logical variants, etc.)  (N is a general expression.)

Thus, the number of blank lines or comments matters here!

cjl
Xref: sparky alt.folklore.computers:12707 comp.unix.misc:3270
From: davgot@auto-trol.com (David Gottner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 18 Aug 92 15:34:47 GMT
Organization: Auto-trol Technology Corporation

In article <1992Aug18.052636.23004@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>I think others may have differing opinions about the statistics behind that.
>I offered an open challenge for someone to quantify how many bugs they might
>attribute to various language-based implementations of any code released by
>any author on any basis, to rate the use of the various languages as that
>pertains to reliability of product.  I don't see anyone challenging my
>opinion that C would come in dead last.  I would think that writing buggy
>code in C qualifies at least in part as not knowing what goes on under
>the hood so to speak.  Presumably all of these "experts" you claim exist 
>(aren't they "experts" since they aren't as ignorant as I make out?) had
>full access to all of the associated wonderful development tools to 
>eliminate all known problems, etc., so if so, then why the failing grade?
>
>I have friends who are of the opinion that C is more like a demented
>macro assembler being misused with the "wrong" macroes, but I won't let
>my personal friends bias the count here.
>
>cjl

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.

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.

Since most code is written in C now days, there is more buggy C code.  If
most code was written in Ada, people would be complaining that the Ada language
led to buggy code.  (Or any language, put your favorite language here)

-- 
Amrit Prem			|
davgot@auto-trol.com		| This area is intentionally left blank
{...}ncar!ico!auto-trol!younam 	|
Xref: sparky alt.folklore.computers:12643 comp.edu:1285 comp.human-factors:1796 comp.misc:3253 comp.programming:2351