On 2010-11-03, Steven D'Aprano <steve-remove-t...@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-nos...@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. -- http://mail.python.org/mailman/listinfo/python-list
