Ok, you bring up some good points! Rather than respond directly, I think
I'll take a step back and ask:
1. Do you agree string formatting and/or string interpolation could be
done better in SC?
2. What are some ways we could make it better that would be less harmful
than the % approach?
-Brian
On Fri, Dec 22, 2017 at 7:11 AM <i@xxxxxxxxxxxxxx
<mailto:i@xxxxxxxxxxxxxx>> wrote:
On 22 Dec 2017, at 12:21, brianlheim@xxxxxxxxx
<mailto:brianlheim@xxxxxxxxx> wrote:
> 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?
You lost me here, sorry.
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.
S.