Because there are places where indentation signifying intention breaks down.

The classic example being the arbitrary restrictions on the Python lambda syntax.

Ruby is more orthogonal and systematic. Everything is an object, and you call methods on those objects. And sending a block as a method parameter gives you something that very much resembles functional programming (minus the immutability).

There are a few other constructs (it's not quite so dogmatic about object orientation as Smalltalk), but Ruby is very regular and so you can understand how everything works with a small number of syntactic constructs.

The lambda thing is not about whitespace indentation. It is a purposeful decision that if you need more than one line to do it, it should have a name.

At first I disliked this, but it does nudge you towards readability, which winds up to be a good thing. And if you look at it, there is very little space difference between an unnamed lambda and an embedded function:

  def lambda_version():
    a = lambda x:
      line one
      line two # note: this sort-of requires the idea of implicit return, which Python does not have outside of lambda
    a()


  def named_version():
    def lambda_replacement():
      line one
      return line two
    lambda_replacement()

> The classic example being the arbitrary restrictions on the Python lambda syntax.

That's actually because Guido thinks multi-line expressions are messy to parse, rather than because they can't be done. Consider:

  f = lambda x:
      return x + 5

Or, perhaps:

  print(sum(map(lambda n, b:
      while n:
          b.append(n)
          n -= 1
      return b
  , range(3), [[], [], []]), []))

You can see why this was never added to the language, though.

A language that uses parentheses does not preclude one from also using indentation to convey code structure. In fact, this is usually standard practice.

Python, however, does indeed preclude one from using additional signifiers of code structure beyond indentation.

And in practice you don’t type out parentheses. You put in a single opening parentheses and your editor will add the closing parentheses and add the appropriate indentation (and if desired, newlines) for you. In practice the only difference in typing is typing a single ( character vs a single <tab> character.

All that being said, this is the very definition of bike shedding, so it’s really not a factor when picking one language over another.

I don't understand what you mean. How are parentheses relevant? Also, personally I hate the parenthesis completion, it gets in the way more than it helps.

By "parentheses" do you mean "brackets"? If so, sure, you can use indentation along with brackets, but why am I now using two things? With Python, all I need to do is backspace every once in a while, to signify the end of indentation, which is very easy to do.

As a real reply -

I can copy code marked up with parens and brackets from basically any source (no matter how it's indented or how whitespace is handled) and my linter will automatically understand and format it nicely.

In an indentation language - If I copy a chunk of code that's nested more or less deeply than the section I'm currently working on, I have to manually replace whitespace everywhere. Sometimes the linter is smart enough, sometimes it's not.

If your editor keeps the selection once you paste, you can just hit tab / shift + tab until the indentation's correct. And there's no counting “did I copy the correct number of close brackets”.

I actually find Python easier in this regard, even in editors where I have to re-select everything I just pasted.

> By "parentheses" do you mean "brackets"?

I choose to believe that this means S-expressions.

You need to spend a couple of days debugging scripts where someone has fucked up the indentation by copying and pasting with a program messes with leading whitespace. Or where someone has inserted an extra whitespace character in a random line in a long script.

I've been a Python developer for twenty years, I'm sure those things are bound to happen at some point but haven't yet.

I was a TA for a physics lab that used python (3 months)

This came up nearly 100+ times in those 3 months, just in the classes I TA'd for.

Making invisible characters carry significant meaning really throws non-programmers for a loop at times: It's so easy, right until they break it and don't understand how.

If you're honestly having trouble with that, the solution is an editor that shows whitespace. Everything above notepad is capable. I use it with a subtle theme that makes tabs just visible enough to stand out. Indentation guides are helpful as well. Geany is a good choice for beginners, free and x-platform.

Black can also diagnose/fix some issues.

Isn't it the same when their code won't compile because of an extra bracket?

Not really - A missing bracket is immediately a parsing error.

Mis-indented whitespace is not.

  if(err) { 
    console.log('something bad happened') 
    recover()
  continue()

Immediately throws an unmatched brackets error.

No such luck for

  if err
    print("something bad happened")
    recover()
    continue()

now you can spend minutes trying to figure out why continue isn't being called as you expect it to in the success case. It's obvious enough once you open that specific file and see the indentation, but the tooling is no help at all.

I think that's an unfair comparison: in the first example, you have indentation to tell you what the intent was.

With inexperienced programmers like you bring up, if it was mistyped instead:

  if(err) { 
    console.log('something bad happened') 
    recover()
    continue()

I don't believe that compiler syntax error would help one iota (eg. they might just stick } after the continue() to get the compiler to let the code through).

Significant indentation can throw someone for a loop in a very narrow set of copy-paste mistakes (i.e. where pasted code is still indented in a way to pass the syntax checks, since you can't mix and match number of spaces in Python either).

Though having good editor support is crucial for programming.

You can just as easily make a mistake in bracketing as mentioned, in any number of ways.

If you're blindly running software that has never been looked at, tested, and even run once to verify it works, the main problem is elsewhere.

> You can just as easily make a mistake in bracketing

I actually strongly disagree with this. There's a reason basically every style guide under the sun defaults to requiring brackets for things like single-line conditionals (where they're optional in a lot of languages): It removes this class of error entirely.

There are lots of other ways to fuck things up with brackets, so no arguments there.

> If you're blindly running software that has never been looked at, tested, and even run once to verify it works, the main problem is elsewhere.

I don't think this is really relevant. In this context - the goal of the student isn't to produce good python code, it's to complete the lab they're working on with their partners. The single biggest case I see where this happens is as follows:

1 - Student A writes some code

2 - Student B writes some code

3 - Student A wants to use what student B wrote

4 - Student A copies the code from student B into their file, but the indentation is wrong.

5 - Student A then starts removing indentation (line by line - which is the real mistake, really) and goes one line too far, or one line too short.

6 - Student A and B test one of the cases for the integrated code (either the success or the failure) and it works fine (in my example, imagine they test the error case and see it does what they expect)

7 - Then later they realize the other case is breaking, but they don't know why: usually because it's been half an hour since they pasted that code into their editor, and checking indentation doesn't immediately come to mind.

8 - I get called over to help

There is easy to learn and easy to use, they are not always equal.

They shouldn't be copy and pasting between each other if they don't understand how indentation works. Basics first.

A good editor can help. Geany is good for beginners and can show whitespace. I also recommend the tool pyflakes to everyone, beginner and expert alike.

Isn't the actual error in that Python being the missing ":" after "if err"? ;)

Then start worrying about the bad indentation :)

Damn you linter-less HN textbox! :D