[alexhill]

I think it's slightly easier for both humans and computers to parse a function call when there's no space.

I find your question interesting - why SHOULD programming language syntax match English syntax? Programming languages borrow symbols from natural languages for convenience, but there's generally only a very loose analogy between their purposes in each.

Question, does it bug you when you see function calls without spaces in the same way it would if(for example) someone left out a space in writing?

[alok-g]

Programming language syntax does not need to match English syntax, but given that it is just a benign convention (that for almost all programming languages would not change the meaning of the program), I certainly expected a non-zero probability of others using it too. Which is why I was curious about the history of the convention since the probability distribution is nearly 100% skewed towards no-space. :-)

To answer your second question, with English, it certainly bugs me. With programming languages, I use the space but of course do not expect the same from anyone else. No one so far has complained about me using it either. :-)

[alexhill]

This is just speculation, but since as you rightly point out the space is optional in many programming languages, I suspect the existence of the no-space convention simply reflects that a majority of programmers, over the last however many decades, have preferred to read and write code that way.

There are two factors involved: I reckon most people (a) see a function call as a single logical unit and write it as such and (b) feel compelled to follow conventions. The result is that once there's a clear majority, most code will converge on that style. Clearly you do neither :)

Personally I just try to adopt the conventions of the language or ecosystem I'm working in as closely as possible and try not to let my personal leanings get in the way. The most important thing is that others can easily read my code.

I would love to write Python like this, but sadly for me PEP8 and society frown upon it:

  some_dict = {'a_key':       an_expression,
               'another_key': another_expression}

[zo1]

>"I would love to write Python like this, but sadly for me PEP8 and society frown upon it:"

Indeed, that is one of those "big argument" type of minor formatting discussions. Despite my OCD, it doesn't bother me, and in fact, I prefer formatting them as below:

    some_dict = {
      'a_key': an_expression,
      'another_key': another_expression,
    }

Question, if you add another entry, and it throws off the formatting, do you go up and change all the other entries prior so they all align? Because that does bring up questions about code-commits. I.e. you're touching code that hasn't changed.

    some_dict = {
      'a_key': an_expression,
      'another_key': another_expression,
      'a_really_long_key_that_throws_you_off': expression,
    }

As opposed to:

    some_dict = {'a_key':                                 an_expression,
                 'another_key':                           another_expression,
                 'a_really_long_key_that_throws_you_off': expression}

[alexhill]

I expect that's why the current convention was adopted, and another reason I'm happy to do it that way. I don't ever actually format my code like my example - but if I'd learned Python from first principles in a cave, I probably would. :)

Would be cool if IDEs could do this for you at the display level without touching the underlying code!