Re: Pythonic indentation (or: beating a dead horse)

"Roger Pack" <[e-mail]> schrieb im Newsbeitrag 
news:[e-mail]...
> @Michael:
> I don't think having "either or" syntax would be such a terrible thing
> in terms of team re-use or resources--you should be able to convert the
> code back and forth at will (a la ruby2ruby, parsetree [rubylexer has a
> parsetree compatibility mode] etc.)

Uuups, that's me.
(BTW: What a discussion, about 2 vs. 20 ... that's really asymmetric 
warfare...)

Yes, for sure it would be possible to convert sources back and forth and up 
and down.
Maybe someone would create the perfect converter.
Given there are people prefer PyI or not, maybe others loving brackets the C 
way or the Lisp way, or hating them, some would prefer do..end some would 
like curly brackets...
Going to the end: Convert Ruby code to P-Code which could be converted to 
F77... ;)
(If some scripts are not located on read-only media...)

But, put joking aside, for much more sure, it would definitely increase 
(IMHO) the probability of errors much more effective than other variations 
which are already possible.

My work since some year is to decrease probability of errors - I'm creating 
testing tools, environments and scripts, performing integrations tests and 
so on.

People tend to make mistakes. So, extending possibilities for doing so is 
baaaad.
Scripts are always changed, and nearly nobody really cares about indendation 
or formatting when scripts look like:

    # Increase train speed to v_mode1
     @train.increaseSpeed 30

     # Pass signal 'sig1'
    @train.expectPosition 'sig1',5
...
    Did you really notice the different spaces? Try a proportional font.
...
or are created by some foreign language test case generation tools.

I don't like unnecessary syntax elements for scripting languages, because 
they spoil the view for the real problems. So I like Ruby's ability to avoid 
brackets, semicolons and so on.
Some people like brackets.
I like using "unless" instead of "if !" because it's more readable, you 
don't need shift-key.
These possibility of variations did never brought problems into work.
It allows concentrate the attention of people to the real scenarios and 
problems.

But, "end" brings much more safety, it is also a "social" thing - its like 
finally writing "done."
I think, avoid scrolling is a very minor argument. Who needs to scroll so 
much?
Would "J" encourage people to avoid comments and empty lines to avoid 50% of 
scrolling?
(Would "Monk" like "end"?)

I would not like to waste resources of highly specialized people by teaching 
them the last corners of Ruby - it's a scripting language at last. And it's 
wonderful as such.
So I would never try to force them to distinguish between spaces, tabs and 
other whitespaces.
(They would try - these are tolerant people too...)

(Ohh .. sorry ... I wasted _my_ resources. Only 3 hours to sleep. Going to 
sleep now...)

Hope you got my point...

Regards,
Michael B.