Pythonic indentation (or: beating a dead horse)

[Eleanor McHugh]

Yes. You could be required to type 'end' at the end of every
paragraph. But that'd just be silly and redundant, considering that
whitespace does a perfectly good job as a delimiter.

The only significant whitespace in paragraph delineation is a new
line, which funnily enough is also significant white space in Ruby.
The sentences within each paragraph are delineated with full stops and
other punctuation marks which are themselves meaningful. Whilst we
could probably abolish these and use indentation instead to group
sentences into paragraphs and sub-clauses into sentences, I'm not
currently aware of any natural language notation system which adopts
this approach.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[J Haas]

So then that means the common indentataion of:

def foo
  bar
rescue
   0

would also break?  

I don't know if it works in Caleb's script, but this need not cause
any problems in a proper implementation of syntactic indentation, any
more than:

case foo:
when 'bar'
do_something
when 'baz'
do_something else

would, or for that matter

begin:
do_something
rescue
do_something_else

Certain keywords (like 'when' or 'else' or 'rescue') don't start new
blocks that need 'end' to close them, and they can safely be placed at
the same level of indentation as the blocks which must precede them.

Just how many examples of problems do people need here?

One would be nice. Please, do try to make it a problem severe enough
to justify inflating the line count 20% or more, and also so critical
that people shouldn't even have the _option_ to use syntactic
indentation.

 

[Eleanor McHugh]

I'd be careful about making such a narrow definition of the "law of
succinctness." I'd also be careful about trying to twist the
definition of
terse towards meaning incomprehensible. A part of the definition
of terse is
"easy to read."

As with most things in life, whether or not something is "easy to
read" depends upon your frame of reference. What makes perfect sense
to you today may not at a later date, and may never make sense to
someone else. That's why I mentioned implicit knowledge, a commodity
which is present in all skills and that by its nature is hard to
transmit because those who possess it are largely unaware of its
existence.

You can choose whatever word you want to describe conciseness, but
most of them
imply or directly state clearness or an ease of understanding not
compromised
by beating around the bush or cluttering things up. You can choose
a near
synonym for concise that sometimes has a sense of impoliteness to
make concise
look negative, but the fact is the computer doesn't care.

No, the computer doesn't care and is quite happy to be programmed in
its own binary language - just a stream of 1s and 0s. However the
history of language design has been to move away from direct machine
notation (which is tedious and error prone), co-opting syntactic and
semantic features from natural languages. This makes good sense as
code has to be designed and maintained by people who in general have a
higher facility with natural language than they do with machine code.
And one of the interesting things about natural language is that it's
not indentation sensitive.

Trying to argue that longer is somehow inherently better doesn't
make any
sense.

You clearly haven't spent much time trying to maintain extremely terse
C or you'd have quite a different perspective.

If you really feel that way then Ruby is a poor choice considering how
many wonderfully tedious languages there are just filled with
redundancy and
unnecessary syntax. How about Java's long winded forced naming
conventions?
Or better yet how about C++ templates for readability? There's just
a ton of
information about every last detail concerning types and all kinds
of stuff and
lots of redundancy. Certainly that is wonderfully readable compared
to Ruby.

There are two kinds of redundancy. That which comes from cut-and-paste
and is a code smell, and that which exists as a structural safeguard.
'end' is the latter kind of redundancy and whether you like it or not
many of us find that supposed lack of conciseness to be a concise
representation of block identity.

Seriously, if you want to argue some other point about
implementation details
or some implication of a particular solution well then that's fair
game. But
you're not going to get anywhere arguing that longer is better or
telling
people to go away and use some other language.

And you're not going to get anywhere by acting as if significant
indentation is a must-have for Ruby or any other language.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Eleanor McHugh]

When was there ever great innovation in art that didn't cause anger
and revulsion?

Anger and revulsion alone are not the proof of great innovation. Nor
for that matter does aesthetic innovation invalidate the tastes of
those who choose not to follow it.

Currently the one size fits all is that you must use end. It
isn't a choice. Yes, you can be a second class citizen and use a
preprocessor. But how would you feel if the tables were switched
and new ruby forced you to not use end and your only alternative was
to use a preprocessor?

I probably wouldn't have taken to the language, just as I didn't take
to Python.

And would the fact that Python works the way it does justify my
arguing for inclusion of 'end'? It's hard to see how the language
could retain its character that way and it would be rather rude of me
to push the point with people who are clearly comfortable with its
current form. The same applies with Lisp, a beautiful language which I
choose not to use because I dislike the extensive use of parentheses.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Gregory Brown]

One would be nice. Please, do try to make it a problem severe enough
to justify inflating the line count 20% or more, and also so critical
that people shouldn't even have the _option_ to use syntactic
indentation.

Did I ever, at any point in this thread, suggest anything at all about
not having the option?
Or did I respond to your initial post nearly as soon as you wrote it
saying "Implement it and see if people like it".
Or did I say "I have no preference about significant whitespace"?

Seriously, you're doing something very harmful by continuing to treat
people this way. You are discounting absolutely everything everyone
says and you're taking things out of context. Please stop. Please
unsubscribe if that's the only way you can manage to stop yourself.

-greg

 

[Juan Zanos]

And you're not going to get anywhere being a giant douche. Or maybe
you think that (almost) everyone else in this thread is to blame.

Is there a way to block users on this group who use vulgar language
with intent to offend?

 

[Gregory Brown]

Is there a way to block users on this group who use vulgar language with
intent to offend?

The same way you block users with intent to offend (or not) who do not
use vulgar language, with a kill-file in your mail client. Another
way to avoid such discourse is to not act like a troll with no respect
for the other members of this list.

-greg

 

[Caleb Clausen]

I don't know if it works in Caleb's script, but this need not cause
any problems in a proper implementation of syntactic indentation, any
more than:

Indeed. rescue, when, else, elsif, and ensure are special-cased. If
they occur on the beginning of a line with the same indentation level
as the last line with a beginword, an extra end is not inserted.

 

[Juan Zanos]

And you're not going to get anywhere by acting as if significant
indentation is a must-have for Ruby or any other language.

I never said it was. In fact, in my response to you I didn't mention
significant indentation at all. I disagreed with the current anti-
conciseness arguments. I suggested that if you want to argue against
a language feature then you need stronger arguments than terse is hard
to read. Possibly the problem is the term terse is being used
incorrectly. It doesn't mean hard to read. Terse may mean "smoothly
elegant, neat, clean, easy to understand, or even brusque. But it
doesn't mean hard to read.

I'm perfectly happy if you have good arguments against any particular
language feature including significant indentation. I'll be happy to
agree with your criticisms If I can find some validity in them. I
don't own stock in any language features.

I am a bit intrigued by these indentation ideas though. In both human
and computer languages we tend to shorten things that we use often --
even if it makes them irregular. The 'end' word is one of the most
common things in Ruby. Possibly the most common line in Ruby contains
nothing but 'end'. It's perfectly reasonable to think about the
possibility of shortening it.

 

[James Britt]

...
This (and your other, similar example) actually works in endless.rb
right now. Leave off the end and it inserts one for you, just where
you'd expect. You can always indent things more than necessary, and
that's fine.

Interesting. Thanks!




James

 

[Gregory Brown]

Indeed. rescue, when, else, elsif, and ensure are special-cased. If
they occur on the beginning of a line with the same indentation level
as the last line with a beginword, an extra end is not inserted.

Caleb, have you thought about toying around with forking Ruby and
invoking your pre-processor automatically in some way? I think
that'd turn this conversation into something much more productive.

Even if it's not a realistic implementation at first, it could lead to
productive discussion on how it could be integrated, and what
syntactic changes it would need to make Matz happy.

-greg

 

[James Britt]

For what it's worth, when I got rid of indentation sensitivity in Reia (by
adding "end" keywords) I got a lot of positive feedback from
indentation-haters, and no unsolicited cries to preserve it. I had to
encourage people to give feedback in defense of indentation sensitivity.

What was the reason for remove indentation sensitivity?



James

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

What was the reason for remove indentation sensitivity?

I was using a Python-style lexer in conjunction with a Ruby-like (almost)
pure expression grammar, and running into the issues I've outlined in this
thread regarding indent blocks in expressions.

I detailed many of the problems in this blog post:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

I'm surprised by how well the solutions others are coming up for this are
working. The script J Haas found just throws regexes at the problem (and
removes any degree of formal decidability), however the RubyLexer approach
sounds interesting.

That said, I have no regrets with ditching indentation sensitivity. If
anything it seemed to alienate people who would otherwise be interested, and
now Reia has the advantage of looking nearly identical to Ruby. Porting
Ruby programs to Reia programs is now substantially easier.

 

[James Britt]

Trying to argue that longer is somehow inherently better doesn't make any
sense.

Same holds for the inverse. But no one has been arguing that longer is
inherently better.

My point is that zero entropy and maximal information is a poor goal
when targeting people, that some amount of redundancy reduces errors and
improves communication (again, for people).

I do not have any objective way to say what, exactly, that is for a
programming language. My own experience from working with indentation
sensitive languages is that the trade-offs do not always sit well with
me. Nor does the verbosity of Java

My experience with Haskell has been much different than my attempts at
Python. Maybe it's Haskell's emphasis on mathematical functions, on
using a format that employs (so it seems) a whole lot of equal signs.
The use of white space there feels much more natural than it did for me
with Python. (I also think Haskell induces different expectations about
what things should look like. It would probably feel wrong to use do/end
for something that is essentially mathematics.)

The information provided by significant indentation, while usable (and
possibly more efficient for some cases of human parsing), introduces
restrictions on how it may be used elsewhere, effectively limiting how a
writer expresses non-syntactical information in a program.

What puts me off so many discussions about code formatting is the idea
that code is first meant to provide instructions to a machine, and ideas
for people second.

The "machines first" attitude may be the reason for so much cruft in
Java. I'm sure GvR had "people first" in mind when opting for
significant indentation, but perhaps he viewed writing software as
primarily an exercise in generating code, less as writing a document for
other humans that is also machine readable. That is, the goal was
highly-readable computer expressions, not machine-readable people
expressions.


--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

 

[James Britt]

I was using a Python-style lexer in conjunction with a Ruby-like (almost)
pure expression grammar, and running into the issues I've outlined in this
thread regarding indent blocks in expressions.

I detailed many of the problems in this blog post:

http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html

I'm surprised by how well the solutions others are coming up for this are
working. The script J Haas found just throws regexes at the problem (and
removes any degree of formal decidability), however the RubyLexer approach
sounds interesting.

It seems that without formal decidability you'll end up coding yourself
into a corner, where you can't change or add anything because of the
side-effects.

That said, I have no regrets with ditching indentation sensitivity. If
anything it seemed to alienate people who would otherwise be interested, and
now Reia has the advantage of looking nearly identical to Ruby. Porting
Ruby programs to Reia programs is now substantially easier.

Very cool!

--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

 

[Michael Bruschkewitz]

@Michael:
I don't think having "either or" syntax would be such a terrible thing
in terms of team re-use or resources--you should be able to convert the
code back and forth at will (a la ruby2ruby, parsetree [rubylexer has a
parsetree compatibility mode] etc.)

Uuups, that's me.
(BTW: What a discussion, about 2 vs. 20 ... that's really asymmetric
warfare...)

Yes, for sure it would be possible to convert sources back and forth and up
and down.
Maybe someone would create the perfect converter.
Given there are people prefer PyI or not, maybe others loving brackets the C
way or the Lisp way, or hating them, some would prefer do..end some would
like curly brackets...
Going to the end: Convert Ruby code to P-Code which could be converted to
F77...
(If some scripts are not located on read-only media...)

But, put joking aside, for much more sure, it would definitely increase
(IMHO) the probability of errors much more effective than other variations
which are already possible.

My work since some year is to decrease probability of errors - I'm creating
testing tools, environments and scripts, performing integrations tests and
so on.

People tend to make mistakes. So, extending possibilities for doing so is
baaaad.
Scripts are always changed, and nearly nobody really cares about indendation
or formatting when scripts look like:

# Increase train speed to v_mode1
@train.increaseSpeed 30

# Pass signal 'sig1'
@train.expectPosition 'sig1',5
....
Did you really notice the different spaces? Try a proportional font.
....
or are created by some foreign language test case generation tools.

I don't like unnecessary syntax elements for scripting languages, because
they spoil the view for the real problems. So I like Ruby's ability to avoid
brackets, semicolons and so on.
Some people like brackets.
I like using "unless" instead of "if !" because it's more readable, you
don't need shift-key.
These possibility of variations did never brought problems into work.
It allows concentrate the attention of people to the real scenarios and
problems.

But, "end" brings much more safety, it is also a "social" thing - its like
finally writing "done."
I think, avoid scrolling is a very minor argument. Who needs to scroll so
much?
Would "J" encourage people to avoid comments and empty lines to avoid 50% of
scrolling?
(Would "Monk" like "end"?)

I would not like to waste resources of highly specialized people by teaching
them the last corners of Ruby - it's a scripting language at last. And it's
wonderful as such.
So I would never try to force them to distinguish between spaces, tabs and
other whitespaces.
(They would try - these are tolerant people too...)

(Ohh .. sorry ... I wasted _my_ resources. Only 3 hours to sleep. Going to
sleep now...)

Hope you got my point...

Regards,
Michael B.

 

[Michael Bruschkewitz]

This was my point. It would be good to still have the option of
freeform indentation. Much Ruby code _isn't_ presently canonically
formatted, and it'd break if put through your preprocessor. One
solution to this would be to only activate the preprocessor on a per-
file basis, but I think a better solution would be for the
preprocessor not to damage existing code. The ultimate goal in the
long term should be to make this style part of core Ruby syntax rather
than the result of a preprocessor, and the best way to do that would
be for the parser to be able to distinguish between indentation-aware
blocks and "old-style" blocks.

If it would be strictly optional it would be fine.
Should be need to be explicitely allowed for not breaking existent code.
Maybe as gem possible.


However, Ruby is about 10 years old now, Python and its insertion is even
older.
If it would be so superior, didn't you think it would have been widely
accepted in the mean time?
And would have been spread over to other scripting languages already?

 

[Michael Bruschkewitz]

You'll have to start shopping for a new language. White space is
already significant in Ruby.

Did somebody tried Brainf*ck language?

 

[Juan Zanos]

Same holds for the inverse. But no one has been arguing that longer
is inherently better.

Well, maybe we'll just have to agree to disagree on that one. Shorter
is better to the degree that nothing is harmed by doing so. If
significant indentation sufficiently harms something else then I agree
that is important too.

My point is that zero entropy and maximal information is a poor
goal when targeting people, that some amount of redundancy reduces
errors and improves communication (again, for people).

There is a well known and written about principle of economy that
applies universally to human languages. If we're talking about
shortening everything then I'd agree with you completely. But when
something is really common we alter the language to make it shorter.
An entire line occupied only by the word 'end' is one of if not the
most common line in Ruby. That makes it a great candidate for
applying a principle of economy.

I do not have any objective way to say what, exactly, that is for a
programming language. My own experience from working with
indentation sensitive languages is that the trade-offs do not always
sit well with me. Nor does the verbosity of Java

The commonness of the occurrence is one key factor. All those
needless semicolons in Java, for example.

My experience with Haskell has been much different than my attempts
at Python. Maybe it's Haskell's emphasis on mathematical functions,
on using a format that employs (so it seems) a whole lot of equal
signs. The use of white space there feels much more natural than it
did for me with Python. (I also think Haskell induces different
expectations about what things should look like. It would probably
feel wrong to use do/end for something that is essentially
mathematics.)


The information provided by significant indentation, while usable
(and possibly more efficient for some cases of human parsing),
introduces restrictions on how it may be used elsewhere, effectively
limiting how a writer expresses non-syntactical information in a
program.

Well that could be a good argument against. I'm not familiar enough
with such counter examples to say. So far I've
been pretty impressed with what Caleb's tool can do.

What puts me off so many discussions about code formatting is the
idea that code is first meant to provide instructions to a machine,
and ideas for people second.

The "machines first" attitude may be the reason for so much cruft in
Java. I'm sure GvR had "people first" in mind when opting for
significant indentation, but perhaps he viewed writing software as
primarily an exercise in generating code, less as writing a document
for other humans that is also machine readable. That is, the goal
was highly-readable computer expressions, not machine-readable
people expressions.

I agree with you. Java advocates I know will claim that static typing
is worth the added redundancy and verbosity because it reduces the
chance of type errors and provides structure. They don't believe that
you can have industrial strength applications without it. Sound
familiar?

My own guess is that static typing currently provides an efficiency
advantage that isn't yet available in most dynamic languages.
Actually, I've heard that Sun's JVM now throws away static type
information anyway. It would be interesting to know more about that.

I write way too much Java. I've been pretty disappointed that it
seems to be getting more verbose and less expressive for reason that
at this point still don't make much sense to me. JRuby is a breath of
fresh air.

 

[Juan Zanos]

Did somebody tried Brainf*ck language?

Now there's a readable language!