Ron Parker <ron### [at] povrayorg> wrote:

> On 8 Feb 2001 08:35:10 -0500, Geoff Wedig wrote:
>>The white space thing I tend to agree with.  It does take getting used to. 
>>On the other hand, it's actually pretty nice.  I've worked with programmers
>>who use "arbitrary" rules -- which is to say rules that change from one line
>>to the next -- to write their code.  Having a built in requirement to lay
>>your code out neatly isn't a bad thing at all.

> But tools like "indent" can fix stupid programmer tricks in C.  In Python,
> the same stupid programmer tricks (or corruption due to some idiot loading
> the script into a word processor, or whatever) kill the program in weird
> and wonderful ways.

In other words, the language enforces something you have to go to outside
tools for in other languages?  And this is a bad thing?

Geoff

Post a reply to this message

On 8 Feb 2001 09:26:41 -0500, Geoff Wedig wrote:
>In other words, the language enforces something you have to go to outside
>tools for in other languages?  And this is a bad thing?

That's not what I said.  What I said is, you can fix broken indentation in
other languages, because there are other cues as to how it should have been
done.  In Python, when (not if) the indentation gets broken, the program stops 
working, and you might not even notice.  Yes, that is a bad thing.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"Merits of Python" as topic should probably be moved to a Python newsgroup,
but here goes:

> > How about   "# end" or whatever you choose?   :-)
>
> The "# end" would be a comment...but what do you mean by "whatever you
> choose"?

# end, # endloop, # end whateverthehellyerstopping       :-)

> Can you tell Python to allow terminating characters/keywords?
> Will it then use that keyword instead of indentation to figure things
> out?

I'd be surprised if that was possible from within Python itself, but it
would probably not be difficult to modify source code and recompile.  Call
it Pythoff.   Sounds like a Russian variant.  :-)


> Visual structure is exactly why I *don't* like it. It's white space,
> there is nothing there, it's a vacuum, and nothing should be affected by
> it. I can understand space being used to separate "words", but to
> determine if something is inside or outside a loop or condition...I
> prefer a visual termination, not something that relies on an area of
> blank paper.

Yet, I am using blank spaces to seperate conceptual blocks even in the
dialog I write here- to good effect, I think.  Early Greek texts did not
even use white space to seperate WORDS, itjustallrantogetherlikethis.
(Like the way Germans build long words... just schmush a small sentence
together. :-)

> Pascal's "begin" and "end", C's "{" and "}", AppleScript's
> "end repeat", "end tell", POV-Ray's "#end", etc...
> I can't imagine the way it is in Python being *good* for code
> maintenance, but maybe I'm wrong...

I don't think you're 'wrong,' any more than Brits drive on the 'wrong' side
of the road from an American perspective.  But I do believe the
whitespace-as-codeblock-end is as easy to get used to as paragraph indents
in literature.  In truth, we look for such cues all the time in our reading.

> > In fact, if I adopt Python for major projects involving multiple
> > programmers, I would welcome a scheme which enforces comments
> > beginning in, say, column 60, and a minimum number of comments per
> > page.
>
> I hope I'm misunderstanding you...you want to push all comments to the
> far right, and minimize the number of comments?!?

Perhaps I should have said "and an enforced minimum."   In other words,
programmers using the IDE within my programming groups would be REQUIRED to
have at least a certain amount of text within the 'comment zone' or the code
would not be accepted as syntactically complete.

> That's the opposite of
> what it should be...the comments should be close to the code which they
> are commenting on, and code should always be well commented. Minimizing
> the number of comments certainly isn't the goal...

No, I would not have advocated minimal commenting for enhanced maintenance.
:-P

As for comments to the right, as opposed to mixed within the code, that's an
excellent scheme which I've been using for over twenty years, all the way
back to assembler code.  With high level languages the commenting can be
more sparse, but should still be GENEROUS.

In my approach, one begins a project by writing a mission statement, then
(in outline form) pseudocode in large conceptual blocks, then pseudocode
which begins to break down large tasks into smaller until we are writing
pseudocode at the level of code blocks, like this:

# SCAN DATA FOR TRIPLETS
# Read chunk from file,
# normalize data,
# scan,
# place triplets in array,
# remember end data,
# do another chunk.

Personally, I often can't resist coding as I write pseudocode (which I call
'comments').  But given the preliminary pseudocode above, one expands that
(as I do below with my impromptu pseudolanguage).


                                        # SCAN DATA FOR TRIPLETS
while not eof                           # Read chunk from file,
  readfile(nextblock, 1024)             #
  normalize(nextblock)                  # normalize data,
  tripScan(this + nextblock)            # scan,
  writefile(trips, append, 'file')      # place triplets in file,
  this = nextblock                      # remember end data,
do while                                # do another chunk.


Of coure, the last line would be unnecessary in SOME languages.  Ahem.  :->

> All I meant was that I've looked for examples of using OOP in Python,
> and haven't found them...
>
>
> > May be due in part to the fact that Python is relatively new.
>
> That would explain it, but I didn't think Python was that new...newer
> than C/C++, but not a new language.
> How long has it been around?

One can really not measure the capabilities of a language by what the
majority of programmers are doing with it, or when.   Fad, trend and hype
would lead us to believe that some languages will do everything imaginable
on every platform with no recoding, with complete stability and security,
replacing entire operating systems and sweeping the world.  The Goddess of
Reality merely smiles.

> > Are you aware of any aspect of object oriented design philiosophy, as
> > commonly defined, which is missing in Python?
>
> No, because I haven't been able to find much information about OOP in
> Python at all. I poked around the www.python.org site for a while, and
> only found a mention that it had OOP features. Any suggestions? Sites
> with good examples?

No, as I indicated, just beginning my own investigation.  Clearly, at least
a subset of OO programming is possible.  If you're concerned about the
degree of OO implementation, a question to that effect in the
comp.lang.python newsgroup should lead to spirited discussion (and
examples).

Post a reply to this message

> But tools like "indent" can fix stupid programmer tricks in C.  In Python,
> the same stupid programmer tricks (or corruption due to some idiot loading
> the script into a word processor, or whatever) kill the program in weird
> and wonderful ways.

There is ALWAYS a way, Ron.  :-O

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 8 Feb 2001 09:26:41 -0500, Geoff Wedig wrote:
> >In other words, the language enforces something you have to go to outside
> >tools for in other languages?  And this is a bad thing?
>
> That's not what I said.  What I said is, you can fix broken indentation in
> other languages, because there are other cues as to how it should have
been
> done.  In Python, when (not if) the indentation gets broken, the program
stops
> working, and you might not even notice.  Yes, that is a bad thing.

I'm reminded of the old schtick:

Patient:  Doctor, it hurts when I do this.
Doctor:   Don't do that.

Yes, a lame or maladjusted word processor might break code.   Just as that
infernal LF-CR or CR-LF ordering which regularly rears its little ugly head
in programming text widgets. But you will SURELY notice, eventually, and
take the necessary steps to insure that your tools behave as needed.

After all, code text editors can be syntax-smart, color-coding keywords and
comments, enforcing close-parens and the like.  Newlines, blank lines and
indents can be rendered just as significant-- and eventually, with a little
practice, become that way in the eye of the prgrammer (or, more importantly,
the MAINTAINER).

I am 100% FOR syntactically requiring white space and visual blocking
structure- perhaps because I have been doing this voluntarily for over 20
years.  I assure you, the practice leads to the most easily modifiable and
maintainable code you will encounter anywhere.

Post a reply to this message

On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
>
>I'm reminded of the old schtick:
>
>Patient:  Doctor, it hurts when I do this.
>Doctor:   Don't do that.

Me too.  And for me, significant whitespace is very much a "Don't do that
then" thing.  Not that I don't enforce whitespace; if I had my way, our 
version-control software here would check for compliance with the coding
standards before allowing checkins.  Unfortunately, the software isn't up
to it and neither is the code (which a whole bevy of contractors got to
before we did.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
>Yes, a lame or maladjusted word processor might break code.   Just as that
>infernal LF-CR or CR-LF ordering which regularly rears its little ugly head
>in programming text widgets. But you will SURELY notice, eventually, and
>take the necessary steps to insure that your tools behave as needed.

The problem is that "eventually" part.  I'd rather not notice it after the
code has been sent to production.  And while it's fine to say "don't do that,
then" it's a lot harder to say that to an entire team of programmers plus an
assortment of random contractors.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
> >Yes, a lame or maladjusted word processor might break code.   Just as
that
> >infernal LF-CR or CR-LF ordering which regularly rears its little ugly
head
> >in programming text widgets. But you will SURELY notice, eventually, and
> >take the necessary steps to insure that your tools behave as needed.
>
> The problem is that "eventually" part.  I'd rather not notice it after the
> code has been sent to production.  And while it's fine to say "don't do
that,
> then" it's a lot harder to say that to an entire team of programmers plus
an
> assortment of random contractors.
>

I understand the nature of the difficulty of working with existing code and
an existing assortment of trained (read 'ingrained habits') programmers.  A
paradigm shift (or even a modest change) in those circusmstances is often
nearly impossible.

But your objections are EXACTLY those which were genuinely expressed when
the world was urged to move from spaghetti code to structured code,  and
from the structured-linear model to the object-oriented model.  Yes, a
change in methods is not without its difficulties in the SHORT term-- and
probably should NOT be attempted mid-project.

(I will have to say, however, that to "notice it after the code has been
sent to production" would suggest a breakdown in- or absense of- adequate
testing protocols.  In my view, any programmer which creates/modifies code
without creating/using in parallel an exhaustive every-state module testing
regime- as much or more work than writing the original code- simply has not
finished the job.)

So, when I speak favorably of Python's use of white space- a concept I would
enjoy seeing extended, as mentioned- I am thinking in terms of new projects,
with programmers who have fully adapted to the needs of the programming
environment, and with a project for which the ongoing needs are as important
as the need to get it done and out quickly.

In these contexts, using white space and enforced commenting will, I
believe, eventually be seen as a scientific, legal and commercial necessity,
simply GOOD programming practice, not just as an arcane preference.

___

Post a reply to this message

> It was *supposed* to go to povray.off-topic...how did your post get
> back here? Followup-To is again set to povray.off-topic...

If you expect a reply, we have to select a newsgroup which is valid.  I'm
not showing the presence of that group, and get an error.

> > # end, # endloop, # end whateverthehellyerstopping       :-)
>
> I really don't like this...it's a comment, not part of the program. And
> if you mess up with it, there won't be any error or warning to let you
> catch the problem.

Actually, an IDE COULD catch any rule you wanted to enforce.  But I was
mostly joking.


> But you are writing in English, not Python and not any other programming
> language. And grouping different concepts by separating them with white
> space is different from specifying which block an instruction is in by
> it's level of indentation. Even when writing instructions in English, I
> tend to take a more structured approach, grouping each stage together
> with it's sub-stages.
> And even English sentences have a termination character, the
> period/exclamation point/question mark.

English (and all other human languages) ARE programming languages.  The
machine they run is a computer we call the human mind.  The only difference
is one of complexity and the amount of ambiguity which is tolerated.  No
differences in principle.

English is obviously not the only language.  Some amazing thoughts have been
expressed in languages which use NO punctuation, with meaning established by
rules of context and convention.

But punctuation is a helpful invention.  As is the use of white space.  It
is ALL expressive, and nothing should be rejected as a potential tool.


> Alright, I understand now...funny how that got interpreted as exactly
> the opposite of what you meant.
> Hmm...would white space count in your comments? ;-)

That's because ambiguity is inevitable in implicit conceptual speech.  Your
interpretation was POSSIBLE, but just how probable was it that I was
completely contradicting myself?  Thus the importance of context (both
linguistic and psychological), and even the greatest punctuation cannot
resolve every implicit referent.

> I think an enforced minimum would just result in a lot of low-quality,
> "space-filler" comments, or even strings of garbage characters.

Just as no enforced comments can result in no comments at all.  Make it
foolproof and some will reinvent themselves as better fools.  At least, such
a scheme would only serve as a REMINDER that commenting is a good idea-- or
a requirement if one is on a programming team.  Anyone on my team who
habitually substitutes garbage characters for meaningful comments would soon
be granted an extended vacation.


> > As for comments to the right, as opposed to mixed within the code,
> > that's an excellent scheme which I've been using for over twenty
> > years, all the way back to assembler code.  With high level languages
> > the commenting can be more sparse, but should still be GENEROUS.
>
> If you say so...20 years of experience certainly beats what I have. It
> just seems like a huge pain when writing or even just reading
> comments...

Yes, it is FAR easier in the short term to slap uncommented code together.
The HUGE pain comes when it grows to over 20 pages.

I once read a book about a language called Forth.  When I finally received
the software, I wrote a screen editor within the first 24 hours.  Worked
pretty well.  The next week, I could not read what I had written.

> especially when you are maintaining the code and the length
> of lines keeps changing.

That's what smart editors are for.

> And what if you have a really long line? Do you just skip the comments
> over it? BTW, how does Python react if you break a very long line
> (function parameters, for example) into several lines and indent them
> for readability? I've got some horrendous examples of this...

There is ALWAYS a way to do things readably.

>> The Goddess of Reality merely smiles.
> Cough...Java...ahem...

Shhh... you want to start a Holy War here?  8-O

Post a reply to this message

On Thu, 8 Feb 2001 14:09:35 -0800, OpenMined wrote:
>(I will have to say, however, that to "notice it after the code has been
>sent to production" would suggest a breakdown in- or absense of- adequate
>testing protocols.  In my view, any programmer which creates/modifies code
>without creating/using in parallel an exhaustive every-state module testing
>regime- as much or more work than writing the original code- simply has not
>finished the job.)

Such testing is impossible in an environment such as the one we work in, 
where the set of possible conditions is dictated by how many "innovative"
ways programmers we'll never meet can find to do the same thing.  The 
"input" to our application is other peoples' programs, and they're often
broken in strange ways.

Who would have thought, for example, that a team of crack monkeys at a
firm I won't name would have decided to draw focus rectangles by calling
ExtTextOut with an empty string and with the "background opaque" flag 
set to TRUE, once for each side of the box?

Anyway, the point is, unit testing and integration testing only go so far.
It's very possible for errors to slip through such processes, and anything
that tends to make it easier to make such errors is a bad thing.  In my
view, that makes significant whitespace a bad thing.

Notice that I'm not saying it's a bad thing for everyone.  It's just not
something I'll ever do, because unlike structured programming and object-
oriented programming, it has no perceptible advantage over enforcing the
whitespace rules at checkin time, and far more caveats.

>So, when I speak favorably of Python's use of white space- a concept I would
>enjoy seeing extended, as mentioned- I am thinking in terms of new projects,
>with programmers who have fully adapted to the needs of the programming
>environment, and with a project for which the ongoing needs are as important
>as the need to get it done and out quickly.

If I were starting a new project, I would put rules in the revision
control system to enforce the style guide.  That solves the problem of
whitespace without causing potential bugs, and it can enforce other rules
too.  IMHO, presentation and syntax should be separate.  I understand that
you don't agree, so I suggest we just agree to disagree.

As to comments, I couldn't agree more.  In fact, I use the same prototyping
method you do: write the pseudocode, then fill in the code (but I fill in
the code between the comments, rather than to the left of them.  That makes 
them less confusing for the visually-impaired members of our team to read.)
We also enforce comments on all closing braces, for the benefit of the same
people (who often have punctuation turned off in their screen readers.)  In
fact, I'd be very surprised if the POV 3.5 code ships without at least one
} // end if

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message