friendly messages

[James D. Allen]

In article <5734 at bsu-cs.UUCP>, dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
> Here's what I would REALLY like to see:
					Really?  :-}
> 
>      $ dir
>      %DIR-Q-AREYOUSURE, you asked for a directory, are you sure [y/n]: y
>      %DIR-Q-VERYSURE, you said yes, but are you REALLY sure [y/n]: y
>      %DIR-Q-REALSURE, are you REALLY REALLY sure [y/n]: y
>      %DIR-F-JUSTINCASE, no directory, say PRETTY_PLEASE
>      $ dir/pretty_please
>      %DIR-I-OHWELL, ok, well, if you insist
>      %DIR-S-UASKED4IT, but we warn you, you did ask for it
>      [ directory listing appears here]
>      %DIR-I-DIRDONE, directory listing done, control returned to CLI
>      %CLI-I-WHEW, *whew*, thought DIR was going to take over system
>      $

This really made me laugh!  From time-to-time I've wanted to mail some
software to where_the_sun_doesnt_shine at software_vendor.  Rahul's
posting has induced me to give the net the benefit of my invective.  :-}

I only wish that superfluous dialog were the worst problem with
friendly software.  The "improved" `dir', for example, when it finally
gets around to listing a directory, will silently substitute a
*different* ("better", "friendlier") directory than the one you asked for.

Here are two examples of programs which try to be helpful, but where I
wish the programmer had called in sick the day he was going to add the
feature.

Example 1)

IBM language processors abound with self-righteous "logic".

Consider a C fragment like:
		/*
		 * Temporarily disable database updates, until
		 * the xlurg_gak module is debugged:
		 */
		#define	write(X,Y,Z)	\
			(printf("Would have written %d bytes\n", Z), Z)

This can be quite convenient.  The macro definition doesn't "use" X or
Y, but that is the intent.

IBM has a macro facility in JCL, something like:
		//FOOBAR	PROC	X,Y,Z

It's been a long time, but as I recall, typical output from `PROC' is:
	ILQJCL773P2: Fatal error, Formal argument `X' not used in `FOOBAR'

If you think about the implementation, it's clear that somewhere in
the JCL processor is code like:
		/*
		 * The `refcnt' array is of no value to *us* whatsoever
		 * but we need it for the friendly ILQJCL773P2 error.
		 */
		++refcnt[var_index];

Great concept!  A `fatal error' you have to go out of your way to
detect and which, if undetected, would harmlessly have the desired
effect (ie, none).


Example 2)

Just yesterday a friend asked me to help transfer some files from his
Mac to his new Unix machine.  First we connected a couple of wires
between pins 2 & 3 and pins 3 & 2.  Then we needed some software to
get the wires busy.  I'm sure everybody in this newsgroup could whip
that together in a few minutes but my friend had already purchased a
Mr_Everything_you_ever_wanted_to_do_with_your_serial_line application
so we double-clicked its icon.  I should have smelled trouble when I
noticed the icon had a real *friendly* smile.

We immediately got a "Password:" string safely back from the other end
of the wire.  "This will be real easy," I said.  "Unix is smart enough to
play stupid when you tell it to."  I did something like
		% stty raw -echo
		% cat -u > foobar^J
and selected Mr_Everything's "Send File" menu.  "We'll have to `kill'
`cat' from the other end, but that's harmless enough."

However, Mr_Everything was too friendly to send a *binary* file over the
wire.  It doesn't care what the data is, mind you, just whether it
recognizes the flavor of the mindless Macintosh file prefix.


Summary)

What are the reasons for this type of software "quality"?  I nominate
1) Mediocre programmers only get a low bug-to-keystroke ratio with
	`printf'-type code so they do lots of it.
2) Too often, software quality is judged by managers who are not
	real users.
3) Programmers view themselves as more intelligent then their users,
	but ignore that their intelligence will be "out of the loop"
	once the software (a tiny subset of their skill) is delivered.

Some will argue that my complaints are not caused because software is
"friendly" but because "it isn't friendly enough!"  But adding lots of
features *increases* problems whenever the features prove inadequate.
It's better to give the user a *simple* model of the software.
This is the original Unix philosophy:
	- do something simple
	- do it well
	- do it silently

Returning to the farcical version of `dir', for example, after receiving
complaints about the inane dialog, the "friendly" solution is to add
another option to `dir':

	$ dir/omit_inane_dialog
	%DIR-Q-IAMSOSAD, sure you want to omit the inane dialog? [y/n]:

Friendly software.  Just say no.