There is no problem with arrays as they have their special syntax anyways as I said above and as mentioned also by @StefanKarpinski . The problem dates back to 2014 when they wanted to allow @m (a, b) to mean calling the macro @m on a tuple. In my opinion, they chose the easiest solution not the best solution in that case. Functions are used more than anything else in Julia, but macros should only be second to them. So, I imagine the better solution was to choose (and I can’t assess how difficult this is TBH):
@m a, b # call @m on two variables a, b
@m a b # call @m on two variables a, b
@m (a, b) # call @m on single variable (a, b)
and leave functions alone. That’s, force a space after macro names because macros are equivalent to functions without the parentheses; f(x, y) should be equivalent to @f x, y.
Allowing spaces after function names, however, can significantly improve readability in many cases. the GNU Coding Standards recommends this (“We find it easier to read a program when it has spaces before the open-parentheses and after the commas”). A similar case in Julia is when they forced a space before ? and after : in 1 > 2 ? 1 : 0. In this case, 1 > 2? 1 : 0 is like normal English and is not bad at all. Many people also, including myself, have the habit of adding that space before function names for clarity (I use it a lot in my introductory C course). In general, languages that give freedom and trust to the programmer seem to be more enjoyable (Nim was criticized at some point for relying heavily on spaces). Some emerging languages even went farther and removed macros altogether, but I think macros are pretty useful though.