The problem, as with all such systems, is that you are now looking
at something the compiler does not. That's the main reason why salient
structure systems such as python's measurably reduce programmer errors:
if you use them you are perforce seeing what the compiler sees, no more,
no less.
Remember the old adage: "Don't get suckered in by comments; read
the code"
-- Markus
P.S. Again, for the record, I am NOT advocating salience for ruby.
···
On Fri, 2004-10-08 at 12:13, Charles Hixson wrote:
markus@reality.com wrote:
> *laugh* I supose the reason I like the abomination is I learned to
>indent back in the days of salient structure (before the matching-pairs
>abomination took over the world). To me (and by extension, all right
>thinking people), python's indentation seems perfectly natural. I suppose
>it's all a matter of what abomination you grew up with.
> That said, it really doesn't hurt as bad as you'd think it would,
>since the main thing people differ on is where to put the closing token
>(e.g., does the "end" or "}" go at the indentation of the enclosed block
>or the inclosing block) and that issue vanishes if you don't have closing
>tokens. I suspect that (if warned) most rubiests would find:
>
> class My_class
> attr_reader :an_atribute
> def initialize a1,a2
> @an_attribute = a1
> @counter = 0
> @limit = a2
> def feed_the_lion food
> raise "Roar" unless food.respond_to? :digestible_by
> raise "Grrr" unless food.digestible_by self
> digest food
>
> waffle = My_class.new :fred,14
>
>perfectly readable (and writable) without all the syntactic clutter/noise.
>Required when you _don't_ pay attention to white space. Further, it's
>well established that when there is discord between them people
>(including long time lispers) will "read the indentation" and ignore the
>punctuation regardless, so it reduces a significant source of bugs to
>have the language look at the same features of the source code as the
>person did. About the only measured downside (IIRC) is that it increases
>the error rate when people are typing in code from a printed source. That
>doesn't happen nearly as much as it used to.
>
> BTW, I am _not_ trying to push this change; I'm just trying to
>explain why I would not object to it, and suspect that many others would
>find it more palatable than they might think.
For that sample, you are correct, but when blocks get a bit more complex
it fails. Miserably in my opinion. Even when programming in Python I
typically add an end statement, e.g.class My_class:
def __init__(self, a1,a2):
self.an_attribute = a1
self.counter = 0
self.limit = a2
#end __init__def feed_the_lion(self, food):
raise "Roar" unless food.respond_to? :digestible_by
raise "Grrr" unless food.digestible_by self
digest food
#end feed_the_lion
#end class My_class
waffle = My_class.new :fred,14Note this is an incomplete conversion. Also note that I don't just use
end statements, I label them. (Also note that I couldn't decide whether
or not waffle was a member of My_class just by looking at it. It
required noticing that it was an instantiation of the class. (Which I
couldn't remember how to do in Python.)I guess that I got my block conventions from Ada. (Fortran was
rather....vague about them, except for not before column 6 and not after
column 72.)My personal convention about when to use {} and when to use do..end is:
If it's within a single line, use {}. Otherwise tend to prefer do..end
This isn't a strong convention, but I try to not depend on relative
binding power (partially because I can never remember the exact
precedence order).
Are you still ticked off after your system crash?