SQLite

[Albert2 (Albert)]

Why does common operators like “=” , “and”, " …" , “or” etc …
can not be overloaded or redefined ?, maybe the complexity of the
Ruby parser comes from the fact that everything is ALMOST an
object or a method.

I don’t actually see this (that everything is “almost” an object).

I read this differently. Certain peculiarities in the english syntax led me
to suspect english-as-second language. I assumed, rightly or wrongly, that
Enric meant that: ALMOST everything is an object or a method.

> > > Why is not "=" a method? >

Again, I think a misunderstanding.

                 assignment        comparator

Smalltalk := =
Ruby = ==

···

On Saturday 02 November 2002 11:56 pm, Austin Ziegler wrote:

On Sun, 3 Nov 2002 10:57:29 +0900, Enric Lafont wrote:

–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay

[Enric_Lafont]

Hal E. Fulton wrote:

I would like to know…

Why does common operators like “=” , “and”, " …" , “or” etc … can
not be overloaded or redefined ?, maybe the complexity of the Ruby
parser comes from the fact that everything is ALMOST an object or a
method. Why is not “=” a method ?

Here is one way to look at it. A variable is essentially a reference
to an object. A method is invoked on an object. An object never
changes class (perhaps it can in Smalltalk?).

If I say: x = “hello”
then what is the receiver for the method call “=”? You can’t say it’s
x, because x is not an object.

On the other hand, the number 5 is an object. If I say: 5 = “hello”
does that mean that every reference to the number 4 is now a reference
to the string “hello”?

In Smalltalk is the same as in Ruby, a variable is a reference, a
variable can change the object it references, but the object never
changes (morphs), there are one exception, when an object morphs, it’s
destroyed and changed by a new one pointed by the same reference.

Same question for “and” and the rest
of operators that can not be redefined, Does the actual implementation
make life easier for the designer ? I say so because for me is more
natural when everything is an object (without exceptions, here Ruby
follows the rule pretty well) and a method is a method ever, not
sometimes. Some methods are keywords, and some other are not v.g. loop
vs. while. The every call is a method could simplify greatly the sintax
parser (look at the Smalltalk parser).

I can’t speak for Matz, but I have NEVER seen him make a design decision
because it made life easier for the designer rather than the programmer.

I have seen him make compromises for clarity or efficiency, however. I
suspect that these fall into these categories somewhere.

As for simplifying the parser: I think you will agree it is better to
have a readable, usable language than a simple parser.

Sometimes languages that are very powerful have difficult syntax (LISP,
Smalltalk, etc.). LISP is arguably the most powerful language in the
world, but people find it difficult to learn and use. Ruby is full of
compromises in its design.

I don’t know a lot of Lisp, but everything I can do in Lisp I can do in
Smalltalk also and is much more readable.

I think that the parser is dificult because you just need to look at how
the language are defined, a pseudo-BNC notation, this is the think that
makes me thing that the language has a complicated parser.

Why primitives are hidden ? In smalltalk you can call a primitive every
time you want with a <primitive: aNumber> , this way the implementation
of native methods, and in some way native Classes like String are not
hidden from the programmer, freeing the programmer to change the
behaviour if needed. Yes you can have the “required” clause and use
binary libraries, but would not be much more “natural” to have a
“require string” when you want to invoque string libraries instead of
having them loaded all the time ?. I want to say here that the
“primitive” keyword frees the language from it’s implementation. This
favours the everything is a module aproach.

I’m not sure about everything you’re asking here. But you can in fact
change the behavior of the standard classes, since the classes are “open.”
There are many examples of this in TRW.

Yes, you can redefine any method, the alias directive helps here but I
would like to have a String.rb file instead of a String.c like I have a
Matrix.rb.

Sintax Sugar (SS), other thing difficult to understand for me, the
question here is why ? Everything has exceptions very few things are
orthogonal with the principe that must drive it, you can wite a.+(3) or
a + 3 or a.+ 3 or a hundred other ways to write the same thing, yes,
this gives you freedom, but a bad deserved (not needed) one. I use one
form, but when I read programs from other persons the code seems strange
and somewhat dificult to read. Sometimes SS is right, v.g. x +=1, but
the every call is a method aproach could give you the same results
without trouble, in this case += could be a method. As could be “++” or
others.

In Ruby, a += b means a = a + b ALWAYS, without fail. This means that you
get += “for free” when you define +, and you are spared having to write
both. If you want += to have some other meaning, I would have to ask “Why?”
It seems logical to me to tie the meaning of += to + (unlike C++).

OK, if you have a
def += (anArgument)
return (self + anArgument)
end

You will have exactly the same behaviour you have know, whitout any trick

As for ++ and --, these are impossible in Ruby for much the same reason
I mentioned before. They are operations on variables, whereas Ruby methods
and operators work on objects. If I say: x++ I am trying to increment
the OBJECT that x refers to. Does this mean that every variable with the
same value should be changed also? For that matter, what should 5++ mean?

Equally, you could define a

def Object::++(anArgument) # Yes, the sintaxis is bad, I try to
explain my point of view
return anArgument + 1
end

AND

def Integer::++
return self + 1
end

And you have NOW for free a pre-increment and a post increment.
This tries to explain the POWER of the every call is a method

Undeclared variables, I don’t know other people but I do fast typing and
writing “aVariable” and “aVariabel” is a mistake that I can do very
easily. Yes you can say, type more slowly, but this is not a solution, I
would like to have a way to force the compiler to generate a warning
when I use a non pre-declared (or pre asigned) variable.

If you use it on the right hand side, it will be an error.

It was difficult for me to get used to a language without variable
declarations. But it seems to be a thing which Matz always insists on.
And I got used to it, and now I like it.

it will be an error because some method will fail, but and undefined
variable is nil, so it’s a valid object. This is something that IMHO is
an error.

Why are Strings arrays of integers ? aString[0] is an integer, yes, it’s
the way it is, but I would like to have String as an array of chars, and
char if you want as a descendant of Integer (nice election because a
Unicode String is and array of double chars i.e. integer), I don’t know
you, but for me aString[i].chr ==‘x’ is somewhat unnatural, because it
breaks the semantic of a String, so it’s not intuitive for me.

This was never intuitive for me either.

Thanks, at least I’m not the only one

Why is Ruby an interpreter ? Yes the less traditional bytecode aproach,
can be harder (or not), but enables external optimizations more easily
(JIT and similars) because the language are separated from the
implementation, enables reduced footprint and gives faster execution
times, yes, look at how Self executes programs, it’s amazingly fast (and
incredibly complex also), but a separated implementation could help
develop better Ruby-engines.

This is planned. Matz wants to add bytecodes to 2.0 I think (which is
still vaporware). In addition, Parrot is being designed not just with
Perl in mind but Python and Ruby as well. So it should be possible to
write a Parrotized version as well (though it has not been done yet).

There is also JRuby, which strives for interoperation with Java. I have
not played with it yet.

I’ve taked a look at parrot, and it seems to be an interesting project,

Don’t get me wrong, I understand that Ruby is a young language that
needs some maturing, and I love how easy is to learn, it’s dinamicity
and the fact that is a kind of mix between my loved Smalltalk, Self and
other languages. In fact I’m writing this because I want to understand
Ruby better and becasue I want to make some suggestions for future
releases, maybe Mr. Matsumoto would like to consider some of them

My advice is to wait 90 days before suggesting language changes.
Every newbie makes these suggestions (as I guess I did too). But most
of them have been thought of before (as a search of the list archives
will show). Some are under consideration, some are planned for the
future, and some have been rejected by Matz.

My comments appeared, becasue Ruby is really very similar to Smalltalk,
just the small diferences makes Ruby less powerfull that it can be.

Just as an example, the closures are not objects, yes you can
“objectify” a closure, but closures seems to be a patch to the language
instead of an extension of it.

There are more things that I see as strange in Ruby, but this is enought
for now …

Please if I’ve make any inaccuracy , don’t be too rude with me, I’m
still learning, and I’ve a loooong way before understand everyting. I’m
just looking for answers.

I hope no one here is rude to you. If someone is, we will
come to your defense…

Thanks, if someone bothers me, I will tell you , so you can defend me
.,.,…

Enric

[Enric_Lafont]

Albert Wagner wrote:

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are simply
messages to an object. In Ruby “operators” are neither objects nor messages,
but are rather handled as in more conventional languages. I don’t know why
Matz only went part way. This part-way-ness is also visible in other
aspects of the language such as “if”, “while”, etc. In Ruby these things
also are neither object nor message. Whereas in Smalltalk, such constructs
are messages to a Boolean object.

Yes, this is one think I don’t understand of the design on Ruby, it
makes Ruby more C-alike, but looses the expresiveness of Smalltalk, when
in fact Ruby is almost as OO pure as Smalltalk is.

Again, what can I say? Ruby is not Smalltalk. Large amounts of functionality
that in Smalltalk were written in Smalltalk, were in Ruby written in C.

Smalltalk is writed in C also, take a look at the bytecode engine, just
better, look at Squeak, the C code is generated by the compiler itself

I agree with you for the same reasons you give. I am a hater of syntax sugar.

I don’t hate sintax sugar, I just see Sintax sugar as a poor replacement
for the real thing, every call is a method.

When in fact the only thing you loose is the multi asignament
capabilities, but I’m sure that I can think in a way to do it.

This is a difference that I have grown to like. Running back to the top of a
method every I need a variable name was tedious.

OK, I don’t like to go to the top of the routine just to put a forgotten
variable, but in C and in other languages, you can declare a variable in
the middle of the code (where it belongs, near the place you are going
to use it).

I’m just asking for a compiler warning telling me that some variable is
undefined, this will really help me .

Why are Strings arrays of integers ? aString[0] is an integer, yes, it’s
the way it is, but I would like to have String as an array of chars, and
char if you want as a descendant of Integer (nice election because a
Unicode String is and array of double chars i.e. integer), I don’t know
you, but for me aString[i].chr ==‘x’ is somewhat unnatural, because it
breaks the semantic of a String, so it’s not intuitive for me.

It is not intuitive to many people. There have been long discussions on the
pros and cons.

The problem is that Ruby has no Char class, and maybe it’s not needed,
but a Char class helps.
For example
?# is an integer
‘#’ is a String

When in fact is neither, it is a Char. This is the problem mixed semantics.

Why is Ruby an interpreter ?

All the things you mention are under consideration or under development.

Thanks God !!! (just kidding…)

Don’t get me wrong, I understand that Ruby is a young language that
needs some maturing, and I love how easy is to learn, it’s dinamicity
and the fact that is a kind of mix between my loved Smalltalk, Self and
other languages. In fact I’m writing this because I want to understand
Ruby better and becasue I want to make some suggestions for future
releases, maybe Mr. Matsumoto would like to consider some of them

Most of the features I loved about Smalltalk are in Ruby. But what I do not
miss from Smalltalk is fact that it is image based. Ruby is not, and I think
that is a good thing.

Yes the Smalltalk environmet is a heavy rock to carry with it, there are
solutions to this problem, but I also prefer the file-oriented
programing paradign of Ruby

I think you will find that this is a very friendly list. Welcome.

Thank you.

Enric

[Enric_Lafont]

Austin Ziegler wrote:

I don’t actually see this (that everything is “almost” an object).
Personally, I think that matz has made the right choice in making
boolean operations (and, &&, or, ||) invariant in the language. You
can, by the way, redefine the bit operators (& and |). There’s
nothing worse than a language which doesn’t do what you expect it to
do with conditionals, and it does so on the whim of another
programmer.

Ok, you are right, it’s Mr. Matz decission, but, why then can I redefine
the “and” method ? It must be a method in the very first time, not an
exception.

Why is not “=” a method?

Because it’s not something done to objects, but to reference
variables that we use to manipulate objects. I’m really curious as
to why one would want to redefine assignment in the first place. I
mean, seriously. It’s not like this is C++ where you have to
reinvent everything every time you work with the bloody language.

It’s not a question to redefine the “=” operator it’s a question of
orthogonality, what you learn for one thing is equally applicable to
other parts of the language, it’s interesting some times to have the
option to redefine the equal operator, but in most of the cases doing so
is adding a real complexity to the understanding of the program, this
does not means, that if you need to do it you can

Same question for “and” and the rest of operators that can not be
redefined, Does the actual implementation make life easier for the
designer ? I say so because for me is more natural when everything
is an object (without exceptions, here Ruby follows the rule
pretty well) and a method is a method ever, not sometimes.

This is just MNSHO, but again I don’t see why one would want to
allow such basic constructs to be redefined. IMO, you can redefine
everything except boolean tests and still have a useful – if obtuse
– language; if you try to redefine those, you’re not going to be
able to have any determinacy with the programs that are written.

You can…

class TrueClass
def and (anArgument)
return “hello”
end
end

I’ve redefined the and, it does not work, but it does not generate any
warning or error…

Why is it necessary to access the primitives? IMO, Java’s biggest
problem is that it makes the primitives available. In Ruby, by the
way, I can still change the behaviour of String – this is where
Ruby differs from every other language that I’ve ever used: it’s
dynamic. If I need a new function on String, I can add it whenever I
need. I’m looking at extending the functionality of a library that
I’ve ported so that it can optionally extend String and Array to
include this library as methods on String and Array instead of as
something else to operate on a String or an Array.

Yes it’s not needed, in Basic, you can not access the primitives and the
language is still working, but Ruby is much more powerful and flexible,
not because you can access the primitives, but because the language
gives you more options. The primitive access is just another option.

Consider for example the string extension you want

class String
def strExtension
call libStrgExtension.o:110
end
end

It’s not this way much more easy to do?

Yes you can have the “required” clause and use binary libraries,
but would not be much more “natural” to have a “require string”
when you want to invoque string libraries instead of having them
loaded all the time ?. I want to say here that the “primitive”
keyword frees the language from it’s implementation. This favours
the everything is a module aproach.

I disagree – allowing access to the primitives ties the developer
very tightly to the local implemententation of the language. I don’t
particularly care whether or not my integers are 32-bit or 64-bit or
even larger – I just expect them to do what they should do (and
that means possibly upclassing to a BigNum class if I exceed the
word size). I think that the only thing that I’d like to see in this
regard is for Ruby to take a page from Ada and allow me to define
ranges as types (that is, I want to be able to automatically define
a class UInt64 < Integer [(-264) … (264 - 1)] and have it do
the Right Thing).

Ok, you have a good point here. Ruby now deals with primitives, and you
don’t care if the Integer is 32 or 64 bits, it’s just an integer, you
can care of their limits only. Any development using explicit
primitives are not going to change this

class Integer # In a 32 bit environment
def sqrt
call libRubyMath.o:110
end
end

class Integer # In a 64 bit environment
def sqrt
call libRubyMath.o:110
end
end

Oh!!! it’s the same !!!, Why there is no diference ? because Ruby is
tied to the environment where it is working, as happens now, you invoque
ruby from the command line and you don’t care if the system is 32 or 64
bits, you make now primitive calls implicitly, as much as you don’t care
if the system is Linux or Windows (ok, without using plattform extensions)

It would NOT be much more natural to require every bloody module I
need every time I need it. A language – especially a language like
Ruby, where Strings are fundamental to everything – isn’t useful
without certain defaults. Would it not make equal sense to “require
integer” when I need to use integers, or are you suggesting that
those are fundamentals and are always included? Strings are part of
what makes Ruby useful immediately (the same applies to Files)
because it’s a scrpiting language.

I did put “String” as an example, but in fact the only needed module is
“kernel”, the base of the language, where Object, Boolean, and Magnitude
are defned (in Ruby there is no Boolean class and no Magnitude, but you
have Fixnum and TrueClass and FalseClass, I think that this is going to
change in the future). The rest are extensions, what an OO language is
supposed to deal with.

I’m sorry, but I don’t understand what you’re getting at here. The
three examples you gave:

a.+(3)
a.+ 3
a + 3

are actually the only ways to express that thought (without getting
silly wrt parenthesis). Ruby explicitly makes parentheses optional
on method calls. Parentheses make complex operations easier to read,
certainly, and can prevent confusion for the interpreter and
programmer, as when you have:

a b, c d
// Is this a(b, c(d)) – OR
// a(b), c(d)

This means only that “a + 3” is syntactic sugar for “a.+(3)” because
it is fundamentally more natural for most people to write “a + 3”
than either “a.+(3)” or even RPN “a 3 +”. Again, matz has made the
proper choice – it keeps the language easily accessible.

You will like then the Perl’s “there is a hundred ways to do it”
slogan…

The fact that there is more than one way to express something, weakens
the mastery of the language. It’s right sometimes becasue it makes
things so “eye sugar” , but I prefer ( I PREFER, it’s me, my option) a
one way to do things, it makes things easy to code and easy to read your
own code and the one made by others.

Actually, it can’t give you the same results without trouble. C++
is trouble because it allows the definition of:

a = a + b // a.=(a.+(b))

to be different from:

a += b // a.+=(b)

If the result of the first call isn’t the same as the result of the
second call, then there’s a disconnect which has to be documented.
Matz made the right choice here, I think, because it prevents this
sort of stupidity that C++ allows. (And this isn’t ‘prevention’ in
the way that I think GvR was beyond silly to require indentation for
block definition in Python.)

I disagree, You loose flexibility, it does not mean that you need to use
it, it means that you have the flexibility there when you need it.

Anyways, if I define a.+=b to be diferent from a.=a.+b it’s my own fault
for using bad semantincs, but it can be posible that someone must be
interested in having side efects associated with the += operator (as in
C++, and yes it’s troublesome). In Smalltalk you can do it and there are
no problems with the added flexibility, contrary to C++ where a lot of
programmers started to do OOP without a solid background on OO analisys,
this bring us the problems with C++

The interpreter will warn you of this, to some degree. If I try to
use an undefined variable, it will complain (at least with 1.7)
because the value is unknown (it’s not even properly ‘nil’). This
won’t help, however, if you have two similarly named variables.

OK, I’ll try…I’m using Linux with 1.6. Anyways a warning would be a
great addition, you will catch the error at compile time instead of at
run-time.

This one is easy: because it was a design decision made earlier. A
new version of String is being worked on, to the best of my
knowledge, that will deal with characters – but this leaves the
problem of existing code which will break because it uses the
current implementation.

It does not need to break nothing a character is an integer with a dual
personality, maybe you will just need to redefine some methods based on
the arguments, but I don’t foresee serious problems.

A bytecode system is being worked on, to the best of my knowledge.

Someone pointed me to Parrot, I’ve done him just a look, and it’s
interesting.

Enric

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

···

In message “Re: Thoughts on Ruby” on 02/11/03, Albert Wagner alwagner@tcac.net writes:

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are simply
messages to an object. In Ruby “operators” are neither objects nor messages,
but are rather handled as in more conventional languages. I don’t know why
Matz only went part way. This part-way-ness is also visible in other
aspects of the language such as “if”, “while”, etc. In Ruby these things
also are neither object nor message. Whereas in Smalltalk, such constructs
are messages to a Boolean object.

They simply cannot implemented as methods.

“=” is assignment, which is not a method even in Smalltalk (:=).
"“and”, “or” and “…” are control structures, which also are not
methods in most implementation of Smalltalk.

						matz.

[Enric_Lafont]

Vincent Foley wrote:

When I started learning Ruby, some things didn’t feel natural (strings
as integer arrays for example), but I eventually learned to cope with
these and also, not think too much of the features I would like to have
(conses, tail-recursion optimization, etc.) Language designers do their
best to write a language that the actual community continues to like.
Larry Wall listens to the Perl people and if their suggestions make
sense, he probably adds them. Same goes for Guido Van Rossum and
Python. And matz listens to the Ruby community (he’s pretty active in
this ML).

Just give it time, eventually the large number of nice features in Ruby
will make it easier for you to accept the little annoyances.

This is one of the reasons for this thread.

Oh, welcome in the Ruby world!

Thank you, I’m becoming now very proficient, I’m really surprised of the
compacness of the language and the incredible cuantity of lines I can
write every day, the bad thing is that the exceptions of Ruby forces me
to spend a lot of time debugging the programms, I’m sure that in the
future things will be easier.

Enric

[Ara.T.Howard1 (Ara.T.Howard)]

[timidly snipping - hopefully it’s o.k. …]

cowardly leaving myself out) refactor this recurring `human code’ into
a wiki or whatever, and redirect people there? We don’t want
ruby-talk to become ruby-design-advocacy, right?
[snip]

i agree with you.

i am relatively new to newsgroups in general, but it seems like comments like
these suggest a move towards splitting into sub-groups may be in order? to
follow your great analogy Massimiliano, when i see this

def Module
…
50,000 lines of semi-related lines of code
…
end

i would suggest a splitting out. i’ve heard the arguments for and against,
but i would really like to see a small split : some groups seem to split too
much and people then use only one or two groups anyhow so something like

ruby-beginers
ruby-advocacy
ruby-devel
ruby-really-tough-questions-for-the-gurus
ruby-drivel

or maybe just

ruby-easy-questions
ruby-hard-questions
ruby-talk

might suffice. the groups split by api’s never seem that productive imo. i
would really like to see advocacy type stuff out of here, or at least some
way to locate the real gems some of the gurus on this list kindly post to all
the questions posed, stupid ones and hard ones alike. imo the best thing
about this group is that you CAN ask a question - and get an answer, not a
flame. i have really apreciated the help given to me on this list and try
to do the same for others - is it just me or is this not the best thing about
a newsgroup like this one? if i’m in the minority then perhaps i’d suggest

ruby-programming

be formed because that’s what i love to do with ruby, and ruby-talk is where i
go for help.

-a

···

On Mon, 4 Nov 2002, Massimiliano Mirra wrote:

–

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================

[Albert2 (Albert)]

Sorry for starting a new thread on this, but the original post was forked
from a non-related thread, the subject of which I keep forgeting. Below,
Massimiliano is calling for a solution to a recurring problem that I have
been a large part of. I apologize for my excesses and give my agreement to
what he proposes. I would personally prefer that there be only one place to
look for answers to the problems discussed below. So I vote for an extended
FAQ, that includes William’s ``List of things that newcomer to Ruby should
know’’ and sections that summarize threads such as this:
Why and How is Ruby different from <my last/favorite language>
I believe that the FAQ is the appropriate place for such things because it
serves this function on so many other lists. After all, the complaint is
that these are Frequently Asked Questions.

···

On Monday 04 November 2002 8:46 am, Massimiliano Mirra wrote:

Folks, what do you do when you see code like this?

c1 = 3 * 3 * Math::PI

c2 = 6 * 6 * Math::PI

c3 = 21 * 21 * Math::PI

You refactor, right?

def area(r)
  return r * r * Math::PI
end

c1 = area(3)
c2 = area(6)
c3 = area(21)

So we’ve got wisdom in programming. Can we please apply it
in life, too?

It’s simply too much to leave the list for a couple of days and find
half a hundred messages resurrecting topics (and beating them to death
again) such as:

- Alternatives in syntax or `There is more than one way to write
  it'
- Overloading '='
- Declaring variables
- Compiling Ruby to bytecode or whatever

First it was because Ruby is different than Pythong, then because it
is different than C++, now because it is different than Smalltalk,
tomorrow because it is different than God knows what.

Can we (or at least those who still have energy to answer, and yes I’m
cowardly leaving myself out) refactor this recurring `human code’ into
a wiki or whatever, and redirect people there? We don’t want
ruby-talk to become ruby-design-advocacy, right? And we don’t want
matz to waste his time justifying design decisions (which thankfully
he does very seldom already)?

William’s List of things that newcomer to Ruby should know'' does a great job of satisfying the practical concerns (How does it work
like…?‘’). Something is needed for the philosophical/theoretical
side (``Why is it like…?‘’).

Does this make sense?

Massimiliano

–
“Every real thought on every real subject knocks the
wind out of somebody or other.”
-Oliver Wendell Holmes, Sr.

[Albert2 (Albert)]

Albert Wagner wrote:

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are
simply messages to an object. In Ruby “operators” are neither objects
nor messages, but are rather handled as in more conventional languages.
I don’t know why Matz only went part way. This part-way-ness is also
visible in other aspects of the language such as “if”, “while”, etc. In
Ruby these things also are neither object nor message. Whereas in
Smalltalk, such constructs are messages to a Boolean object.

If Ruby went all the way on this, like Smalltalk does, then Ruby would
almost be Smalltalk.
The unique about Ruby is that it combines the OO-ness of Smalltalk with
a more conventional syntax. I love Smalltalk’s syntax, but it did scare
a lot of people away.

Yes, superficially, just looking at a piece of Smalltalk code, without
understanding what it means, a lot of people come away with the wrong idea:
“Smalltalk syntax is wierd and complicated”. Actually, Smalltalk syntax is
absurdly simple: There are ONLY objects and messages. e.g.

conventional language:

if
codeExecutedIfBooleanIsTrue
else
code ExecutedIfBooleanIsFalse
end

Smalltalk:

IfTrue: [ codeExecutedIfBooleanIsTrue] IfFalse: [ codeExecutedIfBooleanIsFalse]

This does indeed look strange and complicated until you realize that <boolean

is an object, that can be sent the message IfTrue: with a code
block as an argument that is evaluated by the boolean object if <boolean
evaluates to True. It is exactly the same syntax as:

[boolean expression] # object is code block that answers a boolean
whileTrue: [ code here ] # whileTrue: is message sent to code block

and:

1 to: 6 do: [ :integer | code here ] # object is integer 1
# to: 6 do: is message sent to integer 1

It is this consistency in pure languages that cause problems for people coming
from such languages to Ruby. The corrolary is people coming from simple
procedural languages (C) and hybrid languages (C++) who have trouble grasping
the almost pureness of Ruby. Ruby sits midway between canonical pure OOP
(Smalltalk) and procedural/hybrid languages. Whether you enter Ruby from the
left or right you are bound to be suprised.

···

On Sunday 03 November 2002 5:53 am, Anders Bengtsson wrote:

–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay

[Albert2 (Albert)]

From: “Albert Wagner” alwagner@tcac.net

[Enric:]
Why are Strings arrays of integers ? aString[0] is an integer, yes,
it’s the way it is, but I would like to have String as an array of
chars, and char if you want as a descendant of Integer (nice election
because a Unicode String is and array of double chars i.e. integer), I
don’t know you, but for me aString[i].chr ==‘x’ is somewhat unnatural,
because it breaks the semantic of a String, so it’s not intuitive for
me.

It is not intuitive to many people. There have been long discussions on
the pros and cons.

It’s probably not intuitive to anybody (except perhaps Matz). However, I
see no particular justification for it being any other way, and in fact
it’s changing in 1.7 isn’t it? Anyway, my point is: you’ll never forget it
now. And if you’re like me, you won’t care either.

But to nitpick, a String is not an array of integers. It is a String

Other options, if you’re testing equality of an individual character:

string[i] == ?x
string[i,1] == “x”

So that no one misunderstand my comments about Smalltalk. I don’t mean to
imply that I think Ruby is flawed to the extent that it is not Smalltalk. I
am quite pragmatic about languages: I dislike intensely the image aspects
of Smalltalk. I very much like “require”, “include”, et al in Ruby.

···

On Sunday 03 November 2002 6:12 am, Gavin Sinclair wrote:

Cheers,
Gavin

–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay

[Austin_Ziegler2 (Austin Ziegler)]

Why does common operators like “=” , “and”, " …" , “or” etc …
can not be overloaded or redefined ?, maybe the complexity of
the Ruby parser comes from the fact that everything is ALMOST an
object or a method.
I don’t actually see this (that everything is “almost” an
object).
I read this differently. Certain peculiarities in the english
syntax led me to suspect english-as-second language. I assumed,
rightly or wrongly, that Enric meant that: ALMOST everything is an
object or a method.

I tried to read beyond the ESL. I still don’t see that “almost
everything is an object or method”. To me, everything in Ruby is
an object, and with the exception of boolean combinations and
keywords (and, or, etc.), everything else is a method – even if it
doesn’t have to be written that way. (I agree that from a SmallTalk
perspective that the fact that loops & such aren’t messages does
appear weird.)

Why is not “=” a method?
Again, I think a misunderstanding.

        assignment    comparator

Smalltalk := =
Ruby = ==

I’m not sure. ‘=’ isn’t a method, and it doesn’t make sense to be a
method. ‘==’ is a method and it’s redefinable.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.03 at 14.45.48

···

On Mon, 4 Nov 2002 04:39:35 +0900, Albert Wagner wrote:

On Saturday 02 November 2002 11:56 pm, Austin Ziegler wrote:

On Sun, 3 Nov 2002 10:57:29 +0900, Enric Lafont wrote:

[Enric_Lafont]

Gavin Sinclair wrote:

It’s probably not intuitive to anybody (except perhaps Matz). However, I see
no particular justification for it being any other way, and in fact it’s
changing in 1.7 isn’t it? Anyway, my point is: you’ll never forget it now.
And if you’re like me, you won’t care either.

But to nitpick, a String is not an array of integers. It is a String

Other options, if you’re testing equality of an individual character:

string[i] == ?x
string[i,1] == “x”

OK, Gavin, you are right, it’s an exception, you must deal with it, the
problem is that Ruby has too many exceptions, and when I debug my
programs, most of my errors are this exceptions. I’m starting, it’s
right, but it’s very frustating when all the debuging is just for non
orthogonal sintaxis, this denotes a lack of maturity in the language,
and is one of the things I wanted to put on top of table, so someone can
take a think on it.

Enric

···

[Austin_Ziegler2 (Austin Ziegler)]

Hal Fulton:
In Ruby, a += b means a = a + b ALWAYS, without fail. This means
that you get += “for free” when you define +, and you are spared
having to write both. If you want += to have some other meaning,
I would have to ask “Why?” It seems logical to me to tie the
meaning of += to + (unlike C++).
OK, if you have a:
def += (anArgument)
return (self + anArgument)
end

You will have exactly the same behaviour you have know, whitout
any trick

The problem, of course, is that I can now do:

def +=(anArgument)
return (self - anArgument)
end

This subverts the whole point of +=.

As for ++ and --, these are impossible in Ruby for much the same
reason I mentioned before. They are operations on variables,
whereas Ruby methods and operators work on objects. If I say: x++
I am trying to increment the OBJECT that x refers to. Does this
mean that every variable with the same value should be changed
also? For that matter, what should 5++ mean?
Equally, you could define a
def Object::++(anArgument)
return anArgument + 1
end

AND

def Integer::++
return self + 1
end

What, then, is the result of:

“foo”++

? Also, your definition of ++ with an argument makes no sense.

And you have NOW for free a pre-increment and a post increment.
This tries to explain the POWER of the every call is a method

Really, though, it doesn’t explain it. It explains why you think
that Ruby should have += as a separate method and that it should
have ++/-- operators (even as methods), but it’s not clear why you
think that this demonstrates “every call is a method.”

Undeclared variables, I don’t know other people but I do fast
typing and writing “aVariable” and “aVariabel” is a mistake
that I can do very easily. Yes you can say, type more slowly,
but this is not a solution, I would like to have a way to force
the compiler to generate a warning when I use a non
pre-declared (or pre asigned) variable.
If you use it on the right hand side, it will be an error.

It was difficult for me to get used to a language without
variable declarations. But it seems to be a thing which Matz
always insists on. And I got used to it, and now I like it.
it will be an error because some method will fail, but and
undefined variable is nil, so it’s a valid object. This is
something that IMHO is an error.

Again; on the RHS (including either side of a a boolean test), it
is an error. On the LHS, however, it won’t be – because LHS is an
assignment. I just did the following:

p b == a

I got:

NameError: undefined local variable or method `b’ for
#Object:0x2789330

I don’t think that it’s necessary to require declaration.

Why are Strings arrays of integers ? aString[0] is an integer,
yes, it’s the way it is, but I would like to have String as an
array of chars, and char if you want as a descendant of Integer
(nice election because a Unicode String is and array of double
chars i.e. integer), I don’t know you, but for me aString[i].chr
==‘x’ is somewhat unnatural, because it breaks the semantic of a
String, so it’s not intuitive for me.
This was never intuitive for me either.
Thanks, at least I’m not the only one

It’s not intuitive – it’s bitten me more than once. But it’s also
something that as I said earlier is a clear issue. I think that it
will be fixed by 2.0, if not earlier.

Don’t get me wrong, I understand that Ruby is a young language
that needs some maturing, and I love how easy is to learn, it’s
dinamicity and the fact that is a kind of mix between my loved
Smalltalk, Self and other languages. In fact I’m writing this
because I want to understand Ruby better and becasue I want to
make some suggestions for future releases, maybe Mr. Matsumoto
would like to consider some of them
My advice is to wait 90 days before suggesting language changes.
Every newbie makes these suggestions (as I guess I did too).
But most of them have been thought of before (as a search of the
list archives will show). Some are under consideration, some are
planned for the future, and some have been rejected by Matz.
My comments appeared, becasue Ruby is really very similar to
Smalltalk, just the small diferences makes Ruby less powerfull
that it can be.

I disagree that it reduces Ruby’s power. I’m already finding Ruby to
be the most expressive language that I’ve ever dealt with, bar none.

Just as an example, the closures are not objects, yes you can
“objectify” a closure, but closures seems to be a patch to the
language instead of an extension of it.

This isn’t true.

def foo(a, &b)
p a
p b.arity
end

foo(“foo”) { |a| p “foo” }
foo(“bar”) { |a, b| p “bar” }
foo(“baz”) { |a, *b| p “baz” }

No, you can’t do { |a| p “foo” }.arity, but IMO this is a feature,
not a bug.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.03 at 15.52.53

···

On Mon, 4 Nov 2002 05:42:37 +0900, Enric Lafont wrote:

[Enric_Lafont]

Anders Bengtsson wrote:

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are simply
messages to an object. In Ruby “operators” are neither objects nor messages,
but are rather handled as in more conventional languages. I don’t know why
Matz only went part way. This part-way-ness is also visible in other
aspects of the language such as “if”, “while”, etc. In Ruby these things
also are neither object nor message. Whereas in Smalltalk, such constructs
are messages to a Boolean object.

If Ruby went all the way on this, like Smalltalk does, then Ruby would
almost be Smalltalk.
The unique about Ruby is that it combines the OO-ness of Smalltalk with
a more conventional syntax. I love Smalltalk’s syntax, but it did scare
a lot of people away.

(It can be argued that you could do “if” as messages internally, which
is left as an excercise to the reader

For me Ruby is almost Smalltalk, yes it uses a sintaxis that more
closely resembles traditional 3G languages, and uses a more restricted
environment, this and the file orientation, is what makes Ruby more
suitable for Scripting.

Enric

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

(regarding the fact “abc”[0] being fixnum)

It’s probably not intuitive to anybody (except perhaps Matz). However, I see
no particular justification for it being any other way, and in fact it’s
changing in 1.7 isn’t it? Anyway, my point is: you’ll never forget it now.
And if you’re like me, you won’t care either.

It will in 1.9 or later.

						matz.

···

In message “Re: Thoughts on Ruby” on 02/11/03, “Gavin Sinclair” gsinclair@soyabean.com.au writes:

[Austin_Ziegler2 (Austin Ziegler)]

Austin Ziegler wrote:

I don’t actually see this (that everything is “almost” an
object). Personally, I think that matz has made the right choice
in making boolean operations (and, &&, or, ||) invariant in the
language. You can, by the way, redefine the bit operators (&and

). There’s nothing worse than a language which doesn’t do what
you expect it to do with conditionals, and it does so on the whim
of another programmer.
Ok, you are right, it’s Mr. Matz decission, but, why then can I
redefine the “and” method ? It must be a method in the very first
time, not an exception.

class Foo
def and(o)
“and”
end
end

f = Foo.new
p f
p f and nil
p (f and nil)
p f.and(“o”)

If you run this, you’ll see that Foo#and isn’t related to the
boolean operation at all. Thus, while you can define an ‘and’
method, you are not redefining the ‘and’ boolean operator.

You can redefine the ‘&’ (bitwise-and) operator, because that’s
actually a method ‘&’. So, I’m not sure what you’re really asking
for, here.

Why is not “=” a method?
Because it’s not something done to objects, but to reference
variables that we use to manipulate objects. I’m really curious
as to why one would want to redefine assignment in the first
place. I mean, seriously. It’s not like this is C++ where you
have to reinvent everything every time you work with the bloody
language.
It’s not a question to redefine the “=” operator it’s a question
of orthogonality, what you learn for one thing is equally
applicable to other parts of the language, it’s interesting some
times to have the option to redefine the equal operator, but in
most of the cases doing so is adding a real complexity to the
understanding of the program, this does not means, that if you
need to do it you can

There is no orthogonality allowed by the redefinition of assignment
in Ruby – or in any other language that I’ve ever dealt with. What
it does is creates “exceptions” – and that violates orthogonality.
Beyond that, since “=” (which is ASSIGNMENT in Ruby) isn’t done to
objects, but to references. You can, of course, easily redefine
‘==’ (COMPARISON).

Same question for “and” and the rest of operators that can not
be redefined, Does the actual implementation make life easier
for the designer ? I say so because for me is more natural when
everything is an object (without exceptions, here Ruby follows
the rule pretty well) and a method is a method ever, not
sometimes.
This is just MNSHO, but again I don’t see why one would want to
allow such basic constructs to be redefined. IMO, you can
redefine everything except boolean tests and still have a useful
– if obtuse – language; if you try to redefine those, you’re
not going to be able to have any determinacy with the programs
that are written.
You can…

class TrueClass
def and (anArgument)
return “hello”
end
end

I’ve redefined the and, it does not work, but it does not generate
any warning or error…

I just did that – and I still get the “and” that I expect. As I
pointed out above, “and” isn’t a method. Just because you can define
a method that is named the same as a keyword doesn’t mean that it
will actually be that keyword.

Why is it necessary to access the primitives? IMO, Java’s biggest
problem is that it makes the primitives available. In Ruby, by
the way, I can still change the behaviour of String – this is
where Ruby differs from every other language that I’ve ever used:
it’s dynamic. If I need a new function on String, I can add it
whenever I need. I’m looking at extending the functionality of a
library that I’ve ported so that it can optionally extend String
and Array to include this library as methods on String and Array
instead of as something else to operate on a String or an Array.
Yes it’s not needed, in Basic, you can not access the primitives
and the language is still working, but Ruby is much more powerful
and flexible, not because you can access the primitives, but
because the language gives you more options. The primitive access
is just another option.

IMO, Ruby is more expressive than Java – which gives access to the
primitives behind a lot of objects.

Consider for example the string extension you want
class String
def strExtension
call libStrgExtension.o:110
end
end

It’s not this way much more easy to do?

No, it isn’t, actually. Mostly because my library is written in Ruby
itself, but also because Ruby has clear and easy ways of extending
itself which don’t require access to primitives from within Ruby.

[more on primitives elided]

It would NOT be much more natural to require every bloody module
I need every time I need it. A language – especially a language
like Ruby, where Strings are fundamental to everything – isn’t
useful without certain defaults. Would it not make equal sense to
“require integer” when I need to use integers, or are you
suggesting that those are fundamentals and are always included?
Strings are part of what makes Ruby useful immediately (the same
applies to Files) because it’s a scrpiting language.
I did put “String” as an example, but in fact the only needed
module is “kernel”, the base of the language, where Object,
Boolean, and Magnitude are defned (in Ruby there is no Boolean
class and no Magnitude, but you have Fixnum and TrueClass and
FalseClass, I think that this is going to change in the future).
The rest are extensions, what an OO language is supposed to deal
with.

Matz determined that String, Regex, Array, Files, and Hashes (among
other thigns) are necessary parts of the language. Given the sorts
of work that I’ve done with Ruby so far – I agree.

I’m sorry, but I don’t understand what you’re getting at here.
The three examples you gave:
a.+(3)
a.+ 3
a + 3

are actually the only ways to express that thought (without
getting silly wrt parenthesis). Ruby explicitly makes parentheses
optional on method calls. Parentheses make complex operations
easier to read, certainly, and can prevent confusion for the
interpreter and programmer, as when you have:
[…]
You will like then the Perl’s “there is a hundred ways to do it”
slogan…

It’s actually “TMTOWTDI” – there’s more than one way to do it.
Indeed, this is the mark of a mature, expressive language. Look
closely at your own native human language – there’s more than one
way to express something. Even silly invented languages like logban
have multiple ways of expressing ideas.

The fact that there is more than one way to express something,
weakens the mastery of the language. It’s right sometimes becasue
it makes things so “eye sugar” , but I prefer ( I PREFER, it’s me,
my option) a one way to do things, it makes things easy to code
and easy to read your own code and the one made by others.

That’s what coding standards are for, not programming language
designs.

Actually, it can’t give you the same results without trouble. C++
is trouble because it allows the definition of:
a = a + b // a.=(a.+(b))
to be different from:
a += b // a.+=(b)
If the result of the first call isn’t the same as the result of
the second call, then there’s a disconnect which has to be
documented. Matz made the right choice here, I think, because it
prevents this sort of stupidity that C++ allows. (And this isn’t
‘prevention’ in the way that I think GvR was beyond silly to
require indentation for block definition in Python.)
I disagree, You loose flexibility, it does not mean that you need
to use it, it means that you have the flexibility there when you
need it.

I don’t see it as flexibility lost. I see it as “utterly stupid
behaviour” prevented. There is no legitimate reason for someone to
define a = a + b to be different from a += b.

Anyways, if I define a.+=b to be diferent from a.=a.+b it’s my own
fault for using bad semantincs, but it can be posible that someone
must be interested in having side efects associated with the +=
operator (as in C++, and yes it’s troublesome). In Smalltalk you
can do it and there are no problems with the added flexibility,
contrary to C++ where a lot of programmers started to do OOP
without a solid background on OO analisys, this bring us the
problems with C++

There’s more problems with C++ than the “lack of solid background”;
I suggest that Smalltalk, if it were as popular and widespread as
C++, would have a lot of the same stupid behaviours (like the
idiotic redefinition of a+=b differently from a=a+b).

The interpreter will warn you of this, to some degree. If I try
to use an undefined variable, it will complain (at least with
1.7) because the value is unknown (it’s not even properly ‘nil’).
This won’t help, however, if you have two similarly named
variables.
OK, I’ll try…I’m using Linux with 1.6. Anyways a warning would
be a great addition, you will catch the error at compile time
instead of at run-time.

There is no compile time.

This one is easy: because it was a design decision made earlier.
A new version of String is being worked on, to the best of my
knowledge, that will deal with characters – but this leaves the
problem of existing code which will break because it uses the
current implementation.
It does not need to break nothing a character is an integer with a
dual personality, maybe you will just need to redefine some
methods based on the arguments, but I don’t foresee serious
problems.

It will break things. If string[i] no longer returns an integer,
then code will break. There are numerous libraries out there – how
many of them use this behaviour? I don’t know – but there’s a big
chance of breakage – and not everything is easily available
anymore.

A bytecode system is being worked on, to the best of my
knowledge.
Someone pointed me to Parrot, I’ve done him just a look, and it’s
interesting.

Parrot isn’t Ruby’s bytecode system, although it may work with it in
the future.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.03 at 18.17.34

···

On Mon, 4 Nov 2002 06:44:46 +0900, Enric Lafont wrote:

[Brian_Candler]

I don't think you have redefined 'and', you have just added a method called
'and' to TrueClass.

At least, that's the case in 1.6.7. Before adding your method above, true
does not have an 'and' method:

irb(main):001:0> true.and(false)
NameError: undefined method `and' for true
        from (irb):1
irb(main):002:0> true and false
false

Regards,

Brian.

···

On Mon, Nov 04, 2002 at 06:44:46AM +0900, Enric Lafont wrote:

You can...

class TrueClass
def and (anArgument)
   return "hello"
end
end

I've redefined the and, it does not work, but it does not generate any
warning or error...

[Albert2 (Albert)]

Hi,

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are
simply messages to an object. In Ruby “operators” are neither objects
nor messages, but are rather handled as in more conventional languages.
I don’t know why Matz only went part way. This part-way-ness is also
visible in other aspects of the language such as “if”, “while”, etc. In
Ruby these things also are neither object nor message. Whereas in
Smalltalk, such constructs are messages to a Boolean object.

They simply cannot implemented as methods.

“=” is assignment, which is not a method even in Smalltalk (:=).

True.

"“and”, “or” and “…” are control structures, which also are not
methods in most implementation of Smalltalk.

  					matz.

IIRC, “and:” and “or:” are both methods of classes “False” and “True”.
You are correct concerning “…”. I have never seen it in Smalltalk; perhaps
because “.” ends a statment. In Smalltalk the same functionality is handled
by the class Interval.

···

On Sunday 03 November 2002 4:12 pm, Yukihiro Matsumoto wrote:

In message “Re: Thoughts on Ruby” > > on 02/11/03, Albert Wagner alwagner@tcac.net writes:

–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay

[Paul_Duncan]

Hi,

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are simply
messages to an object. In Ruby “operators” are neither objects nor messages,
but are rather handled as in more conventional languages. I don’t know why
Matz only went part way. This part-way-ness is also visible in other
aspects of the language such as “if”, “while”, etc. In Ruby these things
also are neither object nor message. Whereas in Smalltalk, such constructs
are messages to a Boolean object.

They simply cannot implemented as methods.

“=” is assignment, which is not a method even in Smalltalk (:=).
"“and”, “or” and “…” are control structures, which also are not
methods in most implementation of Smalltalk.

Be careful everyone. Matz is a sqeak-this and smalltalk-that
conversation this weekend.

···

• Yukihiro Matsumoto (matz@ruby-lang.org) wrote:

In message “Re: Thoughts on Ruby” > on 02/11/03, Albert Wagner alwagner@tcac.net writes:

  					matz.

–
Paul Duncan pabs@pablotron.org pabs in #gah (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562

[Enric_Lafont]

Yukihiro Matsumoto wrote:

Hi,

Smalltalk is pure OOP. Ruby is not. In Smalltalk the “operators” are simply
messages to an object. In Ruby “operators” are neither objects nor messages,
but are rather handled as in more conventional languages. I don’t know why
Matz only went part way. This part-way-ness is also visible in other
aspects of the language such as “if”, “while”, etc. In Ruby these things
also are neither object nor message. Whereas in Smalltalk, such constructs
are messages to a Boolean object.

They simply cannot implemented as methods.

“=” is assignment, which is not a method even in Smalltalk (:=).
"“and”, “or” and “…” are control structures, which also are not
methods in most implementation of Smalltalk.

Yes you’re right, “:=” and “.” are language structures in Smalltalk as
are “(”, “)” , “<” (subclass), “<<” and others in Ruby.

But, some others like “and”, “or”, “…”, “…” , etc … can be equally
solved with a more purist aproach, yes, it’s your language and you
decide what is best for him, this is just a suggestion you may not like

Enric

···

In message “Re: Thoughts on Ruby” > on 02/11/03, Albert Wagner alwagner@tcac.net writes: