Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS at cybersource.com.au> wrote:
> On Wed, 03 Nov 2010 20:30:43 +0000, Seebs wrote:
>> I'm not expecting it to change;

> Then why talk about it?

Because I find technical questions interesting in and of themselves.  I
will happily talk with people about the reasons for which the C preprocessor
is the way it is, even though it's never going to change and we all
hate it like poison.

>> I'm pointing out that insisting that it's not a problem is
>> *insulting* to the people for whom it is a problem.

> And insisting that it is a problem is equally insulting to those for whom 
> it is not a problem.

No, it isn't.

A friend of mine is colorblind.  For him, certain red/green pairings are
indistinguishable.  For me to insist that it is not a problem that a
user interface uses those to distinguish two things is insulting to
him; I am dismissing a very real problem.  For him to insist that it
is a problem for him is in no way insulting me.  He's not saying that it's
a problem for me.  He's merely saying that *there exist* people for whom
it is a problem.

No one has claimed that this is a problem *for everybody*.  Just that
there exist real-world workflows for which it is a problem, or people
for whom it is a problem.

This is an asymmetrical situation.  The opposite of "it's never a
problem for anybody" isn't "it is always a problem for everybody"
but "it is at least sometimes a problem for at least some people."

The reality is, the indentation-instead-of-markers thing *does* sometimes
lead to problems.  We could blame it on tools, but the tools could just as
easily blame the language for being brittle.  Given the degree to which
the rest of the world has standardized on not caring how *much*
whitespace is between things (though sometimes caring whether or not
there's *any* whitespace between them), it seems to me that the odd
man out is the one who is creating the burden.

Once many file formats exist which don't care how many spaces you
use, and many tools have been developed with those file formats in
mind, coming up with a new file format which cares how many spaces you
use seems a little short-sighted.  Demanding that all tools be changed
to fit a new paradigm is a pretty big demand to place on people.

On the whole, I don't personally think the benefits have been worth it.
I think Python would be a better, richer, language if it used explicit
end tokens of some sort.  Maybe it wouldn't.  I do know, though, that
of the programmers I know outside the Python newsgroup, not a single
one likes that aspect of Python.  It is consistently regarded as an
annoying quirk.  Some use Python anyway; it has merits, certainly.  If
I were offered a choice between Python and PHP for a project, I would
*absolutely* pick Python.  (Subject, of course, to the assumption that
the project would in some way involve computers, or programming, or
that I would at some point have to either write code for the project
use it, or possibly come within twenty feet of someone who was working
on it; outside of those limitations, I might consider PHP.)

I feel the same way about pretty much every language I use.  C would
be a much better language if the macro processor weren't such a giant
filesystem verification stage for a filesystem distributed across
multiple machines*.  They all have flaws.

Python's the only language I use where an obvious flaw, which is repeatedly
observed by everyone I know who uses the language, is militantly and
stridently defended by dismissing, insulting, and attacking the character
and motives of anyone who suggests that it might be a bit of a nuisance.

I suspect part of that is simply because it *is* a tradeoff, and there
are good reasons for it.  It offers some advantages.  It's not something
that you'd be insane to like; the problems are easily mitigated once you
know about them, and the benefits are worth it.  If I worked with a lot
more novice-level C programmers who hadn't yet had the importance of
careful style drilled into them, I might well find the indentation problems
people keep talking about to be a real thing, possibly even a very
serious one.

But the fact remains, being brittle in the face of whitespace changes *is*
a flaw.  It breaks code under circumstances which are, for better or
worse, common.  As I pointed out before:  There is a *REASON* that diff
has an option for ignoring whitespace changes -- because they are common
enough that such an option is commonly useful for distinguishing between
real changes and inadvertant ones.

Note that "whitespace indentation" in and of itself isn't the thing I'm
describing as a flaw; it's the side-effect of being brittle when whitespace
changes.  The indentation thing as a whole has some definite plusses, and
it's a tradeoff that I think may even be a good fit for a language
specifically focused on easier readability.

-s
[*] clusterfsck.
-- 
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.