On Thu, 2003-08-28 at 14:07, Pigeon wrote:
> On Thu, Aug 28, 2003 at 05:01:05AM -0500, Alex Malinovich wrote:
> > On Thu, 2003-08-28 at 04:41, Steve Lamb wrote:
> > --snip--
> > > Yeah, on supported languages. I don't see the point of having a tool to
> > > shoehorn the code into one bracket style and another tool to shoehorn it into
> > > a different bracket style (and hope it remains decent) when one could just get
> > > rid of the bloody brackets and be done with it. Hence my last stanza of
> > > pseudo code showing all of the different styles being all the same code
> > > without the brackets.
> >
> > But see my last paragraph in my previous post. Those brackets which make
> > things so hard for you to read are the same brackets that make it easy
> > for me to read. I look at Python code and I get lost. I guess my eyes
> > are out of alignment or something, because I can't just look at
> > indentation and see what corresponds to what. (Especially so with 4
> > nested ifs, loops, etc) With bracketed languages, however, I can just
> > keep a count of brackets in my head and always know where I am.
> >
> > Though I'm afraid that I do at least have to agree on the multiple ways
> > of bracing. I much prefer method C in your descriptions, and method A I
> > can deal with, but B drives me up a wall! Now if someone would devise a
> > language with an extremely solid OO structure, good garbage collection,
> > easy interfaces to C libraries, and most importantly, forced type C
> > bracketing, I'd be in heaven! :)
>
> I pretty much agree with this. I want the braces, in order to be sure
> that I've read it in the same way as the compiler will.
>
> Personally I use method C, partly because I think it looks neater and
> partly because it uses fewer lines, so you can get more code on the
> screen at a time. As far as reading other people's code is concerned,
> as long as the block between the braces is indented - which it
> invariably is - I don't let the positioning of the braces worry me too
> much.
>
> But I do insist on the braces being there! The Python method fails for
> me on several counts:
>
> - There isn't an explicit end-of-block delimiter. A tab to start a
> block; what ends it? A tab that isn't there? Yuck.
As a long-time Python programmer, I must say, "Huh?". What's
so hard about this:
i = 1
for i in range(10):
i = i * i
print i
> - The delimiters are not visible characters. I want to *see* something
> that says the block STARTS HERE and ENDS HERE. { and } are fine. begin
> and end are OK. if-then-else-fi, while-do-done and the like are
> bearable, though I prefer to use the same delimiters for everything.
> Having the actual meaning as seen by the compiler/interpreter change
> according to something as vague as how far across the screen the line
> starts just fills me with a total lack of confidence that the code is
> going to do what I want. Indentation is great as an *aid* to *human*
> reading of the code, but for it to actually control the flow of
> execution is RIGHT OUT.
You'd get used to The Python Way really quickly. Everyone does.
> - A corollary of this is that non-visible characters get munged. Yes,
> I know this *shouldn't* happen, but it *does*. Too many passes through
> stupid software that performs bad end-of-line translation between LF /
> LF-CR / CR when it shouldn't, and you end up with a file with its line
> structure wiped out. With explicit delimiters, it'll probably still
> compile, and it's not too hard to whack line breaks in at appropriate
> points to make it more-or-less readable. With delimiting based on
> whitespace and line breaks, you've had it.
That happens occasionally, but most, going on all,) Python program-
mers set their editor config files to this:
set expandtab
set shiftwidth=4
set tabstop=4
set smarttab
> - A personal subset of this is that I HATE TABS! Each different
As do all Python programmer. See above paragraph.
> Guess I'll be sticking to C for a while yet...
Try Python. You might like it. Really!
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA
"Experience should teach us to be most on our guard to protect
liberty when the Government's purposes are beneficent. Men born
to freedom are naturally alert to repel invasion of their
liberty by evil-minded rulers. The greatest dangers to liberty
lurk in insidious encroachment by men of zeal, well-meaning, but
without understanding."
Justice Louis Brandeis, dissenting, Olmstead v US (1928)