Personally, I often use parentheses in languages like Ruby where avoiding them is in vogue. Perhaps it's just a personal preference, but I feel it communicates better (which is what source code is for)
I'm currently learning Elixir at a new job, and I really, really dislike the (what I think of as) the ruby-style where `return` statements and function call parentheses are optional.
A colleague convinced me to look at this a different way (although for Ruby as opposed to Elixir). Functions always return a value. This is different than some languages where there is a distinction between a procedure and a function. In Ruby, if you don't call "return", then the function returns the return value from the last statement. We get fooled into thinking that we are returning "nothing", but it's still just returning the value from the last statement -- which is hopefully nil.
To be consistent, we could choose to always add "return" to the last line of every function -- because that's what it's doing. But this is a completely redundant bit of typing once you know what the language is doing. Having that "return" on the last line of every single function is not helpful in the least. Instead we can define "return" to be a statement that you only use when you are returning early from a function.
Since he pointed that out, languages that force me to type "return" at the bottom of functions bug me :-) As for parentheses, I'm mostly in agreement. Omitting parentheses is mostly useful when you are writing a DSL where you want to obfuscate that what you are doing is actually a function call. In Ruby land, Rails uses this effectively. However, it's a double edged sword because I have seen junior developers who do not understand that this is normal Ruby and a function call. They just think it is "Rails Magic". I'm of mixed feelings on the matter. I use it occasionally when I feel that it helps express the intent of my DSL rather than the plumbing, but I always feel a bit uneasy when I do it.
I don't know Ruby or Elixir's way of doing this, but I assume it's not too dissimilar to in Haskell and I'd argue there isn't much ambiguity -- the spaces are enough to discern arguments once you get used to it, and if your call gets too large maybe it's time to consider binding the arguments so it's clearer what's being passed to the function anyway.
Same thing for implicit return statements, when they're implicit it just takes getting used to the fact that the last statement in the block returns -- I've never really had trouble reading code because of the lack of function call parentheses or explicit return statements but I guess in a language where it's optional it can be a bit more unexpected versus a language like Haskell where this style is encouraged more strictly.
There's a good deal of ambiguity in Haskell, but people tend to resolve it with operators like '$'. But I'd argue that it works very well in Haskell due to the fact that whitespace as function application and automatic currying go together well to make an elegant syntax. Lacking those features, it might be better to stick to the standard parenthetical notation.
There’s a principle of OOP called the “uniform access principle” (articulated by Bertrand Meyer, among others) that holds that a class should not leak whether a value is computed or is just a field on the object. That way, you don’t need getters/setters because, if you want to change the storage of a class member, you can just change it from being a data member to a method of vice versa. This helps avoid the explosion of getters and setters that characterize a certain sort of Java project.
