Your example is worse than stringWithFormat: for the same reason C++ iostreams are worse than format strings.
It's hard to control once you want anything more interesting than + and it's not localizable. Complaining that a function call's name is too long doesn't matter at all.
If you think that function name length doesn't matter you haven't written enough ObjC yet. It matters. Source code shouldn't read like Tolstoy.
ObjC itself is not responsible, it's NeXT and Apple's fault for perpetuating that abominable naming convention for much too long.
As for localisation, only a tiny fraction of strings in a software program are user visible. I don't think we should be designing language syntax around that edge case.
I'm sure I've written more than most other people currently alive.
ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.
For algorithmic string building, I'm not sure how often you want + (aka appendString:), appendFormat: or componentsJoinedByString: are more flexible.
>if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.
Not necessary. There's a very sensible "huffmanization" principle created within Perl/Raku community which says that the need for a name/token to be overly descriptive is inversely proportional to frequency of its usage. So you can have short names and they still be human-parseable just because they are used often, and your brain used to register it. FWIW they will be easier human-parseable, because longer words take longer to read. With this approach one can has both fmt, and formatSomethingSomewhereSomeday
1. param:value is used, but convention is param:value not the gratuitous Engrish verbingParamProposition:value ObjC inherited from Smalltalk.
2. param: is optional if the variable holding value in the calling function is named "param" at compile time. This pushes you to name your params "param" everywhere that makes sense.
Jakt's popularity is limited, obviously, but it's a compile-to-C++ language, so you could use it many places.
It's hard to control once you want anything more interesting than + and it's not localizable. Complaining that a function call's name is too long doesn't matter at all.