In languages where white space is insignificant, it is pretty much universal that we use syntactic elements to communicate block structure to the compiler, and white space to communicate block structure to humans. Having two different ways of communicating block structure is: a) redundant and wasteful, and b) a source of bugs.

So, if you buy into the idea that having two different ways of communicating block structure is somewhere between an annoyance and a language design defect, and also buy into the idea that computers should serve the needs of humans, then it follows that the compiler should extract block structure from source the same way that humans do. That being: significant white space.

The {} languages seem very primitive to me any more.

{} languages have the advantage of allowing you an immediate restyling of the code when the original author (who can be of varying skill level) wrote something you don't like looking at, or when you want to change the style of your own code for various reasons.

I find that Python-style blocks generally cause me more mild annoyances than {} blocks. A frequent thing that happens is copy-pasting/moving a line from some place to another with a different depth: In C, I paste and run my automatic indentation, while in python I have to specify manually by how much I want to indent my new code so that it can know within which block I want it. ... And it's not like you could do so automatically: if I want to paste something after the code of an "if ...:" block, the editor cannot know if I want it inside or outside the block.

On a more abstract level, I personally prefer a language where the end of a block is explicitly specified by the presence of a visible character rather than by the absence of an (arguably) invisible one, and where the form of the code does not affect its function in any way...

I'm not trying to argue that much against the python logic though, because the potential for disastrous style is indeed limited, it has its specific advantages, but I don't think delimiter-based languages can be qualified as more primitive just because of this.

And, yes, it is hard to argue that presence of {} makes a language objectively more primitive, which is why I used the word "feel"... the syntactic sugar necessary to keep the block structure straight just looks like noise to me any more. But as with many things, it comes down to personal preferences.

My code has whitespace that reasonably closely matches Python's rules regardless of the language. I only say "reasonably closely" because I don't spend enough time in Python to really be sure about any potential gotchas.

But like PEP 20 says:

> Explicit is better than implicit.

Brackets are explicit. Whitespace is implicit.

And the end of a block, the lack of indentation that denotes that, is absolutely implicit.

Personally I prefer {} blocks so I don't have to know what sort of white space is creating the indentation, even though I do miss using python sometimes and may come back to it for the right project.

This is trivially solved. You can find and replace with sed[0] if you want to be fancy, or just use your favorite text editor/IDE. The teams I've worked on have never had a problem with this. There is always an established convention in a project, and if you're breaking the convention -- e.g. because you prefer tabs -- you're doing it wrong, just by virtue of breaking the convention. If your project is new and you need to set a convention, do that. (also, PEP8 recommends spaces, so there is an authority to reference as a tie-breaker)

[0]: something like: find ./ -type f -exec sed -i -e 's/ / . /g' {} \;

While you're at it, please also s/\s+$//g on save. Those unintentional trailing spaces really clutter up Git history, and that comprehensive, clean history is what enables the team leads to do their job without bugging you on Slack. It also signals carelessness, or at least a lack of care for personal tools, and has your name attached to it.

I just tried with three different editors, and literally could not manage to get code in a file indented with a mix of tabs and spaces despite actively attempting to. Who are your co-workers who actually personally have had this happen to them in, say, this decade (not nebulous stories from the internet of "I heard once about this"), and how did they do it?

Though I do know in Visual Studio (what I do my day to day coding in these days) I've had situations at work where tabs and spaces got mixed together and at some point it finally started complaining but not right away.

   sub (@) { return map { "@{[ $_[0] . $_ ]}" } @$_ };

Sadly, you can write code just like that in Python. I don't know what that perl snippet does, my caches have long since flushed ;) -- but here's a Python snippet that's relatively dense:

   def foo(y): return lambda x: {str(i) : '_{}'.format(i**y) for i in range(x)}

Was just reviewing colleague's code with them the other day. Hit some blocks like this (not quite as offensive, but tackling a bit in one line), and hell if they knew what was going on in their own code.

Not because I want to write everything on one line, but because it's an extra step when trying to understand what code does.

For instance, a piece of code is misbehaving, not being called as part of the block it visually appears part of. In a bracket/paren language I can highlight one bracket and my editor shows which one matches. In Python I have to figure out what the indentation is built from, spaces or tabs, and make sure there's no ambiguity there.

We have developers here that are claiming they wrote things in Python for their PHD, and yet when I look at their code in any language there are tabs and spaces mixed in the same line, with inconsistent indentation. Multiple people have tried to express the issue or teach ways to deal with it, to no avail.

The fact of the matter is that whitespace is by definition invisible, and that makes it hard for people to grasp its importance. Basing control flow on invisible characters is asking for trouble.

To quote PEP 20:

> Explicit is better than implicit.

Brackets are explicit, whitespace is implicit. You only can see whitespace by the gaps between visible characters, and then you have to guess. Is it an actual U+0020 like you see 99% of the time? Is it an nbsp? It it a tab that happens to stop after the width of a space? You don't know until you encounter an error or turn on whitespace rendering.

Was it copied and pasted from www.python-help-7575.com, which uses a platform that favors punctuation spaces? Was it copied from a site that didn't wrap their code in <code> or <pre>? (I see this all the time in comment systems on programming blogs) Should we claim that copying and pasting code in a beginner targeted language is something you do at your own risk?

The following program throws a TabError in Python 3:

  def demo():
  	print("1 tab")
          print("8 spaces")

EDIT: So Hacker News has code blocks, but doesn't strip the indentation that is required to introduce them. So you'll have to lead the 2 leading spaces in each line if you want to try this out for yourself.

Your example is good, but the technical issues experienced in posting your example are perfect.

That function is easy to parse if you take 20 min learning the syntax. Object oriented monstrosities aren't.

    sub

    (@)

Prototypes are mostly for giving hints to the compiler on how to unambiguously parse calls to your function later. For an anonymous sub, it's pointless because you assign its value to a variable, and then brackets are required when calling it.

    return

    map

    { "@{[ <some stuff> ]}" }

The @{} dereferences the contents of the braces as an array, and [] creates a new arrayref. The arrayref has one element, and perl's default stringification of an array (join them all with no separator) means that it… iterpolates the thing inside the @{[]} into the surrounding string.

This is pointless though, since it's the only thing in the string. The author might have been trying to give a string context to force stringification of the thing, but the dot operator already provides that context.

    $_[0] . $_

    @$_

I would have written this as:

    my $prefixer = sub { my($prefix , @rest) = @_; return map { $prefix.$_ } @_ };

    say $prefixer->('Hi_', 1, 'str', 7);
    > 'Hi_Hi_Hi_1Hi_strHi_7'

    sub { $_[0].join($_[0], @_) }

    lambda *lst: ''.join([str(lst[0]), str(lst[0]).join([str(_) for _ in lst])])

    {,/(*t),/:t:$x}

    lambda *lst: ''.join(['{}{}'.format(lst[0], _) for _ in lst])

(I guess the original code did something useful and looked very similar to this.)

It might just be the code base I'm working with..

But then they have to go and ruin it by making single letter variables a common thing.