HDTenEightyP/NetNews huggingface dataset:
From: IQTI400@INDYCMS.IUPUI.EDU (macphil)
Subject: GOTOs
Organization: IUPUI
Date: Mon, 31 Aug 1992 18:05:09 GMT

In article <1992Aug31.160756.23324@news.columbia.edu>
lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
 
>Since you admit you virtually never use GOTO's, you seem not to be able to
>express the intended method for their usage.  The problems you suggest simply
>never happen unless an incompetent programmer creates unnecessary spaghetti.
>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.
 
I think "feature", "GOTO", and "skilled person" create a number of
oxymorons when permuted and combined.
 
There are scenarios where a GOTO is a timesaver in the short-haul and
even more where it's an immediate convenience.  There are very few
situations where they are absolutely, positively necessary.  The
ability to distinguish these situations is fairly rare when it comes
to the off-the-shelf, run-of-the-mill programmer/analyst simply
because most are not *good* programmers writing high-quality code.
 
I'm betting 99+% of COBOL programs used by the average business for
doing nothing more than running various sort/summary/total reports
would be significantly improved by allowing businesses to purchase
a COBOL compiler which flagged "GOTO" as a syntax error.  Similar
arguments could be made for many other languages in their native
habitats.  Only when you get to extremely complex situations could
you start attempting to make serious efforts against this argument.
 
I'm not a COBOL-bigot, I'm just pointing this out as one of the
most-abused languages which can be highly procedural and fairly
easy to read when used properly.
Newsgroups: alt.folklore.computers
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: GOTOs
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 4 Sep 1992 05:23:57 GMT

In article <16857D02D.IQTI400@INDYCMS.IUPUI.EDU> IQTI400@INDYCMS.IUPUI.EDU (macphil) writes:
> 
>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.

But, some C compilers in fact do this very thing.  Ask Richard Stallman.
The people who want to brag about how good they think compilers are won't
agree with you :-).

cjl
From: hugh_davies.wgc1@rx.xerox.com
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM?
Date: 28 Aug 92 07:13:39 GMT

Infernal Brotherhood of Morons.
International Brain Machines (in an SF book I read once.)
It's Being Mended.

Regards,

Hugh.
------------------------------------------------------
Snr. S/ware Engineer, MC&SE, Rank Xerox European Systems Centre, Welwyn Garden City, UK.
From: bob@kc2wz.bubble.org (Bob Billson)
Newsgroups: alt.folklore.computers
Subject: Re: Intel seeking an injucnction!!!!!!!!!
Summary: but not surprising
Date: 23 Aug 92 16:39:18 GMT
Distribution: na
Organization: Color Computer 3: Tandy's 'game' machine

skagos@hercules.cs.uregina.ca (panagiotis skagos (187802923)) says:
>--Quote--
>
>Intel is seeking an injunction against Seeq Inc, Milipitas, California.
>The suit seeks to temporarily bar Seeq from making devices similar to
>Intel's 2864, a 64 K-bit EEPROM (electrically eraseable, programmable
>read-only memory) that may be marketed later this year.  Seeq was started
>by four former Intel staffers who had worked in Intel's  special-products
>division while the 2864 was being developed.  Seeq intends to develop
>nonvolatile memory devices.
>
>
>--BYTE, August 1981, Vol 6 No 8.
>
> ... Frightening, isn't it?

Frightening?  Yes, but not surprising.  Intel has all those lawyers sitting
around doing nothing.  Have to give them something to do before they get
bored. (half :-) )

Between the look-alike suits and this stuff, you would almost wish the Japanese
companies would steal away all of Intel's business.  It seems like Intel is
become a corporate bully just like Ma Bell used to be.  They'll crush anyone
who even remote seems to be in competition.  "We want it ALL!!" should be there
slogan not "Intel Inside".
-- 
  Bob Billson, KC2WZ                          | internet: bob@kc2wz.bubble.org
                                              |           kc2wz@amsat.org
  $nail:  21 Bates Way,  Westfield, NJ 07090  | uucp:     ...!uunet!kc2wz!bob
                  C code.  C code run.  Run code run...<please!>
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 1 Sep 92 21:56:44 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <jimf.715271557@centerline.com> jimf@centerline.com (Jim Frost) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>In article <jimf.714924310@centerline.com> jimf@centerline.com (Jim Frost) writes:
>>>>BTW, if HLL theory is that it abstracts what computers actually do,
>>>>then why the deficiency in so many languages regarding goto?  Do people
>>>>believe that computers lack program control branch instructions?
>>>
>>>Nope, but using abstracted branches (if/else, for, while, repeat, etc)
>>>leads to much easier-to-follow code.  Easier-to-follow code is the
>>>goal in a large project, since the code has to be developed and
>>>maintained by many people.
>
>>The first sentence is an opinion.
>
>Yes, but it's an opinion derived from experience -- both mine and
>others'.
>
>The reason why is simple: using the abstracted flow-control constructs
>leads naturally to self-contained code units, which are easier to
>understand simply because they are relatively small.  This isn't such
>a big deal during initial implementation, but after several people
>have hacked on a program written with goto's you tend to get spaghetti
>-- while abstracted flow control code tends to stay organized as small
>units.  This is also an opinion, but again it's an opinion spoken with
>the voice of experience.
>
>I take it you seldom (if ever) have to deal with code that's needed
>extensive modification by several people over many years.  It didn't
>take a lot of that for me to realize that organization is *everything*
>in a large program if it's to live a long time.  Everything else is
>secondary (including performance for all but a tiny fraction of code).
>Anything that helps naturally organize code is a bonus IMHO.

Sorry to disappoint you there, but I was the 20-somethingth person to work
on some bad code.  The program was poor throughout not due to bad organization
but rather due to sloppy implementation, and not being true to its own form.
OF course organization is important.  Your "brand" of organization is not
unique.

>
>>Using GOTO may be light
>>years more easy to follow or be clearer about what's going on.
>
>True, particularly in bailout situations.  For most processing,
>though, it's not clearer -- and with age and maintenance its clarity
>degrades even more.

IT all depends.  Obfuscating a clearly stated problem into an unnatural
but operational alternate form merely to make it be a bunch of independent
sections doesn't but you either clarity or maintainability depending on
the skills of who follows.  IF the purpose of programming is to write as
badly as the worst person who might be pressed into service is a goal, then
you might be right.  I always assume that I am writing for someone as good
as I am, or is there a problem with that?

cjl
Newsgroups: alt.folklore.computers
From: cflatter@nrao.edu (Chris Flatters)
Subject: Flawchart
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Fri, 28 Aug 1992 02:05:36 GMT

A mention of flowcharts in another posting here touches off a question that
occasionally bugs me when I have nothing better to think about.

In "The Science of Programming" David Gries consistently refers to flawcharts.
Is this strange spelling, with its derogatory overtones, a peculiarity of
Dr. Gries or his proofreader or was it ever in common use?

	Chris Flatters
	cflatter@nrao.edu


Newsgroups: alt.folklore.computers,comp.windows.misc,comp.windows.x,comp.human-factors
From: b1i3297@zeus.tamu.edu (Bryan A. Ignatow)
Subject: Re: GUIs Considered Harmful
Reply-To: b1i3297@zeus.tamu.edu
Organization: Texas A&M University/Academic Computing Services
Date: Thu, 3 Sep 1992 22:38:39 GMT


In article <ABERCROMBIE.92Sep3124717@apphpp10.mdcbbs.com>, abercrombie@mdcbbs.com (Phil Abercrombie) writes:
>
>These days mice seem to be constructed such that if you lift them from
>the desk the ball will stop turning. 
>

What Ball?  My good ol' trusty ball-mouse was replaced with the new and improved
model:  two cylinders.  One cylinder is pitched for the horizontal, the other
one for the vertical.

No wrist flicking done here...

--

  Bryan A. Ignatow                   Bitnet:    b1i3297@tamzeus
  Programmer/Analyst I               Internet:  b1i3297@zeus.tamu.edu
  Academic Computing Services        THEnet:    zeus::b1i3297
  Texas A&M University               YellNet:   (409) 845-9577

  And this just in --
    Guerrilla exchange students have seized the governments of independent
    republics of Latvia, Estonia, and Lithuania and renamed them Metallica,
    Frangelica, and Wrestlemania.
                                 -- CNN, 27-Mar-1992

Xref: sparky alt.folklore.computers:13233 alt.religion.computers:581
From: dhesi@cirrus.com (Rahul Dhesi)
Newsgroups: alt.folklore.computers,alt.religion.computers
Subject: Re: Good source code to read?
Date: 27 Aug 92 21:29:02 GMT
Organization: Cirrus Logic Inc.

In <25310.Aug2406.55.5692@virtualnews.nyu.edu> brnstnd@nyu.edu (D. J.
Bernstein) writes:

>The same solution can be implemented in software. *The halting problem
>is decidable in practice.*

Chess players have sort of known this for years.  A game of chess
always halts!  Even if one must first detect an infinite loop by
recognizing that identical state is reached three times.

(In an ideal world, this could be achieved by having two equivalent
games in progress, one at half the speed of the other.  But nobody
wants to slow down a chess game any more than it already is, so they
just try to remember positions, and do a pretty good job of it.)
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net
From: klaus@diku.dk (Klaus Ole Kristiansen)
Newsgroups: alt.folklore.computers
Subject: Re: What You See Is All You Get
Date: 28 Aug 92 12:02:41 GMT
Organization: Department of Computer Science, U of Copenhagen


A lot of posters have defended You'll See What You'll Get word processors
by listing features that most What You See Is What You Get word processors
lack, but could (and should) have. Those are not really arguments against
the WYSIWYG _idea_. The advantages of WYSIWYG are abvious, are there any
advantages in You'll See What You'll Get?

Klaus O K
From: zzassgl@uts.mcc.ac.uk (Geoff Lane)
Newsgroups: alt.folklore.computers
Subject: Re: What has AI done for me lately?
Date: 27 Aug 92 08:31:22 GMT
Organization: Manchester Computing Centre, Manchester, England, M13 9PL.


There does seem to be a lack of simple, small generic AI modules that can
be built into other systems (like the embedded languages such as tcl.) 


-- 
Geoff. Lane.                                  Janet: zzassgl@uk.ac.mcc.uts
UTS Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
Newsgroups: alt.folklore.computers
From: u734120@bruny.cc.utas.edu.au (John Lamp)
Subject: Re: Non Unix-OS's
Organization: University of Tasmania, Australia.
Date: Sun, 23 Aug 1992 22:17:57 GMT

zrepachol@cc.curtin.edu.au (Paul Repacholi) writes:

>In article <20064@nntp_server.ems.cdc.com>, tbruseha@kafka.ems.cdc.com (Tom Brusehaver) writes:
>...
>> many arguments that IBM did it with a system with a future, but lets
>> face it, if IBM wasn't the name on the box, the PC would have been an
>> also ran, and we would have something better on the desktop today.
>>
>>

>Ah, how quickly they forget... The SMC was never an also-ran. Non-starter would
>have been a better descripion. My memory is general increduality that even IBM
>could pick such a dog of a system.

>~Paul

And how many of us had to, regretfully, abandon far better machines just so
we could make a living using the IBM PC.

In Lament Mode
John
--
   _--_|\             John Lamp, originating in Hobart, Tasmania
  /      \                 Phone: 002 23 1366 - Fax: 002 34 5685
  \_.--._/                   email: u734120@bruny.cc.utas.edu.au
        v <-----------------------------------------------------
From: bruno@broue.rot.qc.ca (Bruno Majewski)
Newsgroups: alt.folklore.computers
Subject: Re: Better dead than IBM
Date: 4 Sep 92 12:47:58 GMT
Distribution: world
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT)
X-Newsreader: Tin 1.1 PL4

John C. Dvorak had a `contest' concerning IBM acronyms in the early `80s
and he got this one he really liked:

Incredibly Belligerent Mossbacks

(he also went on an _IBM songbooks_ trip; some of the songs he dug up
 were quite... interresting, I'd say).

----------------------+-----------------------------------------------------+
Bruno Majewski        | Groupe de Recherche Operationnelle en               |
                      |   Telecommunication (R.O.T.)                        |
bruno@broue.rot.qc.ca +-----------------------------------------------------+
                      | also @: Synerlogic Inc, div. of Andersen Consulting |
There is good beer,   |         Voice: (514) 685-7575                       |
& there is bad beer;  |         FAX  : (514) 685-7692                       |
don't confuse them!   |                                                     |
----------------------+-----------------------------------------------------+
Newsgroups: alt.folklore.computers,alt.folklore.urban
From: bwatson@nyx.cs.du.edu (bruce watson)
Subject: Re: flash pictures of the sunset
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Sat, 29 Aug 92 00:54:10 GMT

In article <1992Aug27.065843.19645@tigger.jvnc.net> keithd@bigguy.timeplex.com (Keith Dickinson) writes:
>In article <1992Aug26.192737.21279@ttinews.tti.com> hollombe@polymath.tti.com (The Polymath) 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. (-:
>
>Actualy on 474's and the such I like to sit a couple of rows behind the wing
>so I can watch it flap. 
>
Flapping beats the hell out of breaking :-)


--
Bruce Watson  wats@nyx.cs.du.edu  Toy Cows, Toy Cows in Africa, Toy Cows
From: bennett@dstos3.dsto.gov.au
Newsgroups: alt.folklore.computers
Subject: Re: Musical Peripherals
Date: 27 Aug 92 15:28:42 GMT
Organization: Defence Science and Technology Organisation

I'm not sure what started this thread, so forgive me if its a repetition...

In the DECUS Library there was a program for playing music on the register 
display lights on a PDP8.  You loaded a paper tape (you know, like a ribbon 
shot to pieces :-) which contained the player program, then there were several 
tunes (Teddy Bears Picnic comes to mind) which were also loaded on paper tape. 
You had to put a radio near the display lights and tune it for best effect.  
It sounded quite good on a classic PDP8, but rather buzzy on a PDP8E.

Regards,

John Bennett                                E-mail: bennett@dstos3.dsto.gov.au
Head, Networks Group                        Phone : +61 8 259 5292
Corporate Information Systems               FAX   : +61 8 259 5537
DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal: Bld 73 Labs Area
AUSTRALIA                                           PO Box 1500 Salisbury 
            "Lord Warden of the Sync Ports"         South Australia  5108
                (DSTO Network Manager)              AUSTRALIA
Newsgroups: alt.folklore.computers
From: IQTI400@INDYCMS.IUPUI.EDU (macphil)
Subject: Re: GOTOs
Organization: IUPUI
Date: Tue, 1 Sep 1992 16:30:25 GMT

In article <15232@umd5.umd.edu>
malmberg@umsa8.umd.edu (Norwin Malmberg) writes:
 
>I have seen all too many COBOL programs where the person had been told
>"You should never use a GOTO".  In general, these programs contain
>strange switches to handle control flow, force you to flip pages all
>over the place when trying to trace how they work (since every little
>thing is handled by a separate paragraph, usually not on the same page),
>and generally are a pain to trace.  They also have a tendancy to exhibit
>strange bugs because of all those switches.
 
Perhaps the person writing the code wasn't particularly able to find
decent algorithms, either.  As I've said before (recently), there is
too much software out there where people took one or two classes and away
they went for a job or were taught by people /c that type of background.
 
>In particular, there is the "read records from a file and process them
>until there are no more records".  Doing this without a GOTO usually
>looks like this:
>
>MOVE "NO" TO NO-MORE-RECORDS.
>PERFORM READ-AND-PROCESS UNTIL NO-MORE-RECORDS = "YES".
>
>READ-AND-PROCESS.
>  READ IN-FILE AT END
>    MOVE "YES" TO NO-MORE-RECORDS.
>  IF NO-MORE-RECORDS NOT = "YES"
>    PERFORM PROCESS-RECORD.
>
>Rather clumsy.  By comparison, it looks fairly clean using a GOTO:
 
 
Sans GOTO and rather clean.  You just change the structure of the loop
a little:
 
    MOVE "NO" TO INPUT-EOF.
    PERFORM READ-INPUT-FILE.
    PERFORM PROCESS-ROUTINE UNTIL INPUT-EOF = "YES".
    ...
 
PROCESS-ROUTINE.
    {do whatever processing}
    PERFORM READ-INPUT-FILE.
 
READ-INPUT-FILE.
    READ INPUT-FILE
       AT END MOVE "YES" TO INPUT-EOF.
 
In essence:
 
Read File
Do While Not( EOF( InputFile ) )
   { process records }
   Read File
End
 
Instead of:
 
Do Until EOF( InputFile ) ;
   Read File ;
   If Not( EOF( InputFile ) )
   Then Process ;
End ;
 
I find the former easier to read than a GOTO.  Once I find a GOTO in
a program which has no need for it (based upon the stated objective)
particularly things like read a file and print it out, then I almost
feel paranoid because I never know what context will suddenly produce
another and another and another.
 
I think that in most cases, if one feels the temptation to GOTO, they
should put down their pencil, go outside, take a deep breath, and
smell the roses until the feeling passes.  GOTO is (almost always)
a copout from seeking a better algorithm.
Xref: sparky alt.folklore.computers:13145 alt.folklore.urban:22154
From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner)
Newsgroups: alt.folklore.computers,alt.folklore.urban
Subject: Re: flash pictures of the sunset
Date: 26 Aug 92 20:34:01 GMT
Organization: DB and ES Subdivision, TU Vienna

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?

I would say it's quite a natural reaction to look out at the weather
conditions.
-- 
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
Newsgroups: alt.folklore.computers
From: jimf@centerline.com (Jim Frost)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Organization: CenterLine Software, Inc.
Date: Tue, 1 Sep 1992 19:45:29 GMT

avg@rodan.UU.NET (Vadim Antonov) writes:
>In article <1992Sep1.083701.2898@pollux.lu.se> magnus@thep.lu.se (Magnus Olsson) writes:
>>Speaking of spaghetti code, one common reason for writing spaghetti
>>code was (is?) the lack of a line-renumbering utility in primitive
>>BASICs...
>>
>> [example deleted]
>>
>>Horrible? Yes, of course, but the alternative (manually renumbering
>>maybe hundreds of lines) would be even worse.

>And writing a 10-lines long program to do it automatically is 
>obviously above mental abilities of both users and authors of
>such BASIC interpreters.

You need a parser to do the renumbering because you have to catch goto
and on-goto operations in the renumbering process as well.  The parser
doesn't need to be terribly complicated, but it's going to be more
than 10 lines of code before you're through, particularly given the
BASIC approach to handling spaces in source code.

So it's not quite that easy ... but it's still not that tough either.

Happy hacking,

jim frost
jimf@centerline.com
Newsgroups: alt.folklore.computers
From: snippe@prl.philips.nl (Snippe DM)
Subject: Re: You know when you're hacking too long when...
Organization: Philips Research Laboratories Eindhoven, Netherlands
Date: Fri, 28 Aug 1992 09:26:22 GMT

aki@cruzio.santa-cruz.ca.us writes:

>In article <1992Aug24.114326.58347@cc.usu.edu>, ivie@cc.usu.edu (CP/M lives!) writes:
>> I saw a billboard for a pizza place the other day that proudly proclaimed
>> "More than 255 choices!" Let's see, that makes eight things that you can
>> either have or not have...


>Those advertising types are always the same.  "more than 255 choices"...
>read:  _EXACTLY_ 256 choices,  unless you count the fact that you don't
>need to buy the pizza as the 257th choice.

Is there a difference between buying a pizza without cheese, tomato, 
olives, onion, [insert other 4 items] and not buying a pizza at all ?
Or do they also serve empty plates there...
If so, do you pay for them?

BTW Have you been using Latex too long when your (handwritten) letters 
include things like \begin{verbatim} ? I recently did that when writing
a letter that included a newspaper article.

Also, when I write algorithms for other people (like the algorithm to bake a cake,
or how to find my house), I don't write first do this and than do that, but:
do_this();
do_that();

It used to be even worse after I had written some Occam programs, lots of nested
SEQ's and PAR's.

Make Pizza:
SEQ
  mix flour and salt
  add water, oil and yeast
  mold this into an elastic dough.
  PAR
    slice tomatoes
    slice pepperoni
    slice mushrooms
    slice onions
    make tomato sauce
  convert dough into pizza
  put tomato sauce on pizza
  PAR
    put tomatoes on pizza
    put pepperoni on pizza
    put mushrooms on pizza
    put onions on pizza
    ALT
      put olives on pizza
      put anchovis on pizza
      put blue cheese on pizza
  put mozzarella on pizza
  put pizza in oven

(You know you've been hacking too long when you think indentation has to
do with pizza's)

-Dick-
Newsgroups: alt.folklore.computers
Subject: Re:  DataPoint (Was: Non Unix-OS's)
From: liam@durie.amigans.gen.nz (Liam Greenwood)
Date: 1 Sep 92 20:52:34 GMT+12
Distribution: world
Organization: It's Home, really...

In article <kcj.714956812@dptspd> kcj@dptspd.sat.datapoint.com (Kevin Jones) writes:
>We're still here and doing much better than some of our former competitors.
>By the way,  RMSXA is to UNIX as UNIX is to TRS80-DOS.
>Thats the only relationshipbetween the two that readily comes to mind.
 It's older?
--
 Liam Greenwood ------ liam@durie.amigans.gen.nz ------ Wanganui, N.Z.
                 Don't tell my Mother I'm a programmer,
               she thinks I'm a piano player in a brothel

Xref: sparky alt.folklore.computers:13523 comp.unix.misc:3480