Why not adopt "Python Style" indentation for Ruby?

C

Chris Dew

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

class Foo

def bar(value)
if value < 7
puts "hello"
else
puts "world"
end
end

def foobar
puts "foobar"
end

end

could be

class Foo

def bar(value)
if value < 7
puts "hello"
else
puts "world"

def foobar
puts "foobar"

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.)

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

Michal Suchanek

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"

|What are the reasons why this isn't used/implemented/liked?

Python style block by indentation is an interesting idea, but it works
badly with

* tab/space mixture
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks
* clipboards, email, pastebins, and other places where the code is not
preserved literally

Thanks

Michal
 
J

Julian Leviston

Actually,

Isn't end repeating yourself full stop?

Do we really need it?

Julian.
 
C

cies

* tab/space mixture
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks
* clipboards, email, pastebins, and other places where the code is not
preserved literally
* code generators

tabs can be made forbidden (g.v.rossum himself said he'd never
supported tabs in the first place if he new what it would cauze)

maybe it can be made optional. or one could write a little conversion script.

i agree python's indentation looks clean. yet i have experienced
allmost all of the above mentioned "cons"...

_c.
 
X

Xavier Noria

* tab/space mixture
* templates, e.g. eRuby
* expression with code chunk, e.g lambdas and blocks
* clipboards, email, pastebins, and other places where the code is not
preserved literally
* code generators

tabs can be made forbidden (g.v.rossum himself said he'd never
supported tabs in the first place if he new what it would cauze)

maybe it can be made optional. or one could write a little
conversion script.

Or add source filters:

http://search.cpan.org/~fxn/Acme-Pythonic-0.45/lib/Acme/Pythonic.pm

MWUUAHAHAHA.

-- fxn
 
B

Brian Candler

code generators

Disabling sections of code, i.e.

if false
...
... code with original indentation
...
end

Also, multi-level namespaces where you don't want to indent the entire
source file that much, e.g.

module Foo
module Bar
class Baz
def wibble
...
end
end # Baz
end # Bar
end # Foo

(Admittedly, I believe it's now possible to write

module Foo; module Bar; end; end
class Foo::Bar::Baz
...
end)
 
D

Daniel Martin

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

Note that the Haskell folks have managed to evolve a language in which
python-like spacing can be used to mark the extent of discrete code
chunks, but so can traditional braces.

This is more then kind of thing I'd like to see in Ruby: having it
allow the compact python notation, but not require it. (So that,
e.g., code generators would still be easy to write)

I think anyone serious about adding indentation-as-syntax to Ruby
should take a very close look at how Haskell manages to allow it
without requiring it.
 
R

Ryan Leavengood

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.)

This is a very subjective thing. A lot of people don't use Python
because they don't like this feature.

In my case I like the symmetry that Ruby's matching end provides. I
find it makes the code easier to read and maintain. I've written and
maintained some Python code that "trails off into nowhere" with a long
series of indentations. I find this "stairway" code rather painful to
work with.

But if it is possible to add this feature to Ruby without breaking
anything, it could be interesting. It would certainly draw a few
Pythonists to check out Ruby.

Ryan
 
E

Eric Mahurin

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"

|Note that the Haskell folks have managed to evolve a language in which
|python-like spacing can be used to mark the extent of discrete code
|chunks, but so can traditional braces.

I admit Haskell syntax is much better than Python's. But I am not yet
sure if it can be applied to Ruby.

matz.

I've picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

Syntactically it isn't too difficult once you have the lexer generate
indent and unindent tokens. Then the parser just looks for matching
indent and unindent tokens instead of {} or begin/end, etc.

You might consider something like this as an alternative block syntax.
Maybe a ":" followed by a newline (and extra indentation) would start
this style. I'm not sure of a clean way to handle arguments though.

p.s. in the late eighties I made a little shell language (for the
Atari ST) that used indentation just like python.
 
F

Filipe Fernandes

On 5/18/07 said:
I've picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

You could always run it through a tool to clean up code and provide
proper indentation. I personally don't like it when a language
dictates how my code ought to look, since I'm pretty picky myself :s
Syntactically it isn't too difficult once you have the lexer generate
indent and unindent tokens. Then the parser just looks for matching
indent and unindent tokens instead of {} or begin/end, etc.

When working in a team, regardless of how the code has been formatted,
I've always been able to slap pieces of code together and not worry
about indentation (when such language doesn't worry about
indentation). Working in python always adds a little extra stress
when mixing and matching code, and the problem gets bigger when
indentation isn't standardized across teams or when applying code from
the web.

filipe
 
A

Austin Ziegler

I've picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

Scope indicated by whitespace is an indication, IMO, that the compiler
thinks that it knows better than you do.

Always a mistake.

I want a programming language that works how I do; I don't want to
have to work how a stupid programming language requires it.

(I sometimes put debug statements flush left so that it's a simple
/^p<CR> to search for them. Can't do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)

-austin
 
E

Eric Mahurin

Scope indicated by whitespace is an indication, IMO, that the compiler
thinks that it knows better than you do.

Always a mistake.

I want a programming language that works how I do; I don't want to
have to work how a stupid programming language requires it.

(I sometimes put debug statements flush left so that it's a simple
/^p<CR> to search for them. Can't do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)

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
I don't do print debugging as much.

I would rather have multiple ways to specify blocks:
* {}'s
* indentation
* in-line (single statement/expression)

BTW, python's lambda sucks! You can't put generic code in there - it
must be a single expression. I think it has to do with the
indentation thing. Only statements can have code blocks (using
indentation) and a lambda is an expression. I don't like the clear
separation of statements and expressions that python has. I think it
all comes back to the indentation thing. They didn't do it right.
Sounds like Haskell did (but I have no experience with it).
 
G

gga

I've picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

No, it is just the other way around. Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page. Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it. Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types. And most editors can easily find matching braces. No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).

Python is a true nightmare to debug and understand once you have code
that trails off a single page. A good example of these problems, for
example, is the Maya Python API which is as ugly as it can be, using
all of the ugliest things of python (tabulation using tabs, lots of
underscore methods, lots of code that is not easily refactored, etc).

Another problem with indentation only that has not been mentioned is
that simple cut and paste of source code between two files is not
guaranteed to work (and often will lead to a syntax error or worse, a
runtime error). This to me is still a big no-no for indentation only,
as most programmers *do* often cut and paste code from different
contexts or files. With languages that use braces or Ruby's do/end
you really don't have to worry about that, for the most part.
 
J

Jeremy Henty

No editor I am aware knows how to match indentation yet or do/end
contexts (not that it could not be coded, thou).

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

Regards,

Jeremy Henty
 
W

Wolfgang Nádasi-donner

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

class Foo

def bar(value)
if value < 7
puts "hello"
else
puts "world"
end
end

def foobar
puts "foobar"
end

end

could be

class Foo

def bar(value)
if value < 7
puts "hello"
else
puts "world"

def foobar
puts "foobar"

The is one big disadvantage in Python's syntax. Things like...

def bar(value); (value<7) ? (puts "hello") : (puts "world"); end

...are not possible in Python - and they are useful for the typical
one-to-three-liners in support areas, where Ruby still has the chance to
replace Perl - a chance that Python never had.

I know that my example has nothing to do with documentation oriented
software development, but this is not necessary for a broad range of
small ad-hoc tools.

Wolfgang Nádasi-Donner
 
E

Enrique Comba Riepenhausen

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.)

Here my 5 cents...

Gentlemen, if you want to code Python style, go ahead, program in
Python.

I mean every language has it's pros an cons. I come from a Java world
(11 years of Java) and I am not asking that Ruby should be Java like.
That is absolute nonsense.

Ruby is like Ruby, so, if you like it (as I do) take it, if you
don't... there are lots of different programming languages out there
you can choose from, or like Mats, go ahead and develop your own (you
will notice it's actually not that easy to do it right...)

Cheers,

Enrique Comba Riepenhausen
 
A

Austin Ziegler

No, it is just the other way around. Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page. Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it. Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types. And most editors can easily find matching braces. No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).

Vim does this just fine.

-austin
 
S

Sven Suska

Eric said:
You might consider something like this as an alternative block syntax.
Maybe a ":" followed by a newline (and extra indentation) would start
this style. I'm not sure of a clean way to handle arguments though.


What about another syntax:
Putting a special character at the beginning of every line that is
governed by significant whitespace.
Thes would cause no problems with normal Ruby syntax,
but would provide a way to use significant indentation if one really
wants to.

If "~" were that special character, it would look like that:
~ 5.times do |n|
~ n.times do
~ print n
~ puts

Of course, hardly any editor would be prepared to support this,
currently...

This approach would have the additional advantage
of being more robust to contexts where leading whitespace
gets stripped.


Cheers
Sven
 
T

Trans

What about another syntax:
Putting a special character at the beginning of every line that is
governed by significant whitespace.
Thes would cause no problems with normal Ruby syntax,
but would provide a way to use significant indentation if one really
wants to.

If "~" were that special character, it would look like that:
~ 5.times do |n|
~ n.times do
~ print n
~ puts

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top