| > Yes, but they're consistent with the mathematical notation everyone has used over their entire life. By the time you pick up a programming language you have most likely used parenthesis for a while. As opposed to the natural visual distinctions that we make all the time? Braces are a learned concept. Having something visually offset might be a learned concept, but if it is I bet it's so early it's prior speech developing. People notice visual patterns. An offset bit of text forms a visual pattern. Again, I don't prefer it, but I think you're reaching in your arguments against it. > I am going to create a new language 99% identical to English, where fork means knife, knife means spoon and spoon means fork. Have a happy time translating paragraphs of text involving those 3 objects from English into my language. So, exactly the same situation we have with English today, where it changes and slang is used? I'll have to ponder that problem as I kick it in my crib tonight. Or maybe I'll just settle in and watch the boob tube. Surely replacing some words with others isn't and intractable problem? > Implicit meaning takes non-zero effort to understand. Whitespace blocks are not always implicit. They may be well defined within the language they are used in (such as in Python). It's no more implicit than < means less than. Both are defined within the language, and < happens to also share meaning with mathematical notation, which makes it easier to grasp initially for those familiar with that, but there's nothing implicit about either as they both use the inclusion of one or more symbols to confer meaning (even if they are space characters), rather than the exclusion of information. You are confusing whitespace for no-space. > Now you have 2 ways of doing the same thing with no added value. Of course there is added value. People prefer it. People's preferences have value. > Now you have more possible ways of writing down an expression, if you are parsing an expression or refactoring your code with a regex now it's much more complex. That depends on the language and whether there are multiple ways of defining a block. Unless you expect your expression to parse C, Lisp, Python, Smalltalk and Prolog correctly it it's just those pesky Python whitespace blocks that are holding you back. Within Python, space indented blocks are canonical. If you think that is causing too many ways to define how to perform something in different languages, you're probably better off not looking at some of the other languages I listed earlier... > In 2017 there's still people fighting over tabs vs spaces. Now we add another dimension to it: spaces vs parenthesis. An endless source of bikeshedding. Not really. Tabs vs spaces is something people that interact in code with each other have to deal with. I doubt Perl and Python developers get upset when they load each other's code, in the other's language, and see the other used spaces instead of parenthesis[1] or vice-versa, because that choice doesn't make sense within those languages. Sure, try to use indentation to define blocks in Perl. It won't do you any good without the parenthesis, because Perl doesn't support that choice. 1: It's obvious at this point we're actually talking about curly-braces, and not parenthesis, right? I'll keep using parenthesis for now for consistency's sake. |
But since everything is relative, it doesn't matter anymore. Let's delimit function evaluations and operator precedence with the words "cat" and "dog" from now on. Since everything is a preference, and is relative, it doesn't matter.
However, what you fail to see is that in reality a choice like this involves effort, it has an economic cost, it's not only preference.