Compare source code

[Seebs]

On 2010-11-06, Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> wrote:
> On Thu, 04 Nov 2010 19:37:25 +0000, Tim Harig wrote:
>> Examples of communication channels that mangle white space abound.

> Yes. So what?

So something which is broken by them is brittle.

And in every circumstance *other* than the syntax of Python, specifically,
we regard brittleness to common events as a flaw in a design.  For instance,
Makefiles require tabs to indent rules, and behave strangely if for some
reason you use spaces.  Many editors, though, can be configured to insert
spaces when you hit the tab key.  This setup is not intrinsically "broken",
it's just a matter of preference.  And yet, when used with make, it produces
cryptic failures.

Everyone, without exception, agrees that this is a flaw in the design of
make, and that the "tabs" rule should never have existed.

> If your communication channel mangles your data, change 
> your communication channel, don't expect users of clean communication 
> channels to hand-enter error-correcting codes (braces) into the data.

If you have to hand-enter them, perhaps you should get better tools,
as many tools don't require you to hand-enter them.

Ahh, but I forgot.  You only need to get "better" tools if you're talking
about why you *don't* find Python's design to be the one true pinnacle of
idealized and perfect engineering.  If you're talking about any other
language which works fine and is no hassle if you have suitable tools, it
is of course ridiculous to suggest that people should need to change
away from tools which currently suit them fine.

> Why is it the responsibility of the programming language syntax to 
> correct the problem with Seebs' faulty mail server?

It's not.  And honestly, if it were just one misconfigured mail server,
no one would probably ever start this conversation.  But instead it's
dozens of mail servers, dozens of web forums, dozens of editors, OCR
scanning of printouts, and dozens of other media in which it is easy
for small whitespace changes to creep in or appear.  All of which were
known to exist when the decision was made to design a new file format
to be brittle in the face of such changes.

> XML is not a data format for human use, it is for use by machines. It is 
> slow, inefficient, and uneditable by humans except for the most trivial 
> cases.

There are thousands of web pages which have been entered in something
which could easily be imagined to be a variant of XML.  For that matter,
OS X ".plist" files are often stored in XML, which is widely liked because
it gives you a nice, robust, human-readable format.  Which is amenable
to hand-editing if you want to tweak something.

XML isn't a *great* format for human use, and it's certainly been aimed
much more at use by machines.  However, there's a lot to be said for
designing machines to use formats which happen also to be easy for humans
to read, at the very least, and possibly even easy to write.

("Easy" being, of course a relative term.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at 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.