I would argue it adds readability and clarity, and reflects the naturalness of the string formatting operation. Not only fewer characters, but also one less pair of parens, or in the array case swapping parens for brackets, which is easier to visually parse. The general problem is that string formatting and interpolation are very uncomfortable in SC. Your options are:
- postf, for which you will almost always forget the necessary ending \n
- interpolating ++s, which is 10 extra characters (" ++ and ++ "), 6 of them symbols, which breaks apart the string and makes it difficult to understand the message being constructed
- format, which means you are probably avoiding postf and placing the formatted string within postln. Then you end up with:
postln("Why is % afraid of %?".format(6, 12))
Or something similar that is in my experience noisy and makes you really wish the token came at the end so you could just write:
postln("The answer is " ++ answer)
In my time using SC I have never felt comfortable formatting strings. Other languages do this much better, and rightly so because it is an extremely necessary and frequent task. Cf Swift's "My \(var).", and PHP's "My $var." and Ruby's "My #{var}." I am presenting this as one possible (easy) solution to that problem. I think genuine, simple string interpolation would also be valuable, even more valuable than what I'm suggesting to be honest. In Swift I actually prefer typing "End of \(message)" because the string interpolation notation is so clean visually.
> If the issue is that you don't want type "format," two rejoinders:
I hope I make it clear in the above response that it isn't typing that's a problem, it's that the design of format in this language feels bad and looks bad, and there are viable alternatives that have worked well in other languages. This is primarily a readability concern. Descriptive/lengthy method names definitely are worth it for many operations, but I also feel that having to read another word for a very common operation adds unwanted noise. How is this different from using ++ over (fictional) ".concat"?
> make SC harder to learn
Fair. although parallelism with Python 2 helps I would think.
> violate existing conventions
I think anything new would have to do that, right? I do not see what convention this violates, unless it's the general one of "there is another method." + and ++ are also symbolic String operators.