Why not adopt "Python Style" indentation for Ruby?

[Robert Dober]

I can't count how many times I've forgotten "do". Sometimes I have
wished a colon could "induce" the block:

That puzzles me, would you not forget the ":" then? Or do you have a
lot of Python experience. Not that I think bad of the ":" syntax, just
wondering.

Robert

 

[Trans]

That puzzles me, would you not forget the ":" then? Or do you have a
lot of Python experience. Not that I think bad of the ":" syntax, just
wondering.

Hehe. Probably so. I'm not a hisser But I think I would forget the
colon much less often, especially given it created indention
significance.

T.

 

[gga]

Emacs + ruby-mode.el understands do/end just fine.

Regards,

Jeremy Henty

No, it doesn't. When I type a close brace in emacs, I get the
corresponding line where the matching brace matches (hilited if
visible in the page, or in the modeline if not).
When I position myself next to a brace, I get the same hiliting
happening. Can't recall if that's a feature of hilite or the electric
mode of emacs.
However, whenever I type "end" to close a block, I have NO clue where
the block begins. And if it is code I did not write, not knowing
where the code begins is a killer.
Being emacs, I *could* potentially hack the lisp code to handle do/end
blocks properly (or indentation too). I haven't seen anyone do it yet
(and publically give it away).

 

[Brendan]

...
with no reduction in meaning, yet 25% fewer lines of code.

What are the reasons why this isn't used/implemented/liked? It would
be a small change to the interpreter. Enabling meaningful indentation
would only make 'end' optional, not invalid; backwards compatibility
wouldn't be a problem.

(I use both Ruby and Python. I think indentation is one of the few
*language* features where Python leads Ruby.)

I personally prefer that 'end' be in place, so that all ruby code is
readable. I personally believe there may be something wrong with a
syntax which sacrifices explicit readability (for everyone, not just
python programmers) for increased typing speed and the illusory gain
of 'fewer LOC'. This was one of the major reasons which convinced me
to use ruby instead of python.

 

[Chad Perrin]

I personally prefer that 'end' be in place, so that all ruby code is
readable. I personally believe there may be something wrong with a
syntax which sacrifices explicit readability (for everyone, not just
python programmers) for increased typing speed and the illusory gain
of 'fewer LOC'. This was one of the major reasons which convinced me
to use ruby instead of python.

I, personally, don't have an argument on principle like that for my own
preferences in this matter. I just like the fact that an "end" makes it
look more complete to me. Reading Python code always makes me feel like
my eyes are just going to trail off the right-hand edge of the page
because the "shape" of the code never brings me back to the leftmost
edge, the way code "should".

When I look at Python code, and ponder the way it does things so
differently from Ruby regarding delimiters and indentation (the same
thing in Python), it seems to me that Python was created for people who
write code in a particular mindset, and it's not a mindset I share when
I'm writing code. I guess maybe some people, when writing code, think
in footnote hierarchies, while others (like me) think in nested scopes.

That's just an off-the-cuff hypothesis.

 

[M. Edward (Ed) Borasky]

I, personally, don't have an argument on principle like that for my own
preferences in this matter. I just like the fact that an "end" makes it
look more complete to me. Reading Python code always makes me feel like
my eyes are just going to trail off the right-hand edge of the page
because the "shape" of the code never brings me back to the leftmost
edge, the way code "should".

When I look at Python code, and ponder the way it does things so
differently from Ruby regarding delimiters and indentation (the same
thing in Python), it seems to me that Python was created for people who
write code in a particular mindset, and it's not a mindset I share when
I'm writing code. I guess maybe some people, when writing code, think
in footnote hierarchies, while others (like me) think in nested scopes.

That's just an off-the-cuff hypothesis.

I've been watching this debate go by for some time, and I'm not sure
this sort of thing can ever be solved, but here are my personal opinions:

1. When you come right down to it, there are only a few basic syntax
styles that have survived the test of time. *Most* languages, including
C, Ruby, Pascal and Perl, use some variant of the Algol 60 syntax. The
other "survivors" are the Lisp/Scheme variant of prefix notation,
Forth's postfix notation, and the regular expression syntax. I suppose
assembly language syntax has also survived, and FORTRAN and COBOL, but I
don't think anyone would design a new language with those.

2. I think Python's "variant" of Algol 60 notation is less than
satisfactory, but I also have problems with the liberality present in
the syntax of Perl and Ruby. I don't like to make the reader or parser
work any harder than necessary just for the convenience of the coder. So
I like explicit delimiters like curly braces, parentheses, mandatory
semicolons at the end of statements, begin/end pairs, etc. for the Algol
60 languages. Lisp/Scheme and Forth were deliberately designed to make
the parser's job trivial, and I like them too.

3. I've pretty much given up on the dream that I'll be able to program
in one language only, although some languages are close enough. At the
moment, I can get just about everything done in either Perl or R, with
the other languages simply being fun to learn and use but not essential.
I could probably eliminate Perl if there were more R programmers, but
there aren't and won't be, because R is designed for scientists and
mathematicians, not business people.

 

[Sven Suska]

But I don't think a line prefix is worth the trouble.

Trouble? -- I want the editor to insert the prefix, of course.
Some editors are already able to do this with line comments,
so they can be adapted easily.

Sven

 

[rocky.bernstein]

That is the exact same case I find the indentation thing gets in the
way. I had to change my way of putting in print debug statements
(same as yours). Every language makes you change your ways a bit. Of
course python's debug facilities (pdb) are much better than ruby's so

Well, I think that's going to change over the next year. If you
haven't tried Ken Sibilev's ruby-debug, http://rubyforge.org/projects/ruby-debug/
give it a shot. Over the last year it has improved quite a bit and I
expect over the next year it will make the same steady progress. I'm
hoping the next release will have a user manual, and possibly start
adding some regression tests (which by the way pdb doesn't currently
have).

As someone who's a little bit familiar with both debuggers, I think
the design of ruby-debug is the cleaner and more flexible. In fact, I
think it's the best organized debugger of any that I've seen so far.
(But then. as it grows..)

 

[Robert Klemme]

2. I think Python's "variant" of Algol 60 notation is less than
satisfactory, but I also have problems with the liberality present in
the syntax of Perl and Ruby. I don't like to make the reader or parser
work any harder than necessary just for the convenience of the coder.

I would understand why you would want to make the reader's job easier -
but the parser? That's just a piece of software and I believe that we
should always strive to make software easier to use for humans not machines.

Besides of that, personally I don't find the current Ruby syntax hard to
read. Do you have some examples where you feel that reading Ruby is
made hard(er) because of the liberties you mention?

Kind regards

robert

 

[SonOfLilit]

IMHO, at least in complicated cases, the reader has to emulate a
parer, so both are the same.

Whenever there is syntax that's tricky to parse, it's also tricky to read.

See pythons space-vs-tab problem, for example.


Aur

 

[znmeb]

I would understand why you would want to make the reader's job easier -
but the parser? That's just a piece of software and I believe that we
should always strive to make software easier to use for humans not machines.

Besides of that, personally I don't find the current Ruby syntax hard to
read. Do you have some examples where you feel that reading Ruby is
made hard(er) because of the liberties you mention?

Kind regards

robert

I can think of three examples right off the top of my head: Rails, Rake and
RSpec. There's something really eerie about seeing code like that. You *know*
it works, but you can't figure out why or how.

 

[Dick Davies]

Quoting Robert Klemme <[email protected]>:

I can think of three examples right off the top of my head: Rails, Rake and
RSpec. There's something really eerie about seeing code like that. You *know*
it works, but you can't figure out why or how.

And you think replacing do/end with indentation would help?

I really can't see how - could you give an example?

 

[Peter Marsh]

I can't count how many times I've forgotten "do". Sometimes I have
wished a colon could "induce" the block:

5.times |n|:
n.times:
print n
puts

But I don't think a line prefix is worth the trouble.

T.

I totally agree. A line pre-fix is a bit pointless in my opinion,
although I am in favour in moving towards a Python-style indentation
syntax. As for the 'do' issue I don't see why it can't be removed, if
something is always expected then you can just assume its there, right?

5.times do |n|
n.times do
print n
end
puts
end

(Or using the ':' instead) Could just be:

5.times |n|
n.times
print n
end
puts
end

 

[Michael Fellinger]

I totally agree. A line pre-fix is a bit pointless in my opinion,
although I am in favour in moving towards a Python-style indentation
syntax. As for the 'do' issue I don't see why it can't be removed, if
something is always expected then you can just assume its there, right?

5.times do |n|
n.times do
print n
end
puts
end

(Or using the ':' instead) Could just be:

5.times |n|
n.times
print n
end
puts
end

Sorry, but how would you handle block_given? without parameters?

 

[Michael Fellinger]

And you think replacing do/end with indentation would help?

I really can't see how - could you give an example?

Let's try:

describe 'myself'
it 'should be readable'
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)


# pretty much impossible, if you ask me
# same in usual ruby now

describe 'myself' do
it 'should be readable'
lambda{ @reader.reading }.
should change{ @reader.knowledge }.
by(text.amount)
end
end

# well?

 

[Peter Marsh]

Sorry, but how would you handle block_given? without parameters?

I'm still quite new to Ruby, so I'm not entirely sure what you mean,
could you explain what you feel the problem would be please?

 

[Dick Davies]

Let's try:

describe 'myself'
it 'should be readable'
lambda
@reader.reading
.should change
@reader.knowledge
.by(text.amount)


# pretty much impossible, if you ask me
# same in usual ruby now

describe 'myself' do
it 'should be readable'
lambda{ @reader.reading }.
should change{ @reader.knowledge }.
by(text.amount)
end
end

# well?

The only extra words there are do/end and you could replace them
with {} if they really bothered you.

If you're saying you personally don't like do/end blocks, then you're
as entitled to that opinion as anyone else, but I don't see this as making
DSLs any more or less comprehensible personally

 

[Michael Fellinger]

The only extra words there are do/end and you could replace them
with {} if they really bothered you.

If you're saying you personally don't like do/end blocks, then you're
as entitled to that opinion as anyone else, but I don't see this as making
DSLs any more or less comprehensible personally

uh, actually that was an example that i can't interpret the
indentation. I do like the idea of supporting indentation, but not
within ruby.
It's just getting into a mess with method-calls with blocks, manual
lambdas and doing methodchains like foo{bar}.duh{x} - it's not really
about the braces but about the possibility to write that code in a
different syntax at all.

If someone is brighter than me, you're welcome to propose alternatives

 

[Gregory Brown]

I can think of three examples right off the top of my head: Rails, Rake and
RSpec. There's something really eerie about seeing code like that. You *know*
it works, but you can't figure out why or how.

None of those are especially magical if you have a decent understand
of how Ruby works.
method_missing + block syntax does not necessary mean evil black magic.

 

[Neil Wilson]

As far as I can see, the 'end' keyword is 'repeating yourself' when
used with properly indented code.

Maybe it is maybe it isn't. Personally I'm an 'end' man. I like my
blocks.

It would be easier if you learnt to type, or used editor macros.

(I use both Ruby and Python. I think indentation is one of the few
*language* features where Python leads Ruby.

If this post generates a positive response, I'll make a patch for Ruby
1.9.

Nope, leave the language as it is. I like it unaltered thank you very
much.

However I've never understood why there has to be 'one true syntax'
for any computer language. As long as the syntax generates the same
ASTs in the interpreter I can't see why you couldn't choose the syntax
you prefer - whether that is whitespace indentation, or the symbolic
mush of the 'C' derived languages.