[SLL] enforced white space

[Derek Simkowiak]

    Chuck,
    Like you -- and pretty much everyone -- I, too, had the "you can't 
be serious" reaction when I was first subjected to Python's syntax 
rules.  Almost all of the languages I had worked with -- C, C++, Java, 
Javascript, Perl, PHP, Tcl, etc. -- used the curly-block notation.  
Facing something entirely new was a challenge.

    But having worked with Python for a few years now, I have to say, I 
absolutely love it.  I can (literally!) write working Python code as 
fast as I can write psuedocode, and it is by far the most maintainable 
language I've worked with.  I recently wrote 3000 lines of Python before 
running it even once to check syntax.  It took me roughly 15 minutes 
from the initial run it to having all my syntax errors eradicated (incl. 
typos, spelling errors, mismatched parens, etc.).  On another project, I 
converted 3000 lines of C code to just 300 lines of Python, and the 
Python version had new functionality that would have added several 
thousand lines in C.  And, contrary to your assumption, one does still 
have a lot of stylistic freedom with whitespace in Python. 

Chuck>/ Being objective is hard to do./


    I don't think being objective is hard at all.  Just use science.

    If you do a real project -- say, 300 lines or more, and maintain it 
for at least 1 month -- you'll get over the "ohmygod whitespace 
matters?!" hump.  If not, I'll buy you a beer.

--Derek


Chuck Wolber wrote:
> On Fri, 16 Jan 2009, nicafyl wrote:
>
>   
>> On Thu, Jan 15, 2009 at 8:03 PM, Chuck Wolber <chuckw at quantumlinux.com>wrote:
>>
>>     
>>> You mean parsing? Like with semi-colons and brackets etc? That's a 
>>> tokenizing issue, not a formatting issue.
>>>       
>> Does that matter? That is, when you are writing code, there are some
>> "rules".
>>     
>
> The rule is that your code has to be parseable so the parser can parse it. 
> Enforced formatting makes your code parseable *AND* it forces the 
> developer to write readable code. In my book, that's two things which is 
> one thing too many.
>
>
>   
>> If you are writing a compiler or interpreter, you are well aware of what you
>> must do to translate what is written into what is executed. You know what is
>> parsing, for example.
>>     
>
> That's what tokens are for. The parser looks for tokens and then does the 
> right thing. A parser does not, and should not (IMHO), care if your code 
> was readable to other human beings.
>
> If you want something that forces your code to be readable, then use a 
> tool to do that. Eclipse has a tool that I personally use to do just that. 
> As a group, we agree on a code formatting policy, generate a policy file 
> and then everyone loads that into their eclipse instance. Part of the 
> code-review step is making sure that the developer prettied up their code 
> based on the agreed upon policy.
>
>
>   
>> But, if you are "just writing code" you have no need to separate the 
>> rules into types. It is just "you gotta do X to end a block".
>>     
>
> Agreed. I am still of the opinion that reducing complexity is a good 
> thing. Making things do one thing and one thing only is a noble goal... 
> IMHO...
>
>
>   
>> I, for one, objected when I first started looking at Python. It just 
>> "didn't seem normal". But, having read a lot and even talked to Guido 
>> about it, it started seeming "ok". Now that I have written Python for 
>> years, it feels downright natural. But, more important, my experience 
>> has taught me that more often than not, if my program looks right it 
>> also works right.
>>     
>
> Anything can feel natural if you do it long enough. This is why people 
> kill each other over religion. Being objective is hard to do.
>
> I'll also point out that just because I said that, it does not imply that 
> you are wrong.
>
> This is a nuanced issue. Some people do not have the stomach for nuance, 
> so they get turned off by discussions like this, and walk away. As long as 
> things do not get personal, someone is going to learn something, and that 
> is a Good Thing(TM).
>
>
>   
>> After years of writing C and then having to find a misplaced brace that 
>> made things work not the way it looked like it should work, I have to 
>> agree with the "easier to follow" suggestion.
>>     
>
> I agree that code formatting is a good idea. I am thinking that the real 
> issue lies with who (or what) gets to decide how the code is formatted.
>
>
> ..Ch:W..
>
>
>