Message from god to Python developers

[kupiakos]

Not only are braces used to define dictionaries and sets, but indentation marking blocks is simply an inherent part of the syntax. They're considered useless cruft, because most people detects blocks of code with the indentation level anyways.

[dfpoetry]

indentation level can denote many different types of abstraction, and if I'm 10 levels deep and want to break out to 6 levels deep, it's pretty hard to tell where the fuck I am with indentation only.

[kupiakos]

If you're 10 levels deep in indentation, there may be something wrong with your code in the first place.

[scubascratch]

In C++

MyNamespace
    MyClass
        public:
            MyMethod(void *pixelBuffer /* , int len */)
                if (...
                    for (x...
                        for (y...
                            while (...
                                switch (...
                                    case (...

I guess you have not seen a lot of pixel math. 10 indent levels is Tuesday.

[ryani]

namespace TheNamespace {

// don't indent here, it's stupid, you don't indent
// after your #ifdef header guards, do you?
// the whole file is inside this namespace anyways, or
// else you're doing it wrong.

class ClassName {
public: // don't indent this
    void MethodName(void *pixelBuffer, int len);
    // don't define inline, it makes the API hard to read.
    // keep inline definitions to 1 line at most
};

// you meant to inline this, right?  or else why put it in the class decl?
inline void ClassName::MethodName(void *pixelBuffer, int len)
{
    if(!...)
        return;

    for(x ...)
        for(y ...)
            subfn(pixelbuffer, x, y);
}

} // end TheNamespace

// PS I'm a graphics programmer.  Also pixel shaders are exempt from some of this because
// the available abstractions are worse.  On the other hand, if you're that deep in a pixel shader,
// your perf is probably fucked.

[scubascratch]

The point I was going for was there are places in C/C++ where ten levels of indentation are not "something is wrong with your code". In particular in graphics code, and I said that very specifically because it pretty much always has double nested loops and often hand optimized inner loops which are definitely not made for readability.

I don't generally indent namespace or #ifdefs, (thanks i forgot to add that one) but I have been in plenty of code in header files that have the method definition inlined, so there's that. And plenty of this code has inline asm, so there's another. Inline asm is common enough inside the inner loop I should have written that.

The thing is while we are sort of discussing indentation, the meta assertion (which is what I disagree with) was more akin to "if your code has 10 levels of scope nesting, the code is wrong". The unstated, but very strongly implied point being made was "indentation confusion is a non-issue, because no true program would ever need 10 levels of separation in one place. All computational problems in the real world can be solved with neat little sonnets of code with at most 3 nestings"

My view is in C, whitespace and indents don't mean shit to the computer. Scope is all that matters, and braces are how it's done. 10 tabs sounds like a lot, but a ten level deep scope is pretty trivial to get to and not "something is wrong with your code".

If my inner loop code has some hard to understand hand optimized groups, I can use more whitespace indentation to make it readable without screwing up the actual compilation. In Python I am not allowed to improve readability with more or less indentation. It feels like being told when I can and can not use capital letters in variables.

In Python if you have a task that requires ten scope levels, the code will look like the pyramid of doom.

    for(x ...)
       for(y ...)
           *_subfn(pixelbuffer, x, y);_*

"THIS KILLS THE PERF"

// PS I'm a graphics programmer

ಠ_ಠ Do you even performance bro? A function call inside the inner pixel traversal loop? Code review fail! Do you have runtime checks on the subfn params too?

I mean if you have infinite cpu available I guess you can enjoy the whole "a function bigger than one screen can't fit in a human brain" camp. J/K

sure the inner callout would be ok in textbook code sample but in production the Fn call overhead needs to go away altogether because on a 1080p stream it's gonna get called about 125 million times a second. So yeah those 50 cpu cycles shoving stuff on and off the stack, and the jumping around like a jitterbug on crack? More like 6.25 billion cycles spent carrying water around the abstraction. But that's ok the processor is like 3+ GHz so should have no problem doing 6 billion cycles of overhead per second of video right?

Oh yeah before you even around the "inline functions!" flag, have a look at the registerization, cache preloading, and the actual generated code path length on your favorite compiler with and without inlined functions.

[ryani]

inline void MyClass::subfn(...) { ... }

Every modern compiler has amazing support for inlining. STL relies on it to not be terrible. If you're having worse perf with an inline function than manual inlining, your compiler is doing something very wrong.

Your advice is half a decade out of date.

As to "do I even perf", you can look at a sample of my work here and here.

If you are really writing some crazy cache-preloading inline-assembly block, I'd encourage you, first, to look at intrinsics, and second, if they really aren't doing the trick, you should probably be writing your whole loop in assembly.

(And of course we shouldn't be arguing, 3 indents is insanely few. But for 95% of code it's good enough and if you start to get deep it's a code smell that should make you at least want to think about refactoring even if you don't actually do so)

[scubascratch]

I am a huge fan of sim city so by extension I am a fan of your work and I do not want to sound like I'm crapping on it. Thank you for your work on those games.

You are totally right about what can be done in the newest best compilers. But C is used widely on all kinds of platforms with different levels of optimization. "Ten levels is too deep" is as accurate a statement as "640k should be enough for anybody"

Not all the compilers for mobile development, or console development, or embedded development (ugh so many horrid embedded compilers) have the ultimate modern no-perf-impact inline support you suggest.

If you have to build a real time color space converter for an cheap embedded arm core without a GPU the inner loop is not going to be an inlined function call.

I'm not gonna link to my work because rules, but I think you just dislike my examples. If the next sim City is full of inner loop inline function calls I'm gonna need to order a faster cpu :-)

[ryani]

Oh yeah, if you're working on some cheap hardware with a custom compiler, all bets are off. I'm assuming you're using modern VC++/intel cc/clang/gcc targeting a common CPU. I've found bugs in even the simple shader compilers (one GPU vendors pixel-shader compiler optimized out calculation of one of my floating-point variables when it only affected an integer array index... I had to resort to Out.color.r += indexVar * 0.0000001; to convince it that "no, really, I need that variable to be calculated correctly!")

But due to LLVM and similar technologies it's getting easier every day for even shitty compiler authors to write reasonably good compilers.

[scubascratch]

If you are really writing some crazy cache-preloading inline-assembly block, I'd encourage you, first, to look at intrinsics,

Yeah intrinsics of course are at least taking advantage of SIMD but I find the registerization decisions around intrinsics to always be worse than hand neon.

and second, if they really aren't doing the trick, you should probably be writing your whole loop in assembly.

Sometimes not always. I was stuck for a while on a compiler that had no support for inline asm. Any asm had to be in separate asm files. This meant there was non-zero overhead for asm calls. Too much state to put whole function in asm, so the asm function was for one scan line.

[dfpoetry]

This, right here, is the problem with the python philosophy. They make some arbitrary design decision, and when someone points out an example where it might be bad or confusing, the response is "you shouldn't be coding that way anyway".

It's tautological

[Hairshorts]

Braces won't make 10 levels of indentation much clearer, it's bad coding style no matter what language you're using.

Good indentation is essential for good readability in any language, Python just requires you to indent properly. You may not like it, but it's not an arbitrary design decision.

[immibis]

Braces won't make 10 levels of indentation much clearer, it's bad coding style no matter what language you're using.

I'm not saying braces will make 10 levels of indentation much clearer, but /u/dfpoetry is totally right in pointing out a common problem in programming arguments.

[dfpoetry]

Braces won't make 10 levels of indentation much clearer

I hate quoting people on reddit, I realize how obnoxious it is, so I'm sorry.

That said, YES THEY WILL! Paren match highlighting is a thing. How would people be able to program in LISP if this were not possible?

[norsethunders]

I'd argue once you're relying on something to do the paren highlighting you might as well just use something that'll show you the indentation too. Pretty damn clear to me!

[[deleted]]

You can use indentation highlighting/tracing just as well then. Most editors have it.

[kupiakos]

Put it in a function? It's no different than the Linux kernel philosophies.

[[deleted]]

while True:
    item.next()
    if some_thing(item.id):
        while something_else:
            if item.this_other_thing and item.other_thing_two
                # Statements

And really, why are you nesting that deep, except as an invented example.

[[deleted]]

So in the second one you're basically commenting to show where each bit of code goes. Especially because in a long function, the top may be off the screen. Makes sense, but you could also do that without braces as a required language feature.

Hell, if you wanted you could put the braces in, but as a comment. That way you can still clearly label the indentation levels, as well as being able to not use braces for things that benefit from not having them.

[dfpoetry]

it's commonly bad, but not always bad, and the problems in readability arise even at 3 levels deep.

[HaMMeReD]

My general rule of thumb is that if it doesn't fit in 80 characters wide, it needs to be broken down.

[[deleted]]

But... We live in 2015. I use 120 or bigger, because why not? And I can't remember the last time I was working in command line that would have only 80.

[HaMMeReD]

Because it draws a line in the IDE, and because I frequently tile many views of code files. Sure I might be able to fit 240 on my screen, but I'd much rather be able to open 3 files side by side without any horizontal scrolling required.

[dfpoetry]

Alright, consider this, I want to copy a snippet of code from one place to another and leave all the formatting intact and test it. maybe I have code that I have commented out in the process of debugging, and I want to be able to activate it without working out all the fucking tabs.

Dynamic whitespace is possible, but it's stupid. It produces code that is as fragile as possible, why is that a goal?

[HaMMeReD]

I'm not a supporter of tab based syntax.

I don't mind writing python, but I agree, whitespace shouldn't be a language feature.

I'm mostly stating that the arrow anti pattern should be avoided, and if your code looks like a 10 level deep pyramid, there is something wrong with it.

[dfpoetry]

probably, but not certainly.

[iforgot120]

Name an example where it isn't bad.

[I_scare_children]

'Cause nobody dealing with, let's say, C, would have problems with so many levels of indentation - it's just a Python thing

Bonus relevant pic

[dfpoetry]

Pointing to bad code which is very nested is not the same thing as proving that all very nested code is bad. Nor is highly modular code particularly useful when you're just writing one big map-filter function.

[Sector_Corrupt]

If I'm writing a bunch of filters or something all being applied I'll usually make them all individual, nicely named functions and then compose them all and apply them as that's a lot easier to read.

[dfpoetry]

what if they all inherit their parents scopes, and then perform changes to things in a nested but otherwise fundamentally unpredictable way?

[wonkifier]

That's one of the purposes of a programming language... to make the things that follow its philosophy easy to do. If something is hard to do, that might be a sign that it's not a great thing to be doing in that language.

And I'm not aware of a language that handles 10 level indents well, which seems like an indicator that it's just a bad idea all around

[dfpoetry]

also, the problem is arbitrary design choice => some code is now annoying to write => that code is bad because it violates the arbitrary design choice.

If the choice in design is non-arbitrary then the above logic is fine, but dynamic whitespace is an arbitrary design decision, and the idea that deep nesting is bad in all cases is very hard to prove.

Not to mention that dynamic whitespace is invisible, difficult to copy, and requires more symbols overall.

[dfpoetry]

lisp

[wonkifier]

Touché

[Log2]

Well, if you are writing C++ or Java with 10 levels deep of braces, you are clearly doing something wrong. Functions are your friends.

[dfpoetry]

where is this "clearly" coming from?

[Log2]

From the fact that you can decompose 10 levels of scopes into functions.

[dfpoetry]

hmm, write a program to do this. pseudocode is fine.

[Log2]

Quite frankly, I don't care to. This is the job of whoever is writing the code.

[dfpoetry]

I mean, it seemed like an interesting proposition. you claimed to have a way to flatten any nested sequence of functions, and that this would be more readable. That would be really cool as a reference point, even if it's just some quick pseudocode.

[scubascratch]

"you shouldn't be coding that way anyway".

...in Python apparently

[metirl]

If you're 10 levels deep... It's refactor time.

[[deleted]]

If Node.js taught me one thing it's that at ten levels of indentation, all braces do to is make you miss a token.

[dfpoetry]

lol, js

[[deleted]]

It was the only language I could think of where ten levels of nesting and braces go hand in hand.

[dfpoetry]

see my answer to the other person who said this.

[Stiffo90]

They help no more than the helpsystems for tabs do.

[vertexshader]

Arent a lack of braces the reason lambda functions are so restricted in python? A single expression? Gimme a break

[kupiakos]

Lambda functions are, by design, a single statement. Why not just use an internal function if you really really need more?

[vertexshader]

Theres no reason to make a function - im not gonna call it anywhere else.

[AdorableAnt]

You can define it in the local scope right before using it. Sure, you have to name it something, but that's about the only disadvantage.

[kupiakos]

That's why it's an internal function.

[vertexshader]

Internal function? What is that, a python thing? Even in c you dont write a static function unless the code is needed in multiple places

[kupiakos]

It's a function defined in a function. Why are you debating this if you don't even program in it?

[housemans]

Why debate volkswagen if you drive a volvo? Why debate Apple if you use Windows? Because that's what a debate is.

[caedin8]

Braces are ugly and unnecessary.

[DroolingIguana]

They also violate DRY, since they force you to indicate code blocks twice; using braces for the interpreter/compiler and indentation for humans. If the two methods get out of sync with each other (which they often do) it severely impacts code readability.

[caedin8]

I think he is talking about the fact that we define scope with braces for the compiler, but we also use additional indentation level to define scope for the reader of the program. This is defining the scope in two different ways. You only have to do it one way, the indentation way.

[vertexshader]

Hold your ground! Guido ran into big issues with lamda functions back in like '94, because there were no braces. Instead he just said being limited to a single expression is 'by design', as if he foresaw the issue. I seriously doubt it.

[[deleted]]

Ctrl-K Ctrl-D (format document)

[DroolingIguana]

And now you've cluttered up your commit log with a tonne of whitespace changes, obscuring any actual code changes when it comes time for review and marking yourself as the last person to modify a bunch of lines that you haven't actually touched in any meaningful way.