> These add little or nothing new
I would argue it adds readability and clarity,
I don’t see how it’s more readable or clear. ‘format' is rather clear. % looks like mod. + with string is at least somehow related to adding something.
Any clarity and readability gained by a syntax variant has to be weighed against loss of clarity and readability resulting from users needing to know two or more things instead of one. SC is already pretty bad for this. Maybe not quite Perl-like, but despite all the expert enthusiasm for many variants Perl has not faired well generally.
db is less clear and readable than dbamp. It looks like it should get decibels from the receiver rather than convert from them.
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.
Don’t think about how it feels to you, think about the effect it has on the language, users and general case.
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.
format is not lengthy, or more onerous to read than %. We parse words, not letters. If it was Objective C style replaceInstancesOfPercentageSignWithCorresponingArgs: I would agree you have an argument.
How is this different from using ++ over (fictional) ".concat”?
++ is at least the only way to do it. That’s one way and easy to learn. % and mod, or at, [], @ are not so great, and two wrongs don’t make a right.
> make SC harder to learn
Fair. although parallelism with Python 2 helps I would think.
This is my biggest issue, and based on almost 20 years of teaching SC I can say it is pretty hard to overestimate the effect this has. Most users of SC are not experts, or python programmers. SC is domain specific, and for many, probably most users, it’s their first language, and maybe their only one. Their feelings are more important than yours, sorry. They hate needing to read and learn multiple syntaxes. Harder to learn is harder to use.
Even if not, why stop at Python? Why not add formatting equivalents for PHP, Swift, C++, Ruby, Pascal.? Then everyone could learn faster right? Nope… SC is already full of syntax variants which people added only because it was like their favourite language.
> 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.
It uses an existing symbolic operator in a different non-intuitive sense. + and ++ at least make some sort of sense as being related to addition. I’m sure you can find other exceptions, but again two wrongs…
db replicating dbamp violates the well established convention of conversion methods being named fromto.
> and bloat the method table unnecessarily.
I fail to see how this is a concern at all. Maybe 8-16 extra bytes? No new selector symbol added. The dispatch itself is constant time.
True. Let’s say bloat the language unnecessarily.