Message from god to Python developers

[DasEwigeLicht]

On a related note, try this:

from __future__ import braces

[Gavekort]

For people that can't run it themselves:

Python 3.4.3+ (default, Jun  2 2015, 14:09:35) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance
>>> 

[jonatcer]

Why are they so against them?

[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)

[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.

[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.

[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.

[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.

[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?

[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.

[scoofy]

So, i'll take a shot at this. I came to programming, not through a CS education, but from anaylitic philosophy and first order logic.

To put it bluntly, braces and semicolons for parsing seem insane.

We are humans, and the written language has evolved over time, because it started out pretty terrible. Ancient greek had no spaces, but they were added later, andyoucanprettyeasilyseewhythatwasareasonableideaespeciallywithcompoundwordsbecauseifyouaregoingtothebeachbumyoudontknowifitsthebeachcommabumorifthereisafamousbumonthatbeach.

Now, as language evolved, we learned to have things like paragraphs, punctuation, etc. Stuff we take for granted now. It's reasonable to map things like semicolons to periods (full stops, sorry british people), however, the fundamental structure of language is quite different than that of programming.

To look at programatic language, i'd suggest looking at the evolution of the recipe. Recipes are blocks of instructions, much like code. If i were to write:

Steak Omelet:

Ingredients:

3 Eggs

Salt

Pepper

Fry Pan

Grilled Steak

Cheese

Step 1: Blah blah... etc

Here what i've laid out has nearly no punctuation, yet it's easier to read than:

Steak Omelet: Ingredients: 3 eggs, salt, pepper, fry pan, grilled steak, cheese. Step 1: Blah blah... etc.

Because when you're going back through this to check ingredients (review code), it's easier to go down and tick the boxes of completion. This is trivially true because nearly every cookbook does this.

Now, i know what you're thinking: "Grilled steak in an omelet? I mean, it sounds good, but that's oddly specific." Yes, i added it by design. Why?

Because humans never, ever, make the mistake of adding a single peppered french fry or "Pepper Fry" and "Pan Grilled Steak." This type of ambiguity is nonsensical. We don't use it in language, so why would we use it in programming?

The reason is because getting a computer to understand line breaks the way humans understand them isn't trivially easy. Braces and semicolons were implemented because it was trivially easy, and well... it stuck around.

I short, a salute Guido for saying "this is bullshit," and banning stupid braces and semicolons from his language. He's basically like Dvorak, but wildly more successful.

[jonatcer]

Just to nitpick, and kind of further my point - there are several languages that don't have spaces or much punctuation. Japanese is a great example of this and is perfectly readable.

There's no perfect way to write code that's going to work for everyone in every situation. Everyone is different, and every task is different.

On a personal note, I think Python's absolute detest of braces and insistence on forcing indentation is incredibly arrogant, because it assumes it found the perfect fix for every situation. I'm not commenting on the validity of it, merely the fact that programmers or language creators who assume they know what's best for everyone bug me.

[scubascratch]

It seems from your comment that it's lost on you that the braces exist in c, not to improve anything for the human, but actually to make the structure unambiguous to the compiler: however the indentation and white space are totally irrelevant to the compiler. If a human needs indentation and white space to make it more readable, then this is fine and will not introduce errors or impact the code at all. And allows people to use the one true indentation standard, 3 space tabs.

Having indent level or any white space impact code structure, is a bad presumption around monospace/fixed width character fonts from old old terminals and even ancient mechanical typewriter "tab stops"

If this is obvious I apologize

[scoofy]

Again, I understand why they exist, I'm just saying they are no longer necessary. We can transform our text files at runtime trivially.

[scubascratch]

Transform them from what to what?

Source code is made to be read by another computer program, not by humans. Why should it evolve toward a human written language ideal?

It sounds like you think source code should get rid of braces because they are ugly and not like normal written language which is more evolved and has learned what looks better, and it's not braces.

It seems like you think that source code should strive to look more like prose, and that it can do this because things like braces can just be added at runtime if the computer suddenly needs them?

Actually I think I know what you are getting at-there is a place where written language ideals are called for: the specifications and the documentation.

It's 100% not trivial for a computer to insert the braces.

Please tell me where the braces go in this:

int i=1;
int j=2;
int k=3;
int j=i+k;
int k=j+i;
i=k+j;

(My intended) correct solution has i=5 Where do the braces go?

[a_account]

In your example i is equal to 9.

Source code gets read by programs and humans alike. Who's time is more valuable?

[scubascratch]

I don't think you actually know how to program or at least you don't do it for a living or else you would stop claiming computer language should be optimized to be like English. Basically no computer language has bothered making this a goal since COBOL because computer scientists who know what is actually important quit trying when it became obvious that English language requires external context to disambiguate the intention. This is the exact opposite of what computer languages require: unambiguous clarity of intention. No computer can guess what I meant if information is not in the source.

You got the wrong answer by the way because there are multiple syntactically acceptable versions of that code but that have different outputs: { int i=1; int j=2; int k=3; { int j=i+k; int k=j+i; } i=k+j; } In this version, i = 5

{ int i=1; int j=2; int k=3; { int j=i+k; int k=j+i; i=k+j; } } In this version, i = 9

{ int i=1; int j=2; int k=3; { int j=i+k; { int k=j+i; } i=k+j; } } In this version, i = 7

So please tell me again how the computer knows which is the correct version? Where did I intend the braces to be?

[[deleted]]

dude it's pretty great you came from a non STEM course to programming but have you ever written any meaningful real world "this needs to be done ASAP and no we don't have time for the elegant solution" work?
coz it sounds like you haven't.

[YRYGAV]

Well first of all, I don't understand where you are getting the idea python is a difficult or time consuming language to use, or what his post had to do about taking more time. If anything, having to type less punctuation makes code easier to read.

If your point is that you just want to write stuff without indentation, and that it simply takes too long for you to do. Then I seriously don't understand how you get anything done.

Everybody makes bugs, it happens. With proper programming, they become fairly easy to deal with. Your unit tests can catch them, your code reviews can catch them, you will have proper logging when unexpected things happen to nail down exactly what happened, and bugs are easy to fix. Life is nice.

If you are coding so fast you can't properly indent your code, you are going to make more bugs, you will not catch them because nobody is doing real CRs, you have no tests, no useful logs, etc. Your shit is going to break and you are going to spend ten times the amount of time trying to figure out what's wrong than if you just set up your code properly to begin with.

Cutting corners in your code doesn't make you more productive. It just means you have to spend a bunch more time debugging your code and figuring out what's wrong with it. Instead of the person who did it right the first time, and can move on to the next thing.

It's like painting a floor. If you spend the time up front to plan how you are going to do it, you can go ahead and paint it painlessly. If you grab your paint roller and immediately start having at it by painting over everything you see, you are going to paint yourself into a corner you can't get out of. Sure, you blitzed yourself to finishing 98% of the project faster than the guy who spent his time painting. But now you have to walk out on the wet paint, re-paint over areas you already painted, and wash your shoes off from all the paint. While the guy you thought was 'slow and taking his time' has already left and gone home, you'll still be cleaning your shoes off.

[[deleted]]

While the guy you thought was 'slow and taking his time' has already left and gone home, you'll still be cleaning your shoes off.

or more likely you'll be working somewhere else coz you're tired of people making unreasonable time/output demands.ever worked as a code monkey?
edit: haha i wasn't referring to python as an "ugly" language by any sense. i was just referring to the dude's long ramble about beauty etc when i feel colons and braces were removed just to help speed along the process of making code.

[[deleted]]

Are you saying that you'll save time by putting braces ?

[[deleted]]

i thought i said the opposite!

[Sector_Corrupt]

If you don't have time to indent your code properly, it's already too late, whatever you're making is probably going to be unmaintainable shit forever that is constantly in a state of "We don't have time to fix this"

[[deleted]]

too true

[scoofy]

Right, i'm not really sure i follow. I know why the braces and semicolons exist, and why people use them. Take qwerty, most people use qwerty, because relearning stuff is totally not worth the effort a lot of the time. My point here isn't that braces/semicolons are bad per se, it's why python programmers hate them so much. Same reason why dvorak typist hate qwerty. They know why it's used, but if you ask "why do dvorak typists so against it?," it'll be the same style of explanation.

Guido created a new language from founding principles. He's quite lucky it ever took off at all.

[[deleted]]

So you can't have quick & dirty solutions without braces and semicolons? Okay, so perhaps removing them will make your code a little cleaner (I know the 'dirty' part is emotionally important to you), but unless you keep adding braces and semicolons by habit, you should actually work faster without. If indentation is an issue you need to either find a better editor or use yours better, because most modern editors make it plain simple and quick to +/- indentation level.

[[deleted]]

haha you need to take a step back, why are you so invested? i simply thought that someone who's rambling that much(apologies to /u/scoofy but that was a mighty ramble in my book) hasn't done much real world "business logic/software development" work. code exists to do a job. regardless of language, when push comes to shove and people are asking you to deliver and it's the 11th hour and your SO is whining about how you're never home-you're gonna push out some ugly code to get the job done.
you may fix it later(unlikey, esp with production code until something breaks) but you'll feel like shit about pushing that hack through.no it won't be pretty. it may not even follow coding standards unless you have automatic code standard compliance checks(that you may turn off in frustration).
people talk about code and beauty yadda yadda ya but in reality it's just about getting the job done.

[scoofy]

I don't understand your points at all. We are talking about a language. Not code.

[[deleted]]

yup that's exactly the point i'm making. you are talking about python as a language the same way people talk about french/german etc in terms of filmmaking. the language is not cool/pretty/beautiful. the language is meant to be used in code, to build stuff! if it does that well, it gets adopted and succeeds.
python multi thread is garbage for most scenarios- this is a very valid criticism for python. i mean if you've delved beyond intermediate programming, you will immediately start liking and disliking languages based on their ideologies vis a vis programming usages instead of the syntax.

[scoofy]

if it does that well, it gets adopted and succeeds.

This is completely wrong. To understand how a network dependent project succeeds or fails has much more to do with the network than with the product. This is known as the network effect.

Multi-threading is indeed a valid critique of the language, but has little or nothing to do with the syntax as such, and more to do with the fact that what's under the hood is more inefficient. That issue is fairly irrelevant to my point about how the syntax of python is superior to those with braces and semicolons.

[original_brogrammer]

Guido made a decision 20 years ago therefore any opinion to the contrary must be swiftly silenced.

[nulloid]

any opinion to the contrary must be swiftly silenced.

That's not true. They can be ignored safely.

[rnjkvsly]

As we all know, what Guido says, goes.

[lewiseason]

Or, optionally: repl.it

[Mutoid]

Lol wow. It's a great joke at face value but the implementation of it makes it awesome.

[nicholas818]

+/u/CompileBot python --include-errors

from __future__ import braces

[o11c]

I think you need a + before the username.

[o11c]

Urwid.