Forum: Ruby Poll: Significant Indentation

I've just re-read the "Beating a Dead Horse" thread. I will bring that 
up
shortly, but first I want some actual numbers.

I really like Haml. But I really like Erector (inspired by Markaby). The
biggest reason I prefer Haml to Erector is significant indentation.

I'm curious how many people agree with me. A quick poll -- send answers
directly to me, and I'll count and summarize them for the list:



What is your favorite Ruby template language for generating HTML?

Which editor do you use to edit HTML templates?

Which editor do you use to edit Ruby source?

If Ruby had optional significant whitespace as a core language feature 
(maybe
like http://gist.github.com/117694), would you use it:
 - Never?
 - Sometimes?
 - All the time?
 - Don't care?
 - Only with different syntax (lazibi, colon, something else?)

If your favorite template language is Haml, would you prefer Erector if 
Ruby
had significant whitespace?
(yes/no/NA)

If you actually dislike Haml, is it because of the significant 
whitespace?
(yes/no/NA)

Have you done any significant development in Python?
(yes/no)



That's all.

I welcome opinions, but what I'm after here are either specific, 
countable
statistics, or a criticism of the questions being asked. I think there 
will be
a lot more to discuss once we have some numbers.

Also: Should I cross-post this to the Rails group?

On 2009-12-13, David Masover <ninja@slaphack.com> wrote:
> What is your favorite Ruby template language for generating HTML?

I've been using erb since that's what's handy in rails.

> Which editor do you use to edit HTML templates?

vi

> Which editor do you use to edit Ruby source?

vi

> If Ruby had optional significant whitespace as a core language feature (maybe 
> like http://gist.github.com/117694), would you use it:
>  - Never?
>  - Sometimes?
>  - All the time?
>  - Don't care?
>  - Only with different syntax (lazibi, colon, something else?)

Never, ever, ever, ever, ever.  I would weep for the horror of knowing 
that
people would send me code which was broken that way.

> If your favorite template language is Haml, would you prefer Erector if Ruby 
> had significant whitespace?
> (yes/no/NA)

NA.

> If you actually dislike Haml, is it because of the significant whitespace?
> (yes/no/NA)

Pretty much.

> Have you done any significant development in Python?
> (yes/no)

No.  I did a little bit, and quit because I couldn't get past the horror
of significant whitespace.

It turns out to be surprisingly error-prone.  I'd rather have actual
tokens drive indentation (through tools like indent/cb) than have
spaces break things.  If there are tokens for, e.g., blocks, or 
beginning
and end of grouping, it's reliably possible to figure out what's 
happening
and to modify the indenting to fit.  If you go the other way, you are
totally, completely, screwed if anything goes wrong -- there's neither
information to let you determine what was intended, nor a way to detect
that something else was intended.

-s

Okay, flame on ;)!

> What is your favorite Ruby template language for generating HTML?

ATM, Erector. I have to admit that "template language" is a topic
I hate because I've never seen one that I totally like while not being
able to come up with a better one. I do miss a Ruby version of TAL,
though, just for play.

> Which editor do you use to edit HTML templates?

Textmate, VIM

> Which editor do you use to edit Ruby source?

Textmate, VIM

> If Ruby had optional significant whitespace as a core language  
> feature (maybe
> like http://gist.github.com/117694), would you use it:
> - Never?
> - Sometimes?
> - All the time?
> - Don't care?
> - Only with different syntax (lazibi, colon, something else?)

Never, such a feature should not be optional. I would not use Code
written
using that feature.

> If your favorite template language is Haml, would you prefer Erector  
> if Ruby
> had significant whitespace?
> (yes/no/NA)

> If you actually dislike Haml, is it because of the significant  
> whitespace?
> (yes/no/NA)

yes, while it is not the only reason.

> Have you done any significant development in Python?
> (yes/no)

What's significant? I've done my fair share of development in
languages using
the off-side-rule, e.g. Python and Haskell.

yes

> That's all.
>
> I welcome opinions, but what I'm after here are either specific,  
> countable
> statistics, or a criticism of the questions being asked. I think  
> there will be
> a lot more to discuss once we have some numbers.

Okay, I tend to ignore this discussion, mostly because I don't think
it is
worth much. It comes up every half a year, fills the mailing list and
is only
beaten by long discussions about ++.

While I'm not explicitly against using the off-side-rule (I like how
Haskell
uses it), I think you should pick one and stick with it. Ruby doesn't.
In the
end, I don't see syntax as that important.
For example, if I'd had to steal something from Python, it would be
guaranteed
Method identity.

I also would prefer a parser for literal Ruby much more than having
significant
whitespace.

Regards,
Florian

On Dec 13, 2009, at 5:07 PM, David Masover wrote:

What is your favorite Ruby template language for generating HTML?

erb


Which editor do you use to edit HTML templates?

textmate/vi

Which editor do you use to edit Ruby source?

textmate


If Ruby had optional significant whitespace as a core language feature 
(maybe
like http://gist.github.com/117694), would you use it:
- Never?

Never


If your favorite template language is Haml, would you prefer Erector if 
Ruby
had significant whitespace?
(yes/no/NA)

NA


If you actually dislike Haml, is it because of the significant 
whitespace?
(yes/no/NA)

Yes


Have you done any significant development in Python?
(yes/no)

No

Cheers--

Charles
--
Charles Johnson
Advanced Computing Center for Research and Education
Vanderbilt University

On Sunday 13 December 2009 06:02:23 pm Florian Gilcher wrote:
> Okay, flame on ;)!

Well, if you want...

> Never, such a feature should not be optional.

If you mean you hate it so much you don't want to see it, fine.

If you mean you'd like to see it go one way or another, that's 
interesting.
Parentheses are often optional in Ruby. I think options are good -- 
coding
conventions should be enforced by the project, not the language.

> > Have you done any significant development in Python?
> > (yes/no)
> 
> What's significant?

Mostly looking for self-assessment here. The fact that you can identify
something else you'd want to take from python suggests you've at least 
used
it. Contrast to Seebs, who "couldn't get past the horror" -- not that 
it's an
invalid opinion, but I'd much rather hear from people who are 
comfortable in
both.

For example, I can't get past the horror of PHP or Visual Basic, so my 
opinion
isn't as valuable as that of someone who has done significant 
development in
PHP and lived to tell about it.

> Okay, I tend to ignore this discussion, mostly because I don't think
> it is
> worth much. It comes up every half a year, fills the mailing list and
> is only
> beaten by long discussions about ++.

I agree, which is why I've made it a poll. Mostly, I'm wanting to find 
out if
it's worth my time to pick an implementation and bring it up to speed, 
or
organize with other people who like significant indentation.

Since people are replying on-list, I might as well. If you couldn't 
guess:

On Sunday 13 December 2009 05:07:40 pm David Masover wrote:
> What is your favorite Ruby template language for generating HTML?

Haml.

> Which editor do you use to edit HTML templates?

Kate.

> Which editor do you use to edit Ruby source?

Kate.

> If Ruby had optional significant whitespace as a core language feature
>  (maybe like http://gist.github.com/117694), would you use it:

Sometimes.

> If your favorite template language is Haml, would you prefer Erector if
>  Ruby had significant whitespace?

Yes.

> Have you done any significant development in Python?

No.

On 2009-12-14, David Masover <ninja@slaphack.com> wrote:
> If you mean you'd like to see it go one way or another, that's interesting. 
> Parentheses are often optional in Ruby. I think options are good -- coding 
> conventions should be enforced by the project, not the language.

The problem is that indentation sensitivity isn't optional -- it's
not something you can just not use if you don't want it, because if
it's there, you'll get code that relies on it.

> Mostly looking for self-assessment here. The fact that you can identify 
> something else you'd want to take from python suggests you've at least used 
> it. Contrast to Seebs, who "couldn't get past the horror" -- not that it's an 
> invalid opinion, but I'd much rather hear from people who are comfortable in 
> both.

> For example, I can't get past the horror of PHP or Visual Basic, so my opinion 
> isn't as valuable as that of someone who has done significant development in 
> PHP and lived to tell about it.

I disagree.  I have done significant development in PHP, and your 
opinion
is PRECISELY correct.

-s

On Dec 13, 2009, at 8:49 PM, David Masover wrote:

> On Sunday 13 December 2009 06:02:23 pm Florian Gilcher wrote:
>> Okay, flame on ;)!
>
> Well, if you want...

It was more meant as a joke. Remember: pack irony tags next time ;).

>
>> Never, such a feature should not be optional.
>
> If you mean you hate it so much you don't want to see it, fine.
>
> If you mean you'd like to see it go one way or another, that's  
> interesting.
> Parentheses are often optional in Ruby. I think options are good --  
> coding
> conventions should be enforced by the project, not the language.

Yes, and it is one of the issues where there are often collisions while
defining coding standards. The problem is that I believe there should
not
be a too big visual delta between two options.

While options are good (I do have my fair share of strange patterns I
love
to use as well), you can also over-cramp the language with options. As
I wrote,
I would love to see literal Ruby and actually thought about
implementing it.
But on such a scale, that would mean two and a half things:

1. your project is not accepted and a lot of unnecessary work
2a. your idea is accepted into core
2b. you introduce a hard community split - those who install you
library and
those who don't.

Literate Haskell for example only works because GHC understands it.

> that it's an
> invalid opinion, but I'd much rather hear from people who are  
> comfortable in
> both.

It's not like I am opposed to Python. Most of the time, I just don't
see a reason
to do a lot of work in it, being very proficient in Ruby. They kind of
solve the
same problem. I am in great pain for not being able to visit the RuPy
the last
two years.

I do have some fun with pypy from time to time and would never think of
reimplementing that in Ruby, just because it is written in Python.

> For example, I can't get past the horror of PHP or Visual Basic, so  
> my opinion
> isn't as valuable as that of someone who has done significant  
> development in
> PHP and lived to tell about it.

I also did significant work with PHP. PHP 5.3 is... somehow okay as a
language.
The core library is still horrible. And thats kind of my point: I use
Ruby because
I like the way the core and std lib is built. Not because there is an
end-thingy
at the end of my blocks or not. Matz's EuRuKo2009-talk had a nice stab
at the
"API defines the language" thing.

I know quite a share of languages that a lot of people find horribly
ugly. Haskell,
Prolog and Erlang mostly. I don't mind their syntax that much, because
I am more
interested in the runtime system they use. I write Ruby because it
allows some
pretty descriptive concepts and is a good in-between between all those
languages.
Sure, the end-wall at the end of nested class definition can be ugly
from time
to time, but it by far does not make irritate me enough to want a
whole alternative
parser for it.

On Sunday 13 December 2009 06:47:14 pm Florian Gilcher wrote:
> On Dec 13, 2009, at 8:49 PM, David Masover wrote:
> > On Sunday 13 December 2009 06:02:23 pm Florian Gilcher wrote:
> >> Okay, flame on ;)!
> >
> > Well, if you want...
> 
> It was more meant as a joke. Remember: pack irony tags next time ;).

Oh, I got it. The smiley was a dead giveaway, right? :P

> >> Never, such a feature should not be optional.
> >
> > If you mean you hate it so much you don't want to see it, fine.
> >
> > If you mean you'd like to see it go one way or another, that's
> > interesting.
> > Parentheses are often optional in Ruby. I think options are good --
> > coding
> > conventions should be enforced by the project, not the language.
[snip]
> While options are good (I do have my fair share of strange patterns I
> love
> to use as well), you can also over-cramp the language with options. As
> I wrote,
> I would love to see literal Ruby and actually thought about
> implementing it.
> But on such a scale, that would mean two and a half things:
> 
> 1. your project is not accepted and a lot of unnecessary work

That's the purpose of this poll. If there's no interest, I probably 
won't
bother.

> 2a. your idea is accepted into core
> 2b. you introduce a hard community split - those who install you
> library and
> those who don't.

I don't see where this is a huge problem. If it really can be a library, 
there
are either those who adopt it or those who don't. For example, Rails
introduces the .map(&:foo) idea, which eventually made it into core. It 
also
introduces 5.hours.ago, 2.minutes.from_now, and 'octopus'.pluralize, 
none of
which will ever make it into core. And it's far from the only library to 
hack
all over core.

It would be especially non-problematic if it had a tool similar to 
lazibi, so
that people who absolutely couldn't stand it could convert it back.

But even as it is, we still have a few Lisp people who throw parentheses
around EVERYTHING in Ruby, a few people moving from C and other 
languages who
find it just weird to define a method without parentheses, even if it 
won't be
used that way:

def foo(options)
  ...
end
foo :bar => :baz

And of course, we have people who use define_method and other 
metaprogramming
techniques, and people who pipe things into eval, and people who store
configuration as Ruby scripts, and people who store it as Yaml, and 
people who
write their own storage format.

I don't think those who cry out in agony at the mere sight of 
significant-
indentation code will really have more trouble reading and maintaining 
it than
I would maintaining lisp-style Ruby.

For that matter, did you know Ruby 1.9 now supports this JSON-like 
syntax
natively?

{
  a: 'b',
  c: 5
}
# => {:a=>"b", :c=>5}

The new lambda syntax is cool, too:

-> { puts "I'm a lambda!" }

So I don't think this is an issue -- there are as many ways to write 
Ruby than
there are other programming languages, and new versions can add new 
syntax. I
think backwards-compatibility and parser manitainability are much bigger
concerns. That is, if my idea is a complete flop, it shouldn't affect 
anyone
else.

By the way: This post is a _defense_ for the idea of alternate syntax. 
I'm not
going to start advocating it again just yet.

On Sunday 13 December 2009 06:40:09 pm Seebs wrote:
> On 2009-12-14, David Masover <ninja@slaphack.com> wrote:
> > If you mean you'd like to see it go one way or another, that's
> > interesting. Parentheses are often optional in Ruby. I think options are
> > good -- coding conventions should be enforced by the project, not the
> > language.
> 
> The problem is that indentation sensitivity isn't optional -- it's
> not something you can just not use if you don't want it, because if
> it's there, you'll get code that relies on it.

That is true of any library. It's also true of the Lisp-like syntax I
mentioned before -- the following is valid Ruby:

((def setf(name, value)
  (instance_variable_set name, value) end);

(setf :@file, (open '/etc/passwd'));
(@file.each_line {|line|
  (puts (line.gsub 'foo', 'bar'))});
(@file.close))

And yes, that's probably going to be unmaintainable, even if you did 
come from
Lisp. The point is, no one's forcing you to maintain it -- even if 
someone has
written code like this, you can still choose to ignore it, or maybe to 
brave
it with some automated tools to sort it out.

Even things like spaces or tabs for indentation are again up to the 
individual
project or coder to set some standards and adhere to them.

> > For example, I can't get past the horror of PHP or Visual Basic, so my
> > opinion isn't as valuable as that of someone who has done significant
> > development in PHP and lived to tell about it.
> 
> I disagree.  I have done significant development in PHP, and your opinion
> is PRECISELY correct.

That's good to know, but again, your firsthand experience is far more 
valuable
than my opinion which is mostly formed by reading about PHP, and only 
ever
trying it for a few hours at a time.

David Masover wrote:
> I really like Haml. But I really like Erector (inspired by Markaby).

But which is better? There's only one way to find out. FIGHT!!!

> What is your favorite Ruby template language for generating HTML?

HAML

> Which editor do you use to edit HTML templates?

joe

> Which editor do you use to edit Ruby source?

joe

> If Ruby had optional significant whitespace as a core language feature 
> (maybe
> like http://gist.github.com/117694), would you use it

Never in a million years. If I wanted that, I'd be using python.

> If your favorite template language is Haml, would you prefer Erector if 
> Ruby
> had significant whitespace?
> (yes/no/NA)

NA, since I wouldn't be using ruby.

> If you actually dislike Haml, is it because of the significant 
> whitespace?
> (yes/no/NA)

NA. HAML is great.

> Have you done any significant development in Python?
> (yes/no)

No. But I have in the past done significant development in Occam, which 
is also a signficant-indentation language.

   SEQ
     .. do X
     .. do Y
     .. do Z

It was bearable when using a folding editor, and that limits your choice 
of editor a lot. I ended up writing one.

I agree it does seem paradoxical that one can like indentation for HTML 
but dislike it for programming. For me the following are important:

- HTML has the need for balancing end tags, and the annoying </...> 
syntax. With Ruby it's just three characters, 'end'

- I find HTML templates are small and don't often need moving around or 
commenting out; the occasional indent/outdent I can cope with

- I do write ruby in a consistently indented way, but I like seeing the 
'end' rather than the execution path falling off a cliff. That is, loops 
and other control structures have a bound shape.

OTOH it doesn't matter to me in HTML, since it's all just content and 
nested divs.

What is your favorite Ruby template language for generating HTML?

Which editor do you use to edit HTML templates?

Well, I'm not using regularly HTML templates, but for what I know of 
them,
I'd probably use TextMate

Which editor do you use to edit Ruby source?

TextMate

If Ruby had optional significant whitespace as a core language feature
(maybe
like http://gist.github.com/117694)
, would you use it:

Never, that jus looks awful to me, and very hard to read. Also, it 
doesn't
let you use some extra indentation.

If your favorite template language is Haml, would you prefer Erector if 
Ruby
had significant whitespace?
(yes/no/NA)

No, I prefer Erector, as it is, mainly because I love to write pure Ruby

If you actually dislike Haml, is it because of the significant 
whitespace?
(yes/no/NA)

No, I think it's a good feature in a template for XML-like languages. 
But
not for a programming language(because it is far more complex syntax 
than
just XML nodes, ins't it?)

Have you done any significant development in Python?
(yes/no)

Not really, I did a little at a time, and found more easier to write a 
"end"
and then be able to read it fast than not writing it and be dead if the
indentation got wong.

For example:

def meth(*args)
  if args.length && ...
    do_something
  end
end

def another_meth
end

def third_meth
end

or ?

def meth(*args)
  if args.length && ...
    do_something

def another_meth

def third_meth


Yes, you get rid of this "useless" end's, but also the readability I 
think
because you never see the end of a context, you have to deduce it from
lesser indentation, what is not easy when you come to 5 levels...

Just try to "translate" a stdlib of Ruby, and you'll see your pain to 
read
it after ;)

Brian Candler wrote:
> OTOH it doesn't matter to me in HTML, since it's all just content and 
> nested divs.

Also: with HTML, a missing or badly-overlapping tag will usually go 
unnoticed, and may have unpredictable effects in the browser(s). It may 
render as intended in one but not in another. With HAML the output is 
well-formed always, and at worst my nesting will be wrong (and will be 
consistent in all browsers).

With Ruby, if I'm missing an 'end' the code won't run. I'd rather get 
the error, so I can correct it, than have the compiler insert end's 
silently.

> What is your favorite Ruby template language for generating HTML?

rhtml


> Which editor do you use to edit HTML templates?

e

> Which editor do you use to edit Ruby source?

e


> If Ruby had optional significant whitespace as a core language feature 
> (maybe
> like http://gist.github.com/117694), would you use it:
>  - Never?
>  - Sometimes?
>  - All the time?
>  - Don't care?
>  - Only with different syntax (lazibi, colon, something else?)


Probably all the time, a different syntax might be useful...

> Have you done any significant development in Python?
> (yes/no)

a bit.

On Monday 14 December 2009 04:12:42 am Brian Candler wrote:
> > If Ruby had optional significant whitespace as a core language feature
> > (maybe
> > like http://gist.github.com/117694), would you use it
> 
> Never in a million years. If I wanted that, I'd be using python.

This is interesting, and came up a lot in the previous discussion -- 
mostly in
the form of, "If you like significant indentation so much, why don't you 
just
use Python?"

I do want that, but I don't want Python. Just about everything else that 
makes
Ruby different than Python makes me want to use Ruby. There are only two
things I would want from Python:

 - Execution speed
 - Significant indentation.

If I can't have those in Ruby, fine, there are still many reasons I'll 
use
Ruby instead. And people are working on execution speed.

> > If your favorite template language is Haml, would you prefer Erector if
> > Ruby
> > had significant whitespace?
> > (yes/no/NA)
> 
> NA, since I wouldn't be using ruby.

I think that's a no.

And again, _optional_ significant whitespace. Would you stop using Ruby 
if it
became an option?

> I agree it does seem paradoxical that one can like indentation for HTML
> but dislike it for programming. For me the following are important:
> 
> - HTML has the need for balancing end tags, and the annoying </...>
> syntax. With Ruby it's just three characters, 'end'

Same with Erector, though. This is actually one of the few reasons I 
prefer
Haml to Erector, and there are many things I want from Erector.

On 2009-12-14, David Masover <ninja@slaphack.com> wrote:
> And again, _optional_ significant whitespace. Would you stop using Ruby if it 
> became an option?

I don't think it makes sense to describe it as optional.

If it's there, then the parser has to handle it for any modules which 
use it.
Which means I have to deal with at least some incoming code using it, 
and
that means I can no longer trust blocks to have end markers.

You can talk about optional parentheses, because both in the pair are
optional and we know how to detect the argument list.  With significant
whitespace, though... It seems like you'd have to know whether or not it
was in use in advance.

But basically, I find significant whitespace a sufficiently high barrier
to reading and maintaining code that, if a noticeable chunk of Ruby code
were written that way, I would probably lose a lot of interest.  I 
frequently
have to read and deal with other peoples' code to get things done, and 
if
that code were illegible to me, that would be a big downside.

I have yet to comprehend any circumstance in which whitespace 
significance
does anything but increase the number of undetectable and uncorrectable
failure modes.  I'm pretty happy with 1.9 warning about mismatched
indentation, because that DOES actually catch errors.  But it only 
catches
errors because it has an absolutely definite cue (the end token) to 
compare
with.

-s

On Sun, Dec 13, 2009 at 4:07 PM, David Masover <ninja@slaphack.com> 
wrote:

> If Ruby had optional significant whitespace as a core language feature
> (maybe
> like http://gist.github.com/117694), would you use it:
>  - Never?
>  - Sometimes?
>  - All the time?
>  - Don't care?
>  - Only with different syntax (lazibi, colon, something else?)
>

I would support Haskell-style optional indentation in Ruby, although I 
can't
say how often I'd use it myself.

David Masover wrote:

> 
> 
> What is your favorite Ruby template language for generating HTML?

Erb or Ezamar, depending on what I'm doing.

> 
> Which editor do you use to edit HTML templates?

Vim

> 
> Which editor do you use to edit Ruby source?

Vim

> 
> If Ruby had optional significant whitespace as a core language feature (maybe 
> like http://gist.github.com/117694), would you use it:

Maybe. I prefer, for example, the more tolerant offside whitespace rules
of Haskell to the brittle horror of Haml.  But Ruby's not Haskell.  Each
encourages you to think about programs differently.

> 
> If you actually dislike Haml, is it because of the significant whitespace?

Probably; it's a poor syntax because it favors a rigid DOM-centric view
over a fluid document view.   (I see programs as documents, e.g. essays,
so whitespace freedom matters. Same for Web pages.)

> 
> Have you done any significant development in Python?
> (yes/no)

No.  Tried it out, and have had to adjust some Python code here and
there for one or another project, but nothing major.

My(__self__) didn't care for it.

> 
> 
> 
> That's all.
> 
> I welcome opinions, but what I'm after here are either specific, countable 
> statistics, or a criticism of the questions being asked. I think there will be 
> a lot more to discuss once we have some numbers.
> 

Ruby already has significant whitespace considerations: '\n' in place of
';', for example.  A better term might be  "significant indentation".

More clarity on possible forms of significant indentation would be
helpful, too.

> Also: Should I cross-post this to the Rails group?
> 

No.

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

On Monday 14 December 2009 02:55:06 pm Seebs wrote:
> On 2009-12-14, David Masover <ninja@slaphack.com> wrote:
> > And again, _optional_ significant whitespace. Would you stop using Ruby
> > if it became an option?
> 
> I don't think it makes sense to describe it as optional.

Why not?

> If it's there, then the parser has to handle it for any modules which use
>  it. Which means I have to deal with at least some incoming code using it,
>  and that means I can no longer trust blocks to have end markers.

So, by this logic, use (or lack) of parentheses are optional, as are 
curly
brackets around hash literals (if they're immediately passed as the last
argument to a method)...

> You can talk about optional parentheses, because both in the pair are
> optional and we know how to detect the argument list.  With significant
> whitespace, though... It seems like you'd have to know whether or not it
> was in use in advance.

That depends what the syntax looks like. One thing that was proposed was 
using
a colon:

def some_value:
  @some_value

In the last discussion, Matz wasn't opposed to the idea, but he said the
colon, specifically, wouldn't work.

> But basically, I find significant whitespace a sufficiently high barrier
> to reading and maintaining code that, if a noticeable chunk of Ruby code
> were written that way, I would probably lose a lot of interest.  I
>  frequently have to read and deal with other peoples' code to get things
>  done, and if that code were illegible to me, that would be a big downside.

Do you really not find ways people can write unreadable code in Ruby as 
it is?
If the problem is unreadable code, the solution is coding standards and
comments.

I don't feel it should be the job of the language to enforce coding 
standards,
and that is one of the reasons I use Ruby in the first place.

But this is more than I wanted to say, yet.

Ultimately, it's a matter of taste, which is why I'm more interested in 
how
many people want such a feature than how many people think it should 
exist.
The biggest pain point for me is HTML generation, so if no one else 
cares,
I'll just go use Haml.

On 2009-12-15, David Masover <ninja@slaphack.com> wrote:
> On Monday 14 December 2009 02:55:06 pm Seebs wrote:
>> On 2009-12-14, David Masover <ninja@slaphack.com> wrote:
>> > And again, _optional_ significant whitespace. Would you stop using Ruby
>> > if it became an option?
>> 
>> I don't think it makes sense to describe it as optional.

> Why not?

>> If it's there, then the parser has to handle it for any modules which use
>>  it. Which means I have to deal with at least some incoming code using it,
>>  and that means I can no longer trust blocks to have end markers.

> So, by this logic, use (or lack) of parentheses are optional, as are curly 
> brackets around hash literals (if they're immediately passed as the last 
> argument to a method)...

The grammar for parentheses in Ruby is not-optional, but it happens to
allow either form.

Hmm.  Here's the thing.  You can't do it unless you have some special
token that indicates the start of a block which is whitespace-delimited.
Otherwise, consider:
  if true
    indented
    things
  more things
  end

Did that block end at "more things" or at "end"?

For it to not be ambiguous, you have to know in advance which one you're
looking for.

> Do you really not find ways people can write unreadable code in Ruby as it is? 
Oh, sure.  But the language is at least theoretically subject to 
indentation
fixers now.  It wouldn't be with this change.

> I don't feel it should be the job of the language to enforce coding standards, 
> and that is one of the reasons I use Ruby in the first place.

I suppose if we're talking about a special thing which introduces 
blocks,
part of my objection goes away -- it's no longer impossible.

I still can't comprehend wanting that feature -- it's always struck me
as introducing a lot more prospective undiganosible errors than it
could ever remove.

(Disclaimer:  I get a lot of mail that's been corrupted by a messaging
server which strips or squashes leading whitespace.)

-s

> -----Original Message-----
> From: Seebs [mailto:usenet-nospam@seebs.net]
> 
> I still can't comprehend wanting that feature -- it's always struck me
> as introducing a lot more prospective undiganosible errors than it
> could ever remove.
> 
> (Disclaimer:  I get a lot of mail that's been corrupted by a messaging
> server which strips or squashes leading whitespace.)

This has always been my objection to significant whitespace, is it's too
darned easy for it to get confused and either cause syntax errors, or
worse, change the meaning of your code.  It becomes even more fun when
you enter into the spaces vs. tabs debacle.  Don't get my wrong, I
think proper indentation is important, but in the same way that I
think proper documentation is important.  I don't want my language
throwing a syntax error or doing something unexpected because I
didn't place a comment in the right spot.

I just think we should try to avoid adding new exceptional situations to 
the
language. The simpler the language, the more elegant and easy to use, 
all
these "it works this way... except sometimes, but sometimes that's not 
the
case either" just bog everyone down.

I do hate the pyramid code I see fairly often:

class This
  class That
    def something
      call_method do |obj|
        obj.blah_blah do
          if condition
            puts 'Mt. Everest!'
          end
        end
      end
    end
  end
end

I find it extremely difficult to figure out where I am, so I somehow 
manage
to avoid typing code like this. If whitespace is the solution, then I'm 
not
opposed to it, but having to remember "this little section has that 
little
identifier which means that whitespace is turned on this time, but the 
line
ended in a comma or slash or plus sign, so this line is actually a
continuation of the last line so whitespace doesn't matter on this 
line." is
just a weight on my ability to concentrate.

I need simple intuitive consistent rules that I don't have to look up
constantly, or make frequent exceptions to.

On Monday 14 December 2009 08:10:09 pm Seebs wrote:
> For it to not be ambiguous, you have to know in advance which one you're
> looking for.

I agree. I don't think it has to be a special token at the start of a 
block,
but definitely, some context which unambiguously marks this as an 
indented
block, and which doesn't make existing blocks autoindented.

If I were writing a new language, I'd much prefer something like 
endless.rb,
where 'end' is simply optional, but as you point out, that would screw 
up
existing code. So, very worst case, you'd specify it per-file or 
per-block.

> > Do you really not find ways people can write unreadable code in Ruby as
> > it is?
> 
> Oh, sure.  But the language is at least theoretically subject to
>  indentation fixers now.  It wouldn't be with this change.

Sure it would, they'd just be more complicated to write, and wouldn't 
apply
universally. Also, indentation fixers are far from the only automated 
tools
which could be applied -- I suspect there are some that already don't 
work
because of syntax that's already flexible.

> > I don't feel it should be the job of the language to enforce coding
> > standards, and that is one of the reasons I use Ruby in the first place.
> 
> I suppose if we're talking about a special thing which introduces blocks,
> part of my objection goes away -- it's no longer impossible.
> 
> I still can't comprehend wanting that feature -- it's always struck me
> as introducing a lot more prospective undiganosible errors than it
> could ever remove.

I'd argue that "undiagnosable" is a strong word, especially when we're 
talking
about a language with a strong community ethic of testing and beautiful 
code.
Again, I'd suggest that it's that code in particular, and not the 
syntax,
which would make it unreadable.

But my goal here isn't to get you to agree. I think at least you're no 
longer
opposed to the feature existing, though you'd be opposed to the use of 
it.

> (Disclaimer:  I get a lot of mail that's been corrupted by a messaging
> server which strips or squashes leading whitespace.)

And I see the same thing happening in IM clients.

But IM clients also tend to notice smileys and such, which can corrupt 
the
code to unreadability long before indentation would, and don't always 
even
make it possible to copy and paste it in its original format.

There's no limit to the extent that bad tools can screw up code. The 
solution
is to not use tools like that -- worst case, that's what pastie is for.

On Monday 14 December 2009 10:40:19 pm Josh Cheek wrote:
> I just think we should try to avoid adding new exceptional situations to
>  the language. The simpler the language, the more elegant and easy to use,
>  all these "it works this way... except sometimes, but sometimes that's not
>  the case either" just bog everyone down.

If you really think that, I think you'll find Lisp much easier and more
intuitive. We already have tons of exceptional situations, and most of 
them, I
think, make the language _more_ readable. The obvious example:

has_many :comments, :through => :posts

So, you can omit the parens and the curly brackets sometimes, but not 
all the
time. For example:

p {:a => :b}

Whoops. I meant a Hash literal, but Ruby assumed it was a block instead. 
Looks
like I have to do this:

p({:a => :b})

It's not too much to hold in your head, and it's fairly easy to figure 
out,
but it's not pure, and it's not consistent.

>         end
>       end
>     end
>   end
> end
> 
> I find it extremely difficult to figure out where I am, so I somehow manage
> to avoid typing code like this.

I agree, which is why I dropped it for awhile. But I like Haml, and I 
find
that this is inevitably what happens with any even moderately complex 
HTML
document -- so it would happen if I started using Erector.

But even without that, while your example looks ludicrous, how would you
refactor it? I only see two obvious changes:

class This::That
  def something
    call_method do |obj|
      obj.blah_blah do
        some_other_method obj
      end
    end
  end
  def some_other_method obj
    if condition
      puts 'Mt. Everest!'
    end
  end
end

But that didn't really get rid of the problem, nor did it remove a 
single end
statement. I'd argue that actually makes it _less_ readable -- in this
contrived example, it's not as though some_other_method is being reused
elsewhere, so all this serves to do is spread the logic out more. It may 
be
easier to follow in that it's not as deeply nested (theoretically), but 
it's
more complex.

In fact, interestingly, the ratio of 'end' noise to actual code is still
exactly the same -- 6 ends to 7 real lines of code, almost 50%.

There is one way to really seriously refactor it:

class SomeObject
  def foo
    self.blah_blah do
      if condition
        puts 'Mt. Everest'
      end
    end
  end
end

class This::That
  def something
    call_method do |obj|
      obj.foo
    end
  end
end

You could imagine similarly pushing the "call_method" logic somewhere 
else,
until eventually, your nested loops are hidden deep in library code, or 
even
removed -- blocks replaced with even more methods.

But this comes at a cost of flexibility. Presumably there was a reason
blah_blah is exposed, and takes a block. Blocks are, after all, one of 
the
coolest things about Ruby. You can say that nesting that deeply is a Bad
Thing, but there are many cases where it really is appropriate.

I suppose it all comes back to that basic idea of not wanting the 
language to
tell me what to do. I'd like to be able to nest things that deeply, when 
I
have to, and have them look good.

> If Ruby had optional significant whitespace as a core language feature 
> (maybe
> like http://gist.github.com/117694), would you use it:
>  - Never?
>  - Sometimes?
>  - All the time?
>  - Don't care?
>  - Only with different syntax (lazibi, colon, something else?)

In general I'm in favor of optional significant whitespace, because it 
fits more code onto the current viewable page.

In general I think that whitespace delimited code is easier to read, but 
harder to write.

Does anybody have any experience as to whether that makes code easier to 
maintain, or not?

-r

2009/12/15 Roger Pack <rogerpack2005@gmail.com>:
>> If Ruby had optional significant whitespace as a core language feature
>> (maybe
>> like http://gist.github.com/117694), would you use it:
>>  - Never?
>>  - Sometimes?
>>  - All the time?
>>  - Don't care?
>>  - Only with different syntax (lazibi, colon, something else?)

I'm not sure adding significant indentation  is a good idea. The Ruby
syntax is already so complex that most editors can't get all of it -
some constructs simply don't indent right so I have to split them
differently or indent them manually.

Imagine adding significant indentation to that.

I would probably use the feature it it just implicitly sprung to
action the moment I forget some ends. However, it would probably make
working with Ruby code harder.

>
> In general I'm in favor of optional significant whitespace, because it
> fits more code onto the current viewable page.
>
> In general I think that whitespace delimited code is easier to read, but
> harder to write.
>
> Does anybody have any experience as to whether that makes code easier to
> maintain, or not?

I think that there are already fine languages with significant
indentation, and fine languages with syntax that does not heavily rely
on whitespace, including Ruby.

I would like to point out one trend that I noticed: the languages
which do rely on significant indentation seem to have overall simpler
syntax so that even in case of clobbered code it's somewhat easier to
deduce what goes where though it's unambiguous only if you have some
idea what the code does.

Ruby has already gone the way of more complex syntax which is more
concise at times but requires more explicit delimiters at others.
Undoing that is a challenge which requires more than just adding
significant indentation.

There has to be a balance between the two features to keep the code
readable and maintainable.

Thanks

Michal

>
> If you really think that, I think you'll find Lisp much easier and more
> intuitive.
>

I've actually just bought the Prag Prog  book for Clojure :)


> has_many :comments, :through => :posts
>

Yes, this is more readable, and not especially complex. I am not opposed 
to
all exceptional situations, but we do have quite a few as is, and I'd 
prefer
not to superfluously add more, just because we can.

On Thursday 17 December 2009 01:11:18 am Josh Cheek wrote:
> > If you really think that, I think you'll find Lisp much easier and more
> > intuitive.
> 
> I've actually just bought the Prag Prog  book for Clojure :)

And I finished the Gigamonkeys book on Common Lisp:

http://gigamonkeys.com/book

Actually, syntax wasn't my problem with Lisp -- macros make it even 
better,
and if I really had a problem, it'd be trivial to write an indentation-
sensitive language that compiled to s-expressions.

While Ruby just looks better, my biggest problem with Lisp was that 
Common
Lisp, at least, has accumulated decades of cruft. It wasn't the syntax, 
it was
naming conventions for the functions -- things I find in Ruby, like
String#chop vs String#chop!, don't always seem to exist. Plus, too many 
things
seem to be named at an uneasy balance between wanting names to be short 
enough
to type (I'm guessing from the days of teletypes and such), and wanting 
them
to not be "hieroglyphs" (generally preferring something like "add" to +,
though that's a bad idea since + exists.)

Maybe I should look at Clojure, though...

> > has_many :comments, :through => :posts
> 
> Yes, this is more readable, and not especially complex. I am not opposed to
> all exceptional situations, but we do have quite a few as is, and I'd
>  prefer not to superfluously add more, just because we can.

In this case, it's not "just because we can", but because I think it 
would
look noticeably better. In particular, Ruby's greatest strength is good-
looking DSLs. However, Haml looks better to me than any Ruby-based 
builder
DSL, and the biggest reason is all those 'end' statements.

It just bothers me that, as a Rubyist, I would prefer a DSL targeted at 
Ruby,
but which isn't actually Ruby syntax.

But based on the response so far, it doesn't look like enough people (at 
least
on ruby-talk) care enough about this. I suspect most of them are still 
too
fatigued from the "beating a dead horse" thread.

> In this case, it's not "just because we can", but because I think it would
> look noticeably better. In particular, Ruby's greatest strength is good-
> looking DSLs. However, Haml looks better to me than any Ruby-based builder
> DSL, and the biggest reason is all those 'end' statements.
>
>
I agree about Haml, so I suppose  my answer to the poll must be that 
white
space should always count, or never count, but not that it should 
sometimes
count. (I know the question was whether I would use it, but I'm saying 
that
I shouldn't have a choice, I would rather the language does or doesn't 
not
implement it, without the ability to choose).

On Thu, Dec 17, 2009 at 11:11 AM, Josh Cheek <josh.cheek@gmail.com> 
wrote:

> I agree about Haml, so I suppose  my answer to the poll must be that white
> space should always count, or never count, but not that it should sometimes
> count. (I know the question was whether I would use it, but I'm saying that
> I shouldn't have a choice, I would rather the language does or doesn't not
> implement it, without the ability to choose).
>

I guess I'm on the completely opposite side of the fence: I find the way
Python enforces indentation rather rigid and hacky.  To handle the sorts 
of
cases Haskell's optional indentation handles quite elegantly, Python has 
to
employ things like implicit line joining.

Furthermore, since Ruby is already a mature language, requiring 
mandatory
indentation is extremely impractical.  Indentation sensitivity in Ruby 
must
allow you to retrofit it into existing codebases.