I think Gavin is right… we don’t “add” strings, we concatenate them.
Using the + operator to mean “concatenate” violates our eighth grade
algebra sensibilities. It’s, um, surprising.
Note that the often-awkward Perl uses . as a string concatenation
operator, not +. This is one of the things Perl got right and Ruby got
wrong, imho.
I think Gavin is right… we don’t “add” strings, we concatenate them.
Using the + operator to mean “concatenate” violates our eighth grade
algebra sensibilities. It’s, um, surprising.
I have to ask… how much surprise or learning curve is really
involved in finding out that a language uses ‘+’ to concatenate
strings? I don’t mean to sound gruff – I’m just surprised (!) by
what seems to be the extreme fine-tunedness of people’s expectations.
Eighth grade seems like a long time ago… (and probably was longer
for me than for most people here Was everything so rigidly set so
long ago, that the slightest expansion or reinterpretation really
causes problems?
Note that the often-awkward Perl uses . as a string concatenation
operator, not +. This is one of the things Perl got right and Ruby got
wrong, imho.
You can’t blame Ruby, though – after all, ‘.’ is already doing quite
a lot
Agreed. Until now, I still mistakenly use the “.” operator from time to
time in Ruby, just because of the previous Perl experience, which was
very natural.
I think Gavin is right… we don’t “add” strings, we concatenate them.
Using the + operator to mean “concatenate” violates our eighth grade
algebra sensibilities. It’s, um, surprising.
Note that the often-awkward Perl uses . as a string concatenation
operator, not +. This is one of the things Perl got right and Ruby got
wrong, imho.
Anyone that has studied abstract algebra won’t be overly confused by
this, as the first entry into group theory will leap you into addition
systems that don’t work the way you used to expect.
Admittedly, that’s a long way from eighth grade algebra.
But on the other hand, if you’re going to get anywhere in being a
computer programmer, you have got to be cognizant of the fact that
addition on computers doesn’t work with the “abstract purity” it did
in grade eight:
a) 1.0 + 0.000000001 may not add up to exactly what you expected.
b) 2147352576 + 175000 often will not add up to 2147527576 unless you
are using Common Lisp, where that can revert to a BIGNUM.
Computer addition generally isn’t like grade eight.
This is a multipart message in MIME format.
–=alternative 0051BBBD86256C30=
Content-Type: text/plain; charset=“us-ascii”
I think Gavin is right… we don’t “add” strings, we concatenate them.
Using the + operator to mean “concatenate” violates our eighth grade
algebra sensibilities. It’s, um, surprising.
Note that the often-awkward Perl uses . as a string concatenation
operator, not +. This is one of the things Perl got right and Ruby got
wrong, imho.
Agreed. Until now, I still mistakenly use the “.” operator from time to
time in Ruby, just because of the previous Perl experience, which was
very natural.
But then what would Ruby use for method calls on strings? Honestly, I
don’t think this can be cited as an example of an incorrect choice in
Ruby.
On the Perl topic: I knew I was definitely hooked on Ruby when I had
occasion to write a Perl script and (a) left out semi-colons; (b)
wrote calls to “puts”; (c) found myself writing things like: @array.map …
David
···
On Wed, 11 Sep 2002, William Djaja Tjokroaminata wrote:
Anyone that has studied abstract algebra won’t be overly confused by
this, as the first entry into group theory will leap you into addition
systems that don’t work the way you used to expect.
I never heard about “noncommutative sum” in algebra. I think in
every algabraic structure, the sum is commutative. E.g. in Group
Theory, the group opertion is denoted by + as long as the group is
Abelian, that is commutative but it is always denoted by * for
noncommutative groups.
I, as a mathematician, still find it very intuitive and natural to
denote the concatenation of strings by “+”. I have no problems with
it and this would be the last thing I would change in Ruby.
b) 2147352576 + 175000 often will not add up to 2147527576 unless you
are using Common Lisp, where that can revert to a BIGNUM.
And I feel the need to weigh in here, too. Not everyone is surprised by
overloading. Context pretty often resolves overloads easily, even in the
mind of humans reading code.
For instance, when you read the the above paragraph did you see red? And if
you read the next paragraph, your head will head you in the right direction
(or left, or correct). If I lead you down the wrong path, you have been
lead, unless you use lead to protect you from the radiowaves I’m using as a
mind-control device. And did you notice I used two 'the’s in the first
paragraph of this sentence? Probably one too many.
Hopefully, our code doesn’t look this bad, but my point is that we deal in
ambiguity regularly. We resolve both symbols and sounds contextually and
are quite adept at it. We do so because it is easier to re-use a symbol,
resolving ambiguities as we go, than to create and burn in a new
symbol/semantic combo.
I think Gavin is right… we don’t “add” strings, we concatenate them.
Using the + operator to mean “concatenate” violates our eighth grade
algebra sensibilities. It’s, um, surprising.
I have to ask… how much surprise or learning curve is really
involved in finding out that a language uses ‘+’ to concatenate
strings? I don’t mean to sound gruff – I’m just surprised (!) by
what seems to be the extreme fine-tunedness of people’s expectations.
Eighth grade seems like a long time ago… (and probably was longer
for me than for most people here Was everything so rigidly set so
long ago, that the slightest expansion or reinterpretation really
causes problems?
Note that the often-awkward Perl uses . as a string concatenation
operator, not +. This is one of the things Perl got right and Ruby got
wrong, imho.
You can’t blame Ruby, though – after all, ‘.’ is already doing quite
a lot
Agreed. Until now, I still mistakenly use the “.” operator from time to
time in Ruby, just because of the previous Perl experience, which was
very natural.
I used to bounce back and forth between writing or maintaining ActiveServer
Page code written in JavaScript and VBScript. VB uses the ampersand to
concat strings; JavaScript used ‘+’. If one mistakenly uses the ampersand
in JavaScript, it simply takes it as a logic operation and goes merrily in
its way …
Anyone that has studied abstract algebra won’t be overly confused by
this, as the first entry into group theory will leap you into addition
systems that don’t work the way you used to expect.
Really? I have been doing abstract algebra and algebraic geometry for
something like six or seven years, and I have never seen anyone use
the symbol ‘+’ to denote a non-commutative operation …
Ruby could use a different operator, which is what I’ve read that perl6
will do, since it is also going to be using “.” for method calls.
I think “+” is more natural to me for concatenation than “*” or “/”, and
I would expect that even a Perl programmer would agree. As for “+” vs.
“.” or “_” or “~”, I feel at home with “+” because of my experience with
BASIC. The fact that it has an overloaded meaning doesn’t bother me,
since I’m used to having symbols with overloaded meaning in mathematics
(sigma, for example, can indicate standard deviation or 2-D density; it
just depends on the context).
On Wed, 11 Sep 2002, William Djaja Tjokroaminata wrote:
Agreed. Until now, I still mistakenly use the “.” operator from time to
time in Ruby, just because of the previous Perl experience, which was
very natural.
But then what would Ruby use for method calls on strings? Honestly, I
don’t think this can be cited as an example of an incorrect choice in
Ruby.
Oh yes, the consequence is there will more syntax in terms of
free-floating period (period with white space before and after), which
will be different from a period attached to its left operand, which still
can be used for method calls on strings. I am not proposing this at
all; it just felt natural in Perl.
On the other hand, this additional syntax is not completely an exception
by itself. There is already the “&” special syntax for Proc/block, which
is not strictly object-oriented.
On Wed, 11 Sep 2002, William Djaja Tjokroaminata wrote:
Agreed. Until now, I still mistakenly use the “.” operator from time to
time in Ruby, just because of the previous Perl experience, which was
very natural.
But then what would Ruby use for method calls on strings? Honestly, I
don’t think this can be cited as an example of an incorrect choice in
Ruby.
On the Perl topic: I knew I was definitely hooked on Ruby when I had
occasion to write a Perl script and (a) left out semi-colons; (b)
wrote calls to “puts”; (c) found myself writing things like: @array.map …
Perl might not have used . for string concatenation were it not for the
number/string morphing nature of perl scalars.
In Ruby a variable’s type tells us what it is, in Perl the operators
provide context as to what a scalar ought to be viewed as, and this
is why they need an “extra” set of comparison operators e.g.
perl
$a = '123 ';
$b = 45;
$a + $b => 168
$a . $b => ‘123 45’
$a > $b => 1
$a gt $b => a false value
I prefer the explicitness of ruby (requiring .to_?), and its overloading
of + isn’t too surprising e.g.
But then what would Ruby use for method calls on strings? Honestly, I
don’t think this can be cited as an example of an incorrect choice in
Ruby.
Ruby could use a different operator, which is what I’ve read that perl6
will do, since it is also going to be using “.” for method calls.
I think “+” is more natural to me for concatenation than “*” or “/”, and
I would expect that even a Perl programmer would agree. As for “+” vs.
“.” or “_” or “~”, I feel at home with “+” because of my experience with
BASIC. The fact that it has an overloaded meaning doesn’t bother me,
since I’m used to having symbols with overloaded meaning in mathematics
(sigma, for example, can indicate standard deviation or 2-D density; it
just depends on the context).
The >/gt dichotomy prevented me from ever grokking Perl. That was unnatural!
Gavin
···
----- Original Message -----
From: “Mike Stok” mike@stok.co.uk
In Ruby a variable’s type tells us what it is, in Perl the operators
provide context as to what a scalar ought to be viewed as, and this
is why they need an “extra” set of comparison operators e.g.
perl
$a = '123 ';
$b = 45;
$a + $b => 168
$a . $b => ‘123 45’
$a > $b => 1
$a gt $b => a false value
I prefer the explicitness of ruby (requiring .to_?), and its overloading
of + isn’t too surprising e.g.
The >/gt dichotomy prevented me from ever grokking Perl. That
was unnatural!
The mnemonic there was to use the “stringish” comparitors to compare
values as strings (since, as the poster noted, context made the
difference, not the data).
The >/gt dichotomy prevented me from ever grokking Perl. That was
unnatural!
The mnemonic there was to use the “stringish” comparitors to compare
values as strings (since, as the poster noted, context made the
difference, not the data).
Yes, I’m aware of that. But I kept getting errors in my code that were
hard to work out. Even though I “knew” the difference, errors kept
slipping in because it’s not a natural difference.
Was everything so rigidly set so