Thursday, December 19, 2013

Python: Yes, that indentation thing again

No, I'm not going to get over it.

These:   { }  

rock.

And Python clearly rocks, too--because if you accidentally hit tab a few times, or your cat dances on your keyboard, or you fall asleep and your forehead starts typing, why wouldn't you want to have to carefully read the code again to fix it, instead of just re-indenting the code automatically (possible in sane languages, because, surprise!  That's what explicit bracketing allows!)

Please don't suggest that it's always an awesome idea to re-understand code to fix indentation.  I'm porting some complicated compression code from C, and frankly, once it works, I don't want to have to understand it again if I paste it, or forehead it. Or whatever.

The "white space is significant" thing was tried in the past, and failed.  It's a stupid idea.  COBOL had an excuse, but we're not using punchcards anymore.

COBOL whitespace:  fail.

SNOBOL whitespace:  fail.

Python significant whitespace and no bracketing for code blocks:  huge fail, because it's 2013, not 1950.

It's an awesome language in terms of expressiveness, but the lack of bracketing is 100% fail. Fine, it's 90% fail.  That combined with slow and broken threading means it's a huge missed opportunity.

Will I write Python to contribute to projects that use it?  Of course.

Will I voluntarily use Python for other projects?  Maybe.  Not if I can help it.  OK, I'm not sure. Obviously I'm torn.  But are there really great alternatives?  Perl is a broken mess.  Ruby's threading needs help, too.    I love C and in some sense its my "native language", but can you really imagine writing a framework like Volatility in C?  

These:  { }

are awesome.

Proper threading:

is essential.  Modern hardware insists.  And we should listen.

And yes, I know about Whython.  But it's just a toy and it's really too late, right?  Because portability for security tools is essential.  

Maybe I just need a glass of wine.


No comments: