HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (peter da silva)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 27 Aug 92 16:20:20 GMT
Organization: Xenix Support, FICC

In article <1992Aug26.075307.15738@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> OK, we all know that there is a segment of our industry cranking out poor
> HLL code, and there is another segment doing a better job.

We do? I can't imagine anyone could address this point unless you identify
these segments.

I do know that one of the segments of the industry that produces crappy HLL
code is extremely familiar with assembly: the hobbyists who are now writing
Mac and Amiga and Windows programs, but who have previously hacked on Apple-2,
Commodore-64, and Atari-800 machines where you HAVE to pretty much use
assembler because they're too small to FIT a decent compiler. The HLL code
I've picked up from BBSes from these people is horrible, even compared to the
stuff in alt.sources. And these are ALL competant assembly programmers.

> If my remark is so self-serving, then let me see either of you defend how
> ignorance of assembler helps your hll skills.

My point would be that it is largely irrelevant. Having a good grounding in
computer design and hardware will help *both* assembly and HLL skills, but
that learning assembly will not in and of itself make you a better programmer.

Correlation is not cause.
-- 
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
From: pt@geovision.gvc.com (Paul Tomblin)
Subject: Re: Good source code to read?
Reply-To: pt@geovision.gvc.com
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario
Date: Tue, 25 Aug 1992 13:03:43 GMT

I'm not a computer science theoretician, just a programmer, but it seems to
me that many of you are missing a very important point.

People seem to be just taking it for granted that this business of comparing
the machine state of machines of speed X and speed X/2 will catch a loop
eventually, and thereby solve the halting problem.

The problem is that the halting problem, as far as I understand it, is not
necessarily about loops.  If I write a program that calculates digits of pi,
for instance, this program will never halt, but it will also never loop.

-- 
Paul Tomblin, pt@geovision.gvc.com (Not an official statement of GVSI)
"All rights and all wrongs have long since blown away/For causes are ashes
were children lie slain/Yet the damed UDL and the cruel IRA/Will tomorrow go
murdering again" - Stan Rogers "The House of Orange"
Newsgroups: alt.folklore.computers
From: eadengle@watcgl.uwaterloo.ca (Ed "Cynwrig" Dengler)
Subject: Re: GOTOs
Organization: University of Waterloo
Date: Thu, 3 Sep 1992 15:47:41 GMT

In article <1992Sep03.104918.10823@bnr.uk> agc@bmdhh298.bnr.ca (Alan Carter) writes:
>
>Or there is the C version:
>
>communicate()
>{
>from_the_top:
>
>   if(!init_rs232()) goto from_the_top;
>
>   if(!init_modem()) goto from_the_top;
>
>   if(!dial_number()) goto from_the_top;
>
>   if(!log_on()) goto from_the_top;
>
>   if(!do_the_business()) goto from_the_top;
>}
>
>This kind of thing is a pig to do with cutesy structured loops, 
>and trying to do it that way makes the danger of introducing bugs 
>much greater. Religious zealots tend to forget that gotos are deprecated
>because they tend to encourage complexity, leading to bugs that stop our
>programs working. No other reason. Where they encourage simplicity they
>help our programs work properly, quickly and are OK.
>

communicate()
{
    while ( TRUE )
    {
        if ( !init_rs232() ) continue;
        if ( !init_modem() ) continue;
        if ( !dial_number() ) continue;
        if ( !log_on() ) continue;
        if ( !do_the_business() ) continue;
        break;
    }
}

but I do admit that <continue> and <break> are types of gotos (though a
structured style of goto, much like if) so how about:

communicate()
{
    while ( TRUE )
    {
       if ( init_rs232() &&
            init_modem() &&
            dial_number() &&
            log_on() &&
            do_the_business() ) break;
    }
}

but even this uses <break> so how about:

communicate()
{
    while ( !init_rs232() ||
            !init_modem() ||
            !dial_number() ||
            !log_on() ||
            !do_the_business() );
}

(And yes, I do realize that I am taking advantage of C's short circuited
boolean evaluation (which is required in all C compilers), but you were
taking advantage of <goto>s).


>   Alan
>

Structured programming versus using <goto>s has long been a very large
debate. Yes, I agree that sometimes <goto>s does make for a more readable
program, however, most programmers I know would not make more readable
code (please remember that the above is a very simple programming
consisting no more than a quarter page, just imagine the havoc of
goto labels throughout a procedure that was about 10 pages long with no
idea where the label for a particular goto is!!).


Ed
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: alt.folklore.computers
Subject: Re: IF-less programming
Date: 4 Sep 1992 12:52:05 -0400
Organization: Berkeley Software Design
NNTP-Posting-Host: rodan.uu.net

In article <Bu14o2.Hvz@world.std.com> dpbsmith@world.std.com (Daniel P. B. Smith) writes:
>[reimplementing code with branches as code with logical states]
>
>So, the way I figure it ... lots of bugs are the result of logic paths not
>taken, right?  So if you eliminate all the IF statements there is only
>one logic path, hence it's easy to get 100% test coverage.

Well, to be precise it is not the "path not taken" but "states never
reached". Thus your approach worth nothing as a tool for improving
reliablity of software. It is widely employed by modern RISC compilers
to eliminate pipeline stalls, though. Such a code can be much faster on
a RISC machine than jump-plagued straightforward conditionals.

--vadim
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: You know when you're hacking too long when...
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 26 Aug 1992 23:19:55 GMT

In article <a=anyyn@lynx.unm.edu> quirk@pioneer.unm.edu (Gym Z. Quirk) writes:

>
>Come to think of it, It's probably some marketoid's miscalculation.
>He included the bun in the list of ingredients (making a total of 10)
>and forgot to consider the consequences of *not* having a bun.
>(Shades of Bloom County - "Chocolate Shake...Hold the cup!")

I have it on the word of a friend that Burger King will sell a loose patty, no
extra charge for it to still be frozen, thus the bun is a deletable option, as
is cooking the meat.

Also, there was a discussion of tri-state ingredients such as none, a little
or a lot of ketchup.  Some people would grade this further to 4 or even 5
"states".

You could also argue "to go" versus "to stay" which gets you different
packaging and the ability to perhaps specify more/different extras to be
included (I want 4 salts, 1 pepper, one lemon juice packet, crackers, a spoon,
a knife, 14 napkins, 1 medium fries and a medium drink and therefore a free
Coke-type glass (that's not a go/stay option per se), N scratch and sniff
game cards (because you can argue that a 1-dollar min purchase has been 
satisfied N times on your $N order).  Also, by ordering additional items, you
become "entitled" to ask for additional items, thus if you order a side salad
you can also ask for various/multiple salad dressings, even though you intend
them for the burger, etc.)

Thus, there are literally multiple Sagans (billions and billions) of possible
ways to "have your way" with Burger King.  (Earth girls are easy, but 
Burger King? :-))

cjl (sex, drugs, rock-n-roll, computers, and food, not necessarily in that
order :-))
Newsgroups: alt.folklore.computers
From: aduell@nyx.cs.du.edu (Tony Duell)
Subject: ICL PERQ ?
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Thu, 27 Aug 92 10:31:03 GMT


( If you know of a more appropriate newsgrop for this, please tell me. I
can't find a comp.sys.icl, or a comp.sys.perq).
  Anyway, I've been given an ICL perq. It came with a A4 monitor,
keyboard, mini-tablet/mouse, and a Summagraphics bit pad 1. I beleive it
to be a perq 2 - it's a flo0r-standing cabinet containing a PSU, 8"
floppy, Winchecter drive, and the following boards : 16K WCS CPU, 1Mbyte
DRAm, EIO (contains a Z80, a couple of microcode sequencers, SIO's, 9914
IEEE 488 chip, etc). I was told by the previous owner that the floppy
doesn't work, and that there was PNX on the hard disk. I also have a PNX
floppy kit, but obviously, I can't use that.
 Now for the problem. I have cabled up everything apart from the
summagraphics tablet. I switch on. The LED display show 010, the
winchester spins up, the dsiplay counts up to 30, asorted bit-map-test
paterns appear on the monitor, and the display then counts up to 158 and
the ssytem hangs. Does anyone have any ideas as where to look next.
Do I need to have the summagraphics connected?
The PNX manual I have lists that as floppy readerror. Why is it trying to
read the floppy? If I remove the data cable from the floppy, and try to
boot, it gets up to 151, which is microcode file length error. Why should
that happen? I suspect that the list of error messages I have is incorrect
for the version of PNX I've got.
 What I really want is the circuit diagrams. I could then attempt to fix
the floppy drive/controller so theat I can boot from floppy. Does anyone
know aof a source for this?
-tony 'PDP11 Hacker' Duell
ard@siva.bris.ac.uk
From: hollombe@polymath.tti.com (The Polymath)
Newsgroups: alt.folklore.computers
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Date: 28 Aug 92 22:14:21 GMT
Organization: The Cat Factory

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

}... I understand
}that GOTOs give you more leeway to write obfuscated spaghetti, but just
}because you *CAN*, doesn't mean you *HAVE TO* :)

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).

I've written one (count 'em) one GOTO in the last 7 years.  I tried hard
to avoid it, but someone else had done something stupid and a GOTO was the
cleanest way to handle it.  I commented the heck out of it and the label
it branched to (and apologized anyway).

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
Subject: Re: Proof of 'Halting Problem'
From: comjohn@ccu1.aukuni.ac.nz (Mr. John T Jensen)
Date: Wed, 26 Aug 1992 00:10:44 GMT
Organization: University of Auckland, New Zealand.

boebert@sctc.com (Earl Boebert) writes:

>Apologies if this is redundant, as I got in this discussion in the
>middle...

>Recent postings have made reference several times to a proof that it
>is impossible to write a program which will tell whether another
>program terminates. The proof in question involves hypothesising such
>a program and then showing that its application to itself leads to a
>contradiction.

>This proof was presented by Strachey in a letter to the (British)
>_Computer Journal_ in January of 1965.  Strachey's letter is somewhat
>ambiguous but implies strongly that the proof originated with Turing
>in 1953, and that the it was being offered publicly for the first
>time.  A rather lively exchange of letters from various correspondents
>ensued throughout 1965. That thread was finished off by a letter from
>Maurer of MIT. In this he offered a proof (which he claimed was
>orginal, and dated to mid-1965) that such a program is possible in
>cases where memory is finite. He also presented an argument that his
>proof was consistent with the Strachey/Turing [?]  result.  You can
>look it all up, if you're interested and your library is good enough
>:-)

All originating from Kurt Goedel, Ueber formal unentscheidbare Saetze der
Principia Mathematica und verwandter Systeme, 1931 (where the 'verwandter
Systeme' include computer programmes).  Title in English means 'On formally
undecidable propositions of certain propositions of [Russell and
Whitehead's] Principia Mathematica and related systems.'  Or, if you
like, it goes back to 'Who shaves the barber?' and 'Cretans are always
liars...' (the latter quoted by St Paul in Titus 1:12, from a
classical author unknown to me).  No programme which can decide whether a
programme IN GENERAL will halt is possible.

jj

John Thayer Jensen                      64 9 373 7599 ext. 7543
Commerce Computer Services              64 9 373 7437 (FAX)
Auckland University                     jt.jensen@aukuni.ac.nz
Private Bag 92019
AUCKLAND
New Zealand
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Good source code to read?
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 29 Aug 1992 14:27:25 GMT

lowen@lorc.UUCP (Lamar Owen) writes:

>I'm not a Computer Science student; I'm an engineer who happens to hack a 
>little (I used to do lots of hacks, but I no longer can take the time...).  So,
>although I've been following this thread, I want to know two things: 
>
>1.) What, exactly, IS a Turing Machine (Note that I have an idea what one is,
>    I just don't know the *rigoroous* CS definition)?

Basically, a Turing machine is a machine with an infinite length tape,
a tape read/write head, and a finite number of states.
Each execution consists of reading the tape symbol under the read/write head,
and then determining on the basis of that symbol and the current state whether
to halt, and if not, which symbol to write and which direction (left or right)
to move the tape read/write head in.

More formally,

A Turing machine is a sextuple (Q, Epsilon, Gamma, B, delta, q0) where
	Q is a finite set of states
	Gamma is a finite set, called the tape alphabet
	B is an element of Gamma, called the blank symbol
	Epsilon is a subset of Gamma - {B} called the input alphabet
	delta is a partial function from Q * Gamma to Q * Gamma * 2
		called the transition function
	q0 is an element of Q, called the start symbol

There are also a lot of variants, eg. two-way tape, n-track machine, n-tape
machine, nondeterministic.

>2.) What is the Halting Problem?  From the articles in this thread thus far, I
>    have a pretty good idea.

Given any Turing machine, and given the initial contents of the tape
(the input must be finite - the rest of the tape will be blank),
determine whether or not the computation will halt.

>3.) (I lied)  Why is this Halting Problem so important?????

(a) We would like to be able to prove that our programs are correct.
    One prerequisite for this is to at least prove that our programs
    halt for a given input. (Some programs are not supposed to halt,
    but most programs are... we would like to be able to prove that those
    in the latter category DO eventually halt for all input.

(b) A lot of other problems can be shown to be undecideable by reducing them
    to the halting 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
Subject: Re: Better dead than IBM
From: alanb@sdl.mdcbbs.com (Alan Braggins)
Date: 28 Aug 92 12:11:22 GMT
Organization: Shape Data (Division of EDS), Cambridge UK
In-reply-to: fstuart@eng.auburn.edu's message of Thu, 27 Aug 1992 16:23:30 GMT

>>>>> On Thu, 27 Aug 1992 16:23:30 GMT, fstuart@eng.auburn.edu (Frank Stuart) said:

> What does IBM *really* stand for?  Let me know if you know the answer and
> I'll post a summary in a week or two.

I've seen a mouse mat with

I thought, therefore
I Bought Macintosh

(about the time IBM was running "I think, therefore IBM" ads - I don't know
whether these were international, hence the explanation)
--
Alan Braggins, Shape Data (A Division of EDS Ltd), Cambridge, UK +44-223-316673
   "Any technology distinguishable from magic is insufficiently advanced."
 "My employer does not necessarily share my views - but I'm working on it."
Newsgroups: alt.folklore.computers,alt.religion.computers
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Good source code to read?
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 26 Aug 1992 14:26:36 GMT

pt@geovision.gvc.com (Paul Tomblin) writes:

>I'm not a computer science theoretician, just a programmer, but it seems to
>me that many of you are missing a very important point.
>
>People seem to be just taking it for granted that this business of comparing
>the machine state of machines of speed X and speed X/2 will catch a loop
>eventually, and thereby solve the halting problem.
>
>The problem is that the halting problem, as far as I understand it, is not
>necessarily about loops.  If I write a program that calculates digits of pi,
>for instance, this program will never halt, but it will also never loop.

That depends on how you write it.
A simple pi program WILL halt eventually, with the message "Out of memory".
A more resiliant pi program will pause occaisionally with messages like
"insert next floppy disk", or "insert previous floppy disk".
So long as you don't mind switching the floppies when requested,
and even going down the street for a new box of disks occaisionally,
then such a program will neither halt nor loop.

-- 
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
From: andy@research.canon.oz.au (Andy Newman)
Subject: Re: Indentation
Organization: Canon Information Systems Research Australia
Date: Fri, 28 Aug 1992 01:17:31 GMT

jimf@centerline.com (Jim Frost) writes:
>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).

The original occam development systems dealt with this by using a
folding editor. Things that got deeply nested were hidden away in
folds. You'd "enter" the fold (create a new editing context with the
fold as the root) rather than "open" the fold (expand the fold within
the current context). Things get a little messy when writing occam in
a non-folding editor though.

>Having used both free-form and layout-dependent languages I'll take
>free-form and try to make they layout obvious, thank you.

Ditto.
-- 
Andy Newman (andy@research.canon.oz.au)		"int - God's own type"
Newsgroups: alt.folklore.computers
From: IQTI400@INDYCMS.IUPUI.EDU (macphil)
Subject: Re: GOTOs
Organization: IUPUI
Date: Thu, 03 Sep 92 14:48:03 EST

In article <1992Sep3.055140.929@news.columbia.edu>
lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
 
>Yes, there are even people advocating structured COBOL :-(.
 
>The same crap all over again.  Instead of a nice simple clean efficient
>routine, you have clumsy confusing inefficient code, which you can mindlessly
>read in small sections, because someone decided that's "better" :-(.
 
>COBOL has traditionally been known as a language which is somewhat clunky
>to get anything done in, but the binary generated for what it does state
>well is excellent and likely compares to good assembler for a slightly
>contrived set of cases.  (But leave it to the structurites to ruin a good
>thing :-(.)
 
I only selected COBOL because I know it's very inefficient in the
realm of HLL:assembler translation, particularly if the ability to
generate assembler output exists and you show hardcare COBOL
programmers just how much code it takes for some of the commonly-used
statements.
 
But in terms of attempting to write "clever" code, one can go too far
and whilst you may feel you are qualified to do so for yourself,
there are still too many in the industry who use GOTOs indiscriminately
and any apparent gains in execution time are lost cutting the
"GO<to>rdian Knot" by deciphering exactly what the code was supposed to
to and how it differs from what it is actually doing.
 
/C regard to the inefficiency of the code the compiler generates, I
agree that should be taken into account, but so too should readability and
ease of maintenance.  You are looking @ what you can accomplish alone
and how you can shave cycles off of a program using inside information, but
I'm looking @ it from the greatest common divisor:  who is most likely
to have to maintain the silly thing?
 
Case in point:
 
If I do this to swap values
 
   XOR R1,R2
   XOR R2,R1
   XOR R1,R2
 
knowing that 1) no intermediate variable is needed and 2) it's fast
because of the opcodes used, that's fine in the assembler world where
one is expected to see such things.  But in other HLL environments,
many are not adept enough to know (or want to) what this does and why
it works.
 
One has to write for their audience and while the position could be taken
the audience is the business or client and giving them the most bang
for their buck, but that's primarily a short-term view.  Considering a
second audience (the poor soul stuck /c maintaining old code) is just
as important and all-too-often overlooked.
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Newsgroups: alt.folklore.computers
Subject: Re: Spaghetti  DO's in FOCAL (was: Re: Branching in HLL vs. Assembler)
Date: 3 Sep 92 17:54:00 GMT
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
News-Software: VAX/VMS VNEWS 1.41

In article <Bu0BEy.IKt@world.std.com>, dpbsmith@world.std.com
 (Daniel P. B. Smith) writes...
>FOCAL was a delightful language. It was current around the mid seventies in
>DEC environments. 
>...
>The statement "DO 3.14" meant to execute the statements on line 3.14 and
>then return.
> 
>The statement "DO 3", however, meant to do group 3 -- that is, execute
>ALL of the statements in group 3, in numerical order, then return.
>...
>I liked FOCAL. FOCAL was neat.  It coulda been a contenda!  If Digital
>had only marketed Intersil-chip PDP-8's ... twelve bits when everyone
>had eight, and OS/8 when everyone had CP/M, and FOCAL when everyone else
>had BASIC... 

	Let everyone remember what oS CP/M was modeled after...

>Of all sad words of tongue or pen, the saddest are these:
>"that's not our marketing strategy."

	Focal was/is available on PDP11s under RSX/IAS, (courtesy of
	Glen Everhart,) and also on the VAX. (As I remember, VAX Focal is
	the first item in the VAX DECUS library.)

   Frank R. Borger - Physicist    __       Internet:  Frank@rover.uchicago.edu
Michael Reese - Univ. of Chicago |___      Phone : 312-791-8075 fax : 567-7455
  Center for Radiation Therapy   | |_) _   
    2929 South Ellis Avenue        | \|_)  You may already be a looser... Form
    Chicago, Illinois 60616           |_)  letter received by R. Dangerfield