Pythonic indentation (or: beating a dead horse)

[Mark Kremer]

You might. And you'd be right. Python is widely accepted. Python,
by every indication I'm aware of, is more popular than Ruby. TIOBE
lists Python is slightly more than twice as popular as Ruby
(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html).
And arguably, excluding any discussion of indentation, Ruby is a
better language.

And as you can see on the same lists the top 5 languages (which includes
PHP, which is the most popular scripting language) all use an "end" or
{} for code blocks. That could be a clear indication that identation is
not the preferred method to define code blocks.

I'm told that at Google they won't even let you code in Ruby. They
only allow a limited number of popular languages, which includes
Python but not Ruby.

It makes sense to limit the amount of languages programmed in an
environment, as you need programmers with the appropriate knowledge and
skills to maintain your code. My previous employer did everything in PHP
5. This was not so because it is the best language for every job (it
clearly isn't), but because it was easy to hire and train programmers
with a decent skill level on it and all of the (relatively small)
company's programmers could work on all of the company's code.

 

[Mark Kremer]

There is simply no perfect programming language. If one would exist it
would be the only programming language and we would all be using it.

 

[Andy F]

It's hard to understand why Ruby would allow semicolons to be optional bu=

t not "end" keywords.=0A=0AThere's necessarily a newline where the semicolo=
n would be no? This makes the ommission of semicolons more of an obvious ch=
oice to me than removing ends.=0A=0A> My best guess (and personal reason to=
be against such an option) is that it would add complexity=0A> to programm=
ing and maintaining Ruby code without actually providing new functionality =
(it would only=0A> add a new syntax option).=0A=0A+1: you don't want to mir=
e the progress of a language by constantly seeking backward compatibility, =
but at the same time it seems like a _lot_ of upheaval for a small change.=
=0A=0A> Any time any language change is proposed, one could use the same ar=
gument: there is <language_that_contains_feature_x>=0A> for those who want =
feature x.=A0 I want the Ruby language, but I think it might well be improv=
ed by making a change.=0A=0A+1: new to Ruby and the list, so hope I'm not t=
oo rude in saying I'm not impressed with some of the attitudes of 'piss off=
and use a different language'. Everything's discussable!=0A=0A> There is s=
imply no perfect programming language. If one would exist it would be the o=
nly programming language=0A> and we would all be using it.=0A=0AIMHO if tha=
t logic was right, then you're effectively saying all software studios are =
using the best tools for the job?! Popularity isn't the gauge of utility. =
=0A=0A> Maybe any code in any language should be stored in some generic for=
m meta language (we would have enough space to=0A> store it now - car crysi=
s left enough oil to create magnetic tapes) and the _Editor_ provides the v=
iew which best fits to the=0A> current developer. (Example: translate keywo=
rd to japanese signs, direction of writing a.s.o.)=0A=0ALove it! Be interes=
ted to see anyone playing with that idea in any language. It'd certainly so=
lve the endless debate.=0A=0AA.

 

[Eleanor McHugh]

+1: new to Ruby and the list, so hope I'm not too rude in saying I'm
not impressed with some of the attitudes of 'piss off and use a
different language'. Everything's discussable!

I'm not going to defend any 'piss off' attitude that may be inferred
from some responses to this discussion, but do bear in mind that on
any mailing list there are discussion topics which have been done to
death in the past and that when they recur the posters responsible
will get short shrift.

It's also incredibly rude for someone to make their first post to a
mailing list with something along the lines of "I'm new to this and
think it's really cool, but you're all dumb because..." which whilst
it isn't a fair characterisation of the original post in this thread
does sum up how some people will have perceived it. Were an
established poster to raise such a topic, having already demonstrated
that they understand the trade-offs in the design of Ruby, the
reaction would be very different - but then again the original post
itself would probably have been phrased very differently as well.

As to this particular topic. Outside the Python and Haskell
communities I've seen very little hunger for significant indentation,
and the benefits are hard to demonstrate as suitably compelling to
outweigh all of the other changes people would like to see in their
language of choice. In the case of the Ruby community the main hunger
seems to be for ever-more-powerful meta-programming techniques and
extension of the higher order functionals that so much of our code
comprises of.

In particular Python developers newly acquainted with Ruby tend to
underestimate the difference between statement-oriented and expression-
oriented languages. In the former a statement is an isolated entity
whereas in the latter every expression returns a value, and therefore
it is thoroughly legitimate to treat that expression as a sub-
expression. Whilst I don't doubt that expression-based languages can
be framed in a manner that is compatible with significant indentation,
in doing so they still need to guarantee maintainability.

Our penchant for a certain variety of meta-programming also makes me
uneasy about significant indentation and whilst that unease may be
misplaced I'm sure it's not an isolated phenomenon. The community
would need to be certain that a change such as significant indentation
didn't undermine either the fundamental ability to use those
techniques nor their maintainability, and in hindsight I think a lot
of the posts opposing such a change - even as an optional feature -
reflect that.


Ellie

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

 

[Marc Heiler]

there are discussion topics which have been done to

death in the past and that when they recur the posters
responsible will get short shrift.

I do disagree with your opinion about this.

There is no "hive opinion". Everyone is an individual.

Some may have this opinion, some may have another opinion.

What you deem "have been done to death in the past" someone
else may regard as a topic that is not finished at all. Why
would they then follow your point of view about this?

I find it prematurely to stifle discussion just because someone
disagrees with something.

It's also incredibly rude for someone to make their first post to
a mailing list with something along the lines of "I'm new to this
and think it's really cool, but you're all dumb because...

I do not think it is "incredibly rude".

Quite the opposite - I believe a healthy community must be able to
attract newbies just as easily, without an arrogant bossy tone to
deem what is rude and what is not. Ideas should be kept in free
flow rather than locked down.

The message is there, it is pointless to use argumentum ad hominem
against someone else just because someone gets mad over written
text.

Let's concentrate on the subject at hand without attacking whoever
voiced a specific opinion. People who do insult others aren't
likely to convince anyone whatsoever anyway. And this subject
seems to alienate people much more readily, in that they say
"i hate this idea", and then defend that point of view, rather
than judging from a neutral POINT of view.

And please:

In the case of the Ruby community the main hunger
seems to be for ever-more-powerful meta-programming techniques and
extension of the higher order functionals that so much of our code
comprises of.

This speculation should not be done about a whole "community".

Every community consists of individuals, even if they have a very
similar opinion about something, they still may have different
point of views or arguments as to how they reached that point.

It isn't good to unite all point of views into "logical groups".

For example:
So many people equate the Ruby on Rails community with the Ruby
community - but in my experience these two do not largely overlap.
It is simply unfair to attempt to equate different opinions into
one pool. What does "meta-programming" NEED to have to do anything
with indent at all?

Last but not least, the ultimate freedom would be to have the ability
to omit end as an optional feature in ruby available with a default
being the way it currently is.

To switch between indents, one could use #comment marks, like it is
done for the Encoding stuff already (or for vim files etc...)

Enforcement about official ruby stdlib could still follow one specific
guideline - i.e. it must be properly documented and tested, and it must
use "official" useage of end. (This would be an enforcement of a policy,
rather than syntax.)

 

[Tony Arcieri]

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

On Tue, Jun 2, 2009 at 8:12 AM, Eleanor McHugh <

In particular Python developers newly acquainted with Ruby tend to
underestimate the difference between statement-oriented and
expression-oriented languages. In the former a statement is an isolated
entity whereas in the latter every expression returns a value, and therefore
it is thoroughly legitimate to treat that expression as a sub-expression.
Whilst I don't doubt that expression-based languages can be framed in a
manner that is compatible with significant indentation, in doing so they
still need to guarantee maintainability.

Indeed! Python's statement structured grammar is essential to the way it
implements significant indentation.

What I find incredibly curious is people keep equating the solutions
proposed to Python (which has mandatory statement-structured indentation)
when in actuality they resemble the Haskell approach (optional indent blocks
in lieu of delimiting tokens in a pure expression grammar)

This is what I was trying to explain at the beginning of the thread (if you
want significant indentation in Ruby look to Haskell, not Python), but few
seemed to understand. The proposed solutions aren't "Pythonic", they're...
Haskellish? Or whatever the proper term for that is.

 

[Eleanor McHugh]

What does "meta-programming" NEED to have to do anything
with indent at all?

Because if indentation becomes significant it's important that it
doesn't break any central feature of Ruby, and my gut feeling (which I
concede may be totally misguided) is that the area where such breakage
is most likely to occur will be meta-programming. So whilst it may not
have anything to do with the matter at all, determining whether or not
that is the case is still an important consideration. At least for me.

Last but not least, the ultimate freedom would be to have the ability
to omit end as an optional feature in ruby available with a default
being the way it currently is.

I'm not sure that is such an ultimate freedom, but if it is remember
that all freedom comes with responsibility. In this case ensuring code
consistency.

To switch between indents, one could use #comment marks, like it is
done for the Encoding stuff already (or for vim files etc...)

Making two distinct structural layouts interchangeable in a single
codebase would make them marginally less readable than sticking to one
or other convention. And as maintenance of code is often orders of
magnitude more expensive than development that difference of
readability equates to a real long-term cost.

Enforcement about official ruby stdlib could still follow one specific
guideline - i.e. it must be properly documented and tested, and it
must
use "official" useage of end. (This would be an enforcement of a
policy,
rather than syntax.)

The stdlib is as close to a definition of Ruby idiom as we have, so if
significant indentation isn't going to be allowed there it follows
that significant indentation will not become idiomatic and will
instead be idiosyncratic. If that's the case, then what problem is it
solving?


Ellie

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

 

[Caleb Clausen]

Because if indentation becomes significant it's important that it
doesn't break any central feature of Ruby, and my gut feeling (which I
concede may be totally misguided) is that the area where such breakage
is most likely to occur will be meta-programming. So whilst it may not
have anything to do with the matter at all, determining whether or not
that is the case is still an important consideration. At least for me.

So why metaprogramming, particularly? Ahhh, is it because code
generators may not take care to indent their generated code properly?
I know I've written code generators that do that...

 

[Reid Thompson]

This is what I was trying to explain at the beginning of the thread (if you
want significant indentation in Ruby look to Haskell, not Python), but few
seemed to understand. The proposed solutions aren't "Pythonic", they're...
Haskellish? Or whatever the proper term for that is.

can't resist 'Haskellish'.gsub!('ask','')

 

[Tony Arcieri]

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

Tony Arcieri wrote:
can't resist 'Haskellish'.gsub!('ask','')

I am not going to disagree

 

[Eleanor McHugh]

So why metaprogramming, particularly? Ahhh, is it because code
generators may not take care to indent their generated code properly?
I know I've written code generators that do that...

Precisely.

We use code generation so often in mainstream Ruby code - and
sometimes in some pretty arcane ways - that the possibility of
introducing a whole new category of defect into the process concerns
me much more than typing 'end' ever could.


Ellie

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

 

[Caleb Clausen]

Precisely.

We use code generation so often in mainstream Ruby code - and
sometimes in some pretty arcane ways - that the possibility of
introducing a whole new category of defect into the process concerns
me much more than typing 'end' ever could.

OTOH, as I am a macro bigot myself, I'd have to argue the position
that generating a bunch or ruby code to be passed to eval is the wrong
way to go about it; equivalent macros should be used instead....

 

[Eleanor McHugh]

OTOH, as I am a macro bigot myself, I'd have to argue the position
that generating a bunch or ruby code to be passed to eval is the wrong
way to go about it; equivalent macros should be used instead....

And I wouldn't disagree with you


Ellie

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