Today I saw a blog by Guido van Rossum, creator of Python, on www.artima.com in which he criticized Ruby’s mutable strings - saying
that of such a horror he could ne’er conceive, or something
Anyway, all the discussion I’ve seen about (im)mutable strings has
focused on implementation and efficiency. LISP may be a
counter-example, but I’m not sure, and its paradigm is different. I’d
like to know what the design considerations are.
So, is van Rossum’s point valid? I must say, immutable strings sound
elegant to me for some reason I can’t work out, but then Ruby has
oh-so-cool symbols anyway. What are the pros and cons of Ruby and
Python on the string department?
Today I saw a blog by Guido van Rossum, creator of Python, on www.artima.com in which he criticized Ruby’s mutable strings - saying
that of such a horror he could ne’er conceive, or something
If mutable strings are horror, mutable dictionaries should be as well.
The one with such standard should go to side-effect free language like
Haskell.
I rarely have such problems caused by mutable strings. Besides, Ruby
is not a language to keep people away from horror. You can write
ugly, scary, or dangerous programs in Ruby, if you want. It’s cost
for freedom.
matz.
···
In message “Question: immutable strings as design goal?” on 03/08/18, Gavin Sinclair gsinclair@soyabean.com.au writes:
No it’s not. Guido is just insanely jealous that Matz’ personal hero is
Larry Wall and not him, and this “omg, immutable strings are horrid”
crap-o-la is the only thing he could come up with.
Today I saw a blog by Guido van Rossum, creator of Python, on www.artima.com in which he criticized Ruby’s mutable strings - saying
that of such a horror he could ne’er conceive, or something
If mutable strings are horror, mutable dictionaries should be as well.
The one with such standard should go to side-effect free language like
Haskell.
Yes, that thought struck me as well.
I rarely have such problems caused by mutable strings. Besides, Ruby
is not a language to keep people away from horror. You can write
ugly, scary, or dangerous programs in Ruby, if you want. It’s cost
for freedom.
I don’t think his thoughts were on freedon vs restrictions. It seemed
that he just thinks strings, for whatever reason, should be
immutable, like numbers.
As a counter-point, all the freedom in the Ruby world doesn’t allow
you to modify symbols. Guido obviously believes that all strings
should be like that. (And dictionaries, obviously, shouldn’t.)
Gavin
···
On Monday, August 18, 2003, 11:03:50 PM, Yukihiro wrote:
In message “Question: immutable strings as design goal?” > on 03/08/18, Gavin Sinclair gsinclair@soyabean.com.au writes:
I rarely have such problems caused by mutable strings. Besides, Ruby
is not a language to keep people away from horror.
I’m sorry, but I can’t see what the problem/horror is. Can someone
explain it to me? I mean, it’s your own responsibility to keep track if
you’re modifying a copy or not, am I right?
nikolai
···
–
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}
No it’s not. Guido is just insanely jealous that Matz’ personal hero is
Larry Wall and not him, and this “omg, immutable strings are horrid”
crap-o-la is the only thing he could come up with.
Haha! Yeah, that’s probably the reason
nikolai
···
–
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux[“\021%six\012\0”],(linux)[“have”]+“fun”-97);}
javax.servlet.ServletException
at org.apache.jasper.runtime.PageContextImpl.handlePageException(Unknown
Source)
at error_52._jspService(error_52.java(Compiled Code))
at org.apache.jasper.runtime.HttpJspBase.service(Unkn
…
I rarely have such problems caused by mutable strings. Besides, Ruby
is not a language to keep people away from horror. You can write
ugly, scary, or dangerous programs in Ruby, if you want. It’s cost
for freedom.
I don’t think his thoughts were on freedon vs restrictions. It seemed
that he just thinks strings, for whatever reason, should be
immutable, like numbers.
I know, I know. Don’t take my words seriously.
As a counter-point, all the freedom in the Ruby world doesn’t allow
you to modify symbols. Guido obviously believes that all strings
should be like that. (And dictionaries, obviously, shouldn’t.)
Although you can’t change the value of symbols (and numbers),
you can change their instance variables.
matz.
···
In message “Re: Question: immutable strings as design goal?” on 03/08/18, Gavin Sinclair gsinclair@soyabean.com.au writes:
> > I rarely have such problems caused by mutable strings. Besides, Ruby
> > is not a language to keep people away from horror. You can write
> > ugly, scary, or dangerous programs in Ruby, if you want. It's cost
> > for freedom.
>
> I don't think his thoughts were on freedon vs restrictions. It seemed
> that he just thinks strings, for whatever reason, *should* be
> immutable, like numbers.
There are always performance issues to consider as well. Constantly
creating new strings, especially when working with large ones, is a
major performance hit.
Numbers, symbols, booleans, etc don’t have this problem.
Sometimes babelfish can translate Japanese text, but sometimes it
returns garbage (probably because of MIME type or charset issue?). In
this case it’s the latter
I’m no matz or Guido (no surprise there), but I would point out that
Apple’s Cocoa has an immutable string class and a mutable string class.
As Robert Feldt pointed out, you can also implement a ‘freeze’ method,
and if you really don’t trust yourself and others, you can implement
the Seattle Ruby Brigade’s ‘deepfreeze’ method (part of their Ruby
audit, which can be found here:
Also, while I’m speaking out of ignorance and mere supposition,
wouldn’t immutable strings cause difficulties in languages with more
than one writing system? In particular, Korean uses hangul (a phonetic
alphabet) and hanja (Chinese characters) and Japanese uses kanji
(Chinese characters), hiragana (syllabic symbols), katakana (symbols
for foreign words) and furigana (keys to pronounce kanji). Hopefully,
some with knowledge in this area, will correct or confirm my
supposition.
Sometimes babelfish can translate Japanese text, but sometimes it
returns garbage (probably because of MIME type or charset issue?). In
this case it’s the latter
I’m no matz or Guido (no surprise there), but I would point out that
Apple’s Cocoa has an immutable string class and a mutable string class.
Many of the Cocoa core foundation classes have mutable and immutable
versions of themselves, mainly for thread-safety and speed reasons. The
nice thing about immutable objects is that you can treat them as
atomically accessible primitives, skipping potentially costly (though
necessary) synchronization stuff.
It also allows for the sharing of identical constants–if the compiler can
detect that two different immutable objects are otherwise identical they
can be merged into a single object, though this is rarely done for
anything besides strings.
Also, while I’m speaking out of ignorance and mere supposition,
wouldn’t immutable strings cause difficulties in languages with more
than one writing system?
No. String constants are string constants, no matter how they’re encoded
or how many characters are in them. The one place that immutable strings
can be problematic is if you’re using Unicode and your string constants
use a different normalization form than some of the operations in the
language or library do, but that’s more a speed issue than anything else,
since the runtime will end up having to decompose or recompose (depending
on what uses which forms) as the program executes.
