Opinion) Overuse of symbolic constants

[Joona I Palaste]

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts. I assume I am not the only Windows
user who does. Yet I have never heard of this confusing a single
user.

I suspect this is just idle luser bashing. Anyone care to provide
any evidence whatsoever that presenting a pathname with slashes to
a Windows user causes difficulty?

This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames. Already we're seeing URLs written as
http:\\www.something.com\something.html, and I've even seen Usenet
article titles such as "Input \ output question". Sooner or later
greengrocers will start writing "Potatoes in 1\2 kg bags" in actual
pen-and-paper.

 

[Keith Thompson]

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts. I assume I am not the only Windows
user who does. Yet I have never heard of this confusing a single
user.

I suspect this is just idle luser bashing. Anyone care to provide
any evidence whatsoever that presenting a pathname with slashes to
a Windows user causes difficulty?

Do you see slashes in the source code for Windows software, or do you
see it actually displayed when the program runs?

I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup. Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user, and I've never seen any mention of this feature
in Windows documentation. At least one Windows application I use
rejects a path name with '/' characters as invalid, but accepts the
equivalent path name with '\' characters (I suppose that's a bug in
that particular application).

I am a Windows user, but I'm not a Windows programmer. I haven't seen
very much source code intended to run under Windows, and I don't think
I've ever seen any such code that uses a '/' separator.

I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.

 

[Allin Cottrell]

Joona I Palaste quoted:

In my experience (teaching university students), presenting _any_
sort of pathname to Windows users causes difficulty. Their ability
to comprehend anything but point-and-click has atrophied to the
point of disappearance.

This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames.

Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.

Allin Cottrell

 

[Joe Wright]

Joona I Palaste quoted:



In my experience (teaching university students), presenting _any_
sort of pathname to Windows users causes difficulty. Their ability
to comprehend anything but point-and-click has atrophied to the
point of disappearance.



Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.

Most computer users know nothing at all about computers, what they
are, where they are or even whether they are currently using one or
more of them. What's your point?

Just curious, what do you teach at university?

We do not and should not expect anything at all from computer users
except that they use computers. They are our market. Bless them.

 

[Allin Cottrell]

Most computer users know nothing at all about computers, what they are,
where they are or even whether they are currently using one or more of
them. What's your point?

My point, following from the discussion of '/' versus '\' in Windows
pathnames, is that the it's moot, because pathnames are simply not
something Windows users conjure with. (Of course I'm not talking
about programmers, but I am talking about reasonably intelligent people
who use a computer every working day.)

Just curious, what do you teach at university?

Economics. When I teach econometrics (economic statistics), the full
effects of point-and-click-ism hit me in the face (i.e. almost total
inability to do anything that involves typing a command of any sort).

Allin Cottrell

 

[Richard Bos]

(e-mail address removed) (Michael Wojcik) wrote:
Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts.

Which software? I don't think I've ever seen something like that except,
perhaps, in GNUed software.

I have. Personal experience, and I took no notes, so that's no evidence
to anyone but me.

Sooner or later greengrocers will start writing "Potatoes in 1\2 kg bags"

Inconceivable. Unless you mean "Potato's in 1\2 kg bag's".

Richard

 

[Dan Pop]

I assure you, we exist. As recently as 1998 I was writing C using a
keyboard (attached to an IBM 5250 terminal) that did not have square
brackets. I didn't use iso646.h, because long before 1994 we had
programmed the terminals to insert square-bracket characters as
terminal macros (a two-keystroke operation).

That's the point. C has been available on IBM mainframes for almost 30
years and the people using it didn't wait for C89's trigraphs or C95's
digraphs and iso646.h to solve their terminal-related problems. All this
nonsense was due to one Scandinavian country ISO representatives insisting
on C providing a solution to a no longer existing problem (7-bit ASCII
derived character sets that replaced $, # and certain punctuation
characters by other characters).

Dan

 

[Michael Wojcik]

Do you see slashes in the source code for Windows software, or do you
see it actually displayed when the program runs?

Both. This is particularly true with console-mode software, but it's
frequently true of GUI-mode as well.

I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup.

And you believe this is generally true of Windows users because?

Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user

And your evidence for this is what?

At least one Windows application I use
rejects a path name with '/' characters as invalid, but accepts the
equivalent path name with '\' characters (I suppose that's a bug in
that particular application).

Yes, it is. For example, OpenFile() in Windows 3.1 had this problem,
and MS considered it a bug; see MS KB article Q111588.

I am a Windows user, but I'm not a Windows programmer. I haven't seen
very much source code intended to run under Windows, and I don't think
I've ever seen any such code that uses a '/' separator.

Which tells us pretty much nothing.

I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.

It's pretty much utterly beside the point whether the average Windows
user knows that forward slash can be used as a path separator. The
question is whether said user will be confused upon encountering a
forward slash in a path. I don't believe so, and I've seen no
evidence offered to the contrary.

In fact, from what I've seen, Windows users show significant facility
at compensating for all sorts of potentially confusing UI elements.
Windows is full of them, after all.

--
Michael Wojcik (e-mail address removed)

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster

 

[Keith Thompson]

And you believe this is generally true of Windows users because?

I'm guessing. No, I don't think that most Windows users read this
newsgroup, but I'm guessing, based on my own experience, that most
Windows users aren't aware that '/' is a valid path separator.
(Probably a lot of Windows users aren't aware that '\' is a valid path
separator.)

And your evidence for this is what?

I've never seen a Windows program (excluding Cygwin and other Unix
emulation layers) display a directory path using '/' as a path
separator, except perhaps when it had been entered by the user. This
is, of course, anecdotal evidence, not proof.

[...]

It's pretty much utterly beside the point whether the average Windows
user knows that forward slash can be used as a path separator. The
question is whether said user will be confused upon encountering a
forward slash in a path. I don't believe so, and I've seen no
evidence offered to the contrary.

I think others have presented such evidence in this thread.

In any case, this discussion is off topic and not of much concern to
me personally. I have nothing to offer but anecdotal evidence.

 

[marcus hall]

Stephen Sprunk wrote:
The problem goes all the way back to MS-DOS 1.0 using slashes for command-
line flags. Then, when 2.0 allowed subdirectories, they were stuck.

Come on, be fair.. The problem started before MS-DOS, since CP/M used
'/' for options before MS-DOS even existed. And CP/M got it from various
DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
the idea, or if they got it from somewhere previous, but by now we'er
talking about earlier then Unix V6, so DEC can hardly be faulted for not
following "the one true way".

Marcus Hall
(e-mail address removed)

 

[Michael Wojcik]

I think others have presented such evidence in this thread.

Yes, and more of it than I expected. I yield on this one. While
I try not to underestimate users, I appear to have erred in the
opposite direction in this case.

In any case, this discussion is off topic and not of much concern to
me personally.

Agreed.

--
Michael Wojcik (e-mail address removed)

You brung in them two expert birdwatchers ... sayin' it was to keep us from
makin' dern fools of ourselfs ... whereas it's the inherent right of all to
make dern fools of theirselfs ... it ain't a right held by you official types
alone. -- Walt Kelly

 

[Michael Wojcik]

That's the point. C has been available on IBM mainframes for almost 30
years and the people using it didn't wait for C89's trigraphs or C95's
digraphs and iso646.h to solve their terminal-related problems.

Sure, but I was responding to Jakob's query about "people who use a
keyboard that does not allow easy access", and your reply to it. I'm
not claiming that trigraphs, digraphs, and iso646.h were necessary or
a good idea (I don't have strong feelings either way - I've never been
troubled by the "wacky punctuation in a string literal turns out to
be a trigraph" bug, since I never use such punctuation, and I'm not
aware of any other argument against them). I'm just noting that there
are C programmers who have had to cope with C-unfriendly keyboards.

 

[Dan Pop]

Sure, but I was responding to Jakob's query about "people who use a
keyboard that does not allow easy access", and your reply to it. I'm
not claiming that trigraphs, digraphs, and iso646.h were necessary or
a good idea (I don't have strong feelings either way - I've never been
troubled by the "wacky punctuation in a string literal turns out to
be a trigraph" bug, since I never use such punctuation, and I'm not
aware of any other argument against them). I'm just noting that there
are C programmers who have had to cope with C-unfriendly keyboards.

And I have explicitly acknowledged their existence, in the past:

The good question is whether such people do exist. 20 years ago, they
did, but back then there was no <iso646.h>...

The biggest source of problems is gone: the terminals replacing
punctuation characters by accented characters, because they used a 7-bit
character set that had to support various languages using an alphabet
with more than 26 letters.

I have no idea whether brain dead IBM terminals are still being used by
C programmers, OTOH. Back when I had access to an IBM mainframe, the
local setup was perfectly happy with VT100s and was performing all the
necessary character conversions and buffering. And those with an X
server could use the x3270 terminal emulator...

Dan

 

[Ross Kendall Axe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

marcus hall wrote:
| In article <[email protected]>,
|
|>Stephen Sprunk wrote:
|>The problem goes all the way back to MS-DOS 1.0 using slashes for command-
|>line flags. Then, when 2.0 allowed subdirectories, they were stuck.
|
|
| Come on, be fair.. The problem started before MS-DOS, since CP/M used
| '/' for options before MS-DOS even existed. And CP/M got it from various
| DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
| the idea, or if they got it from somewhere previous, but by now we'er
| talking about earlier then Unix V6, so DEC can hardly be faulted for not
| following "the one true way".
|
| Marcus Hall
| (e-mail address removed)

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
. Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAkuB79bR4xmappRARAiDoAJ9v5I6Bt8mBa7/MuioNpFvXQ0rLAwCePwNb
PXPOrDynSuH19OjELKezPuo=
=gGte
-----END PGP SIGNATURE-----

 

[Claudio Puviani]

Hash: SHA1

marcus hall wrote:
| In article <[email protected]>,
|
|>Stephen Sprunk wrote:
|>The problem goes all the way back to MS-DOS 1.0 using slashes for command-
|>line flags. Then, when 2.0 allowed subdirectories, they were stuck.
|
|
| Come on, be fair.. The problem started before MS-DOS, since CP/M used
| '/' for options before MS-DOS even existed. And CP/M got it from various
| DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
| the idea, or if they got it from somewhere previous, but by now we'er
| talking about earlier then Unix V6, so DEC can hardly be faulted for not
| following "the one true way".
|
| Marcus Hall
| (e-mail address removed)

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
. Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets.

Claudio Puviani

 

[Joona I Palaste]

Claudio Puviani <[email protected]> scribbled the following

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets.

I'd bet a lot of users still tried to, though, and were surprised at why
it didn't work.
I've seen my fair share of Commodore 64 BASIC programs that begin by
printing "<CLR>" (literally, as in a less than sign, C, L, R, and a
greater than sign) to the screen, followed by the introductory text.
The writer of the program copied it from a magazine listing where
"<CLR>" was used as a transcript of the CLR control character, which
could be typed by hand on a Commodore 64 but which wasn't printed very
well on paper. The magazine was bound to have an introductory paragraph
about transcripts of control characters, that they were not to be typed
literally, but many readers ignored it when typing in the programs.
I was once in the Finnish science center Heureka and went over to a
computer running a cuneiform scripting program. The program displayed
a menu:
"Please select your language:
Finnish: type 1 + enter
Swedish: type 2 + enter
English: type 3 + enter"
At least one person *insisted* that the choice must be made by first
typing the digit 1, 2 or 3, then by typing the plus sign "+", and
finally by pressing enter.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Goran Larsson]

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets.

Have you actually used CP/M? The CP/M manuals use curly braces to indicate
optional arguments. The arguments that you type in on the command line are
enclosed in square brackets or start with a $ sign (older utilities).

Examples from the "CP/M Plus Command Summary":

A>DEVICE LPT [XON,9600]
A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
A>DIR [EXCLUDE] *.DAT
A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
A>MAC SAMPLE $PB AA HB SX -M
A>SET MYFILE.TEX [PASSWORD=MYFIL]
A>SET [DEFAULT=password]
A>SET [CREATE=ON,UPDATE=ON]

MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
introduce program options, where they got this from I don't know (but
it certainly wasn't from CP/M).

 

[Claudio Puviani]

Have you actually used CP/M?

Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
computers (not "other" computers with CP/M cartridges). Does that count?

The CP/M manuals use curly braces to indicate
optional arguments. The arguments that you type in on the command line are
enclosed in square brackets or start with a $ sign (older utilities).

Examples from the "CP/M Plus Command Summary":

A>DEVICE LPT [XON,9600]
A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
A>DIR [EXCLUDE] *.DAT
A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
A>MAC SAMPLE $PB AA HB SX -M
A>SET MYFILE.TEX [PASSWORD=MYFIL]
A>SET [DEFAULT=password]
A>SET [CREATE=ON,UPDATE=ON]

CP/M Plus (or 3.0) was a too-little-too-late response from Digital Research after
CP/M had already lost the war. CP/M 2.2 is the version that had captured the
maket when there was a market to capture and it's still the baseline that all
CP/M software development targeted. Its commands were different from CP/M Plus,
as you can see at: http://www.gaby.de/cpm/manuals/archive/cpm22htm/index.htm

You'll also note that the original documentation did use square brackets to
indicate optional arguments.

MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
introduce program options, where they got this from I don't know (but
it certainly wasn't from CP/M).

Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Claudio Puviani

 

[Goran Larsson]

Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
computers (not "other" computers with CP/M cartridges). Does that count?
Sure.

Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Yes, but the programs delivered with CP/M never used / for options.
Programs delivered with CP/M 2 prefer to use $ for options.
Programs delivered with CP/M 3 prefer to use [ and ] for options.
Programs sold by MicroSoft opted to use / for options.

Blaming CP/M for MicroSoft's use of / for options is wrong. The blame
must be somewhere else, probably DEC as MicroSoft used DECsystem 10
to cross compile their CP/M programs.

 

[Michael Wojcik]

[Followups set to alt.folklore.computers, where this is topical. AFC
readers: this thread sprang out of a discussion of path separator
characters, and has now become a shouting match over where Microsoft
got the idea to use the forward slash as an option separator, and
then fell back on the backslash as a path separator.]

Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Yes, but the programs delivered with CP/M never used / for options.
Programs delivered with CP/M 2 prefer to use $ for options.
Programs delivered with CP/M 3 prefer to use [ and ] for options.
Programs sold by MicroSoft opted to use / for options.

Blaming CP/M for MicroSoft's use of / for options is wrong. The blame
must be somewhere else, probably DEC as MicroSoft used DECsystem 10
to cross compile their CP/M programs.

"Blame" seems a bit harsh, since slash as an option separator was
already established by VMS when MS-DOS 1.0 came out.[*] Blame
Microsoft instead for a poor choice of path syntax in MS-DOS 2.0.
Since they already used the VMS syntax for options, they might as
well have adopted its syntax for paths, rather than trying for some
weird mix of VMSisms and half-assed Unixisms and ending up with two
crucial punctuation characters that many users (apparently) can't
reliably distinguish.

In any case, MS-DOS 1.0 was basically a rebranding of Seatle
Computer Systems' QDOS, wasn't it? Did QDOS use the slash as an
option delimiter? It might not have even been Microsoft's choice.


[*] I'm assuming here that VMS's use of slash as option separator
dates back earlier than MS-DOS 1.0. VMS 1.0 was released in 1978,
but I didn't use it myself before 1986, so I couldn't say.

--
Michael Wojcik (e-mail address removed)

It's like being shot at in an airport with all those guys running
around throwing hand grenades. Certain people function better with
hand grenades coming from all sides than other people do when the
hand grenades are only coming from inside out.
-- Dick Selcer, coach of the Cinci Bengals