Compare source code

[Seebs]

On 2010-11-03, Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> wrote:
> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 

> Really?

Yes.

> I'm not aware of *any* language that promotes tabs over spaces.

Makefiles.

> I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

No.  However, you've got a fallacy of the excluded middle here -- you're
ignoring the very large set of "doesn't care either way", and looking only
at things that prefer one or the other.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

I don't consider it broken for a tool to favor a more logical style which
is *actually* required by at least one format, and not a problem for anything
I've ever used except (sort of) Python.

In fact, Python works perfectly with tabs; it's just other Python
programmers who get fussy.  :)

> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

I don't miss them, or care about them; after all, I can just run indent/cb
to format something however I like, and run it again to match any given
coding style standard.  Problem solved.

> * it's not an issue for thousands of other users;

This is a non-argument.  That something isn't a problem for other people
makes no difference to the people for whom it's a problem.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

I have never found any other editor that I like as much as the one I use
now.

> * and even if there is no right tool for the job, the feature isn't going 
> to change;

I think you miss the point of the observation.  I'm not expecting it to
change; I'm pointing out that insisting that it's not a problem is
*insulting* to the people for whom it is a problem.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Oh, I'd happily contribute code if it'd matter.  But it wouldn't.

>> It would be much better if the community would simply acknowledge that
>> this is a tradeoff the the language has made and one which is often
>> misunderstood by many first time Python programmers.

> Been there, done that. This is *old news*.

I haven't seen it done yet.  I've seen a whole lot of people tell me that
an editor I've been using for twenty years is "broken" because I found
a program that is brittle with regards to its inputs that is prone to
being triggered by a behavior which has been free of problems (and indeed
in some cases *mandatory*) for everything else.  I've seen people smugly
tell me that I'd love this if I just tried it.  That didn't work for
pickles, it didn't work for Player-vs-Player fighting in video games,
and it's not gonna work for the lack of end markers.

Explicit is better than implicit.

-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.