The problem isn't whitespace period, its that if you aren't careful the significant whitespace can bite you, for example people sometimes accidentally mix tabs and spaces, which can get... ugly.

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.

Why is that?

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.

Good point, I use that feature in C++ quite a bit. But I find that my Python programs tend to use smaller blocks, I don't know if it's just because I'm solving smaller problems or because it's easier to break things down in Python.

You could argue, using the same logic, that when using {} languages, the computer can serve you by automatically doing the indentation anyway. This is the case in practice: I never have to worry about indenting my code in C, as support for that in most editors is great.

{} 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.

I find that the amount of bugs I tend to get when I copy-paste code far outweighs any potential aesthetic pleasure I get from seeing no begin-end block identifiers. Also, I don't want to let python have credit for not having those block identifiers because python has the colon begin identifier, which is completely redundant.

That's absolutely true of any programming.

It's syntactically correct, but pretty much nonsensical.

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

So let's break it down:

    sub

It's an anonymous sub

    (@)

It has a prototype that says it accepts a list of arguments (this is the default in perl though).

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

It returns the result of the map (this default in perl is to return the result of the last expression & everything is an expression though)

    map

same as python map(code, list)

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

This is a particular perl goof for interpolating array lookups into a string. Usually, perl's sigils let variables be interpolated without any issue, but since we're using $_[0] to use the first element of the @_ array, it's ambiguous with $_ . '[0]'.

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] . $_

This is a string of the first element of … hmm. Not of the currently-mapped element (that's $_). $_[0] refers to the first element of @_. This makes a new value which is the concatenation of the first element with the current element.

    @$_

This is a short way of writing @{ $_ }: dereference the arrayref that's stored in $_. But $_ is not set anywhere, so I assume this is a typo of @_

I would have written this as:

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

And it would work like this:

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

The 'best' way to write it would have been:

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

> In Python I have to figure out what the indentation is built from, spaces or tabs, and make sure there's no ambiguity there.

The following program throws a TabError in Python 3:

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

It does work in Python 2, but I'm pretty sure the majority of developers have 4 space wide tabs by now, meaning they won't be able to mix tabs and spaces in Python 2 code either.

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.

If you aren't ideologically opposed to the use of an IDE then PyCharm solves this for the vast majority of cases. I get ~90% of the editor functionality I'd get in a statically typed language in PyCharm. Automated refactors and all that jazz...