Who originated the phrase "user-friendly"?

[Berkeley Brett]

I hope you are all well & in good spirits.

I wonder, is there a general consensus on who originated the phrase
"user-friendly"?

Thanks in advance for anything you may care to share....

--
Brett (in Berkeley, California, USA)
http://www.ForeverFunds.org/
My plan for erasing poverty from the world with micro-endowments that
"give" forever into the future

[Dan Espen]

Berkeley Brett <roya...@gmail.com> writes:

> I hope you are all well & in good spirits.
>
> I wonder, is there a general consensus on who originated the phrase
> "user-friendly"?
>
> Thanks in advance for anything you may care to share....

I did, 1964.

Proof? Don't need to stinkin proof.

--
Dan Espen

[Anne & Lynn Wheeler]

well before this 30yr old email

Date: 09/21/81 20:32:21
From: wheeler

ah, but most ot those systems were also developed as end-user &/or
time-sharing systems. They have two characteristics, one is user
firendly and the other is ease of programming. The first may have in
fact required the later. The big, batch systems all have seemed to
have lost sight of ease of programming somewhere along the line . . .
that is going to be more and more dominent theme as time goes along.
Again the statement that the current time-sharing systems are going to
dry up and blow away (except for use on the dedicated, end user
machines) while the centralized complexes return to be the exclusive
domain of the big, batch operating systems. I contend that the big,
batch operating systesm also dry up and blow away (completely( and one
of the current (or possibly new one designed along the lines of a
current one) end-user, user friendly systems evolve to take over the
centralized batch machines. (Conceptually) simple interfaces between
programs and domains are apparently an absolute requirement on
end-user, user friendly systems. They will also be required in the
big, batch operating centralized machines . . . hardware costs are
coming down dramatically & application program development costs are
sky rocketing.

... snip ...

aka mega-datacenters, cloud computing, etc


--
virtualization experience starting Jan1968, online at home since Mar1970

[hanc...@bbs.cpcn.com]

On Jan 3, 2:10 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
> well before this 30yr old email
>
> Date: 09/21/81 20:32:21
> From: wheeler
>
> ah, but most ot those systems were also developed as end-user &/or
> time-sharing systems. They have two characteristics, one is user

> firendly and the other is ease of programming. . . .

It was in common use a little after that time for mainframe systems.

It's important to note that before roughly 1980 user demands exceeded
_affordable_ computer horsepower (CPU speed and 'core' memory).
Generally, most organizations ran their computer 'full up' and got a
faster CPU and/or more 'core' memory as soon as they could afford to.

As a result, computer systems, particularly on-line ones, developed in
the 1970s tended to be rather conservative with memory and
functionality. To keep screen processing simple field literals were
usually terse and abbreviated. So were error messages. Data fields
were coded in tight terms. Computer users back then had to work with
a hard copy code books to translate error messages and find codes for
various situations. Often the user had to do prep work with pencil
and paper before using the computer.

Some online systems started the transaction with a command string that
had to be precisely formatted and encoded.

As computers got more horsepower programming could be more
sophisticated and the user interface evolved. Screens became easier
to use. I believe the original IBM 3270 terminal only had a few PF
keys, but then later models went up to 12 then 24, making screen-to-
screen navigation easier.

Batch systems evolved, too. One common example was the date check:
instead of merely saying "INVALID DATE", it would be more specific, eg
"INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or, "APPLICATION
DATE MUST BE GREATER THAN DATE OF BIRTH".

Also, as users and developers got more familiar with large scale
applications in actual service, they learned of problem areas and
worked to resolve them. I remember meeting with the keypunch
supervsior who complained that a source document was difficult to
keypunch. We redesigned the form and data entry program with that in
mind, along with user recommendations. Both the user and keypunch
were happy, and errors were down.


Today, one thing that troubles me is that many modern software
developers and young and don't have the exposure to good user
interface. True, many client server I/O interface is much easier to
use (such as a drop down menu listing all choices instead of cryptic
field codes). But there is still an art to designing a screen and
collecting _accurate_ data. In conducting my own personal commerce,
I see some very well design screens and some really crappy ones. (I
know of several systems that required a 10 digit telephone number that
had to be 10 digits, no more, no less. This was a problem for some
customers had needed to enter an extension number, or for customers
from overseas who used a different phone format. Indeed, back in the
early 1980s many people still used letters for their phone number, eg,
KL 5-2358, and a computer required only numbers.)

[Al Kossow]

On 1/3/12 7:20 AM, Berkeley Brett wrote:
> I hope you are all well& in good spirits.

>
> I wonder, is there a general consensus on who originated the phrase
> "user-friendly"?
>

AFIPS proceedings, May, 1975 pg 447

"We felt that a language intended for non-programmers should
be 'user friendly', "


Datamation is Dec, 1976 pg 182

"A new buzzword that has popped up lately, that of describing a
product as being 'user friendly' "


Byte, Oct, 1979 pg 178

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2012.html#11 Who originated the phrase "user-friendly"?

other old user-friendly comments

Date: 08/26/82 12:46:15
From: wheeler

re: computerworld; Aug. 24 issue, IN DEPTH section, The myth of
user-friendly computing. High level, general article w/o references to
manufactorers, operating systems, application packages, etc. but ...

... This is frequently in the form of an "information center," a
concept that is being sold as a way to relieve production systems of
the burden of end-user access and to provide the end user with a
friendly environment (usually VM) and an array of unrelated
user-friendly tools.

... snip ...

and I couldn't resist (part of exchange with MVS support person
complaining about my dis'ing MVS & TSO):

Date: 10/27/82 16:55:11
From: wheeler

yep, you're right a CMS system with an average of 1sec. response for
edit commands would be a sick system. Course it isn't all TSO's fault.
The CMS under MVS project in POK is measuring their CMS performing as
badly as TSO. IBM wants to do the project anyway ... even if it
doesn't provide any better performance, at least it provides an
end-user, user-friendly system for people that have to use MVS.

... snip ...

in line with tests showing that 3274 controller made it impossible to
achieve quarter-second user response. old reference to presentation
on the "CMS under MVS" project in this post
http://www.garlic.com/~lynn/96.html#4a

recent post discussing the quarter-second response issue
http://www.garlic.com/~lynn/2011d.html#53
http://www.garlic.com/~lynn/2011p.html#61
and some 3272/3277 comparisons with 3274/3278
http://www.garlic.com/~lynn/2001m.html#19

from ibm jargon:

bad response - n. A delay in the response time to a trivial request of
a computer that is longer than two tenths of one second. In the 1970s,
IBM 3277 display terminals attached to quite small System/360 machines
could service up to 19 interruptions every second from a user I
measured it myself. Today, this kind of response time is considered
impossible or unachievable, even though work by Doherty, Thadhani, and
others has shown that human productivity and satisfaction are almost
linearly inversely proportional to computer response time. It is hoped
(but not expected) that the definition of Bad Response will drop below
one tenth of a second by 1990.

... snip ...

[ken...@cix.compulink.co.uk]

In article
<3533dfe2-5262-4315...@y25g2000prg.googlegroups.com>,

roya...@gmail.com (Berkeley Brett) wrote:

> I wonder, is there a general consensus on who originated the phrase
> "user-friendly"?

An advertiser and it probably originated before computers.

Ken Young

[Stan Barr]

I first heard of it in connection with weaponry, and its opposite
"user hostile".

--
Cheers,
Stan Barr plan.b .at. dsl .dot. pipex .dot. com

The future was never like this!

[Al Kossow]

On 1/4/12 8:18 AM, Stan Barr wrote:

> I first heard of it in connection with weaponry, and its opposite
> "user hostile".
>

timeframe?

I can imagine "user hostile" being used referring to the M-16

The earliest computing reference I could easily find was the mid 70's
but there may be appear in human factors literature back perhaps
into the late 50's.

[Bernard Peek]

On 04/01/12 17:30, Al Kossow wrote:

> I can imagine "user hostile" being used referring to the M-16
>
> The earliest computing reference I could easily find was the mid 70's
> but there may be appear in human factors literature back perhaps
> into the late 50's.

I know that the Oxford English Dictionary collects references to the
first written usage of all of its words. My SOED is in storage so I
can't check it.

--
Bernard Peek
b...@shrdlu.com

[Mensanator]

On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
> I hope you are all well & in good spirits.
>
> I wonder, is there a general consensus on who originated the phrase
> "user-friendly"?

Don't know. Where I worked, we always used the phrase:
"idiot-proof".

>
> Thanks in advance for anything you may care to share....
>
> --

> Brett (in Berkeley, California, USA)http://www.ForeverFunds.org/

[Tom Sherren]

In article <667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com>, Mensanator <mensa...@aol.com> wrote:

Back in the late '70s or early '80s Univac (now Unisys) coined the term
"end-user computing" or "user designed computing" in conjunction with a
software system named MAPPER (now BIS) . End users develop their own online
applications under the watchful gaze of the all-powerful, all-knowing MAPPER
(BIS) coordinator who reviews and approves all program changes before they are
put into production. If the user developed it, it must be user-friendly, eh?

It was impressive to watch a VP of manufacturing seize a terminal and drill
down through the data to find out what part was holding up the assembly line.

BIS carries on to this day:
http://unisys.com/unisys/product/productdetail.
jsp?id=1120000160000010000&pid=1120000970018210161&sid=2800008

[Charlie Gibbs]

In article <m34nwc5...@garlic.com>, ly...@garlic.com

(Anne & Lynn Wheeler) writes:

> Date: 10/27/82 16:55:11
> From: wheeler
>
> yep, you're right a CMS system with an average of 1sec. response for
> edit commands would be a sick system. Course it isn't all TSO's fault.
> The CMS under MVS project in POK is measuring their CMS performing as
> badly as TSO. IBM wants to do the project anyway ... even if it
> doesn't provide any better performance, at least it provides an
> end-user, user-friendly system for people that have to use MVS.

I thought it was IBM's goal that _everyone_ had to use MVS.

> from ibm jargon:
>
> bad response - n. A delay in the response time to a trivial request of
> a computer that is longer than two tenths of one second. In the 1970s,
> IBM 3277 display terminals attached to quite small System/360 machines
> could service up to 19 interruptions every second from a user I
> measured it myself. Today, this kind of response time is considered
> impossible or unachievable, even though work by Doherty, Thadhani, and
> others has shown that human productivity and satisfaction are almost
> linearly inversely proportional to computer response time. It is hoped
> (but not expected) that the definition of Bad Response will drop below
> one tenth of a second by 1990.

<sigh> I guess the Univac systems I worked on wouldn't cut it,
given that they only polled terminal clusters once a second.
(On the other hand, with multidropped RS-232 lines at 9600 bps
that's probably the best you could do.) I once heard someone
in the 1100 group claim that their goal wasn't fast response,
but consistent response - to the point where they would hold
back a response if it was ready too quickly.

And now we have websites which, even if they manage to feed a
response through the Internet in a decent length of time, will
still take 10 seconds or more just to paint the ads on the screen -
which, of course, they do before displaying any actual content.
Well, not always - but just as you're starting to read the text
the screen gets redrawn and reformatted several times to fit the
ads and get the blinking and animation going.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Charlie Gibbs]

In article
<7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> On Jan 3, 2:10 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>
>> well before this 30yr old email
>>
>> Date: 09/21/81 20:32:21
>> From: wheeler
>>
>> ah, but most ot those systems were also developed as end-user &/or
>> time-sharing systems. They have two characteristics, one is user
>> firendly and the other is ease of programming. . . .

In addition, one must consider ease of learning vs. ease of use.
Contrary to popular belief - and much to the grief of many,
especially the denizens of this newsgroup - the two concepts
are not synonymous. Ease of learning means making it easy for
an inexperienced user to figure out how to do things. Ease of
use for an experienced user means providing lots of shortcuts -
yes, even allowing the use of that funny gadget with 100 buttons
on it - and then getting out of the way.

> It was in common use a little after that time for mainframe systems.
>
> It's important to note that before roughly 1980 user demands exceeded
> _affordable_ computer horsepower (CPU speed and 'core' memory).
> Generally, most organizations ran their computer 'full up' and got a
> faster CPU and/or more 'core' memory as soon as they could afford to.
>
> As a result, computer systems, particularly on-line ones, developed in
> the 1970s tended to be rather conservative with memory and
> functionality. To keep screen processing simple field literals were
> usually terse and abbreviated. So were error messages. Data fields
> were coded in tight terms. Computer users back then had to work with
> a hard copy code books to translate error messages and find codes for
> various situations. Often the user had to do prep work with pencil
> and paper before using the computer.

Unfortunately, much of this became a mystique, remnants of which
survive to this day. Things have to made to look "computerish",
which usually means silly blocky typefaces with lots of upper case
and gratuitous leading zeros.

> Some online systems started the transaction with a command string
> that had to be precisely formatted and encoded.

You dissin' CLIs, boy? :-)

> As computers got more horsepower programming could be more
> sophisticated and the user interface evolved. Screens became easier
> to use. I believe the original IBM 3270 terminal only had a few PF
> keys, but then later models went up to 12 then 24, making screen-to-
> screen navigation easier.

Nevertheless, taking the number of PF keys as a figure of merit is
fraught with peril (ease of learning vs. ease of use again).

> Batch systems evolved, too. One common example was the date check:
> instead of merely saying "INVALID DATE", it would be more specific,
> eg "INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or,
> "APPLICATION DATE MUST BE GREATER THAN DATE OF BIRTH".

It was definitely an improvement over error codes that had to be
looked up. "404 - can't find the manual" :-)

Unfortunately the mystique I mentioned above often interfered with
creating readable messages. It's amazing how often you can come up
with a concise, readable message if you just give it a bit of thought;
many people wrote longwinded expressions and then truncated the words
into gibberish.

From "The Devil's DP Dictionary" by Stan Kelly-Bootle:

curtation n. The enforced compression of a string in the
fixed-length field environment.

The problem of fitting extremely variable-length strings such
as names, addresses, and item descriptions into fixed-length
records is no trivial matter. Neglect of the subtle art of
curtation has probably alienated more people than any other
aspect of data processing. You order Mozart's "Don Giovanni"
from your record club, and they invoice you $24.95 for MOZ DONG.
The witless mapping of the sublime onto the ridiculous! Equally
puzzling is the curtation which produces the same eight
characters: THE BEST, whether you order "The Best of Wagner",
"The Best of Schubert", or "The Best of the Turds". Similarly,
wine lovers buying from computerized wineries twirl their
glasses, check their delivery notes, and inform their friends,
"A rather innocent, possibly overtruncated CAB SAUV 69 TAL."
The squeezing of fruit into 10 columns has yielded such
memorable obscenities as COX OR PIP.

The examples cited are real, and the curtational methodology
which produced them is still with us. Compare TRUNCATE.

My personal favourite was the job description field at a PPOE,
which squashed my programmer-analyst title into PROGRAMMER-ANAL.
It seems kind of appropriate.

> Also, as users and developers got more familiar with large scale
> applications in actual service, they learned of problem areas and
> worked to resolve them. I remember meeting with the keypunch
> supervsior who complained that a source document was difficult
> to keypunch. We redesigned the form and data entry program with
> that in mind, along with user recommendations. Both the user and
> keypunch were happy, and errors were down.

I remember the first keypunch layout I designed. I was almost
lynched.

> Today, one thing that troubles me is that many modern software
> developers and young and don't have the exposure to good user
> interface. True, many client server I/O interface is much easier
> to use (such as a drop down menu listing all choices instead of
> cryptic field codes). But there is still an art to designing a
> screen and collecting _accurate_ data. In conducting my own
> personal commerce, I see some very well design screens and some
> really crappy ones.

Unfortunately, the crappy ones are winning. But they sure have
some pretty pictures...

> (I know of several systems that required a 10 digit telephone number
> that had to be 10 digits, no more, no less. This was a problem
> for some customers had needed to enter an extension number, or for
> customers from overseas who used a different phone format.

As a Canadian, the one I run into most often is trying to fit our
postal code (letter, digit, letter, space, digit, letter, digit)
into a 5- (or 9-) character zip code field that only accepts digits.

> Indeed, back in the early 1980s many people still used letters for
> their phone number, eg, KL 5-2358, and a computer required only
> numbers.)

I remember being told that the letter prefixes (and associated
exchange names) made it easier to remember telephone numbers.
Ironically, during the switch to all-digit dialing, I once
read that the reason was to make it easier to remember.
Ah, the magical world of marketing...

[Charlie Gibbs]

In article
<667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com>,

mensa...@aol.com (Mensanator) writes:

> On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
>
>> I hope you are all well & in good spirits.
>>
>> I wonder, is there a general consensus on who originated the phrase
>> "user-friendly"?
>
> Don't know. Where I worked, we always used the phrase:
> "idiot-proof".

"Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots. So far, the Universe
is winning." -- Rick Cook

"It is impossible to make anything foolproof because fools are
so ingenious." -- Robert A. Heinlein

"Build a system that even a fool can use, and only a fool will
want to use it." -- George Bernard Shaw

[Charlie Gibbs]

In article <jdvs0e$9eh$1...@dont-email.me>, a...@bitsavers.org (Al Kossow)
writes:

"Unix is user-friendly. It's just very selective about
who its friends are."

[Anne & Lynn Wheeler]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:
> <sigh> I guess the Univac systems I worked on wouldn't cut it,
> given that they only polled terminal clusters once a second.
> (On the other hand, with multidropped RS-232 lines at 9600 bps
> that's probably the best you could do.) I once heard someone
> in the 1100 group claim that their goal wasn't fast response,
> but consistent response - to the point where they would hold
> back a response if it was ready too quickly.
>
> And now we have websites which, even if they manage to feed a
> response through the Internet in a decent length of time, will
> still take 10 seconds or more just to paint the ads on the screen -
> which, of course, they do before displaying any actual content.
> Well, not always - but just as you're starting to read the text
> the screen gets redrawn and reformatted several times to fit the
> ads and get the blinking and animation going.

re:
http://www.garlic.com/~lynn/2012.html#11
http://www.garlic.com/~lynn/2012.html#12
http://www.garlic.com/~lynn/2012.html#13

aka got trivial system response to .11 seconds along with 3272/3277
hardware delay (.086) ... comes out to .196 seconds seen by the user
... within the .2 seconds threshold found in human factor studies by
Doherty/Thadhani (impossible with 3274 controller where absolute best
case was 1/3rd seconds).

ideal was response where the user couldn't differentiate from instaneous
... if couldn't achieve that ... then consistent was next goal. the
issue was human characteristic that attention would start to wonder when
response exceeded expected ... and when response finally came in ... for
human to re-focus their attention was approx. the same elapsed time as
the elapsed time that the attention had wondered ... aka if response was
expected to be one second and it was ten seconds instead, attention
would wonder for 9seconds and then take another 9 seconds for attention
to be refocused. I've always assumed that response larger than some
small number of seconds would also result in attention wondering anyway
... even if it was consistent.

for quite some time, I've fired off large number of URLs in different
tabs and then switched between tabs ... to mask browser/web loading
latency (having large number of pre-loaded tabs that I can switch)
... aka allow loading be asynchronous, overlapped with other activity
(trying to minimize synchronized URL click/load behavior) misc. past
references:
http://www.garlic.com/~lynn/2005e.html#50 Mozilla v Firefox
http://www.garlic.com/~lynn/2005n.html#8 big endian vs. little endian, why?
http://www.garlic.com/~lynn/2005n.html#41 Moz 1.8 performance dramatically improved
http://www.garlic.com/~lynn/2005o.html#13 RFC 2616 change proposal to increase speed
http://www.garlic.com/~lynn/2006q.html#51 Intel abandons USEnet news
http://www.garlic.com/~lynn/2007l.html#30 tab browsing
http://www.garlic.com/~lynn/2007m.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2008b.html#32 Tap and faucet and spellcheckers
http://www.garlic.com/~lynn/2008b.html#35 Tap and faucet and spellcheckers
http://www.garlic.com/~lynn/2008h.html#10 What would be a future of technical blogs ? I am wondering what kind of services readers except to get from a technical blog in next 10 years
http://www.garlic.com/~lynn/2008i.html#85 Which of the latest browsers do you prefer and why?
http://www.garlic.com/~lynn/2008k.html#67 Intel: an expensive many-core future is ahead of us
http://www.garlic.com/~lynn/2008p.html#29 How were you using the internet 10 years ago and how does that differ from how you use it today?
http://www.garlic.com/~lynn/2009g.html#54 Windowed Interfaces 1981-2009
http://www.garlic.com/~lynn/2009m.html#66 What happened to computer architecture (and comp.arch?)
http://www.garlic.com/~lynn/2009q.html#72 Now is time for banks to replace core system according to Accenture
http://www.garlic.com/~lynn/2009r.html#36 SSL certificates and keys
http://www.garlic.com/~lynn/2010b.html#48 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010d.html#22 OT: PC clock failure--CMOS battery?
http://www.garlic.com/~lynn/2011j.html#29 DG Fountainhead vs IBM Future Systems

[Jim G.]

Charlie Gibbs sent the following on 04 Jan 12 12:47:52 -0800:

>
> "Unix is user-friendly. It's just very selective about
> who its friends are."

+1

--
Jim G.
Waukesha, WI

[Peter Flass]

On 1/4/2012 3:33 PM, Charlie Gibbs wrote:
> In article
> <7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>>
>> As a result, computer systems, particularly on-line ones, developed in
>> the 1970s tended to be rather conservative with memory and
>> functionality. To keep screen processing simple field literals were
>> usually terse and abbreviated. So were error messages. Data fields
>> were coded in tight terms. Computer users back then had to work with
>> a hard copy code books to translate error messages and find codes for
>> various situations. Often the user had to do prep work with pencil
>> and paper before using the computer.

What could be more user-friendly than a pencil and paper?> You can use
it anywhere, it never needs recharging, the "screen area" is fairly
large, it's light-weight, etc. All the stuff since than has been trying
to duplicate the functionality of a pencil and paper, and they're not
there yet.
...

>
> Unfortunately the mystique I mentioned above often interfered with
> creating readable messages. It's amazing how often you can come up
> with a concise, readable message if you just give it a bit of thought;

Having written my share of error messages, it's more complicated than
that. Not only might the programmer (or whoever writes the messages)
not have the same vocabulary, they might not even be on the same planet.
A message might be completely self-explanatory _to me_, maybe the guy in
India who's looking at the screen might think not so much.
...

>
> As a Canadian, the one I run into most often is trying to fit our
> postal code (letter, digit, letter, space, digit, letter, digit)
> into a 5- (or 9-) character zip code field that only accepts digits.

I've got a simple solution to that one, but you may not like it ;-)

[Peter Flass]

On 1/4/2012 3:44 PM, Charlie Gibbs wrote:
> In article<m34nwc5...@garlic.com>, ly...@garlic.com

> (Anne& Lynn Wheeler) writes:
>
>> Date: 10/27/82 16:55:11
>> From: wheeler
>>
>> yep, you're right a CMS system with an average of 1sec. response for
>> edit commands would be a sick system.

I don't think I've *ever* worked on a system from *anyone*, except
peecees. that had a 1sec average response time. Maybe CMS on a local
terminal at 3:00am when no one else was on, but my guesstimate would be
from a few seconds on up to minutes for various systems.
...

>
> And now we have websites which, even if they manage to feed a
> response through the Internet in a decent length of time, will
> still take 10 seconds or more just to paint the ads on the screen -
> which, of course, they do before displaying any actual content.
> Well, not always - but just as you're starting to read the text
> the screen gets redrawn and reformatted several times to fit the
> ads and get the blinking and animation going.
>

Yes, my pet peeve. Some have told me to install this and that to fix
the problem, but I'd rather sentence all the web designers to a few
years hard labor, maybe the sentences based on how long their wonderful
designs take to load.

[Dan Espen]

Peter Flass <Peter...@Yahoo.com> writes:

> On 1/4/2012 3:33 PM, Charlie Gibbs wrote:
>> In article
>> <7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,
>> hanc...@bbs.cpcn.com (hancock4) writes:
>>>
>>> As a result, computer systems, particularly on-line ones, developed in
>>> the 1970s tended to be rather conservative with memory and
>>> functionality. To keep screen processing simple field literals were
>>> usually terse and abbreviated. So were error messages. Data fields
>>> were coded in tight terms. Computer users back then had to work with
>>> a hard copy code books to translate error messages and find codes for
>>> various situations. Often the user had to do prep work with pencil
>>> and paper before using the computer.
>
> What could be more user-friendly than a pencil and paper?> You can
> use it anywhere, it never needs recharging, the "screen area" is
> fairly large, it's light-weight, etc. All the stuff since than has
> been trying to duplicate the functionality of a pencil and paper, and
> they're not there yet.

Gee, where's Rod?

On the other hand, the pencil breaks, needs to be sharpened.
Erasure is difficult. Penmanship can't match display or print
quality. Color is pretty hard.

And there are no squiggly lines,


--
Dan Espen

[hanc...@bbs.cpcn.com]

On Jan 4, 3:44 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> And now we have websites which, even if they manage to feed a
> response through the Internet in a decent length of time, will
> still take 10 seconds or more just to paint the ads on the screen -
> which, of course, they do before displaying any actual content.
> Well, not always - but just as you're starting to read the text
> the screen gets redrawn and reformatted several times to fit the
> ads and get the blinking and animation going.

I don't understand is what a website is transmitting when the screen
is populated but still locked out for a few seconds afterwards. Is it
loading or reading cookies? Fancy-dancy unnecessary java junk?

One example is the newsite www.nj.com

Certain links to stories on msnbc.com also lock up for a while.

[hanc...@bbs.cpcn.com]

On Jan 3, 5:45 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> from ibm jargon:
>
> bad response - n. A delay in the response time to a trivial request of
> a computer that is longer than two tenths of one second. In the 1970s,
> IBM 3277 display terminals attached to quite small System/360 machines
> could service up to 19 interruptions every second from a user I

> measured it myself. . . .

Of course response time includes multiple factors--within the computer
(CPU to think about the transaction, and disk I/O to get data); the
comm line itself, comm controllers on either end of the comm line, and
the terminal itself. Over the years, the performance of all those
elements improved greatly while costs went down. (I remember their
getting new multiplexors which allowed more terminals yet faster
response time.) We ran coax lines by sticking a paper clip through
the ceiling tile to hold the wire, and I've seen several installations
do that.

I recall reading 1960s literature that talked about response times in
much slower terms--at least several seconds, and in certain cases, a
minute or two (it varied by application).

In my Teletype timesharing days, simply entering a program line
usually got almost instant response time (returning a [linefeed] in
response to a [return].) But it was slower on executing a command,
perhaps several seconds, before responding. Depending on the program,
there could be a wait after entering RUN.

When we had real 3270 terminals connected to our overworked 370-158 in
the next room, I think response time was about one second. To improve
efficiency, we replaced TSO with ROSCOE; something about better use of
address spaces.

[Gene Wirchenko]

On Wed, 4 Jan 2012 15:51:28 -0800 (PST), hanc...@bbs.cpcn.com wrote:

[snip]

>I don't understand is what a website is transmitting when the screen
>is populated but still locked out for a few seconds afterwards. Is it
>loading or reading cookies? Fancy-dancy unnecessary java junk?
>
>One example is the newsite www.nj.com
>
>Certain links to stories on msnbc.com also lock up for a while.

It might be JavaScript up to something. I did not see that
delay, but I have JavaScript disabled. The page does have JavaScript
scripting tags.

Sincerely,

Gene Wirchenko

[Charlie Gibbs]

In article <je2l24$hqp$1...@dont-email.me>, Peter...@Yahoo.com

(Peter Flass) writes:

> On 1/4/2012 3:33 PM, Charlie Gibbs wrote:
>
>> In article
>> <7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,
>> hanc...@bbs.cpcn.com (hancock4) writes:
>>>
>>> As a result, computer systems, particularly on-line ones, developed
>>> in the 1970s tended to be rather conservative with memory and
>>> functionality. To keep screen processing simple field literals were
>>> usually terse and abbreviated. So were error messages. Data fields
>>> were coded in tight terms. Computer users back then had to work
>>> with a hard copy code books to translate error messages and find
>>> codes for various situations. Often the user had to do prep work
>>> with pencil and paper before using the computer.
>
> What could be more user-friendly than a pencil and paper?> You can
> use it anywhere, it never needs recharging, the "screen area" is
> fairly large, it's light-weight, etc. All the stuff since than has
> been trying to duplicate the functionality of a pencil and paper,
> and they're not there yet.

Yup. You have the choice of high resolution (fine point), colours,
special effects (blur with an eraser), plus the joy of vector graphics
vs. raster - no more jaggies!

>> Unfortunately the mystique I mentioned above often interfered with
>> creating readable messages. It's amazing how often you can come
>> up with a concise, readable message if you just give it a bit of
>> thought;
>
> Having written my share of error messages, it's more complicated than
> that. Not only might the programmer (or whoever writes the messages)
> not have the same vocabulary, they might not even be on the same
> planet. A message might be completely self-explanatory _to me_,
> maybe the guy in India who's looking at the screen might think
> not so much.

Granted it's not necessarily easy. But it's certainly possible
to do better than some of the haphazard designs we've both seen.
Despite my best efforts, though, I've caught myself writing
things like "Press <enter> to exit" (not that that's any sillier
than clicking the Start button to shut down a Windows box).

>> As a Canadian, the one I run into most often is trying to fit our
>> postal code (letter, digit, letter, space, digit, letter, digit)
>> into a 5- (or 9-) character zip code field that only accepts digits.
>
> I've got a simple solution to that one, but you may not like it ;-)

That's OK, our government is selling us out as quickly as it can.
And if we elect one that doesn't... well, that's what tanks are
for, innit?

[D.J.]

On Wed, 4 Jan 2012 15:51:28 -0800 (PST), hanc...@bbs.cpcn.com wrote:

Probably not transmitting anything. Probably overloaded from the
number of viewers and the server is trying to catch up and display the
pages for all viewers, and failing at it.
.
JimP.
--
Brushing aside the thorns so I can see the stars.
http://www.linuxgazette.net/ Linux Gazette
http://www.drivein-jim.net/ Drive-In movie theaters
http://story.drivein-jim.net/ A story Feb, 2011

[Walter Bushell]

In article <6942.421T1...@kltpzyxm.invalid>,

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> My personal favourite was the job description field at a PPOE,
> which squashed my programmer-analyst title into PROGRAMMER-ANAL.
> It seems kind of appropriate.

Oh, cum now, on has to have an anal character or at least anal
characteristics to be a programmer. It's detail work after all.

--
It is the nature of the human species to reject what is true but unpleasant
and to embrace what is obviously false but comforting. -- H. L. Mencken

[Walter Bushell]

In article <je2l24$hqp$1...@dont-email.me>,

Peter Flass <Peter...@Yahoo.com> wrote:

> Having written my share of error messages, it's more complicated than
> that. Not only might the programmer (or whoever writes the messages)
> not have the same vocabulary, they might not even be on the same planet.
> A message might be completely self-explanatory _to me_, maybe the guy in
> India who's looking at the screen might think not so much.
> ...

And you can bet your bottom dollar if the message is self explanatory to
the guy in India, it won't be for you. Their English is OK, but their
world view is *different*. Have you ever had to deal with a program
written by a programmer form India? Bramha, Vishnu and Shiva are
different from Father, Son and Pigeon.

[Walter Bushell]

In article <je2lcp$jqv$1...@dont-email.me>,

Peter Flass <Peter...@Yahoo.com> wrote:

> I don't think I've *ever* worked on a system from *anyone*, except
> peecees. that had a 1sec average response time. Maybe CMS on a local
> terminal at 3:00am when no one else was on, but my guesstimate would be
> from a few seconds on up to minutes for various systems.
> ...

Dec 10 and 20 system managed this easily for simple edit commands and
much shorter for echoing typed characters on full duplex. Now if there
is substantial computing to be done, it takes longer.

[Charles Richmond]

"Mensanator" <mensa...@aol.com> wrote in message
news:667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com...

On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
>> I hope you are all well & in good spirits.
>>
>> I wonder, is there a general consensus on who originated the phrase
>> "user-friendly"?
>
>Don't know. Where I worked, we always used the phrase:
>"idiot-proof".
>

The problem is... the world is always making bigger and better idiots, who
can break any "idiot proof" scheme. :-)


--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[Dan Espen]

Wow, 100K of junk.

First the browser reads the main page, 100K.
Then it's got a load of scripts to run and images to load from a variety
of sites.
It does it's best to display the page before it has all the images, and
script results.

--
Dan Espen

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:1083.421T2...@kltpzyxm.invalid...

> In article
> <667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com>,
> mensa...@aol.com (Mensanator) writes:
>
>> On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
>>
>>> I hope you are all well & in good spirits.
>>>
>>> I wonder, is there a general consensus on who originated the phrase
>>> "user-friendly"?
>>
>> Don't know. Where I worked, we always used the phrase:
>> "idiot-proof".
>
> "Programming today is a race between software engineers striving
> to build bigger and better idiot-proof programs, and the Universe
> trying to produce bigger and better idiots. So far, the Universe
> is winning." -- Rick Cook
>
> "It is impossible to make anything foolproof because fools are
> so ingenious." -- Robert A. Heinlein
>
> "Build a system that even a fool can use, and only a fool will
> want to use it." -- George Bernard Shaw
>

And don't forget:

"Against stupidity even the gods struggle in vain." -- Friedrich Schiller


I remember a story BAH used to tell... about testing of the TOPS-10 OS.
Seems DEC would get some of the low level people, like janitors and such,
sit them at a keyboard and let them do anything they want. Banging on some
combination of keys, they could usually bring down the the system beginning
from the user prompt. They would try things that the knowledgeable people
would *never* think anyone would try.

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:1083.421T2...@kltpzyxm.invalid...

> In article
> <667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com>,
> mensa...@aol.com (Mensanator) writes:
>
>> On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
>>
>>> I hope you are all well & in good spirits.
>>>
>>> I wonder, is there a general consensus on who originated the phrase
>>> "user-friendly"?
>>
>> Don't know. Where I worked, we always used the phrase:
>> "idiot-proof".
>
> "Programming today is a race between software engineers striving
> to build bigger and better idiot-proof programs, and the Universe
> trying to produce bigger and better idiots. So far, the Universe
> is winning." -- Rick Cook
>
> "It is impossible to make anything foolproof because fools are
> so ingenious." -- Robert A. Heinlein
>
> "Build a system that even a fool can use, and only a fool will
> want to use it." -- George Bernard Shaw
>

I thought I'd also throw in this definition by Ambrose Bierce:

Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling. The Idiot's activity is
not confined to any special field of thought or action, but "pervades and
regulates the whole." He has the last word in everything; his decision is
unappealable. He sets the fashions and opinion of taste, dictates the
limitations of speech and circumscribes conduct with a dead-line.

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message

news:6942.421T1...@kltpzyxm.invalid...

> In article
> <7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>
>> On Jan 3, 2:10 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>>

>> [snip...] [snip...]
>> [snip...]

>>
>> As a result, computer systems, particularly on-line ones, developed in
>> the 1970s tended to be rather conservative with memory and
>> functionality. To keep screen processing simple field literals were
>> usually terse and abbreviated. So were error messages. Data fields
>> were coded in tight terms. Computer users back then had to work with
>> a hard copy code books to translate error messages and find codes for
>> various situations. Often the user had to do prep work with pencil
>> and paper before using the computer.
>
> Unfortunately, much of this became a mystique, remnants of which
> survive to this day. Things have to made to look "computerish",
> which usually means silly blocky typefaces with lots of upper case
> and gratuitous leading zeros.
>

I worked with an older guy back in the 90's who used a set of colored
pencils to "pencil up" his computer listings. The listings were printed on
continuous-form paper that was run through a dot-matrix printer... *not*
like the individual pagination produced by a laser printer or ink jet
printer. So I think some of the programming techniques of the 60's and 70's
will endure... as long as there are programmers from those eras still living
and working.

When I was studying programming in college in the late 70's, typing one's
program directly into the terminal without first writing it out on a piece
of paper... was disparaged. The only time I felt it necessary to write out
a program on paper... was when programming in assembly language. Somehow it
felt more comfortable to write it out on paper first.

>
> My personal favourite was the job description field at a PPOE,
> which squashed my programmer-analyst title into PROGRAMMER-ANAL.
> It seems kind of appropriate.
>

My favorite is a listing of a course in the class schedule at my college:
ANAL GEOMETRY

[Seebs]

On 2012-01-05, Walter Bushell <pr...@panix.com> wrote:
> And you can bet your bottom dollar if the message is self explanatory to
> the guy in India, it won't be for you. Their English is OK, but their
> world view is *different*.

This is different from talking to everyone else how? :)

I have spent most of my life learning to make sense of world views that are
incompatible with mine.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[Charles Richmond]

"Peter Flass" <Peter...@Yahoo.com> wrote in message
news:je2l24$hqp$1...@dont-email.me...

> On 1/4/2012 3:33 PM, Charlie Gibbs wrote:
>> In article
>> <7a28061c-ecc5-45ef...@z19g2000vbe.googlegroups.com>,
>> hanc...@bbs.cpcn.com (hancock4) writes:
>>>
>>> As a result, computer systems, particularly on-line ones, developed in
>>> the 1970s tended to be rather conservative with memory and
>>> functionality. To keep screen processing simple field literals were
>>> usually terse and abbreviated. So were error messages. Data fields
>>> were coded in tight terms. Computer users back then had to work with
>>> a hard copy code books to translate error messages and find codes for
>>> various situations. Often the user had to do prep work with pencil
>>> and paper before using the computer.
>
> What could be more user-friendly than a pencil and paper?> You can use it
> anywhere, it never needs recharging, the "screen area" is fairly large,
> it's light-weight, etc. All the stuff since than has been trying to
> duplicate the functionality of a pencil and paper, and they're not there
> yet.
> ...

Pen and paper are great thinking tools. The problem is that "you can't grep
dead trees". You do *not* end up with a digital copy of anything. Once it
is in the computer, you can stretch it, copy it, paste it, delete it, move
it, scan it, do all sorts of things with it. Pen and paper has *not*
succeeded in providing this functionality.

>>
>> Unfortunately the mystique I mentioned above often interfered with
>> creating readable messages. It's amazing how often you can come up
>> with a concise, readable message if you just give it a bit of thought;
>
> Having written my share of error messages, it's more complicated than
> that. Not only might the programmer (or whoever writes the messages) not
> have the same vocabulary, they might not even be on the same planet.
> A message might be completely self-explanatory _to me_, maybe the guy in
> India who's looking at the screen might think not so much.
> ...

A cow-orker at a PPoE told me when he was in college, he had to program
using an ALGOL compiler that was written in France. Unfortunately for him
(he is an English-speaking 'merkin), all the error messages were in French.
:-) Sure, it would *not* be that hard to fix... but the point is *no* one
did fix it.

[Charles Richmond]

"Walter Bushell" <pr...@panix.com> wrote in message
news:proto-820B9B....@news.panix.com...

> In article <je2l24$hqp$1...@dont-email.me>,
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> Having written my share of error messages, it's more complicated than
>> that. Not only might the programmer (or whoever writes the messages)
>> not have the same vocabulary, they might not even be on the same planet.
>> A message might be completely self-explanatory _to me_, maybe the guy in
>> India who's looking at the screen might think not so much.
>> ...
>
> And you can bet your bottom dollar if the message is self explanatory to
> the guy in India, it won't be for you. Their English is OK, but their
> world view is *different*. Have you ever had to deal with a program
> written by a programmer form India? Bramha, Vishnu and Shiva are
> different from Father, Son and Pigeon.
>

That's why in the U.S. and Canada, we need a Programmer's Guild (union).
The union rules would expressly forbid union members from working on code
originally written in India or China. Let those folks *fix* the code
themselves!!! If employers don't like the way the Indians and Chinese code,
well then they better think about hiring union programmers.

[Charles Richmond]

"Seebs" <usenet...@seebs.net> wrote in message
news:slrnjga46k.16r...@guild.seebs.net...

> On 2012-01-05, Walter Bushell <pr...@panix.com> wrote:
>> And you can bet your bottom dollar if the message is self explanatory to
>> the guy in India, it won't be for you. Their English is OK, but their
>> world view is *different*.
>
> This is different from talking to everyone else how? :)
>
> I have spent most of my life learning to make sense of world views that
> are
> incompatible with mine.
>

Seebs, you have spent most of your life learning to make sense of other
world views... because there is *no* world view compatible with yours!!!
You are an isolated case. There is *no* one else that begins to think like
you. For people who share a "world view", they are *much* more comfortable
working within that world view than trying to twist themselves into some
highly unfamiliar world view.

[Charles Richmond]

"Walter Bushell" <pr...@panix.com> wrote in message

news:proto-61F445....@news.panix.com...

> In article <je2lcp$jqv$1...@dont-email.me>,
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> I don't think I've *ever* worked on a system from *anyone*, except
>> peecees. that had a 1sec average response time. Maybe CMS on a local
>> terminal at 3:00am when no one else was on, but my guesstimate would be
>> from a few seconds on up to minutes for various systems.
>> ...
>
> Dec 10 and 20 system managed this easily for simple edit commands and
> much shorter for echoing typed characters on full duplex. Now if there
> is substantial computing to be done, it takes longer.
>

Response time for the DEC 10 and 20 depended on how heavily the systems were
loaded down. I *tried* to work on a DEC 10 under TOPS-10 in college... that
was designed for 64 users max. It had 80 users on it. Response time was
abysmal.

[Seebs]

On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
> The union rules would expressly forbid union members from working on code
> originally written in India or China. Let those folks *fix* the code
> themselves!!! If employers don't like the way the Indians and Chinese code,
> well then they better think about hiring union programmers.

This may well be one of the worst ideas I've ever heard.

[Patrick Scheible]

Bernard Peek <b...@shrdlu.com> writes:

> On 04/01/12 17:30, Al Kossow wrote:
>
>> I can imagine "user hostile" being used referring to the M-16
>>
>> The earliest computing reference I could easily find was the mid 70's
>> but there may be appear in human factors literature back perhaps
>> into the late 50's.
>
> I know that the Oxford English Dictionary collects references to the
> first written usage of all of its words. My SOED is in storage so I
> can't check it.

Online OED has the first use in 1976:

Computers & Geosci. 2 345 The integration of processes, the diversity
of data-handling capability, and the user-friendly commands are the key
design features.

-- Patrick

[hanc...@bbs.cpcn.com]

On Jan 4, 5:55 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> What could be more user-friendly than a pencil and paper?

Try reading my handwriting. (Heck, not even my typing is so great.)

[hanc...@bbs.cpcn.com]

On Jan 4, 3:33 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> Unfortunately, much of this became a mystique, remnants of which
> survive to this day.  Things have to made to look "computerish",
> which usually means silly blocky typefaces with lots of upper case
> and gratuitous leading zeros.

In the outside world, making things "computerish" usually meant using
the optical typeface, where numbers look like MICR characters on a
check.

In the computer world, everything was all uppercase since that's what
machines could only understand, display, or print in typical
applications. (Sure, you could get a lower case print chain and lower-
case capable CRT, but it could be cumbersome for various reasons.
Most of the time we had our trusty 1403 printer.)




> > Some online systems started the transaction with a command string
> > that had to be precisely formatted and encoded.
>
> You dissin' CLIs, boy?  :-)

I thank heaven I never had to use such systems. I've seen really
convoluted long strings. I guess the operators who used them
regularly got the hang of them, but they sure looked error prone and
tedious.


> > As computers got more horsepower programming could be more
> > sophisticated and the user interface evolved.  Screens became easier
> > to use.  I believe the original IBM 3270 terminal only had a few PF
> > keys, but then later models went up to 12 then 24, making screen-to-
> > screen navigation easier.
>
> Nevertheless, taking the number of PF keys as a figure of merit is
> fraught with peril (ease of learning vs. ease of use again).

Well, here's an example: in an old system, to navigate around one
typed in a command code and there were several commands available (eg
within the account or to the next account or back to the master menu,
etc.) In the new system, PF keys did the word, and the last line of
the screen was a reference.


>
> > Batch systems evolved, too.  One common example was the date check:
> > instead of merely saying "INVALID DATE", it would be more specific,
> > eg "INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or,
> > "APPLICATION DATE MUST BE GREATER THAN DATE OF BIRTH".
>
> It was definitely an improvement over error codes that had to be
> looked up.  "404 - can't find the manual"  :-)

Better still was "self explanatory".

> As a Canadian, the one I run into most often is trying to fit our
> postal code (letter, digit, letter, space, digit, letter, digit)
> into a 5- (or 9-) character zip code field that only accepts digits.

With all due respect to our northern neighbor, I hate typing in
Canadian zip codes. They're just not symetrical and require shifting
and releasing. I find the letter digit combo confusing.



> > Indeed, back in the early 1980s many people still used letters for
> > their phone number, eg, KL 5-2358, and a computer required only
> > numbers.)
>
> I remember being told that the letter prefixes (and associated
> exchange names) made it easier to remember telephone numbers.
> Ironically, during the switch to all-digit dialing, I once
> read that the reason was to make it easier to remember.
> Ah, the magical world of marketing...

In large cities, phone numbers for manual exchanges were originally
name+4, eg Parkway 2368. When they converted to dial, PARkway would
convert to 727 (later PArkway 7). They felt 727-2368 would be hard to
remember so they kept the name and added letters to the dial.
Ironically, those same letters survive to this day for other uses.

Anyway, when they ran out of names they then claimed the old research
was faulty and it was not hard to remember seven digits. At the time,
many people objected to losing their exchange names, they felt it
humanized the telephone experience.

But admittedly (from one who misses the names) the names had problems--
frequent confusion between 1 and I, and 0 and O, lack of capacity (no
name for 97-), and the need to use 0 and 1 as a middle digit and they
didn't have an associated letter.

Another problem with names was confusion over spelling. For instance,
Phila had BAring which was pronounced locally as 'bearing'. Long
distance calls would get confused. Some names weren't so common, like
HYatt (could be spelled HI) or SWinburne*.


*An old poet. The exchange serving Plainsboro, NJ, home of the
fictional Dr. House.

[Charles Richmond]

"Seebs" <usenet...@seebs.net> wrote in message

news:slrnjga6jn.17f...@guild.seebs.net...

> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>> The union rules would expressly forbid union members from working on code
>> originally written in India or China. Let those folks *fix* the code
>> themselves!!! If employers don't like the way the Indians and Chinese
>> code,
>> well then they better think about hiring union programmers.
>
> This may well be one of the worst ideas I've ever heard.
>

"You got some splainin' to do, Ricky..."

[Andrew Swallow]

On 05/01/2012 07:08, Charles Richmond wrote:
> "Seebs" <usenet...@seebs.net> wrote in message
> news:slrnjga6jn.17f...@guild.seebs.net...
>> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>>> The union rules would expressly forbid union members from working on
>>> code
>>> originally written in India or China. Let those folks *fix* the code
>>> themselves!!! If employers don't like the way the Indians and Chinese
>>> code,
>>> well then they better think about hiring union programmers.
>>
>> This may well be one of the worst ideas I've ever heard.
>>
>
> "You got some splainin' to do, Ricky..."
>
>

I fully understand what you are saying but once the program goes to Asia
if you try pulling the union rule it will not come back. We are paid to
do work on programs that are in the West.

Andrew Swallow

[Stan Barr]

On Wed, 04 Jan 2012 09:30:41 -0800, Al Kossow <a...@bitsavers.org> wrote:
> On 1/4/12 8:18 AM, Stan Barr wrote:
>
>> I first heard of it in connection with weaponry, and its opposite
>> "user hostile".
>>
>
> timeframe?
>

Would be late-'70s, I think.

> I can imagine "user hostile" being used referring to the M-16

:-) If you're an old-school rifleman you should try the British Army
SA-80 - *nothing* is where you expect to find it and it balances so
far back you daren't let go with your right hand :-(

--
Cheers,
Stan Barr plan.b .at. dsl .dot. pipex .dot. com

The future was never like this!

[Rod Speed]

Peter Flass wrote
> Charlie Gibbs wrote
>> hanc...@bbs.cpcn.com (hancock4) wrote

>>> As a result, computer systems, particularly on-line ones, developed
>>> in the 1970s tended to be rather conservative with memory and
>>> functionality. To keep screen processing simple field literals were
>>> usually terse and abbreviated. So were error messages. Data fields
>>> were coded in tight terms. Computer users back then had to work
>>> with a hard copy code books to translate error messages and find
>>> codes for various situations. Often the user had to do prep work
>>> with pencil and paper before using the computer.

> What could be more user-friendly than a pencil and paper?

Something with some real intelligence and retrieval capability.

> You can use it anywhere,

Nope, doesnt work under water or in hell either.

Doesnt work very well when there is no light either.

> it never needs recharging, the "screen area" is fairly large, it's light-weight, etc.

But has other real downsides that even you have nolticed with communication etc.

> All the stuff since than has been trying to duplicate the functionality of a pencil and paper,

Most of its done a hell of a lot better than it can ever do, including what you use yourself.

> and they're not there yet.

Wrong, as always.

>> Unfortunately the mystique I mentioned above often interfered with
>> creating readable messages. It's amazing how often you can come up
>> with a concise, readable message if you just give it a bit of thought;

> Having written my share of error messages, it's more complicated than
> that. Not only might the programmer (or whoever writes the messages)
> not have the same vocabulary, they might not even be on the same
> planet. A message might be completely self-explanatory _to me_, maybe
> the guy in India who's looking at the screen might think not so much.

>> As a Canadian, the one I run into most often is trying to fit our postal code (letter, digit, letter, space, digit,
>> letter, digit)
>> into a 5- (or 9-) character zip code field that only accepts digits.

[Rod Speed]

Yeah, I stupidly thought that letting a little kid bash on the keyboard
couldnt do anything too drastic. I was amazed at what it could actually do.

[Jorgen Grahn]

On Tue, 2012-01-03, hanc...@bbs.cpcn.com wrote:
...
> Today, one thing that troubles me is that many modern software
> developers and young and don't have the exposure to good user
> interface. True, many client server I/O interface is much easier to
> use (such as a drop down menu listing all choices instead of cryptic
> field codes). But there is still an art to designing a screen and
> collecting _accurate_ data. In conducting my own personal commerce,
> I see some very well design screens and some really crappy ones. (I
> know of several systems that required a 10 digit telephone number that
> had to be 10 digits, no more, no less. This was a problem for some
> customers had needed to enter an extension number, or for customers
> from overseas who used a different phone format. Indeed, back in the

> early 1980s many people still used letters for their phone number, eg,
> KL 5-2358, and a computer required only numbers.)

Other annoyances in input:

- Systems which for no good reason want you to input your first name
and last name in separate fields. I.e. when they have no reason to
generate alphabetical listings.

- Systems which "validate" email addresses according to bogus
rules. Like all the systems which don't accept grahn...@snipabacken.se
because of the '+'. Is it that hard to read RFC 822?

- Internet banking. You pay a bill by typing in its unique ID. After
10+ years experience, most companies still use IDs of 12 digits or
more -- as if they plan to issue a hundred billion unique bills.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Nick Spalding]

Morten Reistad wrote, in <je411k$q2b$1...@dont-email.me>
on Thu, 5 Jan 2012 11:14:16 +0100:

>In article <je3496$v2c$1...@dont-email.me>,

>A guild may actually be a way forward for the programming profession,

An old colleague of mine called programming a craft which would make a
guild the appropriate organisation.

>Programming is a natural "liberal arts" profession, and has the same
>personal relationship as lawyers, doctors, dentists, architects etc.
>Everyone have, however, collectively failed in making a usable exam
>for this. You either have the "programmer karma" or you haven't, but
>exams haven't been able to identify this karma.
>
>In real life it is pretty easy to classify, though. So a mentor-driven
>guild may actually be a way forward.
>
>As for fixing rotten code; we make enough of this in the west.
>But elementary coding standards, source control, etc should be mandatory
>for guild members; or the work classified as e.g. "legacy" or
>"not-up-to-standards" code, with disclaimers for quality.
>
>That may be a useful way forward, where academia admits to failure
>after 40 years of efforts.
>
>
>.. mrr
--
Nick Spalding

[Peter Flass]

Mine's pretty bad now too, but back in the day I printed pretty neatly
on coding forms.

[Peter Flass]

On 1/4/2012 11:18 PM, hanc...@bbs.cpcn.com wrote:

> On Jan 4, 3:33 pm, "Charlie Gibbs"<cgi...@kltpzyxm.invalid> wrote:
>>
>> You dissin' CLIs, boy? :-)
>
> I thank heaven I never had to use such systems. I've seen really
> convoluted long strings. I guess the operators who used them
> regularly got the hang of them, but they sure looked error prone and
> tedious.

Did you ever see an airline reservation agent use an online system in
the days before all this flashy eye candy came along? They were a joy
to watch - type a few cryptic characters on a 2741, press enter, and get
back a few other cryptic characters that told them everything they
needed to know without all the overhead of kilobytes of data
transferred. It took a fair amount of training, but you couldn't beta
them for efficiency. That's what all the pretty pictures are trying to
do - eliminate having to train people to do their job properly, and
enable employers to hire any high-school dropout off the street and not
pay them too much.

There are lots of CLIs, ranging from the above systems to PDP-10 systems
where you could press (ESC?) at any time to have the system provide
choices of what you needed to type next up to VAX DCL with a rational
language design and lots of online help.

...

>>> Batch systems evolved, too. One common example was the date check:
>>> instead of merely saying "INVALID DATE", it would be more specific,
>>> eg "INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or,
>>> "APPLICATION DATE MUST BE GREATER THAN DATE OF BIRTH".
>>
>> It was definitely an improvement over error codes that had to be
>> looked up. "404 - can't find the manual" :-)
>
> Better still was "self explanatory".

The designer of the error messages needs to consider the user. Don't
say what's wrong, tell him/her what they need to do to fix it. They
don't care about a lengthy screed on the design philosophy, they just
want to get this transaction entered and get on to the next (they're
often paid by the item).

...

>
> In large cities, phone numbers for manual exchanges were originally
> name+4, eg Parkway 2368. When they converted to dial, PARkway would
> convert to 727 (later PArkway 7). They felt 727-2368 would be hard to
> remember so they kept the name and added letters to the dial.
> Ironically, those same letters survive to this day for other uses.

This drives me nutz. The "1-800-clueles" you hear in the ads might be
nice to remember, but not so easy to disl unless you happen to have
memorized the letters for the buttons. It takes me ten times as long to
dial, and I have to take off my glasses to see the letters. I'd much
rather have all numbers. Anyhow, I'm not sure the original research was
wrong so much as that we're much more surrounded by numbers than people
were years ago, and have better developed the ability to remember them.
>
>

[Walter Bushell]

In article <je320k$ljn$1...@dont-email.me>,

"Charles Richmond" <net...@aquaporin4.com> wrote:

> "Mensanator" <mensa...@aol.com> wrote in message
> news:667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com...
> On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
> >> I hope you are all well & in good spirits.
> >>
> >> I wonder, is there a general consensus on who originated the phrase
> >> "user-friendly"?
> >
> >Don't know. Where I worked, we always used the phrase:
> >"idiot-proof".
> >
>
> The problem is... the world is always making bigger and better idiots, who
> can break any "idiot proof" scheme. :-)

When the system become easier to use then people pay less attention and
more people use the system especially people who would not put in the
time to learn the previous system and just go with what comes naturally.

I suppose we are in violent agreement, with me just pointing out how the
higher level of idiocy comes about.

However for Gooey interfaces support I recommend:

<http://xkcd.com/627/>

But I loved the old days of support on Decwriters where I could read the
interactions that got the people into trouble. CRT Terminals hid all the
evidence.

--
It is the nature of the human species to reject what is true but unpleasant
and to embrace what is obviously false but comforting. -- H. L. Mencken

[Walter Bushell]

In article <je32bf$ms9$1...@dont-email.me>,

I had a job, where we had a person who could bring down the system like
that and he was a valuable member of the software development team.
Unfortunately he was the CEO and founders son and was put in charge of a
major part of the company and sent out a letter talking about how he was
going to make his section "lean and mean". Most of that sections
customer's left and the company was acquired by another company. As a
result many of us got fired including relatives of the founder.

"He liked to burn down houses just to watch the glow, and nothing could
be done because he was the Mayor's son." Tom Lehrer.

[Andrew Swallow]

On 05/01/2012 13:21, Peter Flass wrote:
{snip}

>
> This drives me nutz. The "1-800-clueles" you hear in the ads might be
> nice to remember, but not so easy to disl unless you happen to have
> memorized the letters for the buttons. It takes me ten times as long to
> dial, and I have to take off my glasses to see the letters. I'd much
> rather have all numbers. Anyhow, I'm not sure the original research was
> wrong so much as that we're much more surrounded by numbers than people
> were years ago, and have better developed the ability to remember them.
>>
>>

The letter + number combinations were not designed for dialling but for
speaking. The telephone operator plugged your wire into the socket for
the appropriate town.

Andrew Swallow

[Walter Bushell]

In article <je47rt$u2p$1...@dont-email.me>,

Peter Flass <Peter...@Yahoo.com> wrote:

> The designer of the error messages needs to consider the user. Don't
> say what's wrong, tell him/her what they need to do to fix it. They
> don't care about a lengthy screed on the design philosophy, they just
> want to get this transaction entered and get on to the next (they're
> often paid by the item).

Or keystrokes or terminated if they don't reach a quota.

It took me some time to realize that compiler errors flagged not what
you did incorrectly, but indicated what stage the compiler found the
error, which was usually some other statement. I suppose it was
inevitable that this should be the case, but they could have put
somethings in the manuals to indicate probable cause, as after a while
the originating errors became obvious and avoided except perhaps for
typos. OTOH, I gained insights into the compilation process that way.

[Stan Barr]

On Wed, 4 Jan 2012 21:00:37 -0600, Charles Richmond <net...@aquaporin4.com> wrote:
>
> I worked with an older guy back in the 90's who used a set of colored
> pencils to "pencil up" his computer listings. The listings were printed on
> continuous-form paper that was run through a dot-matrix printer... *not*
> like the individual pagination produced by a laser printer or ink jet
> printer. So I think some of the programming techniques of the 60's and 70's
> will endure... as long as there are programmers from those eras still living
> and working.

Why do you think I have an old dot-matrix printer plugged into the
print server along with the laserjet and an inkjet? :-)
I'm obviuosly getting old...

[Rod Speed]

Morten Reistad wrote

> Charles Richmond <net...@aquaporin4.com> wrote
>> Walter Bushell <pr...@panix.com> wrote

>>> Peter Flass <Peter...@Yahoo.com> wrote

>> That's why in the U.S. and Canada, we need a Programmer's Guild
>> (union). The union rules would expressly forbid union members from
>> working on code originally written in India or China. Let those
>> folks *fix* the code themselves!!! If employers don't like the way
>> the Indians and Chinese code, well then they better think about
>> hiring union programmers.

> A guild may actually be a way forward for the programming profession,

> Programming is a natural "liberal arts" profession, and has the same
> personal relationship as lawyers, doctors, dentists, architects etc.
> Everyone have, however, collectively failed in making a usable exam
> for this. You either have the "programmer karma" or you haven't, but
> exams haven't been able to identify this karma.

Just as true with lawyers, doctors, architects etc.

> In real life it is pretty easy to classify, though.

Then it should at least in theory be possible to automate that detection too.

> So a mentor-driven guild may actually be a way forward.

I doubt it, if only because of the effort required from the mentor.

And the last thing most who are good at programming want is a mentor anyway.

> As for fixing rotten code; we make enough of this in the west.

Yes.

> But elementary coding standards, source control,
> etc should be mandatory for guild members;

Thats very arguable indeed. And its very far from clear
how viable something like Linux would be done like that too.

> or the work classified as e.g. "legacy" or
> "not-up-to-standards" code, with disclaimers for quality.

Sure, but its far from clear how many would be interested in doing the classification.

> That may be a useful way forward,

I doubt it. It isnt even that clear that it actually works for say surgeons etc.

> where academia admits to failure after 40 years of efforts.

Thats not going to happen either.

[Rod Speed]

Peter Flass wrote
> hanc...@bbs.cpcn.com wrote

>> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote

>>> You dissin' CLIs, boy? :-)

>> I thank heaven I never had to use such systems. I've seen really
>> convoluted long strings. I guess the operators who used them regularly got the hang of them, but they sure looked
>> error prone and tedious.

> Did you ever see an airline reservation agent use an online system in
> the days before all this flashy eye candy came along? They were a joy
> to watch - type a few cryptic characters on a 2741, press enter, and
> get back a few other cryptic characters that told them everything they
> needed to know without all the overhead of kilobytes of data
> transferred. It took a fair amount of training, but you couldn't beta
> them for efficiency. That's what all the pretty pictures are trying
> to do - eliminate having to train people to do their job properly, and
> enable employers to hire any high-school dropout off the street and
> not pay them too much.

I believe its more complicated than that. We saw the same thing with
WordPervert and Word. WordPervert is what died.

> There are lots of CLIs, ranging from the above systems to PDP-10
> systems where you could press (ESC?) at any time to have the system
> provide choices of what you needed to type next up to VAX DCL with a
> rational language design and lots of online help.

And hardly anyone who has complete freedom to use anything they like
chooses to use those systems anymore, even someone like BAH doesnt.

There must be a reason for that when the emulation is so trivially available for no cost.

>>>> Batch systems evolved, too. One common example was the date check:
>>>> instead of merely saying "INVALID DATE", it would be more specific,
>>>> eg "INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or,
>>>> "APPLICATION DATE MUST BE GREATER THAN DATE OF BIRTH".

>>> It was definitely an improvement over error codes that had to be
>>> looked up. "404 - can't find the manual" :-)

>> Better still was "self explanatory".

> The designer of the error messages needs to consider the user.

Thats a lot easier said than done.

Whats obviously needed is to have some way of monitoring the
reaction of vast numbers of users to real world error messages
they get and have some way of trying the alternatives on them
to see what works better than other messages.

Again, a lot easier said than done tho.

> Don't say what's wrong, tell him/her what they need to do to fix it.

Thats much harder to do.

> They don't care about a lengthy screed on the design philosophy, they just want to get this transaction entered and
> get on to the next (they're often paid by the item).

Yes, but if the error message is due to the system in the process
of dying, and it often is, its a hell of a lot harder to tell them what
meeds to be done so they can get on with what they are trying to do.

>> In large cities, phone numbers for manual exchanges were originally
>> name+4, eg Parkway 2368. When they converted to dial, PARkway would convert to 727 (later PArkway 7). They felt
>> 727-2368 would be hard to remember so they kept the name and added letters to the dial. Ironically, those same
>> letters survive to this day for other uses.

> This drives me nutz. The "1-800-clueles" you hear in the ads might be
> nice to remember, but not so easy to disl unless you happen to have
> memorized the letters for the buttons. It takes me ten times as long
> to dial, and I have to take off my glasses to see the letters. I'd
> much rather have all numbers. Anyhow, I'm not sure the original
> research was wrong so much as that we're much more surrounded by
> numbers than people were years ago, and have better developed the
> ability to remember them.

Or there is no one best approach with that question.

[Rod Speed]

Walter Bushell wrote

> Peter Flass <Peter...@Yahoo.com> wrote

>> The designer of the error messages needs to consider the user.
>> Don't say what's wrong, tell him/her what they need to do to fix it.
>> They don't care about a lengthy screed on the design philosophy,
>> they just want to get this transaction entered and get on to the
>> next (they're often paid by the item).

> Or keystrokes or terminated if they don't reach a quota.

> It took me some time to realize that compiler errors flagged not
> what you did incorrectly, but indicated what stage the compiler
> found the error, which was usually some other statement. I
> suppose it was inevitable that this should be the case, but they
> could have put somethings in the manuals to indicate probable cause,

Even Internet Explorer does that and it isnt in the manual, its with the error display.

[Seebs]

On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
> "Seebs" <usenet...@seebs.net> wrote in message
> news:slrnjga6jn.17f...@guild.seebs.net...
>> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>>> The union rules would expressly forbid union members from working on code
>>> originally written in India or China. Let those folks *fix* the code
>>> themselves!!! If employers don't like the way the Indians and Chinese
>>> code,
>>> well then they better think about hiring union programmers.

>> This may well be one of the worst ideas I've ever heard.

> "You got some splainin' to do, Ricky..."

Anything that forbids people from *getting the fucking job done* is stupid.

I have coworkers in China. They work on my code, I work on theirs,
everyone's happy. I have no problem with this.

Basically, the idea comes across as nothing but reactionary racism and
protectionism, and those are shitty economic strategies. There are good
reasons to have cheap (and probably inexperienced) programmers do the bulk
of a project, and bring in more skilled people to do the hard parts and
fixups.

It also ignores the rapidly-increasing probability that the programmers in
the US are the noobs and the people elsewhere are the good ones.

It also creates a spectacularly stupid outcome, which is that anyone who
has ever outsourced must never consider going back to a US-based development
team.

It also singles out India and China, ignoring all sorts of other places;
no problem, load a couple hundred Chinese programmers on a train, have them do
their coding somewhere else.

In short:
* It attempts to solve something which is not a problem.
* It does not solve the stated problem.
* It anti-solves the stated problem.
* It does nothing about any of the more serious real issues.
* It's really got nothing to recommend it but knee-jerk racism.

[Charles Richmond]

"Stan Barr" <pla...@dsl.pipex.com> wrote in message
news:9mm15l...@mid.individual.net...

> On Wed, 4 Jan 2012 21:00:37 -0600, Charles Richmond
> <net...@aquaporin4.com> wrote:
>>
>> I worked with an older guy back in the 90's who used a set of colored
>> pencils to "pencil up" his computer listings. The listings were printed
>> on
>> continuous-form paper that was run through a dot-matrix printer... *not*
>> like the individual pagination produced by a laser printer or ink jet
>> printer. So I think some of the programming techniques of the 60's and
>> 70's
>> will endure... as long as there are programmers from those eras still
>> living
>> and working.
>
> Why do you think I have an old dot-matrix printer plugged into the
> print server along with the laserjet and an inkjet? :-)
> I'm obviuosly getting old...
>

IMHO, if one is going to pour over a source listing of a program, the
dot-matrix printer is the only way to go!!! At a PPoE, I remember a young
lady who printed out her program... and spread the listing out on the floor
of her office, where she could view considerably more than a single page at
a time. Also, the dot-matrix listings have the "flavor" (or "flavour") of a
working document, and do *not* attempt to look like a polished and completed
text. As the comedian Flip Wilson used to say: "The good old ways is still
the best!!!"

[Charles Richmond]

"Seebs" <usenet...@seebs.net> wrote in message

news:slrnjgbq5n.1vs...@guild.seebs.net...

> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>> "Seebs" <usenet...@seebs.net> wrote in message
>> news:slrnjga6jn.17f...@guild.seebs.net...
>>> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>>>> That's why in the U.S. and Canada, we need a Programmer's Guild
>>>> (union).
>>>> The union rules would expressly forbid union members from working on
>>>> code
>>>> originally written in India or China. Let those folks *fix* the code
>>>> themselves!!! If employers don't like the way the Indians and Chinese
>>>> code,
>>>> well then they better think about hiring union programmers.
>
>>> This may well be one of the worst ideas I've ever heard.
>
>> "You got some splainin' to do, Ricky..."
>
> Anything that forbids people from *getting the fucking job done* is
> stupid.
>
> I have coworkers in China. They work on my code, I work on theirs,
> everyone's happy. I have no problem with this.

That is what *benefits* employers who want to send the bulk of their work
overseas. My intention is *not* to reward employers for sending the work
overseas that people here could do just as well (or better).

>
> Basically, the idea comes across as nothing but reactionary racism and
> protectionism, and those are shitty economic strategies. There are good
> reasons to have cheap (and probably inexperienced) programmers do the bulk
> of a project, and bring in more skilled people to do the hard parts and
> fixups.
>

Like any union, protectionism is part of it. Unions are supposed to protect
the jobs of union members. Unions are a reaction to bad treatment and lack
of consideration for the workers who formed the union. It is *not* the best
way, but a way to organize the workers to have a voice and say in how the
business is run. China, by refusing to float the Yuan (their currency), is
engaging in a form of protectionism already. IMHO the US will *have* to
return to some degree of protectionism to protect jobs and the economy here.

> It also ignores the rapidly-increasing probability that the programmers in
> the US are the noobs and the people elsewhere are the good ones.
>

That is a different (but related) problem, and requires other solutions.

> It also creates a spectacularly stupid outcome, which is that anyone who
> has ever outsourced must never consider going back to a US-based
> development
> team.
>

Sure, those who outsourced *can* return to a US-based development team.
They just have to scrap all the code written overseas and start over with
*union* code.

> It also singles out India and China, ignoring all sorts of other places;
> no problem, load a couple hundred Chinese programmers on a train, have
> them do
> their coding somewhere else.
>

Sure, I did *not* mean to single out India and China. Any code *not*
written by union workers would be off-limits.

> In short:
> * It attempts to solve something which is not a problem.
> * It does not solve the stated problem.
> * It anti-solves the stated problem.
> * It does nothing about any of the more serious real issues.
> * It's really got nothing to recommend it but knee-jerk racism.
>

I disagree that the unions are *not* an attempt to solve the problems at
hand. You may feel repulsed by the idea, but I think it is a valid course
to consider. In any conflict between groups, it is easy to yell out
"racism!", but I think that is a red herring. Certainly there will be *no*
racial profiling for union members.

[David Dyer-Bennet]

When variable names were short and pretty much any combination of
letters was possible, I learned to block-print legibly (at least to
me).

Then variable names became longer, and mixed case. Luckily, I nearly
always coded directly into an editor then, because I never did learn to
print lower-case legibly. If I do put code on paper, I write much of it
cursively, and even I have to use a lot of inference to figure it out.

--
David Dyer-Bennet, dd...@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[David Dyer-Bennet]

Peter Flass <Peter...@Yahoo.com> writes:

> On 1/4/2012 3:44 PM, Charlie Gibbs wrote:
>> In article<m34nwc5...@garlic.com>, ly...@garlic.com
>> (Anne& Lynn Wheeler) writes:
>>
>>> Date: 10/27/82 16:55:11
>>> From: wheeler
>>>
>>> yep, you're right a CMS system with an average of 1sec. response for
>>> edit commands would be a sick system.
>
> I don't think I've *ever* worked on a system from *anyone*, except
> peecees. that had a 1sec average response time. Maybe CMS on a local
> terminal at 3:00am when no one else was on, but my guesstimate would
> be from a few seconds on up to minutes for various systems.
> ...

That sounds really awful. Might as well use remote batch.

At normal loads, TSS-8 and RSTS-11 and TOPS-20 could all delete a file
or produce a file listing of a non-monster directory in that kind of
timeframe. Or perform most screen editor functions. Compiling a big
project took longer, certainly.

For that matter, echoing characters went through the computer on all of
those, and it could certainly do that about instantly.

[David Dyer-Bennet]

"Charles Richmond" <net...@aquaporin4.com> writes:

> I worked with an older guy back in the 90's who used a set of colored
> pencils to "pencil up" his computer listings. The listings were
> printed on continuous-form paper that was run through a dot-matrix
> printer... *not* like the individual pagination produced by a laser
> printer or ink jet printer. So I think some of the programming
> techniques of the 60's and 70's will endure... as long as there are
> programmers from those eras still living and working.

I miss being able to mark up my screen that way; I've sometimes printed
segments of code I need to really analyze on paper for that purpose. (I
date to the 60s, just barely; started programming professionally in
1969).

> When I was studying programming in college in the late 70's, typing
> one's program directly into the terminal without first writing it out
> on a piece of paper... was disparaged. The only time I felt it
> necessary to write out a program on paper... was when programming in
> assembly language. Somehow it felt more comfortable to write it out
> on paper first.

Strange, by the mid 70s I was coding directly on the terminal a lot of
the time (sometimes from architecture diagrams and things), and I
thought of that as quite common. Writing code out on paper was made fun
of.

[David Dyer-Bennet]

Peter Flass <Peter...@Yahoo.com> writes:

> There are lots of CLIs, ranging from the above systems to PDP-10
> systems where you could press (ESC?) at any time to have the system
> provide choices of what you needed to type next up to VAX DCL with a
> rational language design and lots of online help.

Command (and filename) completion I think of as a TOPS-20 feature; same
hardware, but very different OS. It was all in the COMND JSYS.

[Charles Richmond]

"David Dyer-Bennet" <dd...@dd-b.net> wrote in message
news:ylfk1urd...@dd-b.net...

> Peter Flass <Peter...@Yahoo.com> writes:
>
>> On 1/4/2012 3:44 PM, Charlie Gibbs wrote:
>>> In article<m34nwc5...@garlic.com>, ly...@garlic.com
>>> (Anne& Lynn Wheeler) writes:
>>>
>>>> Date: 10/27/82 16:55:11
>>>> From: wheeler
>>>>
>>>> yep, you're right a CMS system with an average of 1sec. response for
>>>> edit commands would be a sick system.
>>
>> I don't think I've *ever* worked on a system from *anyone*, except
>> peecees. that had a 1sec average response time. Maybe CMS on a local
>> terminal at 3:00am when no one else was on, but my guesstimate would
>> be from a few seconds on up to minutes for various systems.
>> ...
>
> That sounds really awful. Might as well use remote batch.
>
> At normal loads, TSS-8 and RSTS-11 and TOPS-20 could all delete a file
> or produce a file listing of a non-monster directory in that kind of
> timeframe. Or perform most screen editor functions. Compiling a big
> project took longer, certainly.
>
> For that matter, echoing characters went through the computer on all of
> those, and it could certainly do that about instantly.

ISTM that DECsystem-20's used a PDP-11 as a front end. The PDP-11 did the
character echo instead of the main CPU doing it.

[hanc...@bbs.cpcn.com]

On Jan 5, 4:13 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> Other annoyances in input:
>
> - Systems which for no good reason want you to input your first name
>   and last name in separate fields. I.e. when they have no reason to
>   generate alphabetical listings.

There are unexpected times when it is desirable to alphabetize by name
a listing.

> - Systems which "validate" email addresses according to bogus

>   rules. Like all the systems which don't accept grahn+n...@snipabacken.se

>   because of the '+'. Is it that hard to read RFC 822?

Agreed. Often there is too rigid editing and there are real life
exceptions.

In a system I did we set up warning messages. For example, if a zip
code or area code was out of our serving area, we cited it as a
possible error, but the operator could override the error. This
enhanced accuracy as it did catch typos but accomodated special
situations.

> - Internet banking. You pay a bill by typing in its unique ID. After
>   10+ years experience, most companies still use IDs of 12 digits or
>   more -- as if they plan to issue a hundred billion unique bills.

Most long strings of account numbers contain various hierarchies.

The US Social Security number once contained many hierarchies but some
have had to be abandoned due to the shortage of numbers. Sooner or
later they're have to go to a longer number.

[Seebs]

On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
> That is what *benefits* employers who want to send the bulk of their work
> overseas. My intention is *not* to reward employers for sending the work
> overseas that people here could do just as well (or better).

Not rewarding them is one thing; trying to create artificial inefficiencies
to penalize them, however, is another.

> Like any union, protectionism is part of it.

Protectionism is generally a Bad Deal.

> It is *not* the best
> way, but a way to organize the workers to have a voice and say in how the
> business is run. China, by refusing to float the Yuan (their currency), is
> engaging in a form of protectionism already. IMHO the US will *have* to
> return to some degree of protectionism to protect jobs and the economy here.

I dunno. My job's a lot safer now than it used to be, because the company I
work for is getting more done, and now I can focus on hard problems instead
of wasting a bunch of time on easy problems.

> That is a different (but related) problem, and requires other solutions.

It doesn't need a solution. It is the state we're aiming for -- one where
there are both good and bad programmers everywhere.

>> It also creates a spectacularly stupid outcome, which is that anyone who
>> has ever outsourced must never consider going back to a US-based
>> development
>> team.

> Sure, those who outsourced *can* return to a US-based development team.
> They just have to scrap all the code written overseas and start over with
> *union* code.

Which is to say, *IN REALITY*, they can't, because they can't afford to scrap
everything and start over.

Like a lot of naive ideas for organizing labor, this one runs afoul of the
law of unintended consequences. What it actually does is ensure that moving
things offshore is ALWAYS a one-way trip. In the current market, companies
can move stuff back if they are unhappy with the offshore stuff.

> Sure, I did *not* mean to single out India and China. Any code *not*
> written by union workers would be off-limits.

Oh, fuck that. Fuck that with the set of all subsets of the set of
all rusty metal implements.

Not interested. I will never, ever, join a group that mandates something
like that. That's evil. Pure and simple. It creates a set of people who
are prevented from working jobs they could do competently, and I am not
okay with that.

> I disagree that the unions are *not* an attempt to solve the problems at
> hand.

Your proposed solution does nothing to really solve the alleged problem of
outsourcing.

> You may feel repulsed by the idea, but I think it is a valid course
> to consider.

It's valid to consider, but if the consideration doesn't yield "I cannot tell
whether that's more stupid than evil, or more evil than stupid, but either way
it makes the sum total of the sins of middle management towards software
engineers look pathetic and weak by comparison", then something is very wrong.

> In any conflict between groups, it is easy to yell out
> "racism!", but I think that is a red herring. Certainly there will be *no*
> racial profiling for union members.

So what happens if everyone in India and China signs up for the union? For it
to have the desired outcome of "preventing outsourcing", it has to exclude them.

[Walter Bushell]

In article
<5ef6b052-e33f-4c09...@m10g2000vbc.googlegroups.com>,

hanc...@bbs.cpcn.com wrote:

> The US Social Security number once contained many hierarchies but some
> have had to be abandoned due to the shortage of numbers. Sooner or
> later they're have to go to a longer number.

I heard that by knowing your birthdate and place they could pin down
your SS number especially if they knew the last 4 digits.
Fortunaterly[1] for me, I was in a cohort that did not need to be
registered at birth and was not registered near my birthplace or current
place of residence.

[thus]

[hanc...@bbs.cpcn.com]

On Jan 4, 10:09 pm, "Charles Richmond" <netn...@aquaporin4.com> wrote:

> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
> The union rules would expressly forbid union members from working on code
> originally written in India or China.  Let those folks *fix* the code
> themselves!!!  If employers don't like the way the Indians and Chinese code,
> well then they better think about hiring union programmers.

The experience in other unionized industries has shown that in the
short-term the above would work, but in the long term it would only
inspire _more_ work to be farmed out overseas. An _excessively
strong_ union would end up pricing itself out of business.

What I find curious is that back in the 1970s, when programmers were
in great demand, quite a few programmers were quite willing to work in
lousy conditions (others certainly did jump ship to better shops, but
many did not). I knew lots of people who suffered with frequent late
night phone calls about problems not their doing, lots of unpaid
overtime, and nasty old-style bosses. Those people certainly could've
used a union.

Back then, when more workers overall were unionized, a few shops had
unionized programmers, but that was rare. A few more places had
unionized computer operators and clerks while the programmers were not
union.

I do remember back then a number of shops were very rigidly structured
with rules/protocols/procedures and job assignments. One couldn't pee
without filling out paperwork. Management spent more time worrying
about compliance with procedure than whether the system actually
served the end-user. I would not have wanted to work in such a place.

[Rod Speed]

Charles Richmond wrote
> Stan Barr <pla...@dsl.pipex.com> wrote

>> Charles Richmond <net...@aquaporin4.com> wrote:

>>> I worked with an older guy back in the 90's who used a set of
>>> colored pencils to "pencil up" his computer listings. The listings

>>> were printed on continuous-form paper that was run through a dot-matrix printer...*not* like the individual

>>> pagination produced by a laser printer or ink jet printer. So I think some of the programming techniques of the
>>> 60's and 70's will endure... as long as there are programmers from those eras still living
>>> and working.

>> Why do you think I have an old dot-matrix printer plugged into the
>> print server along with the laserjet and an inkjet? :-)
>> I'm obviuosly getting old...

> IMHO, if one is going to pour over a source listing of a program, the
> dot-matrix printer is the only way to go!!! At a PPoE, I remember a
> young lady who printed out her program... and spread the listing out
> on the floor of her office, where she could view considerably more
> than a single page at a time. Also, the dot-matrix listings have the
> "flavor" (or "flavour") of a working document, and do *not* attempt
> to look like a polished and completed text. As the comedian Flip
> Wilson used to say: "The good old ways is still the best!!!"

Doesnt work too well with chiselled stone or clay tablets tho.

Or hand written on parchment either.

[Rod Speed]

David Dyer-Bennet wrote
> Charles Richmond <net...@aquaporin4.com> wrote

>> I worked with an older guy back in the 90's who used a set of
>> colored pencils to "pencil up" his computer listings. The listings were
>> printed on continuous-form paper that was run through a dot-matrix
>> printer... *not* like the individual pagination produced by a laser
>> printer or ink jet printer. So I think some of the programming
>> techniques of the 60's and 70's will endure... as long as there are
>> programmers from those eras still living and working.

> I miss being able to mark up my screen that way;

I dont, I prefer to write the code so that that isnt necessary.

> I've sometimes printed segments of code I need
> to really analyze on paper for that purpose.

I dont ever do that.

> (I date to the 60s, just barely; started programming professionally in 1969).

I started well before that.

>> When I was studying programming in college in the late 70's, typing
>> one's program directly into the terminal without first writing it out
>> on a piece of paper... was disparaged. The only time I felt it
>> necessary to write out a program on paper... was when programming in
>> assembly language. Somehow it felt more comfortable to write it out
>> on paper first.

> Strange, by the mid 70s I was coding directly on the terminal a lot of the
> time (sometimes from architecture diagrams and things), and I thought
> of that as quite common. Writing code out on paper was made fun of.

Yeah, me too, in the 60s and almost never with architecture diagrams either.

[Seebs]

On 2012-01-05, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Jan 4, 10:09?pm, "Charles Richmond" <netn...@aquaporin4.com> wrote:
>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>> The union rules would expressly forbid union members from working on code

>> originally written in India or China. ?Let those folks *fix* the code
>> themselves!!! ?If employers don't like the way the Indians and Chinese code,

>> well then they better think about hiring union programmers.

(I leave this quoted to make it clear that the original proposal was absolutely
based on region, and effectively on race, and had no provisions for, say,
union members in other countries. I note also that Canada is included, but not
Mexico.)

> What I find curious is that back in the 1970s, when programmers were
> in great demand, quite a few programmers were quite willing to work in
> lousy conditions (others certainly did jump ship to better shops, but
> many did not).

I think this may have been in part because the market wasn't yet established.
Now...

The basic purpose of a union is to increase the cost of pissing off the workers.
If you can just replace someone, that cost is low, so a union artificially
raises it.

Programmers cannot be trivially replaced, and companies that don't figure this
out suffer for it.

> I do remember back then a number of shops were very rigidly structured
> with rules/protocols/procedures and job assignments. One couldn't pee
> without filling out paperwork. Management spent more time worrying
> about compliance with procedure than whether the system actually
> served the end-user. I would not have wanted to work in such a place.

This kind of stuff makes life a lot less pleasant for programmers.

Net result: The hypothetical union offers low benefits and high costs because
it conflicts with the nature of the work.

[Bernard Peek]

On 05/01/12 20:15, Seebs wrote:

>> Like any union, protectionism is part of it.
>
> Protectionism is generally a Bad Deal.

Those who fail to learn from history are doomed to repeat it. If we've
learned sone thing in the last century is that protectionism is a really
dumb idea.

All it does is force prices up by subsidising unprofitable industries.
If an industry can't survive without it then shut it down. Use half the
savings to retrain the workers that get laid off and half to pay a
reasonable unemployment benefit. Meanwhile the workers should be
supported by their union until they have a new career. If the union
hasn't warned the workers that their career is toast then they haven't
done what they are paid for.



--
Bernard Peek
b...@shrdlu.com

[Anne & Lynn Wheeler]

Bernard Peek <b...@shrdlu.com> writes:
> Those who fail to learn from history are doomed to repeat it. If we've
> learned sone thing in the last century is that protectionism is a really
> dumb idea.
>
> All it does is force prices up by subsidising unprofitable industries.
> If an industry can't survive without it then shut it down. Use half the
> savings to retrain the workers that get laid off and half to pay a
> reasonable unemployment benefit. Meanwhile the workers should be
> supported by their union until they have a new career. If the union
> hasn't warned the workers that their career is toast then they haven't
> done what they are paid for.

recent posts in this thread:
http://www.garlic.com/~lynn/2012.html#11 Who originated the phrase "user-friendly"?
http://www.garlic.com/~lynn/2012.html#12 Who originated the phrase "user-friendly"?
http://www.garlic.com/~lynn/2012.html#15 Who originated the phrase "user-friendly"?

there was article in the early 80s (washington post?) calling for 100%
unearned profit tax on the US auto industry. In theory, congress imposed
foreign quotas to reduce competition to give the industry profit that
they would use to completely remake themselves. Instead they pocketed
the money and continued business as usual.

circa 1990, the industry had C4 taskforce to look at completely remake
themselves (finally?). They were planning on heavily leveraging
technology and so invited technology vendors to send participants. They
could articulate all the problems (including foreign competition was
significantly more agile and adaptable) and what needed to be
done. However, as seen, they still weren't able to follow through.

misc past posts mentioning call for 100% unearned profit tax
and/or C4 taskforce:
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#22 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests
http://www.garlic.com/~lynn/2006.html#23 auto industry
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)
http://www.garlic.com/~lynn/2007j.html#33 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#88 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#11 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#24 IBM Unionization
http://www.garlic.com/~lynn/2008.html#28 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#39 competitiveness
http://www.garlic.com/~lynn/2008.html#84 Toyota Sales for 2007 May Surpass GM
http://www.garlic.com/~lynn/2008p.html#77 Tell me why the taxpayer should be saving GM and Chrysler (and Ford) managers & shareholders at this stage of the game?
http://www.garlic.com/~lynn/2008q.html#22 Is Pride going to decimate the auto Industry?
http://www.garlic.com/~lynn/2008r.html#63 Have you told your Congressman how to VOTE on the auto bailout?
http://www.garlic.com/~lynn/2008s.html#18 What next? from where would the Banks be hit?
http://www.garlic.com/~lynn/2008s.html#20 Five great technological revolutions
http://www.garlic.com/~lynn/2008s.html#57 Garbage in, garbage out trampled by Moore's law
http://www.garlic.com/~lynn/2009f.html#20 What is the real basis for business mess we are facing today?
http://www.garlic.com/~lynn/2009i.html#2 China-US Insights on the Future of the Auto Industry
http://www.garlic.com/~lynn/2009i.html#3 IBM interprets Lean development's Kaizen with new MCIF product
http://www.garlic.com/~lynn/2009i.html#31 Why are z/OS people reluctant to use z/OS UNIX?
http://www.garlic.com/~lynn/2010b.html#14 360 programs on a z/10
http://www.garlic.com/~lynn/2010e.html#47 z9 / z10 instruction speed(s)
http://www.garlic.com/~lynn/2010f.html#55 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010f.html#70 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010h.html#8 Far and near pointers on the 80286 and later
http://www.garlic.com/~lynn/2010i.html#75 Favourite computer history books?
http://www.garlic.com/~lynn/2010k.html#0 Idiotic programming style edicts
http://www.garlic.com/~lynn/2010o.html#22 60 Minutes News Report:Unemployed for over 99 weeks!
http://www.garlic.com/~lynn/2010o.html#59 They always think we don't understand
http://www.garlic.com/~lynn/2010p.html#23 They always think we don't understand
http://www.garlic.com/~lynn/2011e.html#21 End of an era
http://www.garlic.com/~lynn/2011e.html#90 PDCA vs. OODA
http://www.garlic.com/~lynn/2011f.html#2 Car models and corporate culture: It's all lies
http://www.garlic.com/~lynn/2011i.html#35 Having left IBM, seem to be reminded that IBM is not the same IBM I had joined
http://www.garlic.com/~lynn/2011j.html#34 Boyd's Reading List Revisited
http://www.garlic.com/~lynn/2011l.html#35 The Next Convergence: The Future of Economic Growth in a Multispeed World
http://www.garlic.com/~lynn/2011l.html#73 computer bootlaces
http://www.garlic.com/~lynn/2011n.html#65 Soups
http://www.garlic.com/~lynn/2011n.html#81 A Close Look at the Perry Tax Plan
http://www.garlic.com/~lynn/2011n.html#86 PDCA vs. OODA
http://www.garlic.com/~lynn/2011p.html#52 Has anyone successfully migrated off mainframes?

--
virtualization experience starting Jan1968, online at home since Mar1970

[D.J.]

On Thu, 05 Jan 2012 08:06:04 -0500, Peter Flass
<Peter...@Yahoo.com> wrote:
>On 1/4/2012 11:18 PM, hanc...@bbs.cpcn.com wrote:
>> On Jan 4, 5:55 pm, Peter Flass<Peter_Fl...@Yahoo.com> wrote:
>>
>>> What could be more user-friendly than a pencil and paper?
>>
>> Try reading my handwriting. (Heck, not even my typing is so great.)
>>
>>
>
>Mine's pretty bad now too, but back in the day I printed pretty neatly
>on coding forms.

I work in tech support, spending over 90 percent of my time on a
computer typing. My hand writting is difficult for me to read.
.
JimP.
--
Brushing aside the thorns so I can see the stars.
http://www.linuxgazette.net/ Linux Gazette
http://www.drivein-jim.net/ Drive-In movie theaters
http://story.drivein-jim.net/ A story Feb, 2011

[Gene Wirchenko]

On Thu, 05 Jan 2012 11:34:20 +0000, Nick Spalding <spal...@iol.ie>
wrote:

[snip]

>An old colleague of mine called programming a craft which would make a
>guild the appropriate organisation.

An intructor of mine called it part science, part art, and part
craft (as in witchcraft).

[snip]

Sincerely,

Gene Wirchenko

[Charles Richmond]

"Bernard Peek" <b...@shrdlu.com> wrote in message
news:4f061ebb$0$2491$db0f...@news.zen.co.uk...

And what about China's protectionism??? By refusing the float the Yuan,
they are keeping their labor costs artificially *low*. That is a form of
protectionism. So how about parity... we match their protectionism with
protectionism of our own.

[Charles Richmond]

"Seebs" <usenet...@seebs.net> wrote in message

news:slrnjgc31r.24o...@guild.seebs.net...

> On 2012-01-05, Charles Richmond <net...@aquaporin4.com> wrote:
>> That is what *benefits* employers who want to send the bulk of their work
>> overseas. My intention is *not* to reward employers for sending the work
>> overseas that people here could do just as well (or better).
>
> Not rewarding them is one thing; trying to create artificial
> inefficiencies
> to penalize them, however, is another.
>
>> Like any union, protectionism is part of it.
>
> Protectionism is generally a Bad Deal.
>

This is the way unions have *always* worked. A union seems the only way to
let the rank and file worker have a voice in how the business is run. You
think the rank and file *don't* have the right to such.... I think they do.

>> It is *not* the best
>> way, but a way to organize the workers to have a voice and say in how the
>> business is run. China, by refusing to float the Yuan (their currency),
>> is
>> engaging in a form of protectionism already. IMHO the US will *have* to
>> return to some degree of protectionism to protect jobs and the economy
>> here.
>
> I dunno. My job's a lot safer now than it used to be, because the company
> I
> work for is getting more done, and now I can focus on hard problems
> instead
> of wasting a bunch of time on easy problems.
>

In reality, you do *not* know how safe your job is. You are at the mercy of
the company you work for. And *you* are *not* the only person in the world
concerned with having a job. Just because you may now have a nice job, how
about the millions put out of work by outsourcing to overseas venues???

>> That is a different (but related) problem, and requires other solutions.
>
> It doesn't need a solution. It is the state we're aiming for -- one where
> there are both good and bad programmers everywhere.
>

I think it is very desirable to have most all the programmers be competent.

>>> It also creates a spectacularly stupid outcome, which is that anyone who
>>> has ever outsourced must never consider going back to a US-based
>>> development
>>> team.
>
>> Sure, those who outsourced *can* return to a US-based development team.
>> They just have to scrap all the code written overseas and start over with
>> *union* code.
>
> Which is to say, *IN REALITY*, they can't, because they can't afford to
> scrap
> everything and start over.

Gee, those companies should have thought of that before they dumped their US
employees.

>
> Like a lot of naive ideas for organizing labor, this one runs afoul of the
> law of unintended consequences. What it actually does is ensure that
> moving
> things offshore is ALWAYS a one-way trip. In the current market,
> companies
> can move stuff back if they are unhappy with the offshore stuff.
>

No, it means that companies will be much *less* likely to move programming
offshore.

>> Sure, I did *not* mean to single out India and China. Any code *not*
>> written by union workers would be off-limits.
>
> Oh, fuck that. Fuck that with the set of all subsets of the set of
> all rusty metal implements.
>

You are entitled to *your* opinion... but that's what it is, *your* opinion.
The louder and more vociferously you state it... you get *no* more points
for that. :-)

> Not interested. I will never, ever, join a group that mandates something
> like that. That's evil. Pure and simple. It creates a set of people who
> are prevented from working jobs they could do competently, and I am not
> okay with that.
>

Okay, so *you* do *not* join or support a union for programmers. In fact,
please continue to state your opposition to such. And I will continue with
my support of the idea.

>> I disagree that the unions are *not* an attempt to solve the problems at
>> hand.
>
> Your proposed solution does nothing to really solve the alleged problem of
> outsourcing.
>
>> You may feel repulsed by the idea, but I think it is a valid course
>> to consider.
>
> It's valid to consider, but if the consideration doesn't yield "I cannot
> tell
> whether that's more stupid than evil, or more evil than stupid, but either
> way
> it makes the sum total of the sins of middle management towards software
> engineers look pathetic and weak by comparison", then something is very
> wrong.
>
>> In any conflict between groups, it is easy to yell out
>> "racism!", but I think that is a red herring. Certainly there will be
>> *no*
>> racial profiling for union members.
>
> So what happens if everyone in India and China signs up for the union?
> For it
> to have the desired outcome of "preventing outsourcing", it has to exclude
> them.
>

Okay, we'll make it a Canada/U.S. union... to join, you must be a Canadian
or U.S. citizen.

[Seebs]

On 2012-01-06, Charles Richmond <net...@aquaporin4.com> wrote:
> This is the way unions have *always* worked. A union seems the only way to
> let the rank and file worker have a voice in how the business is run. You
> think the rank and file *don't* have the right to such.... I think they do.

No, I don't think they don't have the right to it. I just think that, if
workers are not fundamentally interchangeable, a union will do them a lot
more harm than good.

> In reality, you do *not* know how safe your job is. You are at the mercy of
> the company you work for.

True enough.

> And *you* are *not* the only person in the world
> concerned with having a job. Just because you may now have a nice job, how
> about the millions put out of work by outsourcing to overseas venues???

And how about the millions who aren't out of work because that outsourcing
reduced costs enough to let a business stay afloat and keep them employed?

You seem to be doing the thing everyone does when they first encounter
economics, which is count exactly and only the effects you can point to
directly.

Think about this: Someone smashes a window. That means employment for
glassmakers, right? So that's good! ... Only, that evaluation doesn't
take into account *what that money would otherwise have been spent on*.

> I think it is very desirable to have most all the programmers be competent.

That sounds lovely, but it's also obviously impossible; if nothing else, there
will always be newbies.

>> Which is to say, *IN REALITY*, they can't, because they can't afford to
>> scrap
>> everything and start over.

> Gee, those companies should have thought of that before they dumped their US
> employees.

But they didn't. And we are in this world, not some hypothetical world where
things were otherwise. And in this world, imposing that rule just means
even MORE offshored work, and even LESS local work.

> No, it means that companies will be much *less* likely to move programming
> offshore.

No, it fucking doesn't.

Virtually all the code anyone cares about HAS ALREADY been touched by Chinese
or Indian programmers. Either people restart from scratch, or they're dead.

And think about open source projects for a moment. Do you really think anyone
would win if we decided that US and Canadian programmers could never work on
Linux or BSD?

>> Oh, fuck that. Fuck that with the set of all subsets of the set of
>> all rusty metal implements.

> You are entitled to *your* opinion... but that's what it is, *your* opinion.

And also basic economics.

> Okay, so *you* do *not* join or support a union for programmers. In fact,
> please continue to state your opposition to such. And I will continue with
> my support of the idea.

Yeah, you do that. And may I recommend to your attention any economics textbook
ever? Because I think even basic exposure to how economies work would help you
here. As would knowing the phrase "law of unintended consequences".

> Okay, we'll make it a Canada/U.S. union... to join, you must be a Canadian
> or U.S. citizen.

Fuck you and the racist horse you rode in on.

Sorry, but the fact is this:

I have Chinese coworkers, and they do good work. You do nothing but bitch about
colored people stealing jobs. If the computer industry is to do without one or
the other of these groups, well. I'm glad I know a little Chinese.

[Seebs]

On 2012-01-06, Charles Richmond <net...@aquaporin4.com> wrote:

> And what about China's protectionism???

It hurts them.

> By refusing the float the Yuan,
> they are keeping their labor costs artificially *low*. That is a form of
> protectionism. So how about parity... we match their protectionism with
> protectionism of our own.

It's been tried. It turns out to be worse than just letting people shoot
themselves in the foot at our expense. We would be *worse* off if we did
it.

Counterintuitive, maybe, but pretty well researched.

Anyway, even if we were to consider protectionism, your proposed scheme would
just move projects to China permanently. Seriously, think about it. Someone's
got $30M invested in a project. If they want to use union programmers, they
have to start from scratch and spend at least $50M before they have *anything
at all*. If they just use Chinese programmers, they already have a working
project and they can get it improved at least some for another $5M.

[Rod Speed]

Charles Richmond wrote
> Seebs <usenet...@seebs.net> wrote

>> Charles Richmond <net...@aquaporin4.com> wrote

>>> That is what *benefits* employers who want to send the bulk of their work overseas. My intention is *not* to reward
>>> employers for sending the work overseas that people here could do just as well (or better).

>> Not rewarding them is one thing; trying to create artificial
>> inefficiencies to penalize them, however, is another.

>>> Like any union, protectionism is part of it.

>> Protectionism is generally a Bad Deal.

> This is the way unions have *always* worked.

Yes, and thats why hardly any engineers have ever been stupid enough to join one.

> A union seems the only way to let the rank and file worker have a voice in how the business is run.

Wrong. They are always free to work for someone
who has a clue about how to run a business.

> You think the rank and file *don't* have the right to such....

Wrong.

> I think they do.

Your problem.

>>> It is *not* the best way, but a way to organize the workers to have a voice and say in how the business is run.
>>> China, by refusing to float the Yuan (their currency), is engaging in a form of protectionism already. IMHO the US
>>> will *have* to return to some degree of protectionism to protect jobs and the economy here.

>> I dunno. My job's a lot safer now than it used to be, because the
>> company I work for is getting more done, and now I can focus on hard problems instead of wasting a bunch of time on
>> easy problems.

> In reality, you do *not* know how safe your job is. You are at the mercy of the company you work for.

Nope, you can always work for someone else if they dont have a clue.

> And *you* are *not* the only person in the world concerned with having a job.

Yes, but there are always plenty of jobs for those who do know what they are doing.

> Just because you may now have a nice job, how about the millions put out of work by outsourcing to overseas venues???

Thats their problem for being stupid enough to not realise that
that sort of work is so trivially exportable and that plenty of
those outside the country can do it just as well as they can.

>>> That is a different (but related) problem, and requires other solutions.

>> It doesn't need a solution. It is the state we're aiming for -- one
>> where there are both good and bad programmers everywhere.

> I think it is very desirable to have most all the programmers be competent.

Yes, but only a fool would claim that no foreigner ever is.

>>>> It also creates a spectacularly stupid outcome, which is that anyone who has ever outsourced must never consider
>>>> going back to a US-based development team.

>>> Sure, those who outsourced *can* return to a US-based development team. They just have to scrap all the code written
>>> overseas and start over with *union* code.

>> Which is to say, *IN REALITY*, they can't, because they can't afford to scrap everything and start over.

> Gee, those companies should have thought of that before they dumped their US employees.

Nope, they have enough of a clue to realise that plenty
of non US employees know what they are doing.

>> Like a lot of naive ideas for organizing labor, this one runs afoul
>> of the law of unintended consequences. What it actually does is
>> ensure that moving things offshore is ALWAYS a one-way trip. In the current market, companies can move stuff back if
>> they are unhappy with the offshore stuff.

> No, it means that companies will be much *less* likely to move
> programming offshore.

Wrong, as always. They realise that you union goons never matter a damn.

>>> Sure, I did *not* mean to single out India and China. Any code *not* written by union workers would be off-limits.

>> Oh, fuck that. Fuck that with the set of all subsets of the set of all rusty metal implements.

> You are entitled to *your* opinion... but that's what it is, *your* opinion.

Corse yours isnt anything like that, eh ?

> The louder and more vociferously you state it... you get *no* more points for that. :-)

Corse yours isnt anything like that, eh ?

>> Not interested. I will never, ever, join a group that mandates
>> something like that. That's evil. Pure and simple. It creates a set of people who are prevented from working jobs
>> they could do competently, and I am not okay with that.

> Okay, so *you* do *not* join or support a union for programmers.

Just as true of almost all programmers.

> In fact, please continue to state your opposition to such. And I will continue with my support of the idea.

And hardly any programmers or engineers agree with you on that.

>>> I disagree that the unions are *not* an attempt to solve the problems at hand.

>> Your proposed solution does nothing to really solve the alleged problem of outsourcing.

>>> You may feel repulsed by the idea, but I think it is a valid course to consider.

>> It's valid to consider, but if the consideration doesn't yield "I cannot tell
>> whether that's more stupid than evil, or more evil than stupid, but either way
>> it makes the sum total of the sins of middle management towards
>> software engineers look pathetic and weak by comparison", then
>> something is very wrong.

>>> In any conflict between groups, it is easy to yell out
>>> "racism!", but I think that is a red herring. Certainly there will
>>> be *no* racial profiling for union members.

>> So what happens if everyone in India and China signs up for the union? For it
>> to have the desired outcome of "preventing outsourcing", it has to exclude them.

> Okay, we'll make it a Canada/U.S. union... to join, you must be a Canadian or U.S. citizen.

All you need now is jackboots and concentration camps and crematoria.

Seig Heil.

[Peter Flass]

On 1/5/2012 2:55 PM, David Dyer-Bennet wrote:
> Peter Flass<Peter...@Yahoo.com> writes:
>
>> On 1/4/2012 3:44 PM, Charlie Gibbs wrote:
>>> In article<m34nwc5...@garlic.com>, ly...@garlic.com
>>> (Anne& Lynn Wheeler) writes:
>>>
>>>> Date: 10/27/82 16:55:11
>>>> From: wheeler
>>>>
>>>> yep, you're right a CMS system with an average of 1sec. response for
>>>> edit commands would be a sick system.
>>
>> I don't think I've *ever* worked on a system from *anyone*, except
>> peecees. that had a 1sec average response time. Maybe CMS on a local
>> terminal at 3:00am when no one else was on, but my guesstimate would
>> be from a few seconds on up to minutes for various systems.
>> ...
>
> That sounds really awful. Might as well use remote batch.
>
> At normal loads, TSS-8 and RSTS-11 and TOPS-20 could all delete a file
> or produce a file listing of a non-monster directory in that kind of
> timeframe. Or perform most screen editor functions. Compiling a big
> project took longer, certainly.
>
> For that matter, echoing characters went through the computer on all of
> those, and it could certainly do that about instantly.

Most of my employers tended to keep systems too long. Even if a system
started out with halfway-decent response time (and TSO never had even
halfway-decent) response really dragged after a year or two. A lot of
my background has been in academia, where the systems were often
underpowered when installed and got much worse later. Many places
practiced "load shedding" by telling programmers not to log on or run
jobs at certain times. Since this was my experience at several
employers over many years I can't believe it was atypical. Of course in
the early days I was happy just to get terminal access so I could do
trivial stuff without having to submit a batch job and wait, often
overnight.

[Peter Flass]

You have to be a licensed engineer to design a bridge. You have to have
a license to be a stockbroker. We should have had licensing for prog^H
"systems engineers" a long time ago. You can't run code on the web
that's not written by a licensed systems engineer.

[Peter Flass]

On 1/5/2012 4:43 PM, Seebs wrote:
> On 2012-01-05, hanc...@bbs.cpcn.com<hanc...@bbs.cpcn.com> wrote:
>> On Jan 4, 10:09?pm, "Charles Richmond"<netn...@aquaporin4.com> wrote:
>>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>>> The union rules would expressly forbid union members from working on code
>>> originally written in India or China. ?Let those folks *fix* the code
>>> themselves!!! ?If employers don't like the way the Indians and Chinese code,
>>> well then they better think about hiring union programmers.
>
> (I leave this quoted to make it clear that the original proposal was absolutely
> based on region, and effectively on race, and had no provisions for, say,
> union members in other countries. I note also that Canada is included, but not
> Mexico.)

There are lots of people of Indian and Chinese descent in the US. I
don't think OP intended to slight them. I don't know enough about
Indian programmers to comment, I suspect they're pretty good. I have
three problems with anything from China:
1. They're clueless. In manufacturing they sometimes do things that
are harmful or dangerous because they don't know enough to understand
the potential problems (e.g lead paint).
2. Worse than the above they often cut corners to make a fast buck.
This isn't just a problem with China, but has to do with inspections,
etc. For example I prefer to buy toys made in the EU over those from
anywhere else because they're safety regulations and inspections are
stricter.
3. I don't trust the government there. Even if the programmers are
good, conscientious and ethical, what's to prevent the government from
demanding access to confidential information and/or forcing them to put
trojan horses into the code. Of course I believe *our* government does
this too, but they're supposed to be on our side.

>
>> What I find curious is that back in the 1970s, when programmers were
>> in great demand, quite a few programmers were quite willing to work in
>> lousy conditions (others certainly did jump ship to better shops, but
>> many did not).
>
> I think this may have been in part because the market wasn't yet established.
> Now...

Back then it was all new and exciting. The working environment wasn't
as important as the project (at least IMHO). We put up with a lot to
get to do something we thought was worthwhile.

>
> The basic purpose of a union is to increase the cost of pissing off the workers.
> If you can just replace someone, that cost is low, so a union artificially
> raises it.
>
> Programmers cannot be trivially replaced, and companies that don't figure this
> out suffer for it.

That's the basis of the current problem. Programmers were respected in
the olden days, now they're just cattle. (I say "they" rather than "we"
because I now work for myself)

>
>> I do remember back then a number of shops were very rigidly structured
>> with rules/protocols/procedures and job assignments. One couldn't pee
>> without filling out paperwork. Management spent more time worrying
>> about compliance with procedure than whether the system actually
>> served the end-user. I would not have wanted to work in such a place.
>
> This kind of stuff makes life a lot less pleasant for programmers.
>
> Net result: The hypothetical union offers low benefits and high costs because
> it conflicts with the nature of the work.
>

I have mixed feelings about unions (I have been in them at various
times), I have even seen places where programmers belonged to the
union. In many places they're a protection against arbitrary bosses,
dangerous working conditions, sexual harassment, etc. Unfortunately
they're in a trap. If an employer wants to fire an obviously
incompetent employee the union has to defend him. First, they fill the
same role as a defense lawyer who defends innocent and guilty clients
equally, second, they can't be seen throwing one of their members to the
wolves if they want to keep their union jobs.

Companies can avoid unionization by treating their employees well.

Unions are not always the problem. Bob Lutz (_Car Guys vs. Bean
Counters_) admits the unionized auto workers didn't want to be slackers;
they wanted to do good work but often the employers prevented this by
their bogus cost-saving.

[David Dyer-Bennet]

It did, for directly-connected terminals (non-LAT).

And in fact the DH-11 terminal interface was actually doing the echo
most of the time at that level, before the character was even read into
the OS.

[Charlie Gibbs]

In article
<f2add696-2223-42bb...@j9g2000vby.googlegroups.com>,
hanc...@bbs.cpcn.com (hancock4) writes:

> On Jan 4, 3:33 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> Unfortunately, much of this became a mystique, remnants of which
>> survive to this day.  Things have to made to look "computerish",
>> which usually means silly blocky typefaces with lots of upper case
>> and gratuitous leading zeros.
>
> In the outside world, making things "computerish" usually meant using
> the optical typeface, where numbers look like MICR characters on a
> check.

Yup. Nowadays new silly "modern-looking" fonts have to be created
because, ironically, that fake MICR looks so old-fashioned.

> In the computer world, everything was all uppercase since that's
> what machines could only understand, display, or print in typical
> applications. (Sure, you could get a lower case print chain and
> lower-case capable CRT, but it could be cumbersome for various
> reasons. Most of the time we had our trusty 1403 printer.)

That was a problem. (I loved using the keypunch's multi-punch key
to add extra zone bits to my password to make it lower-case, which
on most printers came out blank - although I'd throw in a few
truly unprintable characters as well.) But even when lower-case
capability became widespread, many people refused to use it.
Some still don't.

>>> Some online systems started the transaction with a command string
>>> that had to be precisely formatted and encoded.
>>
>> You dissin' CLIs, boy?  :-)
>
> I thank heaven I never had to use such systems. I've seen really
> convoluted long strings. I guess the operators who used them
> regularly got the hang of them, but they sure looked error prone
> and tedious.

ls -l `grep -i somestring *.c | cut -d: -f1 | sort | uniq`

>>> As computers got more horsepower programming could be more
>>> sophisticated and the user interface evolved.  Screens became easier
>>> to use.  I believe the original IBM 3270 terminal only had a few PF
>>> keys, but then later models went up to 12 then 24, making screen-to-
>>> screen navigation easier.
>>
>> Nevertheless, taking the number of PF keys as a figure of merit is
>> fraught with peril (ease of learning vs. ease of use again).
>
> Well, here's an example: in an old system, to navigate around one
> typed in a command code and there were several commands available (eg
> within the account or to the next account or back to the master menu,
> etc.) In the new system, PF keys did the word, and the last line of
> the screen was a reference.

Designed properly, it can be a good thing. But I still remember
firing up an early copy of Norton Utilities, looking at all the
function key selections (why function keys? why not normal characters?)
and thinking, "You are in a little twisty maze of menus, all different."

>>> Batch systems evolved, too.  One common example was the date check:
>>> instead of merely saying "INVALID DATE", it would be more specific,
>>> eg "INVALID MONTH", or, "DATE MAY NOT BE A FUTURE DATE", or,
>>> "APPLICATION DATE MUST BE GREATER THAN DATE OF BIRTH".
>>
>> It was definitely an improvement over error codes that had to be
>> looked up.  "404 - can't find the manual"  :-)
>
> Better still was "self explanatory".

<gasp> But that's not the Computer Way! Who's going to think
it's a sophisticated system if just anyone could understand it?

>> As a Canadian, the one I run into most often is trying to fit our
>> postal code (letter, digit, letter, space, digit, letter, digit)
>> into a 5- (or 9-) character zip code field that only accepts digits.
>
> With all due respect to our northern neighbor, I hate typing in
> Canadian zip codes. They're just not symetrical and require shifting
> and releasing. I find the letter digit combo confusing.

At least it didn't lead programmers into the trap of defining it
as a numeric field. (How would you describe a missing code?
Magic values are Evil.)

>>> Indeed, back in the early 1980s many people still used letters for
>>> their phone number, eg, KL 5-2358, and a computer required only
>>> numbers.)
>>
>> I remember being told that the letter prefixes (and associated
>> exchange names) made it easier to remember telephone numbers.
>> Ironically, during the switch to all-digit dialing, I once
>> read that the reason was to make it easier to remember.
>> Ah, the magical world of marketing...
>
> In large cities, phone numbers for manual exchanges were originally
> name+4, eg Parkway 2368. When they converted to dial, PARkway would
> convert to 727 (later PArkway 7). They felt 727-2368 would be hard
> to remember so they kept the name and added letters to the dial.

Where are the days of Auld Lang Syne?
Butterfield 8! Madison 9!
Let's keep those beautiful names alive!
Crestview 6! Gramercy 5!
Get ready to fight before it's too late!
Temple 2! Murray Hill 8!
Let's let 'em know that this means war!
Gettysburg 3! Concord 4! Hurray!

This is from Allan Sherman's "Let's All Call Up AT&T and Protest to
the President March" - which contained, among other things, the lines:

If he won't change the rules,
Let's take our business to another phone company.

...which in those days was as much a fantasy as arranging to
have the sun rise in the west for a change.

> Ironically, those same letters survive to this day for other uses.

Subject to minor modifications - where is Z this week?

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Charlie Gibbs]

In article <je33ol$ss9$1...@dont-email.me>, net...@aquaporin4.com

(Charles Richmond) writes:

> When I was studying programming in college in the late 70's, typing
> one's program directly into the terminal without first writing it
> out on a piece of paper... was disparaged. The only time I felt it
> necessary to write out a program on paper... was when programming in
> assembly language. Somehow it felt more comfortable to write it out
> on paper first.

Given the availability of terminals back in those days, taking the
time to compose a program directly on a terminal might have gotten
you lynched by the people waiting behind you in line to use it.
That's one of the nice things about the personal computer revolution -
you can now have your own computer for a fraction of what a mainframe
terminal cost back then.

On the other hand, one day when a keypunch was free I sat down and
composed a 100-line assembly-language program and the deck ran the
first time. Sometimes we get lucky.

[Charlie Gibbs]

In article <proto-F96898....@news.panix.com>, pr...@panix.com
(Walter Bushell) writes:

> In article <je320k$ljn$1...@dont-email.me>,
> "Charles Richmond" <net...@aquaporin4.com> wrote:
>
>> "Mensanator" <mensa...@aol.com> wrote in message
>> news:667b940b-0d5c-467e...@n39g2000yqh.googlegroups.com...
>> On Jan 3, 9:20 am, Berkeley Brett <royal...@gmail.com> wrote:
>>
>>>> I hope you are all well & in good spirits.
>>>>
>>>> I wonder, is there a general consensus on who originated the phrase
>>>> "user-friendly"?
>>>
>>> Don't know. Where I worked, we always used the phrase:
>>> "idiot-proof".
>>
>> The problem is... the world is always making bigger and better
>> idiots, who can break any "idiot proof" scheme. :-)
>
> When the system become easier to use then people pay less attention
> and more people use the system especially people who would not put
> in the time to learn the previous system and just go with what comes
> naturally.
>
> I suppose we are in violent agreement, with me just pointing out how the
> higher level of idiocy comes about.
>
> However for Gooey interfaces support I recommend:
>
> <http://xkcd.com/627/>

Love it.

> But I loved the old days of support on Decwriters where I could read
> the interactions that got the people into trouble. CRT Terminals hid
> all the evidence.

My log routines are getting better all the time. :-)

[Charlie Gibbs]

In article <je47rt$u2p$1...@dont-email.me>, Peter...@Yahoo.com

(Peter Flass) writes:

> On 1/4/2012 11:18 PM, hanc...@bbs.cpcn.com wrote:
>

>> On Jan 4, 3:33 pm, "Charlie Gibbs"<cgi...@kltpzyxm.invalid> wrote:
>>>
>>> You dissin' CLIs, boy? :-)
>>
>> I thank heaven I never had to use such systems. I've seen really
>> convoluted long strings. I guess the operators who used them
>> regularly got the hang of them, but they sure looked error prone
>> and tedious.
>

> Did you ever see an airline reservation agent use an online system
> in the days before all this flashy eye candy came along? They were
> a joy to watch - type a few cryptic characters on a 2741, press enter,
> and get back a few other cryptic characters that told them everything
> they needed to know without all the overhead of kilobytes of data
> transferred. It took a fair amount of training, but you couldn't
> beta them for efficiency.
^^^^

I presume you meant "beat". That must be a Freudian slip.
Beta testers wouldn't use the system long enough to really
make it perform, so all they'd see is the cryptic aspect,
not the efficiency a skilled operator would bring.

> That's what all the pretty pictures are trying to do - eliminate
> having to train people to do their job properly, and enable
> employers to hire any high-school dropout off the street and
> not pay them too much.

When you consider the cost of hardware powerful enough to display
all that eye candy - plus recurring upgrades, maintenance, and
training - it makes me wonder whether they're really saving money.
But what the heck, that's what rate increases are for...

[Seebs]

On 2012-01-06, Peter Flass <Peter...@Yahoo.com> wrote:
> You have to be a licensed engineer to design a bridge. You have to have
> a license to be a stockbroker. We should have had licensing for prog^H
> "systems engineers" a long time ago. You can't run code on the web
> that's not written by a licensed systems engineer.

This is a stupid idea, at least as written.

Hint: There is no need to need a licensed professional to put up a web site.

The reason we care about licensing for bridges is that they're public resources
that can kill anyone who comes along. Programming is not all in that category.
Some kind of licensing might be reasonable for *some* programs, but I don't
see what business anyone has declaring that I'm not good enough to populate my
own /cgi-bin.

More generally, the impression I've gotten from people working in licensed
fields (including at least one lawyer) is that for the most part it's a scam
to create artificial scarcity and boost prices.

[Seebs]

On 2012-01-06, Peter Flass <Peter...@Yahoo.com> wrote:

> On 1/5/2012 4:43 PM, Seebs wrote:
>> On 2012-01-05, hanc...@bbs.cpcn.com<hanc...@bbs.cpcn.com> wrote:
>>> On Jan 4, 10:09?pm, "Charles Richmond"<netn...@aquaporin4.com> wrote:
>>>> That's why in the U.S. and Canada, we need a Programmer's Guild (union).
>>>> The union rules would expressly forbid union members from working on code
>>>> originally written in India or China. ?Let those folks *fix* the code
>>>> themselves!!! ?If employers don't like the way the Indians and Chinese code,
>>>> well then they better think about hiring union programmers.

>> (I leave this quoted to make it clear that the original proposal was absolutely
>> based on region, and effectively on race, and had no provisions for, say,
>> union members in other countries. I note also that Canada is included, but not
>> Mexico.)

> There are lots of people of Indian and Chinese descent in the US. I
> don't think OP intended to slight them.

"Racism" is not all about skin color; it includes culture or national identity.
The word's approximate.

> I don't know enough about
> Indian programmers to comment, I suspect they're pretty good.

We used to have some (traditional outsourcing). They were spectacularly awful.
I have known a number of programmers who have had stuff outsourced to India, and
in every single case, it's been spectacularly bad.

I don't actually blame India; I blame the outsourcing model. The big thing we
changed when we moved stuff to China was that we started hiring people directly
and keeping them around so they could learn stuff.

> I have
> three problems with anything from China:

> 1. They're clueless. In manufacturing they sometimes do things that
> are harmful or dangerous because they don't know enough to understand
> the potential problems (e.g lead paint).

My experience has been that, at least for the programmers, they're no worse
than any other newbie progrmamers.

> 2. Worse than the above they often cut corners to make a fast buck.
> This isn't just a problem with China, but has to do with inspections,
> etc. For example I prefer to buy toys made in the EU over those from
> anywhere else because they're safety regulations and inspections are
> stricter.

A point, but not directly relevant to the projects I'm looking at.

> 3. I don't trust the government there. Even if the programmers are
> good, conscientious and ethical, what's to prevent the government from
> demanding access to confidential information and/or forcing them to put
> trojan horses into the code. Of course I believe *our* government does
> this too, but they're supposed to be on our side.

Totally agreed.

So.

What is the best thing we can do to take down a totalitarian regime?

Create a viable middle class of people who have been working with hackers and
computer geeks from free countries, and who have earned enough more money
relative to other people that they feel like their property rights matter.

Every Chinese programmer who gets a job with US coworkers and gets to watch
them griping about their government and taking it for granted that people should
have the right to yell at their government is one more person who might in
the future lead protests.

>> Programmers cannot be trivially replaced, and companies that don't figure this
>> out suffer for it.

> That's the basis of the current problem. Programmers were respected in
> the olden days, now they're just cattle. (I say "they" rather than "we"
> because I now work for myself)

Not true everywhere, certainly. I've repeatedly seen programmers, at multiple
jobs, win arguments about how things should be run. One of my friends went to
HR at a job, and told them:
I will not be working for $MANAGER tomorrow. I might be working for
you. That's your call.

Two hours later, $MANAGER had been put somewhere else, and she and her team were
suddenly a lot happier and productive.

> Unions are not always the problem. Bob Lutz (_Car Guys vs. Bean
> Counters_) admits the unionized auto workers didn't want to be slackers;
> they wanted to do good work but often the employers prevented this by
> their bogus cost-saving.

While this is true in general, the underlying "we must defend jobs and prevent
other people from working" thing is still massively destructive.

To put it another way:

Our Hero has proposed that we respond to foreign protectionism by engaging in
local protectionism for our industries. How well did that work out for the US
auto industry?