Pythonic indentation (or: beating a dead horse)

Ruby
161

On May 28, 2009, at 9:39 AM, Caleb C. wrote:

I feel that I did address this point adequately already, so it’s
annoying to see both you and Joshua B. bring it up again,
without even acknowledging that I had done so. Perhaps you don’t agree
with my points, but as you haven’t tried to rebut them, I think it
more likely that you did not read what I had to say at all.

I did not intend to offend by not explicitly calling you out. I did
read that you had worked around this issue by allowing "end"s to be
optional, and I had assumed that most others following this (now
admittedly very long) thread would have as well. Again, I did not
imply that tackling this issue was impossible (despite my poor choice
of example script name). Indeed, I think I even showed how it would
still be possible to do this even without “end”.

I fear I did not make my point clearly enough: I prefer do…end to
significant-whitespace. I think this is a commonly held preference,
but by no means globally held. However, mixing and matching seems, to
me, like a BAD idea. Why?

Well, if you’re not going to enforce proper indenting when using
do…end, what happens when someone takes working, but poorly
formated, code from a do…end block and copy-pastes it into a block
using indentation instead? You now have code that works in one place
but not in the other. That is, with optional do…end/significant-
whitespace, code that works in one part of a source file might NOT
work in a different part, and the reason for this will be non-obvious.

How about this compromise: Fork Ruby, enforce significant-whitespace,
and instead of writing a preprocessor that converts significant-
whitespace into do…end form, write it to go the other way 'round.
All (or most) of the gems/libraries out there would still be
available, but now you could have a countable number of “Swuby” users
to show the superiority of significant-whitespace.

  • Josh
162

J Haas wrote:

Have you noticed that your post is broken into paragraphs, and those
paragraphs are delimited solely by whitespace, and this does not
impair readability?

Have you noticed that this post contains quotes from you, and the
quotes from you contain quotes from me, and these quotes are delimited
from each other solely by indentation, and this does not impair
readability?

Not so. I have varying levels of ‘>’ characters. Having only
whitespace in a
back and forth message chain does impair readability as far as I’m
concerned.
I ceased long ago using email clients that don’t utilize some form of
leading
indicator.

163

Juan Z. wrote:

On May 28, 2009, at 3:51 PM, James B. wrote:
…

terse != concise.
You’re splitting some fine hairs. Apparently you have your own
dictionary. Terse - definition of terse by The Free Dictionary

That link undermines your point:

terse
Adjective

  1. neatly brief and concise
  2. curt or abrupt [Latin tersus precise]

No one would say “I apologize for being concise with you”!

164

On May 28, 1:25 pm, Rimantas L. [email protected] wrote:

Well, you can go to Python list and make a request to implement those
parts that you like in Ruby.

I could. But frankly, there are more good features of Ruby missing
from Python than there are good features of Python missing from Ruby.
And implementing the biggest feature missing from Ruby would not be
terribly difficult, and would be fully optional and backward
compatible. I’m not sure that any of these things are true about
Python’s deficiencies with respect to Ruby.

Imperfection is in the eye of the beholder.

Do you disagree that Ruby is imperfect? If so, which version is
perfect, 1.8 or 1.9?

165

On May 28, 1:36 pm, Rimantas L. [email protected] wrote:

Have you noticed that your post is broken into paragraphs, and those
paragraphs are delimited solely by whitespace, and this does not
impair readability?

Do you know many other ways to break the text into paragraph?

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.

166

On Fri, May 29, 2009 at 12:54 AM, Joshua B. [email protected]
wrote:

How about this compromise: Fork Ruby, enforce significant-whitespace, and
instead of writing a preprocessor that converts significant-whitespace into
do…end form, write it to go the other way 'round. All (or most) of the
gems/libraries out there would still be available, but now you could have a
countable number of “Swuby” users to show the superiority of
significant-whitespace.

This actually is about the most sensible thing I’ve seen in this
thread, hands down. Whether or not it showed superiority, it could
show utility.

-greg

167

On May 28, 2009, at 4:37 PM, Joel VanderWerf wrote:

Adjective

  1. neatly brief and concise
  2. curt or abrupt [Latin tersus precise]

No one would say “I apologize for being concise with you”!

–
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

It undermines nothing. Concise is used as the definition as you’ve
just shown. Also you seem to have omitted the part about “easy to
understand”. Why would you do that? Or is your concern that the
computer will be offended?

From that same page:

Adj. 1. terse - brief and to the point; effectively cut short; “a
crisp retort”; “a response so curt as to be almost rude”; “the laconic
reply; `yes’”; "short and terse and easy to understand

168

On 5/28/09, James B. [email protected] wrote:

some.stuff

      something.more.important!
      look.at.me!

more.stuff = boring

end

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. If you’d wanted to indent less than the surrounding code,
then I’d be in trouble. This won’t work:

def foo big,
list,
of,
args

some.stuff
some.stuff
some.stuff

something.more.important!
look.at.me!

more.stuff = boring

Gregory B. wrote:

def foo(“bar”, :a => 1, :b => 2,
:c => 3, :d => 4)

end

But that’s not legal. Presumably you meant either this:

def foo(bar, a = 1, b = 2,
c = 3, d = 4)

end

or this:

foo(“bar”, :a => 1, :b => 2,
:c => 3, :d => 4) do

end

Both break endless.rb. I sort of expected that the second one would
fail as soon as I saw it (do is the only thing that requires an end
but doesn’t begin the expressions which it belongs to; I neglected to
consider the case of a do on a line after the one where it’s method
call begins). But the first is a surprise… that should have worked.
Well, they both should work, but now I have 2 bugs to fix. Thanks for
the test cases!

169

On May 28, 2009, at 10:53 PM, Juan Z. wrote:

It undermines nothing.

“It depends on what the meaning of the words ‘is’ is.”

Making Bill C. proud :smiley:

170

On Thu, May 28, 2009 at 5:03 PM, Caleb C. [email protected]
wrote:

foo(“bar”, :a => 1, :b => 2,
:c => 3, :d => 4) do

end

Yeah, just this:

foo(“bar”, :a =>1, :b => 2,
:c => 3, :d => 4)

with or without a block.

This is what I get for staring at the weird macruby method definition
syntax. I’m not even sure if what I wrote was legal there, though :slight_smile:

171

On Thu, May 28, 2009 at 5:03 PM, Caleb C. [email protected]
wrote:

def foo big,
list,
of,
args

some.stuff
some.stuff
some.stuff

So then that means the common indentataion of:

def foo
bar
rescue
0

would also break? Just how many examples of problems do people need
here? :slight_smile:

172

On 28 May 2009, at 19:55, Juan Z. wrote:

Terseness is a perfectly reasonable goal. It’s a corollary to
Occam’s Razer.
No? If you’re going to sacrifice conciseness you should have a
good reason
for doing so.

Occam’s law applies to theory formation, not to literate exposition.
When writing code I’d rather err on the side of verbosity if that
expresses my model well to those who lack my implicit knowledge, than
terse and incomprehensible to anyone except myself.

There is value in redundancy, and the trick is to find the right
balance, not to eliminate it completely.

Exactly. So there should be a choice. Right?

There is. It’s called Python, and as its proponents frequently inform
me it’s every bit as powerful as Ruby.

want to do this.

This is a powerful option.

It’s possible to do this too. Is it not?

And how do you embody syntactic rules for coping with such custom
indenting when the whole point is that they’re both exceptional and
aesthetic in nature?

Ellie

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

raise ArgumentError unless @reality.responds_to? :reason

173

Caleb C. wrote:
If you’d wanted to indent less than the surrounding code,

                :c => 3, :d => 4)

end

This would kill me. I utilize temporary code all the time starting in
column 0
so that it will be easy to find and pull back out

174

On 28 May 2009, at 21:40, J Haas wrote:

On May 28, 1:36 pm, Rimantas L. [email protected] wrote:

Have you noticed that your post is broken into paragraphs, and those
paragraphs are delimited solely by whitespace, and this does not
impair readability?

Do you know many other ways to break the text into paragraph?

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

raise ArgumentError unless @reality.responds_to? :reason

175

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? :slight_smile:

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.

176

On May 28, 2009, at 5:20 PM, Eleanor McHugh wrote:

than terse and incomprehensible to anyone except myself.
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.”

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.

Trying to argue that longer is somehow inherently better doesn’t make
any
sense. 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.

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.

177

On Thu, May 28, 2009 at 7:00 PM, J Haas [email protected] wrote:

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

178

On 28 May 2009, at 23:06, Juan Z. wrote:

verbosity if that expresses my model well to those who lack my
implicit knowledge, than terse and incomprehensible to anyone
except myself.

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.

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

raise ArgumentError unless @reality.responds_to? :reason

179

“Reid T.” [email protected] schrieb im Newsbeitrag
news:[email protected]…

Michael Bruschkewitz wrote:

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.

There’s no way it could be strictly optional.

I dont really understand this sentence (too much indirection - I’m
german
and I’m tired…) Did you mean “It must be strictly optional” ?

Unless you provide some way for
persons that want code block ends to automatically convert code without
ends to
code with ends.

Maybe any code in any language should be stored in some generic form
meta
language (we would have enough space to store it now - car crysis left
enough oil to create magnetic tapes) and the Editor provides the view
which best fits to the current developer. (Example: translate keyword to
japanese signs, direction of writing a.s.o.)
Editor could also apply current coding rules. The would increase code
safety
and security, and efficiency. It would even allow GUI’s for creating
code
from/by Flowcharts.

I’m really serious.
This would be really a revolutionary improvement. (Removing most reasons
for
current holy wars and create a huge field for new, interesting ones.)
But these backbone language would not be Ruby.

Also, IMHO, PyI wouldt break principle of least surprise.

At breakfast I had the idea it would be possible to implement/apply it
to
current file it by simply using
“require ‘tool4endH8ers.rb’” or
“require ‘languageConverter_pyi.rb’” or
“require ‘languageConverter_BASIC.rb’” or
“require ‘languageConverter_f77.rb’” or…
“require ‘applySomeOtherWeirdOptions.rb’” or…
at the beginning of each file or at the beginning of main file.
I’m sure some Kernel.magic would make this possible.

Why not think about providing a mechanism which provides this
possibility?

Regards,
Michael B.

180

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.