I have never seen this done. Maybe I could go check each of the languages I know, but as far as I’m concerned this could just as well be disallowed in all of them.
3 Likes
What has Lisp got to do with this? Those coding standards are for C. There are a few good points in there but far from everything. I have co-maintained a GNU project and we happily ignored the recommendation about space between function name and open-parenthesis. In fact nobody ever suggested even to consider it.
2 Likes
Then, one has to unlearn all languages they learned before Julia including English 
.
Styles and guidelines can be useless at times if they are built off of a personal taste. But the problem is when the language puts restrictions that didn’t exist in the first place just to remedy the side-effects of a newly-added feature. I’d fix the source created that side-effect rather than change a well-established concept. The freedom to wisely use white space for clarity is highly appreciated, especially when code becomes close to human languages.
Okay, good to know then, because I don’t think anybody does this weird space thing. I was just saying the only reason I’d think of is if that’s for Lisp, i.e. postfix
Matlab, Python, C, Fortran, Java, Swedish, English and German - these are the languages I’m on first name basis with, and I’ve never seen or written f ( x ) in any of them. It would probably confuse me if I saw it, and disallowing it is at worst harmless and more likely a good thing for legibility.
7 Likes
In principle I agree with you but this particular restriction I really don’t have a problem with.
1 Like
I’ve seen something like this once: In C# scripts used by the Unity game engine. I don’t know why.
1 Like
Having the right to use whitespace at your own disposal is one thing and actually using it is another thing. Nothing stops you from using whitespace in these languages if it helps improve readability, and I encountered many examples in C (see Linux Kernel) and Fortran doing this. Writing f(x) in English is wrong, by the way. Check also languages like Haskell, OCaml, F#, Lisp, Closure, Forth, Elm, Standard ML, Ada, V, …etc., they do this all the time. And languages that use {..} always add space around and inside the braces; check Rust, C/C++, LaTeX, …etc. I mean, restricting something requires a strong reason because it feels bad to be punished just for adding a space after the function name. Of course f ( x ) seems ugly because the function name and arguments are short, but it feels a bit weird to disallow it.
People often have very strong opinions about surface syntax like this, but in the end it just comes down to personal preference, there is really no objectively superior choice. In past experience, this tends to lead to long circular discussions with little productive outcome. Julia’s syntax is finalized at this point – Except for new non-breaking features and minor consistency improvements the syntax just won’t change. I know it’s a bit of a cliché, but I think at this point, we will just have to agree to disagree. 
13 Likes
f(x) is not wrong in English because of the whitespace. It’s wrong in English because natural languages don’t have function calls.
LaTeX is another example where I have a lot of familiarity and you’re just wrong there. People do not leave a space between the macro name and the argument brackets “all the time”. If you write \macro {something} in LaTeX anyone who reads your code will assume that macro is a zero argument macro. It’s valid code, but it’s rare and bad.
2 Likes
I find it’s just habit. After using one language continuously for a while, I tend to acquire the quirks of that language and when I switch to another language I tend to dislike the new quirks, but after a few months I adapt and change… conventions about underscores, capital letters, space inside arguments vs space inside expressions, omitting or reinserting curly brackets, etc. I have hated and liked them in equal measure. I guess I don’t have the personality to have a personal preference!
1 Like
Doesn’t prohibiting such white spaces in functional notation bring Julia closer to Prof. Edelman’s motto: “with Julia, you don’t code the math, code is the math”?
See his TEDx talk.
1 Like
I’m not complaining about syntax, and I know that Julia’s syntax is finalized. I’m talking about a restriction that can be another source of error in the code if one innocently added one space after the function name. I don’t like that space either, but disallowing it was a bit extreme and sounds to me like a step back in programming language design (Fortran adopted free form after Fortran 77). Syntax in not a problem because one adapts to it after some time as @ptoche said, but this is about a strange behavior not found in other languages and can introduce errors.
That’s true, but look at the new LaTeX3 Layer and you’ll see a lot of spaces around and inside { }s for clarity of arguments.
1 Like
Yes, of course, if what you write is math, then f(x) should exactly be written like that. But Julia is also a general purpose programming language and one can encouter pretty long function names like below. Introducing one space sometimes doesn’t hurt.
function get_substitutions_and_solved_states(sys; no_postprocess=false)
sin (π/6)^2 === horrendous
true
3 Likes
Yes, horrendous, because it is far from math. This is exactly what I said above.
they still call functions without space no?
what does this even mean? everything is still function, math functions have short name because people can’t write verbosely on blackboard so they overload symbols all the time, do you prefer Unicode programming maybe? In any language you can have verbose (english, you may say) function names:
still, people don’t do it. It’s fine you have personal preference, just know it’s rarely adopted and Julia is NOT going to change its syntax, not sure if there’s anything to this discussion anymore