Re: find-library-name fails if file (with no extension) exists.

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Wed, 22 Nov 2006 00:19:28 +0100
>> Cc: Emacs Devel <address@hidden>
>> 
>> > And plenty of successful operating systems have been
>> > case-insensitive, so it is clearly not a bad idea, not unworkable,
>> 
>> It is a constant source for trouble in scripts of all sorts.  I guess
>> about 20% of Windows installation problem reports with AUCTeX
>> originate from capitalization mixups.
>
> Because programmers should be educated to refrain from Posix-centric
> assumptions.

That file names are strings is not Posix-centric.  And that different
strings imply different file names is certainly not Posix-centric
either, unless the principle of least surprise is reserved to Posix.

>> > nor particularly dangerous, difficult to implement, or hard on
>> > the user. It's just another UI decision. One I like a lot.
>> 
>> It is a constant trouble for programmers
>
> For uneducated programmers.

For every programmer.  It is just that some already know most of the
moves and details customarily used to deal with that.  But they still
need to deal with it, and with varying degrees of complication
depending on the application.

> Those are the same programmers who think there's no distinction
> between text and binary files (just yesterday saw a SHA1 signature
> file on a prominent download site that failed to mark binary files
> as needed, which made sha1sum very unhappy).

Features that require "educated programmers" should offer reasonable
value in exchange.

The distinction between text and binary files has the advantage of
being able to copy a text file unchanged to a line printer or terminal
without the need for terminal settings or a formatting utility.  And
it has the disadvantage that files break under all sort of
circumstances when transferred or processed.

It is historic baggage from CP/M from times where C was not used for
programming and there was no concept of a tty (and devices were not
files, anyway).

Of course, the situation is exacerbated by Macintoshs where the "put
the whole line printer CRLF sequence in the file" idea was avoided but
they chose to go with a different line ending character than Unix/C.

I seem to remember that with Darwin, they switched the defaults, but
the inheritage is there to stay pretty much for eternity (for example,
within EPS files created on Mac and NeXT).

Avoiding complications in design is not just a question of
accommodating "uneducated programmers".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum