Collective memory (was: Good code patterns in Python)
Cameron Laird
Bob Gailer <bga...@alum.rpi.edu> wrote:
.
.
.
>This brings back the good old days of FORTRAN IV which had a
>single-statement IF and no ELSE. Thus:
> C = VALUE1
> IF ( A .EQ. B) C = VALUE2
>Notice the indentation. Cols 1-5 were reserved for line # and col 6 for the
>continuation code. So Python is not the only indentation dependent
>language. Nor is it the first to use indentation to convey structure.
.
.
.
Maybe youngsters don't realize this.
One monotonous but unremitting argument that Python inspires
is about the wisdom of its white-space-significance (WSS).
Modern programmers might not realize how strongly old-timers
associate WSS with early FORTRAN and COBOL (as we capitalized
them then), and how unpleasant some of those memories are.
*That*, I assume, is why WSS discussions become as heated as
they do.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Rupert Pigott
news:vg88va...@corp.supernews.com...
> In article <mailman.105708372...@python.org>,
> Bob Gailer <bga...@alum.rpi.edu> wrote:
> .
> .
> .
> >This brings back the good old days of FORTRAN IV which had a
> >single-statement IF and no ELSE. Thus:
> > C = VALUE1
> > IF ( A .EQ. B) C = VALUE2
> >Notice the indentation. Cols 1-5 were reserved for line # and col 6 for
the
> >continuation code. So Python is not the only indentation dependent
> >language. Nor is it the first to use indentation to convey structure.
> .
> .
> .
> Maybe youngsters don't realize this.
>
> One monotonous but unremitting argument that Python inspires
> is about the wisdom of its white-space-significance (WSS).
> Modern programmers might not realize how strongly old-timers
> associate WSS with early FORTRAN and COBOL (as we capitalized
> them then), and how unpleasant some of those memories are.
> *That*, I assume, is why WSS discussions become as heated as
> they do.
OCCAM used WS to denote block structure... For
example the IF construct :
IF
x > 0
y := 10
x < 0
y := 0
x = 0
y := 5
Personally I also found this a pain coming from
a C background... BUT, I grew to love it. It
normalised code layout, which meant that picking
up someone else's code was MUCH easier... As a
bonus it eliminated the holy wars about formatting
that have ravaged through every gathering of >=2
C coders. :)
Cheers,
Rupert
Pete Fenelon
>
> OCCAM used WS to denote block structure... For
...and was generally written with folding editors that just "got it
right" ;)
pete
--
pe...@fenelon.com "there's no room for enigmas in built-up areas" HMHB
Rupert Pigott
news:vg8hns2...@corp.supernews.com...
> In alt.folklore.computers Rupert Pigott
<r...@dark-try-removing-this-boong.demon.co.uk> wrote:
> >
> > OCCAM used WS to denote block structure... For
>
> ...and was generally written with folding editors that just "got it
> right" ;)
I noticed that a few of the KDE 3.1 editors support folding... :)
Took me a while to work out what those lines & + things were in
the left margin... Made me happy. :)
Cheers,
Ruppert
Pete Fenelon
>
> I noticed that a few of the KDE 3.1 editors support folding... :)
Hmmmm, editor and GUI are two concepts that I try to keep firmly
separated ;)
Charles Shannon Hendrix
> Maybe youngsters don't realize this.
>
> One monotonous but unremitting argument that Python inspires
> is about the wisdom of its white-space-significance (WSS).
> Modern programmers might not realize how strongly old-timers
> associate WSS with early FORTRAN and COBOL (as we capitalized
> them then), and how unpleasant some of those memories are.
> *That*, I assume, is why WSS discussions become as heated as
> they do.
The problem with Python is that its use of indentation is not the same
as COBOL or FORTRAN. Apples and Oranges.
Those languages just had an arbitrary format, but it was specific and
easy to catch.
Python uses it for actually determining the logic in your program, which
IMHO is dangerous.
if <something>
<work>
<more work>
<add numbers>
Is <add numbers> part of the if statement, or did someone with different
tab settings from the author make a mistake and align it accidentally?
One really funny problem was when I guy reformatted his Python code,
around 15K lines of it, and basically unindented *ALL* of the code to
column 1. It was the only recoverable copy of the code too.
He had to read the entire program line by line to recreate the logic.
The thing that bothers me though is I have found indent-related bugs in
Python code that no one knew about. The code still ran, but some people
had obviously made some bad assumptions about the logic and indented
it wrong, changing the nature of the program.
I know a lot of people disagree, but I really think whitespace should
not determine flow-control in a program.
--
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Peter Hansen
>
> The thing that bothers me though is I have found indent-related bugs in
> Python code that no one knew about. The code still ran, but some people
> had obviously made some bad assumptions about the logic and indented
> it wrong, changing the nature of the program.
In other words, had they been using a language with, say, braces
to delimit blocks, these same people would have put code inside
the braces when it should have been outside, or vice versa.
In other words, it was merely a bug, unrelated to indentation,
but in fact caused solely by programmer error.
What was the point about indentation you were trying to make again? ;-)
-Peter
Stan Barr
<sha...@news.widomaker.com> wrote:
>
>The problem with Python is that its use of indentation is not the same
>as COBOL or FORTRAN. Apples and Oranges.
>
>Those languages just had an arbitrary format, but it was specific and
>easy to catch.
>
>Python uses it for actually determining the logic in your program, which
>IMHO is dangerous.
I had a disagreement with a Python fan on this very subject not so long back.
I was arguing that indentation should be a matter of programming style not
program logic. Even NCC Filtetab which uses tables as a programming
construct doesn't require exact indentation of each line.
>I know a lot of people disagree, but I really think whitespace should
>not determine flow-control in a program.
*I* agree :-)
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
Irmen de Jong
> Python uses it for actually determining the logic in your program, which
> IMHO is dangerous.
>
> if <something>
> <work>
> <more work>
> <add numbers>
>
> Is <add numbers> part of the if statement, or did someone with different
> tab settings from the author make a mistake and align it accidentally?
To catch such mistakes, Python has the -tt command line option:
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
There's also tabnanny.py in the standard library to check things
before executing code. I'm not sure, but I suspect that PyChecker
also checks this.
--Irmen
Gene Wirchenko
>Charles Shannon Hendrix wrote:
> > Python uses it for actually determining the logic in your program, which
> > IMHO is dangerous.
Not at all. It just means that I will never use Python if it is
at all avoidable. My backhanded compliments: it is actually less safe
than C.
> > if <something>
> > <work>
> > <more work>
> > <add numbers>
> >
> > Is <add numbers> part of the if statement, or did someone with different
> > tab settings from the author make a mistake and align it accidentally?
>
>To catch such mistakes, Python has the -tt command line option:
>-t : issue warnings about inconsistent tab usage (-tt: issue errors)
What is inconsistent about the tab usage above? That is, why
would it be flagged?
>There's also tabnanny.py in the standard library to check things
>before executing code. I'm not sure, but I suspect that PyChecker
>also checks this.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Charles Shannon Hendrix
> Charles Shannon Hendrix wrote:
>>
>> The thing that bothers me though is I have found indent-related bugs in
>> Python code that no one knew about. The code still ran, but some people
>> had obviously made some bad assumptions about the logic and indented
>> it wrong, changing the nature of the program.
>
> In other words, had they been using a language with, say, braces
> to delimit blocks, these same people would have put code inside
> the braces when it should have been outside, or vice versa.
Um, no. That's an entirely different and far less likely class of
error.
> In other words, it was merely a bug, unrelated to indentation,
> but in fact caused solely by programmer error.
But its a bug that can happen in far more cases than with block
delimiters.
Just an editor screwup, a minor one, can render thousands of lines of
logic utterly indecipherable.
Donald 'Paddy' McCarthy
> The problem with Python is that its use of indentation is not the same
> as COBOL or FORTRAN. Apples and Oranges.
>
> Python uses it for actually determining the logic in your program, which
> IMHO is dangerous.
>
> if <something>
> <work>
> <more work>
> <add numbers>
>
> Is <add numbers> part of the if statement, or did someone with different
> tab settings from the author make a mistake and align it accidentally?
Well, no matter WHAT the language, I find tabs are evil little things
that introduce special cases and the need for code to handle them.
That said though, I find python block structure (sans tabs), just fine
thanks.
It would be nice if tabs as indentation for Python was deprecated but
failing that, If you don't use tabs, its wonderful.
If you do try python, try not to indent with tabs, and please try it, I
did and look at me now :-)
Cheers, Pad.
Ben Hutchings
Charles Shannon Hendrix wrote:
<snip>
> as COBOL or FORTRAN. Apples and Oranges.
>
> Those languages just had an arbitrary format, but it was specific and
> easy to catch.
>
> Python uses it for actually determining the logic in your program, which
> IMHO is dangerous.
>
> if <something>
> <work>
> <more work>
> <add numbers>
>
> Is <add numbers> part of the if statement, or did someone with different
> tab settings from the author make a mistake and align it accidentally?
It's true that a difference in tab settings can result in bugs, but
there is only one correct setting - the one that the Python
interpreter uses, which is tab stops at intervals of 8 spaces.
Received wisdom is that it's best to use spaces only, just to be sure.
> One really funny problem was when I guy reformatted his Python code,
> around 15K lines of it, and basically unindented *ALL* of the code to
> column 1. It was the only recoverable copy of the code too.
>
> He had to read the entire program line by line to recreate the logic.
Now imagine accidentally deleting all the close-braces in a C program.
I suspect you can destroy a program in any language very quickly with
a text editor.
> The thing that bothers me though is I have found indent-related bugs in
> Python code that no one knew about. The code still ran, but some people
> had obviously made some bad assumptions about the logic and indented
> it wrong, changing the nature of the program.
Why would they not make the same logical errors if blocks are
delimited by {...} or begin...end?
> I know a lot of people disagree, but I really think whitespace should
> not determine flow-control in a program.
Virtually everyone uses indentation to indicate code blocks in free-
form languages, even though the compiler itself pays no attention to
it. This means that there is duplication of information, and that
duplication can result in inconsistency.
Consider this C code:
if (foo) {
if (bar)
baz;
blah;
}
Due to the misplaced open-brace, this really means:
if (foo) {
if (bar)
baz;
blah;
}
It is impossible to make such a mistake in Python (except with a
misconfigured editor). Making the compiler look at the indentation
avoids the possibility of a discrepancy between the block structures
seen by the programmer and the compiler.
--
Ben Hutchings | personal web site: http://womble.decadentplace.org.uk/
Man invented language to satisfy his deep need to complain. - Lily Tomlin
Ben Hutchings
> Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:
>
>>Charles Shannon Hendrix wrote:
>> > <work>
>> > <more work>
>> > <add numbers>
>> >
>> > Is <add numbers> part of the if statement, or did someone with different
>> > tab settings from the author make a mistake and align it accidentally?
>>
>>To catch such mistakes, Python has the -tt command line option:
>>-t : issue warnings about inconsistent tab usage (-tt: issue errors)
>
> What is inconsistent about the tab usage above? That is, why
> would it be flagged?
If the above used only tabs for indentation, there could be no
question about how the statements were meant to be grouped.
Similarly, if it used only spaces for indentation, there could be no
question. The problematic case that CSH is worried about is where the
code uses a mixture of spaces and tabs (this is what is meant by
"inconsistent"), e.g.:
<SP><SP><SP><SP>if <something>:
<SP><SP><SP><SP><SP><SP><SP><SP><work>
<SP><SP><SP><SP><SP><SP><SP><SP><more work>
<HT><add numbers>
In a text editor misconfigured to use 4-space tabs this appears as:
if <something>:
<work>
<more work>
<add numbers>
but since Python uses 8-space tabs it really means:
if <something>:
<work>
<more work>
<add numbers>
So there is a risk here, and it's probably worth adopting a rule of
not using tabs in Python code. If you think a colleague broke the
rule, the -t flag will alert you to any potential problems.
Mel Wilson
Donald 'Paddy' McCarthy <padd...@netscape.netNOTthisBIT> wrote:
>Charles Shannon Hendrix wrote:
>> IMHO is dangerous.
>>
>> if <something>
>> <work>
>> <more work>
>> <add numbers>
>>
>> Is <add numbers> part of the if statement, or did someone with different
>> tab settings from the author make a mistake and align it accidentally?
>Well, no matter WHAT the language, I find tabs are evil little things
>that introduce special cases and the need for code to handle them.
>That said though, I find python block structure (sans tabs), just fine
>thanks.
The C equivalent is to hide a `;}` in the middle of what
looks like a huge function call.
>It would be nice if tabs as indentation for Python was deprecated but
>failing that, If you don't use tabs, its wonderful.
If you only use tabs it's also wonderful. The worldwide
Python community has settled on spaces. I expand tabs in
any code I share with the world, and everybody seems happy.
Regards. Mel.
Stan Barr
<ben-publ...@decadentplace.org.uk> wrote:
>
>It's true that a difference in tab settings can result in bugs, but
>there is only one correct setting - the one that the Python
>interpreter uses, which is tab stops at intervals of 8 spaces.
>Received wisdom is that it's best to use spaces only, just to be sure.
>
Excuse me if I'm being a little slow-witted here, but what are the
advantages of replacing visible tokens, such as { or BEGIN, with
invisible* ones like tabs or spaces? Surely anything that introduces
the possibility of ambiguity is to be deprecated.
* Or rather tokens indistinguishable from white space.
Charles Shannon Hendrix
<slrnbggc9a.8s2.b...@bunthorne.i.decadentplace.org.uk>, Ben
Hutchings wrote:
> So there is a risk here, and it's probably worth adopting a rule of
> not using tabs in Python code. If you think a colleague broke the
> rule, the -t flag will alert you to any potential problems.
No, it won't alert you to *any* of them.
Outdented coding accidents to happen, and you have to manually review
the code to see it. If you just happen to not know what the code was
supposed to have done, you can't fix these kinds of typos.
If you do it by previous and following implied logic, then you might
well get it right... or you might not.
The point is that when white-space determines logical flow, errors in
indentation add and destroy information.
Sure you can overcome it, but I just don't see the point.
I debugged and maintained big Python programs, and it was a frequent
error and problem.
Charles Shannon Hendrix
In article <3F082031...@netscape.netNOTthisBIT>, Donald 'Paddy'
McCarthy wrote:
>> Is <add numbers> part of the if statement, or did someone with different
>> tab settings from the author make a mistake and align it accidentally?
> It would be nice if tabs as indentation for Python was deprecated but
> failing that, If you don't use tabs, its wonderful.
That would make it even worse.
> If you do try python, try not to indent with tabs, and please try it, I
> did and look at me now :-)
Its precisely because I used it at work that I don't use it now...
There is a lot to like about it, but there's never been a compelling
reason to use it. We used it because it was buzzword compliant at the
time.
Ben Hutchings
Stan Barr wrote:
<snip>
> Excuse me if I'm being a little slow-witted here, but what are the
> advantages of replacing visible tokens, such as { or BEGIN, with
> invisible* ones like tabs or spaces?
I explained them at the bottom of my article.
Ben Hutchings
> In article
><slrnbggc9a.8s2.b...@bunthorne.i.decadentplace.org.uk>, Ben
> Hutchings wrote:
>
>> So there is a risk here, and it's probably worth adopting a rule of
>> not using tabs in Python code. If you think a colleague broke the
>> rule, the -t flag will alert you to any potential problems.
>
> No, it won't alert you to *any* of them.
It will alert you to cases where the block structure could have
appeared wrongly in a text editor, which is what I thought you were
complaining about.
> Outdented coding accidents to happen, and you have to manually review
> the code to see it. If you just happen to not know what the code was
> supposed to have done, you can't fix these kinds of typos.
The same goes for many kinds of typo, surely.
> If you do it by previous and following implied logic, then you might
> well get it right... or you might not.
>
> The point is that when white-space determines logical flow, errors in
> indentation add and destroy information.
When braces determine logical flow, errors in brace placement add and
destroy information.
> Sure you can overcome it, but I just don't see the point.
>
> I debugged and maintained big Python programs, and it was a frequent
> error and problem.
Please explain how your colleagues introduced errors that couldn't
have been caught by -t.
Peter Hansen
>
> Outdented coding accidents to happen, and you have to manually review
> the code to see it. If you just happen to not know what the code was
> supposed to have done, you can't fix these kinds of typos.
>
> If you do it by previous and following implied logic, then you might
> well get it right... or you might not.
>
> The point is that when white-space determines logical flow, errors in
> indentation add and destroy information.
>
> error and problem.
Curious... this is the first time I've seen someone actually report
it as a *frequent* problem.
My group has put out roughly 30 programmer-years of Python development
in the last few years and, to date, I know of only one case where a
simple indentation error caused a (detected) problem.
Analysis actually showed that this likely wasn't accidental, either,
but probably just a "brain fart". The same kind of thing that could
and does happen in any language, where a line is placed outside of a
code block when it should have gone inside. (I'd call it "accidental"
only if it looked like someone accidentally hit TAB once too many times,
or used TABs plus SPACEs instead of just SPACEs.)
I'm very surprised you found this a frequent thing. We've basically
seen none (apart from the above).
Could it be the XP process that helps us? Or our unit tests (not that
we have full coverage yet)? Or was there some problem inherent in your
own development process which makes this a likely occurrence?
-Peter
Charles Shannon Hendrix
>> No, it won't alert you to *any* of them.
>
> It will alert you to cases where the block structure could have
> appeared wrongly in a text editor, which is what I thought you were
> complaining about.
No, I can deal with that. Basically I set my editor up to handle Python
1 hours after playing with it and seeing that problem.
>> Outdented coding accidents to happen, and you have to manually review
>> the code to see it. If you just happen to not know what the code was
>> supposed to have done, you can't fix these kinds of typos.
>
> The same goes for many kinds of typo, surely.
Um, no... I can really screw C code up and reconstruct it without even
thinking.
With Python it is possible to destroy a program just by moving
everything to the first column.
> When braces determine logical flow, errors in brace placement add and
> destroy information.
Apples and oranges. Misplacing a brace is no different than misplacing
a for or a print routine.
Whitespace is a little bit different.
>> Sure you can overcome it, but I just don't see the point.
>>
>> I debugged and maintained big Python programs, and it was a frequent
>> error and problem.
>
> Please explain how your colleagues introduced errors that couldn't
> have been caught by -t.
They "corrected" code based on what they saw in the editor.
They made mistakes by outdenting code when it should have been indented.
If they see this:
statement
{
code;
}
...where code occurs doesn't matter, the structure implies logic and the
proper formatting.
statement
code
...does not. If I have
statement
code
statement
I cannot tell if code is in the right place or not, unless I am
intimately familiar with the details of the code.
Don't get me wrong, in some ways I think the idea of indentation and
logic flow being forced to agree is a neat idea. I just don't think its
always a very good one.
In any case, I can only relate what I've observed. In my own code, I
didn't have this problem, but I was already pretty rigid with my own
formatting.
jmfb...@aol.com
sta...@dial.pipex.com (Stan Barr) wrote:
>On Sun, 6 Jul 2003 15:11:14 +0100, Ben Hutchings
><ben-publ...@decadentplace.org.uk> wrote:
>>
>>It's true that a difference in tab settings can result in bugs, but
>>there is only one correct setting - the one that the Python
>>interpreter uses, which is tab stops at intervals of 8 spaces.
>>Received wisdom is that it's best to use spaces only, just to be sure.
>>
>
>Excuse me if I'm being a little slow-witted here,
You're not slow-witted; it is insane to have non-printing
characters produce code.
> .. but what are the
>advantages of replacing visible tokens, such as { or BEGIN, with
>invisible* ones like tabs or spaces? Surely anything that introduces
>the possibility of ambiguity is to be deprecated.
>
>* Or rather tokens indistinguishable from white space.
By using printable tokens, you can run a TECO macro over it
catch unmatched tokens (which is a common error when keying
in code). There isn't any way to do that because parsers
also use white space to distinguish between mundane things such
as variable names.
/BAH
Subtract a hundred and four for e-mail.
Ingvar Mattsson
[SNIP]
> Please explain how your colleagues introduced errors that couldn't
> have been caught by -t.
Python code being diffed (in a mix of tabs & spaces), unified pasted
into RT, unified pasted from RT to text file, diff applied. There
*may* have been an xterm involved too.
I have seen this myself, about 10 days ago.
//Ingvar
--
When C++ is your hammer, everything looks like a thumb
Latest seen from Steven M. Haflich, in c.l.l
Brian Boutel
And if you don't have printable tokens you can't mismatch them. End of
that problem.
The Haskell language uses indentation, but has an alternative
representation using semicolons and braces, which is more portable and
more suitable for machine-generated code. There is a rule[1] for
converting from the indented form to the bracketed form. The most likely
result of indentation error is misplaced (*not* mismatched) braces, but
it's just as easy to do that when you write them explicitly.
[1] The layout (or "off-side") rule takes effect whenever the open brace
is omitted after the keyword where, let, do, or of. When this happens,
the indentation of the next lexeme (whether or not on a new line) is
remembered and the omitted open brace is inserted (the whitespace
preceding the lexeme may include comments). For each subsequent line, if
it contains only whitespace or is indented more, then the previous item
is continued (nothing is inserted); if it is indented the same amount,
then a new item begins (a semicolon is inserted); and if it is indented
less, then the layout list ends (a close brace is inserted). If the
indentation of the non-brace lexeme immediately following a where, let,
do or of is less than or equal to the current indentation level, then
instead of starting a layout, an empty list "{}" is inserted, and layout
processing occurs for the current level (i.e. insert a semicolon or
close brace). A close brace is also inserted whenever the syntactic
category containing the layout list ends; that is, if an illegal lexeme
is encountered at a point where a close brace would be legal, a close
brace is inserted. The layout rule matches only those open braces that
it has inserted; an explicit open brace must be matched by an explicit
close brace. Within these explicit open braces, no layout processing is
performed for constructs outside the braces, even if a line is indented
to the left of an earlier implicit open brace.
--brian
--
Brian Boutel
Wellington New Zealand
Note the NOSPAM
Kevin Handy
> In article <mailman.105708372...@python.org>,
> Bob Gailer <bga...@alum.rpi.edu> wrote:
> .
> .
> .
>
>>This brings back the good old days of FORTRAN IV which had a
>>single-statement IF and no ELSE. Thus:
>> C = VALUE1
>> IF ( A .EQ. B) C = VALUE2
>>Notice the indentation. Cols 1-5 were reserved for line # and col 6 for the
>>continuation code. So Python is not the only indentation dependent
>>language. Nor is it the first to use indentation to convey structure.
>
There is a big difference between the two.
In FORTRAN, certial columns were allocated to specific purposes.
1-5 for the line number, 6 for comment/continuation, 7-75 for the
program line, 76-80 for sequence numbers. [iirc]
If you want a language that was even more position dependent than
fortran, look at RPG-II. You used printed forms for programming to
get the columns correct. One character in the wrong column would
change the meaning of that line.
In PYTHON, it is the indentation itself that matters, not the
actual column position.
Charles Shannon Hendrix
> Curious... this is the first time I've seen someone actually report
> it as a *frequent* problem.
You are the first I've seen to defend it in awhile too.
It was frequent enough to annoy the hell out of me.
I could not get the others to set up their editor to avoid the problem,
and some people were unable to get in the right mindset and were danger
to every file they touched.
> I'm very surprised you found this a frequent thing. We've basically
> seen none (apart from the above).
I've never seen any of the problems you mentioned for C either. Your
mileage varies... :)
> Could it be the XP process that helps us? Or our unit tests (not that
> we have full coverage yet)? Or was there some problem inherent in your
> own development process which makes this a likely occurrence?
I have XP myself. Yet another problem causing thing in my book, though
I'm sure it can be done right sometimes.
My biggest problem with it is that I feel its solving a problem that
should not exist.
But some of the basic ideas, like pairing programmers, are good.
--
UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com
jmfb...@aol.com
And if they don't show up on your paper in black on white, you can't
tell if a nefarious program substituted other characters codes for
the ones you used as indentation. It wouldn't matter so much if
you could look at the keypunch _holes_ to figure out what characters
you've got, but you can't that with a display of ASCII.
And then you've got people^Wprograms who don't know about
non-proportional fonts...
<snip>
Tim Shoppa
> Charles Shannon Hendrix wrote:
>
>
> > The problem with Python is that its use of indentation is not the same
> > as COBOL or FORTRAN. Apples and Oranges.
And it's not the same as Makefiles, either. Everybody has at one time
been bitten by how 8 spaces is not at all the same in a Makefile as
one tab; and it doesn't help that with many editing/viewing tools that it
is impossible to see the difference.
> > Python uses it for actually determining the logic in your program, which
> > IMHO is dangerous.
Again, it is certainly no use than Makefiles.
> Well, no matter WHAT the language, I find tabs are evil little things
> that introduce special cases and the need for code to handle them.
Compare that to all the punctuation marks that *some* other languages require.
Remember the Dilbert where PHB complains that his programmers are using
way too many semicolons? :-)
Tim.
jmfb...@aol.com
sho...@trailing-edge.com (Tim Shoppa) wrote:
<snip>
>Remember the Dilbert where PHB complains that his programmers are using
>way too many semicolons? :-)
All RIGHT! That's a good PHB. It was so difficult to distinguish
between a semicolon and a colon on the listings.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> And if they don't show up on your paper in black on white, you can't
> tell if a nefarious program substituted other characters codes for
> the ones you used as indentation. It wouldn't matter so much if
> you could look at the keypunch _holes_ to figure out what characters
> you've got, but you can't that with a display of ASCII.
>
will be listed as "^I", which is what the tab character is. Of
course, the keypunch holes are *not* visible in vi(m).
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> FORTRAN isn't indentation dependent, it is position dependent.
> There is a big difference between the two.
>
> In FORTRAN, certial columns were allocated to specific purposes.
> 1-5 for the line number, 6 for comment/continuation, 7-75 for the
> program line, 76-80 for sequence numbers. [iirc]
>
> If you want a language that was even more position dependent than
> fortran, look at RPG-II. You used printed forms for programming to
> get the columns correct. One character in the wrong column would
> change the meaning of that line.
>
a plastic overlay for the screen so they could see what column
that things were being typed into.
The "C" language gives white space significance...especially
if it determines what a token will be. The tokenizer tries to
build the longest token possible. So:
x = i++ + j;
is *not* the same as:
x = i + ++j;
and the statement:
x = i+++j;
is the same as:
x = i++ + j;
If you have:
int *p, x, y;
then:
y = x/*p;
is quite different from:
y = x / *p;
The first way, "/*" will begin a comment...the second way,
you get the integer "x" divided by the integer pointed to by "p".
Charles Shannon Hendrix
> And it's not the same as Makefiles, either. Everybody has at one time
> been bitten by how 8 spaces is not at all the same in a Makefile as
> one tab; and it doesn't help that with many editing/viewing tools that it
> is impossible to see the difference.
Listing one bad thing to defend another?
I hate that part of make too.
However, its very easy to tab a makefile properly, because the logic
is implicit in the rule sets. You just find each rule and indent its
members properly. It's not ambiguous.
You also get an error... in Python, you'll just have a different flow of
logic, which may or may not show errors.
As long as you are strict and careful, Python is OK, but I will likely
never like invisible flow-control characters. In makefiles either... :)
>> > Python uses it for actually determining the logic in your program, which
>> > IMHO is dangerous.
>
> Again, it is certainly no use than Makefiles.
Heh heh... I agree...
>> Well, no matter WHAT the language, I find tabs are evil little things
>> that introduce special cases and the need for code to handle them.
>
> Compare that to all the punctuation marks that *some* other languages require.
> Remember the Dilbert where PHB complains that his programmers are using
> way too many semicolons? :-)
Don't get me started on code reviews by non-programmers.
Somewhere I have one saved, that I still can't figure out.
Tim Shoppa
> In article <bec993c8.03070...@posting.google.com>, Tim Shoppa wrote:
>
> > And it's not the same as Makefiles, either. Everybody has at one time
> > been bitten by how 8 spaces is not at all the same in a Makefile as
> > one tab; and it doesn't help that with many editing/viewing tools that it
> > is impossible to see the difference.
>
> Listing one bad thing to defend another?
I don't think the choice made in Python is bad. Different, yes. I usually
think that "Different is good", in fact :-).
> I hate that part of make too.
>
> However, its very easy to tab a makefile properly, because the logic
> is implicit in the rule sets. You just find each rule and indent its
> members properly. It's not ambiguous.
>
> You also get an error...
Not always. GNU Make is pretty good about flagging errors, but many other
make utilities fail silently in the same circumstances.
> > Compare that to all the punctuation marks that *some* other languages require.
> > Remember the Dilbert where PHB complains that his programmers are using
> > way too many semicolons? :-)
>
> Don't get me started on code reviews by non-programmers.
>
> Somewhere I have one saved, that I still can't figure out.
I'd love to see it! I keep a couple on my office walls where "EXTREME CHANCE
OF FATALITY" is the conclusion.
Tim.
Walter Bushell
<Snip>
> int *p, x, y;
>
> then:
>
> y = x/*p;
>
> is quite different from:
>
> y = x / *p;
>
> The first way, "/*" will begin a comment...the second way,
> you get the integer "x" divided by the integer pointed to by "p".
Ouch!! That is one reason code coloring is *important*.
I remember working in Fortran and being confused why the compiler was
not accepting the if statement, 'til we looked at the cards and saw it
was a "1F" statement.
--
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter
Abigail
<URL:news:1fxw51u.2b4m6zc39wulN%pr...@panix.com>:
++ Charles Richmond <rich...@ev1.net> wrote:
++ <Snip>
++ > int *p, x, y;
++ >
++ > then:
++ >
++ > y = x/*p;
++ >
++ > is quite different from:
++ >
++ > y = x / *p;
++ >
++ > The first way, "/*" will begin a comment...the second way,
++ > you get the integer "x" divided by the integer pointed to by "p".
++
++ Ouch!! That is one reason code coloring is *important*.
Nope. That's a reason why code colouring is evil. If you write code,
and it isn't clear what you mean without the use of code colouring,
you did something wrong. Your code shouldn't rely on a specific code
colouring scheme to be understandable.
All in my opinion of course.
Abigail
Rupert Pigott
"Abigail" <abi...@abigail.nl> wrote in message
news:slrnbgt6ls....@alexandra.abigail.nl...
My preference has been to make heavy use of ()'s to
make the meaning of expressions clear. Also I have
seen people cut & paste expressions from one language
to another without checking the precedence rules. You
know what happened next ! :)
Cheers,
Rupert
Gene Wirchenko
And mine.
>My preference has been to make heavy use of ()'s to
>make the meaning of expressions clear. Also I have
>seen people cut & paste expressions from one language
>to another without checking the precedence rules. You
>know what happened next ! :)
Not unless I know the precedence rules. <G>
Another fun one is mixing languages that truncate when converting
float to integer and that round. Like MBASIC 4 to MBASIC 5. I still
remember that boneheaded maneuver over twenty years later.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
John Roth
This assumes that someone reading the code is going to be using
a brain-dead editor. We need to get beyond that some day, and
assume that people are going to be using decent tools.
John Roth
Charles Richmond
>
> Charles Richmond <rich...@ev1.net> wrote:
> <Snip>
> > int *p, x, y;
> >
> > then:
> >
> > y = x/*p;
> >
> > is quite different from:
> >
> > y = x / *p;
> >
> > The first way, "/*" will begin a comment...the second way,
> > you get the integer "x" divided by the integer pointed to by "p".
>
> Ouch!! That is one reason code coloring is *important*.
>
> I remember working in Fortran and being confused why the compiler was
> not accepting the if statement, 'til we looked at the cards and saw it
> was a "1F" statement.
>
was running the program she wrote for her assignment. One statement
did *not* seem to do anything. She spend at least 30 minutes trying
to figure out what was wrong. Turns out that there was a "*" in
column one, and the statement was really a comment...and generated
*no* code.
This happened because she was punching her program on good ole' 80
column cards, in a student environment where many people used the
same keypunch machines. Often people would pick up the "blank"
cards and stick them back in the input hopper for the keypunch.
It was easy to miss the "*" punched in column one, because the upper
left corner of the cards was sliced off by design. So the unlucky
girl just happened to get a card that *already* had a "*" in column
one, when she punched up her program. Instant bug...
Another favorite beginner mistake was punching code past column 72
in FORTRAN IV. Sometimes, if you were unlucky, the FORTRAN code
would make sense *without* the part beyond column 72. Of course,
the results would *not* be what was expected.
Walter Bushell
Of course, we have to consider color blind programmers.
Well we shouldn't have a single space making such a difference,
particuarly when white space does not usually matter, in an arithmetic s
tatement no less. Division by the integer pointer to by p and the
beginning of a comment in something that is rather large.
Something like this
y = x/*p++ +expression;
Above will be caught usually by results I presume
However, how strings are implemented in quoted strings and the standard
library is a nightmare.
> >
> > All in my opinion of course.
> >
> >
> > Abigail
--
The last temptation is the highest treason:
To do the right thing for the wrong reason. --T..S. Eliot
Walter
Mark VandeWettering
>> Nope. That's a reason why code colouring is evil. If you write code,
>> and it isn't clear what you mean without the use of code colouring,
>> you did something wrong. Your code shouldn't rely on a specific code
>> colouring scheme to be understandable.
>
> This assumes that someone reading the code is going to be using
> a brain-dead editor. We need to get beyond that some day, and
> assume that people are going to be using decent tools.
I don't use code coloring editors for a number of reasons.
1. Code coloring makes code harder to read. There are two obvious choices to
pick for the background color of text editors: white and black. Against
a white background, only darker colors have contrast. Against black, only
lighter ones do. This drastically limits the number of colors that you can
use.
Recently my place of employment changed the default vi that people use to
perform syntax coloring. The result: my comments became dark red against a
black background. Some other class of keywords mapped to magenta and dark
blue. About 30 seconds of it made me want to gouge my eyes out.
2. Code coloring is almost always done on the basis of a syntactic basis.
Call me silly, but I've never found problems with syntax to be very
confusing. Other features of advanced editors like class browsers and the
like are useful because they relay some information which may not be
obvious from context, but that never seems to be a problem with syntax.
3. Good programming style allows you to read programs from top to bottom.
Syntax coloring encourages you to skip around by distracting the eye to
other parts. It's similar to the overuse of font changes in the written
word: it is a poor visual style.
4. Some people are color blind. Syntax coloring may not benefit them to
any significant degree.
I doubt anyone will find this arguments convincing, as this tends to be a bit
of a religious argument, but the problem isn't just one of tools: I have
access to such tools, I merely find them useless.
> John Roth
Charlie Gibbs
(Charles Shannon Hendrix) writes:
>I could not get the others to set up their editor to avoid the problem,
>and some people were unable to get in the right mindset and were danger
>to every file they touched.
This sets off all sorts of warning flags in my head. Although the
use of indentation sounds like an interesting idea on the surface,
the use of white space is just too fluid. Some editors convert
spaces to tabs, others convert tabs to spaces, and I don't want
to even think of what would happen if someone tried to view source
code in a proportional font.
No thanks. There are just too many opportunities for screw-ups.
Murphy never sleeps.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Steve O'Hara-Smith
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
CG> Some editors convert
CG> spaces to tabs, others convert tabs to spaces,
These are evil acts that should never happen - that vi does
this is annoying in the extreme.
CG> and I don't want
CG> to even think of what would happen if someone tried to view source
CG> code in a proportional font.
Works fine if you use TABS for indent and not as space
substitutes.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Walter Bushell
> On 14 Jul 03 10:15:40 -0800
> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
> CG> Some editors convert
> CG> spaces to tabs, others convert tabs to spaces,
>
> These are evil acts that should never happen - that vi does
> this is annoying in the extreme.
>
> CG> and I don't want
> CG> to even think of what would happen if someone tried to view source
> CG> code in a proportional font.
>
> Works fine if you use TABS for indent and not as space
> substitutes.
I once printed out a largish program in "San Fransico", which was an
early Macintosh font. One cirtique was that the only proper use of said
font was ransom notes.
Brian Inglis
"Rupert Pigott" <r...@dark-try-removing-this-boong.demon.co.uk>
wrote:
>"Pete Fenelon" <pe...@fenelon.com> wrote in message
>news:vg8hns2...@corp.supernews.com...
>> In alt.folklore.computers Rupert Pigott
><r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>> >
>> > OCCAM used WS to denote block structure... For
>>
>> ...and was generally written with folding editors that just "got it
>> right" ;)
>
>I noticed that a few of the KDE 3.1 editors support folding... :)
>
>Took me a while to work out what those lines & + things were in
>the left margin... Made me happy. :)
Xedit on IBM mainframes has supported it since at least the early
80s, as have later clones like Kedit, uni-xedit, THE; vim
supports it among the vi clones. emacs?
As an old Xedit user, it was normally called hiding or shadowing
referring to the shadow lines telling you how many lines are
hidden, scope, selective display, or just the "all" command.
What bright spark came up with a third overload of folding: as in
folding long lines; folding upper/lower case; and now folding
"structure"?
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Brian Inglis
sta...@dial.pipex.com (Stan Barr) wrote:
>On Fri, 4 Jul 2003 23:08:33 -0400, Charles Shannon Hendrix
><sha...@news.widomaker.com> wrote:
>>
>>The problem with Python is that its use of indentation is not the same
>>as COBOL or FORTRAN. Apples and Oranges.
>>
>>Those languages just had an arbitrary format, but it was specific and
>>easy to catch.
>>
>>Python uses it for actually determining the logic in your program, which
>>IMHO is dangerous.
>
>I had a disagreement with a Python fan on this very subject not so long back.
>I was arguing that indentation should be a matter of programming style not
>program logic. Even NCC Filtetab which uses tables as a programming
>construct doesn't require exact indentation of each line.
>
>>I know a lot of people disagree, but I really think whitespace should
>>not determine flow-control in a program.
>
>*I* agree :-)
IBM assembler used white space to delimit the label area,
instruction area, operand area, and comment area of a line.
This was okay when they allocated these areas to rigid fixed
column positions, but became a bad idea once they allowed "free
format" input and various amounts of white space advanced to the
next area on the line.
A mistyped space or two could cause you to have a comment in the
operand area, or an operand in the comment area, which did not
always trigger diagnostics.
Brian Inglis
Charles Shannon Hendrix <sha...@news.widomaker.com> wrote:
>In article <3F08E4CB...@engcorp.com>, Peter Hansen wrote:
>
>> Curious... this is the first time I've seen someone actually report
>> it as a *frequent* problem.
>
>You are the first I've seen to defend it in awhile too.
>
>It was frequent enough to annoy the hell out of me.
>
>I could not get the others to set up their editor to avoid the problem,
>and some people were unable to get in the right mindset and were danger
>to every file they touched.
>
>> I'm very surprised you found this a frequent thing. We've basically
>> seen none (apart from the above).
Then you haven't met programmers that insist on working with
their code on screen in proportionally spaced font $PRETTY, and
lean on the space bar and backspace keys for indentation and
alignment. Talk about San Francisco fonts!
Brian Inglis
jmfb...@aol.com wrote:
>In article <bec993c8.03070...@posting.google.com>,
> sho...@trailing-edge.com (Tim Shoppa) wrote:
><snip>
>
>>Remember the Dilbert where PHB complains that his programmers are using
>>way too many semicolons? :-)
>
>All RIGHT! That's a good PHB. It was so difficult to distinguish
>between a semicolon and a colon on the listings.
That's a lousy printer operator: the ribbon should have been
flipped end around long before it got to that stage.
(That's the old equivalent of shaking a laser toner cartridge.)
You also wouldn't be able to differentiate between commas and
dots, some apostrophes and quotes, maybe bars and bangs, possibly
parens brackets and braces, if you had and used them.
Brian Inglis
Hutchings <ben-publ...@decadentplace.org.uk> wrote:
>In article <hff5eb...@escape.shannon.net>,
>Charles Shannon Hendrix wrote:
><snip>
>> The problem with Python is that its use of indentation is not the same
>> as COBOL or FORTRAN. Apples and Oranges.
>>
>> Those languages just had an arbitrary format, but it was specific and
>> easy to catch.
>>
>> Python uses it for actually determining the logic in your program, which
>> IMHO is dangerous.
>>
>> if <something>
>> <work>
>> <more work>
>> <add numbers>
>>
>> Is <add numbers> part of the if statement, or did someone with different
>> tab settings from the author make a mistake and align it accidentally?
>
>It's true that a difference in tab settings can result in bugs, but
>there is only one correct setting - the one that the Python
>interpreter uses, which is tab stops at intervals of 8 spaces.
>Received wisdom is that it's best to use spaces only, just to be sure.
>
>> One really funny problem was when I guy reformatted his Python code,
>> around 15K lines of it, and basically unindented *ALL* of the code to
>> column 1. It was the only recoverable copy of the code too.
>>
>> He had to read the entire program line by line to recreate the logic.
>
>Now imagine accidentally deleting all the close-braces in a C program.
>I suspect you can destroy a program in any language very quickly with
>a text editor.
>
>> The thing that bothers me though is I have found indent-related bugs in
>> Python code that no one knew about. The code still ran, but some people
>> had obviously made some bad assumptions about the logic and indented
>> it wrong, changing the nature of the program.
>
>Why would they not make the same logical errors if blocks are
>delimited by {...} or begin...end?
>
>> I know a lot of people disagree, but I really think whitespace should
>> not determine flow-control in a program.
>
>Virtually everyone uses indentation to indicate code blocks in free-
>form languages, even though the compiler itself pays no attention to
>it. This means that there is duplication of information, and that
>duplication can result in inconsistency.
>
>Consider this C code:
>
> if (foo) {
> if (bar)
> baz;
> blah;
> }
>
>Due to the misplaced open-brace, this really means:
>
> if (foo) {
> if (bar)
> baz;
> blah;
> }
>
>It is impossible to make such a mistake in Python (except with a
>misconfigured editor). Making the compiler look at the indentation
>avoids the possibility of a discrepancy between the block structures
>seen by the programmer and the compiler.
I haven't been in a shop that allowed single statement blocks
without braces in their standards.
I have seen it used in some code at those shops, but that is just
down to lazy, stupid programmers, as usual.
I know to inspect code like that above to determine which of the
two possibilities is correct, then add the block terminators.
The same lazy programmers often indent their code only one or two
spaces per level at random, but will also insert a few extra
blank lines "for readability" at random.
Block delimiters and indentation are redundant, so at least you
know you have to inspect closely if there is a chance of a
discrepancy.
jmfb...@aol.com
Brian Inglis <Brian....@SystematicSw.ab.ca> wrote:
>On Tue, 08 Jul 03 12:43:14 GMT in alt.folklore.computers,
>jmfb...@aol.com wrote:
>
>>In article <bec993c8.03070...@posting.google.com>,
>> sho...@trailing-edge.com (Tim Shoppa) wrote:
>><snip>
>>
>>>Remember the Dilbert where PHB complains that his programmers are using
>>>way too many semicolons? :-)
>>
>>All RIGHT! That's a good PHB. It was so difficult to distinguish
>>between a semicolon and a colon on the listings.
>
>That's a lousy printer operator: the ribbon should have been
>flipped end around long before it got to that stage.
>(That's the old equivalent of shaking a laser toner cartridge.)
>You also wouldn't be able to differentiate between commas and
>dots, some apostrophes and quotes, maybe bars and bangs, possibly
>parens brackets and braces, if you had and used them.
Yep. I know it was due to lousy print quality. However, I firmly
believed that lousy print quality should have been a slight
constraint in designs.
Nowadays, we have great print quality; now, it's my eyesight that
smudges the pixels. And it still should be a slight contraint in
designs. Distinguishing characters, no matter what the display,
has to be a first consideration that is usually forgotten by
the time the design takes its first evolution. Just because
it's forgotten does not mean that it's no longer an implicit
assumption.
Eric Sosman
(comp.lang.python removed)
jmfb...@aol.com wrote:
>
> In article <bec993c8.03070...@posting.google.com>,
> sho...@trailing-edge.com (Tim Shoppa) wrote:
> <snip>
>
> >Remember the Dilbert where PHB complains that his programmers are using
> >way too many semicolons? :-)
>
> All RIGHT! That's a good PHB. It was so difficult to distinguish
> between a semicolon and a colon on the listings.
Semicolons and colons are more easily distinguished
than commas and full stops. Or, as I recall from one
politically incorrect mishap years and years ago, between
a full stop and nothing at all ...
Y'see, COBOL (a language I never learned but occasionally
debugged) used the full stop to terminate a group of related
executable statements -- the grouping may have been called
something like a "paragraph;" I'm not sure. Such a group
was more or less "callable" by means of a PERFORM statement
elsewhere in the program: PERFORM specified the first statement
of a group, which executed subsequent statements up to the full
stop and then returned to the statement after PERFORM.
A female programmer of my acquaintance was once having a
ghastly time trying to debug a COBOL program whose author had
used PERFORM quite heavily. The problem was eventually found
to be that a full stop had been omitted at the end of one of
these groups, so execution kept right on going into the body
of the following paragraph, thus executing a whole slew of
unintended and unexpected operations. And since the full stop
is the very smallest glyph, and since its presence or absence
isn't instantly apparent on a faint and smudgy printout, the
mistake took quite a while to find.
When she eventually found the problem and described the
cause to her manager, he was heard to mention that a girl
quite often first learns she's in trouble when she misses
a period ...
(Well, I warned you it was P.I., didn't I?)
Steve O'Hara-Smith
Brian Inglis <Brian....@SystematicSw.ab.ca> wrote:
BI> Then you haven't met programmers that insist on working with
BI> their code on screen in proportionally spaced font $PRETTY, and
BI> lean on the space bar and backspace keys for indentation and
BI> alignment. Talk about San Francisco fonts!
Is it permissible to execute these programmers instead of
their code ?
John Homes
"Brian Inglis" <Brian....@SystematicSw.ab.ca> wrote in message
news:mmrphvcn4cgpp4rtc...@4ax.com...
>
> IBM assembler used white space to delimit the label area,
> instruction area, operand area, and comment area of a line.
> This was okay when they allocated these areas to rigid fixed
> column positions, but became a bad idea once they allowed "free
> format" input and various amounts of white space advanced to the
> next area on the line.
Not sure here what your problem was. In all my days working with IBM
assemblers, after they got away from the fixed columns, *any* amount of
whitespace took you to the *next* area, which was usually what was wanted.
> A mistyped space or two could cause you to have a comment in the
> operand area, or an operand in the comment area, which did not
> always trigger diagnostics.
>
As in "one space will take you to the operand area, two consecutive spaces
will take you to the comment area"? That would suck mightily. But I've never
encountered anything that stupid. Always, any consecutive string of spaces
was equivalent to any other. I'm happy to work with that convention.
John Homes
Heinz W. Wiggeshoff
"John Homes" <john....@eds.com> wrote in message
news:bfk8r1$l1f$1...@hermes.nz.eds.com...
> As in "one space will take you to the operand area, two consecutive
spaces
> will take you to the comment area"? That would suck mightily. But
I've never
> encountered anything that stupid. Always, any consecutive string of
spaces
> was equivalent to any other. I'm happy to work with that convention.
Regretably, the same squad (or maybe mindset?) governed the design
of
JCL and 360 utility statements as the assembler. One day in the 360
MVT
era I suffered a curious JCL error: if the statement is continued
beyond
column 16 IIRC, it's treated as a comment. This messed up the rest
of
the job stream.
Brian Inglis
IIRC it was something obtuse like the next area was considered to
begin with the next non-space, but if you went over some length
or went over into the fixed columns for an area, because of using
macros, or symbolic constants instead of literal constants, a
space would take you into the area following the next logical
area; and you sometimes had to insert extra spaces to get to the
comment area if there were no operands for an instruction or
macro.
jmfb...@aol.com
Yep. That was a problem with COBOL syntax. I wanted a word,
not a fly spot. However, COBOL had its precedents(sp?) based
on cards so the fly spot didn't matter if you were looking at
holes.
>
> When she eventually found the problem and described the
>cause to her manager, he was heard to mention that a girl
>quite often first learns she's in trouble when she misses
>a period ...
>
> (Well, I warned you it was P.I., didn't I?)
<GRIN> I hope she was able to think fast on her feet and
respond with a comment involving shotguns.
That's (missing period) is where a step debugger is so useful.
DDT had a command that would execute one instruction and another
command that would execute the PUSHJ and stop when the call returned.
The COBOL debugger that DEC had was essentially a paragraph
debugger. So the key, when writing the code, was to include naming
paragraphs (or traces of some TTY flavor) with setting breakpoints
in mind.
/BAH
George R. Gonzalez
> A mistyped space or two could cause you to have a comment in the
> operand area, or an operand in the comment area, which did not
> always trigger diagnostics.
This could be used as a real life-saving "feature"!
In one huge assembly program I worked on (MNF, MInnesota FOTRAN), the
original writer
found that conditional assembly "IF" statements were rather slow.
A few thousand of these could make a serious dent in one's
computer time usage budget.
But he found that the "anything past column X is a comment" code was very
fast..... soooooo, with a little cleverness, one can arrange this column
sensitivity to do the conditional assembly job for you.
Not at all transparent, but when one is paying real budgetary $,
and doing thousands of re-assemblies per year, it seemed worth it.
Even with all the tricks, assembling MNF still took 300-some CPU seconds on
a Cyber 172.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> That's (missing period) is where a step debugger is so useful.
> DDT had a command that would execute one instruction and another
> command that would execute the PUSHJ and stop when the call returned.
> The COBOL debugger that DEC had was essentially a paragraph
> debugger. So the key, when writing the code, was to include naming
> paragraphs (or traces of some TTY flavor) with setting breakpoints
> in mind.
>
execute *one* source language instruction, or to execute
a function call and stop on the return. The debugger syntax
may be different...but I think you will find all of the
features from DDT contained in most dynamic debugging programs
today.
jmfb...@aol.com
Charles Richmond <rich...@ev1.net> wrote:
>jmfb...@aol.com wrote:
>>
>> [snip...] [snip...] [snip...]
>>
>> That's (missing period) is where a step debugger is so useful.
>> DDT had a command that would execute one instruction and another
>> command that would execute the PUSHJ and stop when the call returned.
>> The COBOL debugger that DEC had was essentially a paragraph
>> debugger. So the key, when writing the code, was to include naming
>> paragraphs (or traces of some TTY flavor) with setting breakpoints
>> in mind.
>>
>The dbx and gdb (GNU debugger) *both* have the ability to
>execute *one* source language instruction, or to execute
>a function call and stop on the return.
Is it the person debugging who determine the single instruction
or the compiler? In the example given, how would the missing
PERFORM termination character be found without tracing where
that single source language instruction meandered? A way would
be to set breakpoints at each paragraph name (which cannot be done
_within_ a COBOL sentence) and have the option of just printing
the trace as the program executed. You also need the option of
setting a temporary stop in the middle of a language's phrase.
> .. The debugger syntax
>may be different...but I think you will find all of the
>features from DDT contained in most dynamic debugging programs
>today.
The last time I dabbled, the "interactive" debugger still had
my thumbs duct taped to opposite office walls.
Charles Shannon Hendrix
> Not sure here what your problem was. In all my days working with IBM
> assemblers, after they got away from the fixed columns, *any* amount of
> whitespace took you to the *next* area, which was usually what was wanted.
Keep in mind too that specific columns are far different from
Python's use of indentation. Just a note...
--
UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Giles Todd
<Brian....@SystematicSw.ab.ca> wrote:
> That's a lousy printer operator: the ribbon should have been
> flipped end around long before it got to that stage.
> (That's the old equivalent of shaking a laser toner cartridge.)
> You also wouldn't be able to differentiate between commas and
> dots, some apostrophes and quotes, maybe bars and bangs, possibly
> parens brackets and braces, if you had and used them.
On Sunday last, having finally fixed my bike after two years of
non-use, I wandered off to Amsterdam's Stedelijk Museum, where there
was (and still is) an exhibition of items from its collection of
purchases from the 1960s and early 1970s.
In the last room (of 32, or thereabouts) there were many May 1968 and
anti-Vietnam-war posters, some of them strikingly apt given current
events, plus some others dedicated to apparently 'minor' issues.
Among the latter were two posters printed on [now I have forgotten the
English word for this type of paper, but it has tractor holes along
both sides, and is flimsy, and has horizontal perforations every now
and then] paper, with a silk-screeened slogan advocating recycling on
the supposedly blank side.
The posters were under glass, but I could still see the FORTRAN
listings on the other side of them. Nice (from both of my points of
view).
Anyway, to return to the post I am commenting to, the commas on the
listings I saw (viewed from the back, from the viewpoint of the person
who originally instructed the computer to print them) lacked tails. I
expect that this is probably cause for a law suit nowadays, where
everything is perfect and, if something turns out not to be perfect
then it must be the fault of someone who is LIABLE!
Impact ribbons cost money, you know. Whether you replace them or not.
The exhibition to which I refer is scheduled to carry on until the end
of the year, should anyone else wish to view it. My favourite exhibit
was the TV Buddha. Made me giggle for at least five minutes, in spite
of it being nearly thirty years old and part of it being in
monochrome.
Giles.
Nico de Jong
> English word for this type of paper, but it has tractor holes along
> both sides, and is flimsy, and has horizontal perforations every now
> and then] paper, with a silk-screeened slogan advocating recycling on
> the supposedly blank side.
You are thinking of fanfold and/or leporello.
Leporello comes probably from the operette figure, who in a scene reads a
list of his masters "conquests", and as there are about 1000 names, he had
to fold it in some way.
Nice touch of folklore, I think
Nico
Eric Sosman
You're off by one order of (binary) magnitude:
640 In Italia sei cento e quaranta,
231 In Alemagna due cento e trent'una,
100 Cento in Francia,
91 in Turchia novent'una,
1003 Ma in Ispagna, son giá mille e tre!
====
2065
I once performed this "catalog aria" in an extrememly low-budget
production. As a sight gag, I handed poor Donna Elvira the "non
piccolo libro," turned a couple pages for her while she registered
disbelief and horror, opened up a page as if to show her the
Playboy centerfold, and then strolled clear across the stage from
down left to down right -- still grasping the paper, with forty
feet of fan-fold unfurling as I went ...
Cheap productions, cheap gags. But, I think, a perfect
justification for the term "leporello" applied to fan-fold paper!