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 agree that it sounds like a very ad hoc design decision.
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.
This points to an important “philosophical” difference that stands
out to me when comparing Ruby and Python: Python gives me the feeling of
trying to be a “Language for the Masses” (LFM) and tries to put
restrictions on what can be done. You need to format your code in a certain
way, your strings (but only a minority of other objects) are immutable by
default etc. As discussed on ll1-discuss mailing list and
other places LFM’s are in contrast to LFSP’s (Language for Smart People /
experts) that tries to give you as much power as possible.
To me the LFM thinking is absurd and even inhumane since it (ironically
enough) says that there is an elite that know the area well enough to
decide what other people is allowed to use.
To me matz goal seems to be for less of an LFM than Guidos.
Then again I have too little experience with Python vs. Ruby to actually
know. I also may be exaggerating since also matz has his limits (no
macros in Ruby, no multi-methods etc) ;).
Regards,
Robert Feldt
Ps. “Rough” Immutable strings in ruby:
s1 = “a”
s1[0] = ?b
p s1 # => b
def ims(string)
string.freeze
end
s2 = ims “a”
p s1 # => a
s2[0] = ?b # => `=': can’t modify frozen string (TypeError)
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 agree that it sounds like a very ad hoc design
decision.
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.
This points to an important “philosophical”
difference that stands
out to me when comparing Ruby and Python: Python
gives me the feeling of
trying to be a “Language for the Masses” (LFM) and
tries to put
restrictions on what can be done. You need to format
your code in a certain
way, your strings (but only a minority of other
objects) are immutable by
default etc. As discussed on ll1-discuss mailing
list and
other places LFM’s are in contrast to LFSP’s
(Language for Smart People /
experts) that tries to give you as much power as
possible.
To me the LFM thinking is absurd and even inhumane
since it (ironically
enough) says that there is an elite that know the
area well enough to
decide what other people is allowed to use.
To me matz goal seems to be for less of an LFM than
Guidos.
Then again I have too little experience with Python
vs. Ruby to actually
know. I also may be exaggerating since also matz has
his limits (no
macros in Ruby, no multi-methods etc) ;).
Regards,
Robert Feldt
Ps. “Rough” Immutable strings in ruby:
s1 = “a”
s1[0] = ?b
p s1 # => b
def ims(string)
string.freeze
end
s2 = ims “a”
p s1 # => a
s2[0] = ?b # => `=': can’t modify frozen
string (TypeError)
In message “Re: Question: immutable strings as design goal?” on 03/08/18, Robert Feldt feldt@ce.chalmers.se writes:
This points to an important “philosophical” difference that stands
out to me when comparing Ruby and Python: Python gives me the feeling of
trying to be a “Language for the Masses” (LFM) and tries to put
restrictions on what can be done. You need to format your code in a certain
way, your strings (but only a minority of other objects) are immutable by
default etc. As discussed on ll1-discuss mailing list and
other places LFM’s are in contrast to LFSP’s (Language for Smart People /
experts) that tries to give you as much power as possible.
To me matz goal seems to be for less of an LFM than Guidos.
Yes. It’s a language for smart wannabe (i.e people trying to be
smart). I myself is one of them.
This points to an important “philosophical” difference that stands
out to me when comparing Ruby and Python: Python gives me the feeling of
trying to be a “Language for the Masses” (LFM) and tries to put
restrictions on what can be done. You need to format your code in a certain
way, your strings (but only a minority of other objects) are immutable by
default etc. As discussed on ll1-discuss mailing list and
other places LFM’s are in contrast to LFSP’s (Language for Smart People /
experts) that tries to give you as much power as possible.
This is not the reason Python’s strings are immutable,
and I don’t generally even agree that there’s such difference
between Python and Ruby (LFM vs LFSP). You’re probably just trying
to flatter yourself. Python is also a rather unsafe language
that lets you do several dangerous but powerful things. Such
as redefining functions, classes or objects, or accessing any member
in a class. Also, What language doesn’t force you to format your code
in a certain way? A language with no syntax perhaps? Ruby forces
you to use do/end or {} (or something), Python uses indentation –
not a real difference, don’t you think?
Strings, numbers and tuples are immutable in Python so that they
can be used as dictionary keys. I admit that one could do away
with this restriction by just choosing not to alter strings that
are used as dictionary keys. But allowing this to be done could
lead to subtle bugs, and making strings immutable doesn’t do much
harm, so why not make them immutable? It’s actually just a design
choice that weighted, which would lead to shorter dev times in
general: immutable or mutable strings. Guido thought it was the former.
In his excellent book Effective Java, Josh Bloch talks a lot about the
benefits of making value objects immutable, and about objects being
“good citizens”, by being in a consistent and usable state immediately
after construction (rather than calling a bunch of setter methods to set
up the state before you can use the instance).
A string in Ruby seems to me to be just a convenient way of manipulating
a char array, with a bunch of useful methods such as regular expressions
thrown in. It should be treated no more “specially” than any other class
backed by an array. As Ged says, Ruby has the whole immutable value
object model sewn up much more consistently anyway, with the .freeze
method. You can make anything immutable whenever you like - including in
the initialize method of a well-behaved value object.
Looks to me like another victory for matz’s commitment to
non-astonishing behaviour - I don’t have to learn which objects are
constructed as immutable by default! I’m liking this language more and
more every day.
Now where’s that “final” keyword…?
Cheers,
Dan
Ged Byrne wrote:
···
Am I correct in thinking that as long as you avoid the
methods ending with an exclamation mark, then your
strings will be effectively immutable?
I agree that it sounds like a very ad hoc design
decision.
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.
This points to an important “philosophical”
difference that stands
out to me when comparing Ruby and Python: Python
gives me the feeling of
trying to be a “Language for the Masses” (LFM) and
tries to put
restrictions on what can be done. You need to format
your code in a certain
way, your strings (but only a minority of other
objects) are immutable by
default etc. As discussed on ll1-discuss mailing
list and
other places LFM’s are in contrast to LFSP’s
(Language for Smart People /
experts) that tries to give you as much power as
possible.
To me the LFM thinking is absurd and even inhumane
since it (ironically
enough) says that there is an elite that know the
area well enough to
decide what other people is allowed to use.
To me matz goal seems to be for less of an LFM than
Guidos.
Then again I have too little experience with Python
vs. Ruby to actually
know. I also may be exaggerating since also matz has
his limits (no
macros in Ruby, no multi-methods etc) ;).
Regards,
Robert Feldt
Ps. “Rough” Immutable strings in ruby:
s1 = “a”
s1[0] = ?b
p s1 # => b
def ims(string)
string.freeze
end
s2 = ims “a”
p s1 # => a
s2[0] = ?b # => `=': can’t modify frozen
string (TypeError)
This points to an important “philosophical” difference that stands
out to me when comparing Ruby and Python: Python gives me the feeling of
trying to be a “Language for the Masses” (LFM) and tries to put
restrictions on what can be done. You need to format your code in a certain
way, your strings (but only a minority of other objects) are immutable by
default etc. As discussed on ll1-discuss mailing list and
other places LFM’s are in contrast to LFSP’s (Language for Smart People /
experts) that tries to give you as much power as possible.
To me matz goal seems to be for less of an LFM than Guidos.
Yes. It’s a language for smart wannabe (i.e people trying to be
smart). I myself is one of them.
Thanks,
for nailing down why I find programming in Ruby sooo pleasurable;-))
This points to an important “philosophical” difference that stands
out to me when comparing Ruby and Python: Python gives me the feeling of
trying to be a “Language for the Masses” (LFM) and tries to put
restrictions on what can be done. You need to format your code in a
certain way, your strings (but only a minority of other objects) are
immutable by default etc. As discussed on ll1-discuss mailing list and
other places LFM’s are in contrast to LFSP’s (Language for Smart People
/
experts) that tries to give you as much power as possible.
This is not the reason Python’s strings are immutable,
and I don’t generally even agree that there’s such difference
between Python and Ruby (LFM vs LFSP). You’re probably just trying
to flatter yourself.
In so far as I use Ruby you mean? I didn’t want to give the impression
that I’m smarter because I use Ruby, but I’ve seriously tried to
switch over to Python and find it harder cause it makes me feel
more restricted.
But let’s not get into a flame war comparing languages (although I must
say Guido has a responsability as a representant for Python so why
should he go around “dissing” Ruby, at least thats the way his blog
comes out to me).
Python is also a rather unsafe language
that lets you do several dangerous but powerful things. Such
as redefining functions, classes or objects, or accessing any member
in a class. Also, What language doesn’t force you to format your code
in a certain way? A language with no syntax perhaps? Ruby forces
you to use do/end or {} (or something), Python uses indentation –
not a real difference, don’t you think?
Agreed, and I probably was exaggerating a bit. There are other things
than the indentation requirement and immutable strings that I was
thinking of. But overall I’d say they are very similar so the LFM/LSP
debate was not a good metaphor.
Strings, numbers and tuples are immutable in Python so that they
can be used as dictionary keys. I admit that one could do away
with this restriction by just choosing not to alter strings that
are used as dictionary keys. But allowing this to be done could
lead to subtle bugs, and making strings immutable doesn’t do much
harm, so why not make them immutable? It’s actually just a design
choice that weighted, which would lead to shorter dev times in
general: immutable or mutable strings. Guido thought it was the former.
I’ll refer to Objective C/Cocoa in this context again. In addition to
providing immutable and mutable string classes, Objective C/Cocoa
provides two dictionary classes, an immutable dictionary class and a
mutable dictionary class.
The idea that strings should have only one value with respect to
mutability strikes me as odd. Odder still is the rationale that this is
for the purpose of having objects to use as dictionary keys. Can’t key
mutability be handled at the dictionary level rather than at the level
of the constituents of the dictionary?
And while I’m on the subject, any object can be a key (or value) in a
Ruby hash (one isn’t limited to to tuples, strings and numbers for
keys).
And furthermore, if you want to programmatically avoid accidentally
overwriting keys, there are many other ways to do it without even
addressing mutability questions or checking for key existence before
insertion – for example, draw keys from a Set object, which guarantees
that each key taken from the set will be unique.
Finally, one can easily create, in Ruby alone, an environment with the
same model as mandated in Python, or an environment with the same model
used in Objective C/Cocoa, or any other environment.
There’s a reason I prefer Ruby to all other programming languages for
most tasks. It’s good to see the difference from other, otherwise quite
appealing languages, like Python.
Regards,
Mark
···
On Monday, August 18, 2003, at 01:21 PM, Hannu Kankaanpää wrote:
[snip]
Strings, numbers and tuples are immutable in Python so that they
can be used as dictionary keys. I admit that one could do away
with this restriction by just choosing not to alter strings that
are used as dictionary keys. But allowing this to be done could
lead to subtle bugs, and making strings immutable doesn’t do much
harm, so why not make them immutable? It’s actually just a design
choice that weighted, which would lead to shorter dev times in
general: immutable or mutable strings. Guido thought it was the former.
Ruby gets around this by dup-ing strings used as Hash keys, so the
problem doesn’t crop up.
Cheers
Dave
···
On Monday, August 18, 2003, at 12:21 PM, Hannu Kankaanpää wrote:
Strings, numbers and tuples are immutable in Python so that they
can be used as dictionary keys. I admit that one could do away
with this restriction by just choosing not to alter strings that
are used as dictionary keys.
Mutable strings also result in a more complicated implementation. One of
Python’s principles is to keep the implementation as simple as possible;
think of it as XP’s rule of “Do the simplest thing that can possibly work.”
Consider this code:
d = {}
s = ‘abc’
d[s] = 1
s.sub!(‘ab’, ‘cd’) # abc → cdc
Now what? If dictionaries don’t make copies of their keys, then mutating
the key means that the dictionary now stores a key value of “cdc”. But
because this probably changed the hash code, it’s now in the wrong hash
bucket. When you do d[‘cdc’], it will look in the wrong hash bucket, find
it empty, and report the key isn’t found.
So what’s a language implementor to do? You could have some sort of flag on
strings indicating ‘this is in a dictionary: no mutation’. You could keep a
list of “all dictionaries this string is used as a key in”, and when you
mutate the string rehash all of them. You could make copies of all keys in
dictionaries, but then someone will use a 3Mb string or a tree as a key and
complain that storing keys is slow. You can then try to figure out when
copying keys is necessary and skip it if it isn’t. All of this is more code
to write and more code to be a source of subtle bugs.
Immutable strings cut through all this; you don’t need code to handle these
cases because they never come up.
Python’s design was influenced by Guido’s experience with ABC. ABC went for
theoretical completeness and paid for it in implementation complexity.
Numbers were rationals, and users complained how they got mysteriously slow
after a lengthy computation. Dictionaries were AVL trees, with O(lg N) best
performance but a fairly high constant. Python therefore reacted in the
opposite direction, choosing the simplest implementation and avoiding
complexity as much as possible.
–amk (www.amk.ca)
A is for Adam and E is for Eve. B is for bile, blood and bones.
– Louis Andriessen & Jeroen van der Linden, “The Alphabet Song”
Strings, numbers and tuples are immutable in Python so that they
can be used as dictionary keys. I admit that one could do away
with this restriction by just choosing not to alter strings that
are used as dictionary keys. But allowing this to be done could
That may be the case, but such a pragmatic, agnostic consideration
can’t explain his words in the blog:
[…] (with the exception of Ruby’s mutable strings, which I find an
abomination).
Gavin
···
On Tuesday, August 19, 2003, 3:21:32 AM, Hannu wrote:
It’s actually just a design choice that weighted, which would lead
to shorter dev times in general: immutable or mutable strings. Guido
thought it was the former.
Mutable strings also result in a more complicated implementation. One
of
Python’s principles is to keep the implementation as simple as
possible;
think of it as XP’s rule of “Do the simplest thing that can possibly
work.”
I think this is part of Ruby’s overall philosophy – the focus is on
providing power to the programmer and secondarily on making the
language implementation simpler.
I am aware (as a result of reading what others have said and not from
experience), however, that this does make it harder to write the
interpreter, much less to write a Ruby compiler for a real or virtual
machine. I think this is one source of the tremendous feeling of
gratitude among Ruby users for matz’s work.
[snip]
So what’s a language implementor to do? You could have some sort of
flag on
strings indicating ‘this is in a dictionary: no mutation’.
Or you could do what Ruby does (as elucidated by Dave Thomas in
previous posts).
[snip]
Regards,
Mark
···
On Monday, August 18, 2003, at 04:01 PM, A.M. Kuchling wrote:
Koji Arai put together a Ruby Tk manual in Japanese. This manual looks
like it is very good (from the code samples). Has anyone translated it
into English, or is anyone working on an English translation, or is
anyone planning to do an English translation?
The Japanese language document is available through the RAA:
While we’re still on the subject of Python and Guido Von Rossum’s blog
entry, I noted the following:
"but for me the high point of the evening was Miguel de Icaza’s
excitement over Python’s feature which makes text files iterators
yielding the lines of the file in succession, so that you can write
That’s just Guido being Guido. I wouldn’t particularly read too much
into it (at least technically) besides that.
···
At 8:11 AM +0900 8/19/03, Gavin Sinclair wrote:
On Tuesday, August 19, 2003, 3:21:32 AM, Hannu wrote:
It’s actually just a design choice that weighted, which would lead
to shorter dev times in general: immutable or mutable strings. Guido
thought it was the former.
That may be the case, but such a pragmatic, agnostic consideration
can’t explain his words in the blog:
[…] (with the exception of Ruby’s mutable strings, which I find an
abomination).
–
Dan
--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai dan@sidhe.org have teddy bears and even
teddy bears get drunk
I think the point is that you would have to expressly access the Hash
key to modify it – modifications to the original string, if it’s kept
in existence, won’t affect the Hash key.
Regards,
Mark
···
On Monday, August 18, 2003, at 03:44 PM, Paul Brannan wrote:
On Tue, Aug 19, 2003 at 04:06:24AM +0900, Dave Thomas wrote:
Ruby gets around this by dup-ing strings used as Hash keys, so the
problem doesn’t crop up.
dup-ing and freezing. It would still be possible to modify the Hash
key
if the key were not frozen.
