Whitespace as syntax (was Re: Python Rocks!)

[Bijan Parsia]

<fcahoon at my-deja.com> wrote:

> In article <1e5p92l.xgr4fe1s2x5ptN%bparsia at email.unc.edu>,
>   bparsia at email.unc.edu (Bijan Parsia) wrote:
> > <fcahoon at my-deja.com> wrote:
> >
> > > In article <1e5nkk6.1a5z8bp1lixbdvN%bparsia at email.unc.edu>,
> > >   bparsia at email.unc.edu (Bijan Parsia) wrote:
> > > > <fcahoon at my-deja.com> wrote:
[snip]
> >
> > Well, that would be a telling riposte *if* my argument had anything to
> > do with technical superiority. My point was, as Garrett pointed out,
> > that the fact that there are large bodies of Python code from
> > heterogenous sources which themselves have had heterogenous
> contributers
> > *and yet* there hasn't been (reported) wide scale difficulties is
> *prima
> > facie* evidence that the "whitespace munging" problem is not severe.
> > Given that, the burden of proof returns to you, and analogies from
> > other, *disanalogous* langauges will no longer serve.
> 
> Actually, my mention of Perl in particular is draws on the common
> statements in the Python community about Perl's unmaintainability.
> Granted, _you_ didn't say Perl is unmaintainable, but still this is the
> basis of what I was trying to get at.
>
> A language can have Problems (with a capital 'P') and still acheive
> widespread popularity.

Of course. My point is *completely* independant of that. My point holds
even if Whitespace is a Problem for Python Balanced By Other Groovy
Features. Refuting arguments isn't the same as refuting conclusions. I
recommend a good introductory symbolic logic class. Or, if you prefer, I
could recommend specific texts.

My use of the fact of Python's popularity was to establish that there is
plenty of Python files out there that 1) come from hetergenous sources,
2) get intergrated, and 3) have had multiple programmers working on
them.

This was establish that the extant initial evidence *for you* is exactly
the same as that derived from your "C experience". And yet, as it
trivially observable, the conclusions you drew *from your C experience*
AND *your understanding of Python* don't hold. I grant your C
experience, ergo, your understanding of Python is flawed (at least, your
understanding of the problems of whitespace delimiters being munged in
semantically unresolvable ways). So all your manuevers about popularity
are completely beside the point as the truth of how Python *got* popular
plays *no* role in my critique.

Now, which part don't you understand, if you still don't? I can always
try another explanation.

[snip]

> >
> > Well, look, you've just *changed* your argument. Your original
> argument
> > was that *based* on your C experience, certain conclusions about
> Python
> > can be drawn.
> >
> > Now, that a few people *with* python experience chimed in is some sort
> > of confirmation, but hardly what you should hope for given the
> strength
> > of your claim and the nature of your supporting evidence.
> 
> What I had actually hoped for was a reasoned discussion that would teach
> me some valuable things.  So far, I have learned a bunch of stuff, and I
> am happy.  I expressed my concerns, and gave my reasons for those
> concerns.  Should I not have done so?

I critiqued (one of) your *argument(s)* which was, as I believe I've
shown, fallacioius. Or, at least, not nearly as strong as you seemed to
think. Should I not have done so? Why not?

That you can bring in other considerations and arguments in support of
your position is fine, and even reasonable (though I *do* think that the
*prima facie* case against you is strong enough that only direct
experience/empirical evidence will get *you*, personally, back in to the
ball game; this is *ad hominim*, of course (in the technical sense), but
no less a problem for *your* argumentative position).

What you *should have done*, in my honest opinion, is admit that either
1) you radically mistated your case, perhaps for rhetorical effect, and
repair your argument (I rather suspect that the "C experience" thing was
an authority manuver) *or* 2) you simply have vauge unsupported worries
and would like some reassurance. After the group hug, you may there upon
go ahead and stop worrying and learn to love the NewLine.

> > And, yes, sure, there well may have been people turned off by
> > "whitespace", but isn't the true measure, to be consistent with your
> > argument, of the the defectives of Python's block delimitors that when
> > receiving files from other people, one is *typically* left *totally
> > clueless* as to the intent of the programmer? *No one* has claimed
> that.
> 
> "*typically* left *totally clueless*" !?!?!?  *No one* has claimed that!
> If that were true, the language simply wouldn't work at all!

Well, you came mighty close. Go back and look at your discussion of your
C experience. If Python whitespace got munged to the degree that happen
to C files "in your experience", *and* Python whitespace was
"impossible" or "very difficult" to keep straight wrt to orginal
programmer intentions under those conditions, then it follows that
general chaos would ensure, *or* that people would typically do a lot of
work when dealing with other people's files. Neither is true, as is
simply determinable by inspection of http://www.python.org.

> I'm more concerned about the possiblilty of one bad line being left in a
> infrequently-executed routine, leading to spurious errors which are
> difficult to track down.

Seems to be an issue of code coverage and testing tools, not of
whitespace. And doesn't a little reflection make this seem like not a
pressing issue? I mean, what's the chance of, in a normal sized module
file, of only *one* function being affected by a whitespace munging
operations in a non syntax error generating way? If you can provide some
evidence that this is fairly likely under current practices (and I think
it needs to be an *evidential*, not a speculative, argument; show us
some test cases), then you may have something.

But let's think more generally here: The *reason* C can get it's
whitespace horrible contorted is because, lo, it's not (extra)
whitespace *sensitive*! Different sequences and lengths of sequences of
whitespace are *merely* different spellings of token delimiters. So,
from a langauge point of view, having two spaces between each
indentifier is *consistent* with having 47.

But that's not true in Python. Newlines are statement separators, for
example.
        x = 5
        print x
Not an error.
        x = 5 print x
An error. (er, I hope ;))


> > [ ... ]
> > Of course, it's theoretically possible that everybody *is* spending
> all
> > their time indenting and reindenting code, guessing where things
> should
> > go, and so on, but that the other advantages of Python *so outweigh*
> > this huge effort that people put up with it anyway.
> 
> Yes, that's exactly what I was getting at.  "All the time" is, of
> course, an exaggeration -- but some extra time, yes.

Erm...Given that there are langauges fairly semantically close to
Python, with a slightly different syntax, which doen't seem to be
winning over straight Python, I'd say that your case is thin, indeed.

(I notice a slow withdraw in the power of your claim.)

But heck, download some python code. Be careless with it. See what
happens. If this is *easy* to do, then it'll pop up. If it's rare, then
you have to start weighing tradeoffs.

(After all, it's not like *other* delimintation methods are perfect,
either. They have direct and measurable costs.)

> > I respectfully suggest that the *prima facie* case is very strongly
> > against this. And given that Python is open source and that adding
> > "visible" block delimiters is more or less trivial *and* *no*
> > alternative block delimited version has *appeared* much less gained
> > *any* following, I think we can rest confident that indentation is not
> a
> > problem.
> 
> After python gained a certain level of popularity, though, it would be
> easier to 'put up' with the problem than hack the langauge, because of
> the availability of modules and such.  So this particular argument
> doesn't seem too forceful to me.

How does the amount of popularity of Python have to with the difficulty
of fixing a wart, especially one that would have the putative gains you
mention? It's *trivial* to change the delimiters, and in a backwards
compatible way.

Plus, this completely ignores the history of Python *before* it reached
the "certain level of popularity". What level is that *exactly*, hmm?

Vauge claims are easy to defend.

What argument against your conclusion *would* seem forceful to you?
There have certainly been plenty that *have been forceful*, regardless
of your ability to discern that force.

Cheers,
Bijan Parsia.