ANN: Dao Language v.0.9.6-beta is release!

[Zeljko Vrba]

Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the

But look at the following example:

if a:
some_code1
if b:
some_code2

If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):

if(a) {
some_code1;
}
if(b) {
some_code2;
}

if I delete if(b) I get a syntax error about unmatched braces. IMO, the "right"
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.

 

[Antoon Pardon]

Admittedly, the blind and visually impaired might not. They will need a
screen reader that understands indentation.

Admittedly, a badly formatted arbitrary piece of text with arbitrary
indentation from line to line is difficult to judge.

But fortunately we're discussing code, not arbitrary text. Code will not
jump from one random level of indentation to another: there will often be
blocks of lines with the same indentation; when the indent level increases
it should always increase by one only; and when it decreases it will
usually decrease by one, sometimes two, more rarely three.

Four is not that unusual. The last method in a class and you already
have at least two. If that method ended with an if in a while, not
that uncommon, and you have four.

If your functions have more than, say, twelve levels of indentation, you
should be refactoring them.

Well I'm not going to put a hard number on it, but I agree with the gist
of your statement.

If you are stuck reading other people's code, where they have hard-coded
indents as (say) two spaces, you may have trouble. But if they are using a
more standard four or eight spaces, it is easier to judge, and better
still if they use tabs, you can tell your editor to set the tabs to
whatever size works for you.

IME it doesn't make that much of a difference whether two spaces are
used, or four. One is too little and more than four is too much, but
between those two it doesn't make much difference for me.

[snip]

But sometimes you mess up and your code is no longer indented as it
should. If you marked the end of the indentations, you can easily
correct this.

And sometimes you mess up and delete braces you shouldn't have.

Sure and if you have correctly indented your code, that will be
easily corrected too.

If you
had Or worse, you delete code you shouldn't have. Whoops!

Lets hope you have a backup.

Start/end markers (whether braces or keywords) plus indentation carry
redundant information. Redundancy means you can *sometimes* correct *some*
errors. But there are costs to redundancy: you have to carry the redundant
information around (in source code, in your head, in the complexity of the
parser) for the 99.99% of time that there is no error.

99.99% of the time, I don't need a backup either. Besides what I had in
mind wouldn't force anyone to use end markers. It wouldn't break any
program(with the exception of programs using variable like endif). It
would just allow people to put in the redundancy where they think it would
be usefull.

And what happens when the indentation and the markers disagree? Languages
like C decide arbitrarily that the markers are meaningful and indentation
is not, and it is a potent source of bugs and obfuscation.

Make it an error. That IMO is what redundant information is for, so that
when it doesn't agree, you are alerted to the problem.

Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages. If your editor is smart enough, and the
code is not ambiguous, a smart editor will pick that up straight away. And
if not, the Python compiler will soon tell you, and you can then fix the
bug in your code.

A smart editor may just happily continue, putting all further statements
on the wrong indentation level. Besides I hate smart editors. They
always seem to get in my way. This will probably say more about my lack
of knowledge about emacs, but the fact that it always jumps to the
corresponding left parent, bracket or brace when I type the right
character in, just drives me nuts.

Besides no editor has saved me once from the fact that I forget a colon
as last charater of an if, else, try or whatever compound statement,
so why should I rely on the editor for other problems?

 

[Fredrik Lundh]

But look at the following example:

if a:
some_code1
if b:
some_code2

If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended.

not to mention that if you have

if a:
some_code1
some_code2

and accidentally remove some_code2, it won't be executed at all !

do you often remove code by accident? is this some vi-specific problem ?

</F>

 

[D H]

Zeljko Vrba wrote:




not to mention that if you have

if a:
some_code1
some_code2

and accidentally remove some_code2, it won't be executed at all !

do you often remove code by accident? is this some vi-specific problem ?

If you had bothered to read the context he was merely showing an example
to prove that this is not entirely true:
"Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages."

He was not suggesting that this is some affliction that he suffers, as
you are suggesting.

 

[Christophe]

David Rasmussen a écrit :

Write classes with a smaller interface ;-)

/David

What about an editor that will reserve the first lines in the edit
window to show the current class ? Could be a cool feature here
You'll see something like that when you scroll too far :

File Edit Options About
-------------------------------
class do_something(object):
....
return 1

def do_it(self):
print self.what_now

 

[Benji York]

David Rasmussen a écrit :



What about an editor that will reserve the first lines in the edit
window to show the current class ? Could be a cool feature here

I've been using a Vim script for a while that adds the name of current
class, function, or Class.Method to the status line and it helps quite a
bit.

 

[Steven D'Aprano]

But look at the following example:

if a:
some_code1
if b:
some_code2

If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):

if(a) {
some_code1;
}
if(b) {
some_code2;
}

if I delete if(b) I get a syntax error about unmatched braces.

Not unless you also delete the opening brace on the same line, surely?

Okay, you've deleted the line and you get a syntax error. But not if you
accidentally deleted the previous brace as well, or if there was an
earlier unmatched brace somewhere earlier in your code.

We could play this game all day -- you find some error or typo where
redundant braces will save the day, and I'll find another error where they
won't. In the meantime, you're spending more time thinking about braces
plus indentation than I am thinking about just indentation.

And I bet that you've made more mistakes where you got the indentation
right but the braces wrong, even with a smart editor, than I've
accidentally deleted code in a way that the indentation levels just happen
to wrongly match up.

IMO, the "right"
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.

Sure, and that's good advice for C, but that's because C is labouring
under the disadvantage that indentation is not meaningful to the compiler,
but is meaningful to the human programmer.

 

[Steven D'Aprano]

do you often remove code by accident? is this some vi-specific problem ?

+1 QOTW


I wish I had thought of saying that! In fact, I think I will have done!

 

[Steven D'Aprano]

If you had bothered to read the context he was merely showing an example
to prove that this is not entirely true:
"Making a mistake in indentation level is precisely analogous to leaving
out markers in other languages."

Pardon me, but how is deleting code equivalent to making a mistake in
indentation level? Is there some editor where if you hit tab too few
or too many times it deletes the previous line?

 

[Steve Holden]

But look at the following example:

if a:
some_code1
if b:
some_code2

If I accidentaly delete if b:, then some_code2 gets under the if a: which is
not intended. With braces (or other delimiters):

if(a) {
some_code1;
}
if(b) {
some_code2;
}

if I delete if(b) I get a syntax error about unmatched braces. IMO, the "right"
way to handle braces in C is always to include them, even when they are not
technically obligatory. I code like that for a long time and it has saved me
a lot of headache.

My advice would be to stop using punch cards and start using a sensible
text editor. Your use case is somewhat unconvincing in the 21st century.

regards
Steve

 

[Zeljko Vrba]

My advice would be to stop using punch cards and start using a sensible
text editor.

Such as..?

Find me an editor which has folds like in VIM, regexp search/replace within
two keystrokes (ESC,, marks to easily navigate text in 2 keystrokes (mx, 'x),
can handle indentation-level matching as well as VIM can handle {}()[], etc.
And, unlike emacs, respects all (not just some) settings that are put in its
config file. Something that works satisfactorily out-of-the box without having
to learn a new programming language/platform (like emacs).

 

[Sybren Stuvel]

Zeljko Vrba enlightened us with:

Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,, marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well
as VIM can handle {}()[], etc. And, unlike emacs, respects all (not
just some) settings that are put in its config file. Something that
works satisfactorily out-of-the box without having to learn a new
programming language/platform (like emacs).

Found it! VIM!

Sybren

 

[Steve Holden]

Such as..?

Since choice of text editor tends to be a religious issue, that will
have to be your decision, not mine.

Find me an editor which has folds like in VIM, regexp search/replace within
two keystrokes (ESC,, marks to easily navigate text in 2 keystrokes (mx, 'x),
can handle indentation-level matching as well as VIM can handle {}()[], etc.
And, unlike emacs, respects all (not just some) settings that are put in its
config file. Something that works satisfactorily out-of-the box without having
to learn a new programming language/platform (like emacs).

Jusr choose one that minimises your propemsity to "accidentally delete"
lines.

regards
Steve

 

[Tom Anderson]

Zeljko Vrba enlightened us with:

Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,, marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well as
VIM can handle {}()[], etc. And, unlike emacs, respects all (not just
some) settings that are put in its config file. Something that works
satisfactorily out-of-the box without having to learn a new programming
language/platform (like emacs).

Found it! VIM!

ED IS THE STANDARD TEXT EDITOR.

tom

 

[Zeljko Vrba]

ED IS THE STANDARD TEXT EDITOR.

And:
INDENTATION
SUCKS
BIG
TIME.

Using indentation without block termination markers is opposite of the way we
write spoken language, terminating each sentence with . Ever wondered why
we use such things in written language, when people are much better in
guessing what the writer wanted to say then computers?

 

[Fredrik Lundh]

Using indentation without block termination markers is opposite of the way we
write spoken language, terminating each sentence with . Ever wondered why
we use such things in written language, when people are much better in
guessing what the writer wanted to say then computers?

Interesting. Python's use of indentation comes from ABC, which based the
design partially on extensive testing on human beings. Humans often use
indentation for grouping, and colons to introduce a new level or group are
at least as common. In fact, most humans can understand the structure
of a Python program even if they've never programmed before.

I guess writers don't use indentation to group text on your planet.

</F>

 

[Rick Wotnaz]

And:
INDENTATION
SUCKS
BIG
TIME.

Using indentation without block termination markers is opposite
of the way we write spoken language, terminating each sentence
with . Ever wondered why we use such things in written language,
when people are much better in guessing what the writer wanted
to say then computers?

I believe I may have seen cases in written "spoken
language" where paragraphs were indented, or otherwise
separated with whitespace. It's even possible that I've
seen some examples of written languages that use no periods
at all! And what's more, I've seen more than one *computer*
language that uses no terminating periods! Why, it boggles
the mind.

Despite the arguments advanced by those whose previous
computer languages used braces and semicolons, there
actually are more ways to separate complete statements than
with punctuation.

Make a grocery list. Do you terminate each item with
punctuation? Write a headline for a newspaper. Is
punctuation always included? Read a mediaeval manuscript.
Do you find punctuation? Whitespace? How about Egyptian
hieroglyphs, Chinese ideograms, Ogham runes?

Because you're accustomed to one set of conventions, you
may find Python's set strange at first. Please try it, and
don't fight it. See if your objections don't fade away. If
you're like most Python newbies, you'll stop thinking about
brackets before long, and if you're like a lot of us,
you'll wonder what those funny squiggles mean when you are
forced to revert to one of those more primitive languages.

 

[Steven D'Aprano]

Zeljko Vrba enlightened us with:

Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,, marks to easily navigate text in 2
keystrokes (mx, 'x), can handle indentation-level matching as well as
VIM can handle {}()[], etc. And, unlike emacs, respects all (not just
some) settings that are put in its config file. Something that works
satisfactorily out-of-the box without having to learn a new programming
language/platform (like emacs).

Found it! VIM!

ED IS THE STANDARD TEXT EDITOR.

Huh! *Real* men edit their text files by changing bits on the hard disk by
hand with a magnetized needle.

 

[Steven D'Aprano]

And:
INDENTATION
SUCKS
BIG
TIME.

Using indentation without block termination markers is opposite of the way we
write spoken language, terminating each sentence with .

That's not true at all.

We terminate sentences with punctuation because sentences can and
frequently do go over multiple lines. Sentences are independent of
indentation. But paragraphs are not. We terminate paragraphs with
whitespace, sometimes including indentation. A very common method of
terminating paragraphs in written English is to indent the first line of a
new paragraph, with no vertical whitespace between them.

We also terminate items in lists, sometimes without punctuation, by a new
line:

item one
item two
item three

and indicate long items by a change in indentation:

item one
item two is an extremely long item
which goes over two or more
physical lines
item three

We sometimes indicate a block of text -- which may be one or more
paragraphs -- purely with indentation:

Blocks of quoted text are frequently delimited by a
blank line at the top and bottom of the block, and
indentation on the left margin. The indentation is
necessary because the block of text may include
multiple paragraphs.
On the other hand, vertical white space between
paragraphs is optional. It is a common convention to
flag new paragraphs with an indentation, or if already
indented, an extra indentation.
It is even possible to have multiple levels of
quoting. According to Professor Joe Expert:

As a general rule, one should never indent
more than two levels deep, even if this means
avoiding quoting text which quotes a quotation.


We also delimit larger sections of novels with whitespace. A common
convention is to use an indent and no vertical space to delimit
paragraphs, and three blank lines to delimit a block of text (for example,
when changing the point of view character). Only if that end of block
occurs at the end of the page is it replaced with punctuation,
usually a series of three asterisks.


So, in summary, your argument that block markers are necessary in English
is wrong. Only sentences use start/end markers. Words are delimited by
whitespace, paragraphs and larger blocks of text use either whitespace,
indentation or both.

 

[Zeljko Vrba]

Make a grocery list. Do you terminate each item with
punctuation? Write a headline for a newspaper. Is

actually, I do. i write as much as fits in one line and separate items
with comma.

may find Python's set strange at first. Please try it, and
don't fight it. See if your objections don't fade away. If
you're like most Python newbies, you'll stop thinking about

I'm not Python newbie. I wrote a good deal of non-trivial python code,
and I still don't like it and still find it very annoying.

brackets before long, and if you're like a lot of us,
you'll wonder what those funny squiggles mean when you are
forced to revert to one of those more primitive languages.

Actually, after I learned Python, I value "funny squiggles" in other
languages even more. It's very annoying, for example, that I can't split
a long line in the following way:

print a + b +
c + d
print "other statement"

I guess I'm required to insert some unneccessary () around the long expression
to disable the white space parsing..