Please ignore the above post. I didn’t intend it to be a reply.
OK, i am also a just getting started learning Ruby -but heres what I
think the FAQ should say:
Q:Why and How is Ruby different from <my last/favorite language>?
compare it with anything else! The reason to learn Ruby in the
first place, is because things are done different. And the only way
one becomes a good Ruby programmer is by solving things in Ruby (and
NOT translating solutions to Ruby). To put it short: Ruby is Ruby!
/Peter
-> 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.
···
A:Well the best way to learn Ruby (in fact any language) is NOT to
-> On Monday 04 November 2002 8:46 am, Massimiliano Mirra wrote:
->
ahoward ahoward@fsl.noaa.gov writes:
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 likeruby-beginers
ruby-advocacy
ruby-devel
ruby-really-tough-questions-for-the-gurus
ruby-drivelor maybe just
ruby-easy-questions
ruby-hard-questions
ruby-talkmight suffice.
That never works, because the newbies think to themselves, “My
question is not easy, it’s hard, therefore I’ll ask the gurus or the
hard questions area.” “beginners” groups can have similar problems.
the groups split by api’s never seem that productive imo.
MMV, obviously. I like being able to say, “CGI questions are answered
over there, Tk questions over here, database queries (pun intended)
over there. Hrm, my question is on database stuff, so I’ll ask in
comp.lang.ruby.dbi (or whatever).”
-=Eric
···
–
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
– Blair Houghton
withAllChildrenDo: aBlock
aBlock value: self.
children ifNotNil: [children do: [:c | c withAllChildrenDo:
aBlock]]! !As I said before, I don’t “get” Smalltalk. However, what I can see
here is that there’s four different symbols (!, :, |, ), and at
least one of them does double-duty (:). It’s not very clear at all
– in a reading sense – what this does. I suspect that the
equivalent Ruby is more readable, not least because it uses fewer
symbols.
I use both Ruby and I have used Smalltalk since 1987. So I thought I’d
explain this code above a bit… Maybe it’ll help just to understand.
Quickly, the “!” character isn’t actually part of Smalltalk code. The
person who gave you this got it from a fileout of source. The “!”
characters are used by the file parser as markers for the method boundaries
or when “! !” is encountered, the end of the fileout source (EOF). You never
use “!” in Smalltalk code.
Short course in Smalltalk syntax and reading the code.
There are the following type of messages:
Unary => 5 abs.
“The message to the object takes no arguments”
Binary => 5 + 2.
“This message takes one argument”
Keyword => 5 between: 2 and: 10
“This message has the arguments mixed in with the message syntax at each
keyword. Each keyword is ended by a colon”
“.” ends a statement.
“:=” does assignment.
Parenthesis group message evaluation order. Normal evaluation order is left
to right.
is a block closure. These are full closures. Blocks express the fact
that they can bind input arguments by having a input variable specification
that is expressed like so: [:blockVariable | …code…]. The vertical bar
separates the block variables section of the block from the code of the
block. The colon character before the block variable signifies that it is a
input variable to the block.
Blocks can be executed by sending them the value message or one of it’s
derivatives, value:, value:value:, value:value:value:. For example:
AddOneBlock := [:valueToAddOneTo | valuetoAddOneTo + 1].
Transcript show: (AddOneBlock value: 5).
Above I use parenthesis to group the block to get the “value:” message
before passing the result to the “show:” method. Had I not done that, the
parsing rule about moving from left to right would have had me believing
that there was a message that the Transcript understood called:
“show:value:”.
When put into Smalltalk and executed, the Transcript (aka - Console) will
show 6 as the output.
Now, what is going on with this code:
withAllChildrenDo: aBlock
aBlock value: self.
children ifNotNil: [children do: [:c | c withAllChildrenDo:
aBlock]]
So this code wants all the children of some object to have aBlock (of code)
evaluated on them.
First off, they evaluate the block on the current object. (aBlock value:
self) This follows the syntax I explained up above.
Next they have a message that takes a block as an argument to the message
“ifNotNil:” Somewhere in that message that block will get evaluated by
being sent a value message or its’ derivatives discussed above. The block
that is passed has one input variable “:c” which is bound to one of the
children and then recursively calls this method.
So the syntax in this code is the following:
Keyword messages, “.” (the period end of statement), a Block variable (:c),
and blocks themselves.
Smalltalk only has something like 7 syntactical elements in the language.
The code above falls right into the basic pattern; receiver message args.
For this line of code: “aBlock value: self” the receiver is “aBlock”, the
message is “value:” and the arg is “self”.
For this line of code:
"children ifNotNil: [children do: [:c | c withAllChildrenDo: aBlock]]
The receiver is “children”, the message is “ifNotNil:” and the arg is
"[children do: [:c | c withAllChildrenDo: aBlock]].
Notice that that last argument has a nested block in it. That nested block
won’t be evaluated until the arg is evaluated inside the “ifNotNil” message.
(This is the call chain of the messages)
Hopefully understanding that Blocks are just object receiving the value
messages, this well help you read the code easier.
Hope this helps those of you trying to read Smalltalk. It has been my
experience in teaching Smalltalk for many years, that once you get used to
reading from left to right and understand the basic message types that you
can learn to read any Smalltalk code in about 5 minutes. You just apply
some basic rules over and over just like a very basic parser…
I hope that this helps some people.
Thanks,
···
–
Sam Griffith Jr.
email: staypufd@mac.com
Web site: http://homepage.mac.com/staypufd/index.html
a wiki or whatever, and redirect people there? We don’t want
ruby-talk to become ruby-design-advocacy, right?
i am relatively new to newsgroups in general,
Welcome!
but it seems like comments like these suggest a move towards
splitting into sub-groups may be in order?
It has been proposed a while ago, and I don’t think it’s a good
solution to this particular problem. We’re not dealing with answering
easy questions versus hard questions, we’re dealing with answering
recurring questions and hopefully doing that just once; that’s the job
of a web page rather than of a mailing list.
Massimiliano
···
On Tue, Nov 05, 2002 at 01:40:20AM +0900, ahoward wrote:
Albert Wagner wrote:
Again, I think a misunderstanding.
assignment comparatorSmalltalk := =
Ruby = ==
What about equality (Smalltalk’s ==)?
···
–
…tom
remove dashes in email for replies
http://isectd.sourceforge.net
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.
This is a great analysis, especially the last paragraph.
Thank you for this.
Hal
···
----- Original Message -----
From: “Albert Wagner” alwagner@tcac.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Sunday, November 03, 2002 1:12 PM
Subject: Re: Thoughts on Ruby
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
endSmalltalk:
IfTrue: [ codeExecutedIfBooleanIsTrue] IfFalse: [ codeExecutedIfBooleanIsFalse]
[…]
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.
This helps me understand Smalltalk better, but it doesn’t fix the
fundamental problems that I have with Smalltalk that I don’t find
with Ruby.
First, I find that Smalltalk has too many symbols. It looks like
line noise without the clarity of Perl /-: Second, it doesn’t read
naturally. I think Forth is a neat language, but RPN isn’t a
“natural” way of reading things. It looks odd. As I mentioned in a
different response to this thread, I think that “a + 3” is
definitely easier to read than “a 3 +”. To me, Smalltalk reads like
RPN and Forth and this makes it harder to read.
Even comparing your boolean example, the procedural reads easier
than the Smalltalk version. Further, the procedural version easily
allows chained boolean tests (e.g., if … elsif … elsif … end)
that the Smalltalk version doesn’t lend itself to. I’m not a
Smalltalker, so while there might be a way of doing that, it doesn’t
seem as natural.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.03 at 14.24.10
···
On Mon, 4 Nov 2002 04:12:39 +0900, Albert Wagner wrote:
On Sunday 03 November 2002 5:53 am, Anders Bengtsson wrote:
Austin Ziegler wrote:
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.)
Nope, Closures are not objects. And you need to Objectify closures when
needed, something you don’t need to do with integers or strings…
Why is not “=” a method?
Again, I think a misunderstanding.
assignment comparatorSmalltalk := =
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.
I love Ruby, but this everything has an exception gets me nervous, my
mind works better when there are not exceptions, just the general rule.
= is an assignement and == is a comparission, the primitives are
diferent but both can be methods (look at Smalltalk if you need some
examples)
Enric
···
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:
> >
> > 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 +=.
Of course it does. But you can shoot yourself in the foot with every method
you write. This is not a problem unique to Smalltalk. All user written code
can have bugs.
Only because you do not know Smalltalk and cannot even conceive of “++” being
a message to an object.
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 methodReally, 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.”
He’s thinking in Smalltalk. You’re thinking in Ruby.
> I don't think that it's necessary to require declaration. >Of course it’s not necessary. He is simply expressing his opinion that for
him it is desirable.
Austin, I think that there has been a serious misunderstanding. Ruby is not
under attack. And therefore it does not need your defense. Enric is simply
coming to Ruby from a different environment than the one you came from. (I am
assuming Ruby was not your first language). And he is therefore simply
trying to make sense of his new surroundings.
Nor am I attacking Ruby. I like Ruby. I suspect that if you were to expend
the effort to actually learn Smalltalk you would be delighted at how much it
shares with Ruby. (once you got over your irrational fear of new syntax 
···
On Sunday 03 November 2002 3:09 pm, Austin Ziegler wrote:
On Mon, 4 Nov 2002 05:42:37 +0900, Enric Lafont wrote:
–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay
Albert Wagner wrote:
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
endSmalltalk:
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:
One of the really NICE things in Ruby is the implicit “object” when
calling functions, this is what enables Ruby to rewrite the
aBoolean ifTrue: [ true Closure] ifFalse: [false Closure]
to
if aBoolean then: [true Closure] else: [false Closure]
in this case, “if” is an Object method that evaluates the boolean expresion.
And yes, it does not fit with the Ruby sintax, but maybe some sintax
sugar can correct it…
[boolean expression] # object is code block that answers a boolean
whileTrue: [ code here ] # whileTrue: is message sent to code blockand:
1 to: 6 do: [ :integer | code here ] # object is integer 1
# to: 6 do: is message sent to integer 1It 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.
Yes, but in this cases, the sintax sugar can help a lot, because you
will need to use in very few cases.
Enric
Austin Ziegler wrote:
OK, if you have a:
def += (anArgument)
return (self + anArgument)
endYou will have exactly the same behaviour you have know, whitout
any trickThe problem, of course, is that I can now do:
def +=(anArgument)
return (self - anArgument)
endThis subverts the whole point of +=.
Yes of course, and I can do
def printReport
STDIN.each_line {|aLine| aLine.chomp!} # Nothing gets printed
end
This does not means nothing, It’s the work of the programmer to keep up
with the semantics of a program, If I choose a bad name for a routine,
Ruby can not do nothing (it’s not his job)
Equally, you could define a
def Object::++(anArgument)
return anArgument + 1
endAND
def Integer::++
return self + 1
endWhat, then, is the result of:
“foo”++
? Also, your definition of ++ with an argument makes no sense.
Yes you need also Object:++ (without arguments), ++ is a method that
adds one to the receiver
Object::++(anArgument) is the way to say ++x (pre-increment) because
I’m using the implicit object that Ruby uses , in this context it has a
lot of sense, Integer::++ is the post-increment operator, this way you
can have pre and post increment operators.
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 methodReally, 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.”
I come from Smalltalk, and for me it’s very natural that every call is a
method, maybe I need to look for better examples, but I hoped that this
example was enought.
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:0x2789330I don’t think that it’s necessary to require declaration.
I can not give you a real example now, but I remember a case where a bug
was introduced becasue a mistake in the variable name. This is what made
me think in a way to make the compiler check this errors. I’m testing
now again, and yes, the behaviour is right, I’ll look for that code to
see how the bug was generated.
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.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.
Take the time to learn Smalltalk… Ruby is very expressive and compact
(I love it), and I don’t recomend you to use Smalltalk, I’m learning
Ruby because it’s better suited to a lot of my daily tasks.
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
endfoo(“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.
Con la iglesia hemos topado … It’s a phrase that says that the
discussion is over because we have arrived to the bug vs. feature, and
nothing can be discussed here. Ok, I agree it’s a feature…
Enric
···
On Mon, 4 Nov 2002 05:42:37 +0900, Enric Lafont wrote:
>> 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.
But it would be better to get a warning at "compile-time" (i.e. when the
file is read in), rather than wait until when the code is actually executed.
Some pieces of code get run very infrequently, e.g. under error conditions
which occur once in a blue moon. It's then a real pain if it fails because
of a typo.
perl -w warns if a variable is referenced only once in the source file,
which usually catches this one (even without 'use strict') - even if it's on
the left-hand side of an assignment. This assumes you don't make exactly the
same typo twice
Regards,
Brian.
Hello Enric,
Monday, November 04, 2002, 12:24:56 PM, you wrote:
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
you can easily create additional control structures such as “loop” or
even “UNTIL” described in ruby book
···
–
Best regards,
Bulat mailto:bulatz@integ.ru
Austin Ziegler wrote:
[ … a lot of valid comments snipped … ]
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.
Ok, it was his decission, but Ruby will not lost a single bit of
expressiveness if you delete the String class, becasue String is not
part of the language, it’s part of the Ruby environment, you can write
s String class (a less efficient one) with the Array class, same for
hashes and Regex.
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.
Ok, I was kidding. I don’t want to enter a discussion on how much
diferent ways to say one thing you need to be expressive. In human
languages, when you have more than one way to say something you can need
an interpreter (lawyer) to correctly decipher what it was intended to
say, and in some cases, even a judge. Expressiveness is not ever a good
thing
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.
There is a Ruby Standard I can follow ?
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.
I’m sorry to seem an stupid for you … 
You have decided that the semantic (meaning) of “a += b” is "a = a + b,
and it’s right in some contexts, but if want to define a new meaning
to a +=b. I will need to use other language to express what “+=” means,
or using a method like “agregate” or “addEqual” lossing compactness and
readability. In our world and in our context is right, but I would like
to have the option to redefine it. Anyways I can live without it
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).
I disagree… Smalltalk forces you to learn A LOT.
There is no compile time.
OK, parse-time, load-time, use the one you like more
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.
NO, if “char” responds to the same methods as Fixnum does. Char and
Fixnum are essentially the same thing, a Magnitude.
Parrot isn’t Ruby’s bytecode system, although it may work with it in
the future.
Ok, thanks for the info, I’ll take a look at the Ruby bytecode engine as
soon as it becomes available.
That never works, because the newbies think to themselves, “My
question is not easy, it’s hard, therefore I’ll ask the gurus or the
hard questions area.” “beginners” groups can have similar problems.
The other problem is, none of the guys who know how to answer beginners
questions are going to frequent the “easy-questions” group. (Having said
this, I confess that most of my questions are of the “easy” type).
Carl
Thanks Peter. It’s refreshing to see someone think like this.
Massimiliano
···
On Tue, Nov 05, 2002 at 05:00:45AM +0900, Peter Juhl Christiansen wrote:
OK, i am also a just getting started learning Ruby -but heres what I
think the FAQ should say:Q:Why and How is Ruby different from <my last/favorite language>?
A:Well the best way to learn Ruby (in fact any language) is NOT to
compare it with anything else! The reason to learn Ruby in the
first place, is because things are done different. And the only way
one becomes a good Ruby programmer is by solving things in Ruby (and
NOT translating solutions to Ruby). To put it short: Ruby is Ruby!
Hi,
···
In message “Re: Thoughts on Ruby” on 02/11/21, Thomas Gagné tgagne@wide-open-west.com writes:
What about equality (Smalltalk’s ==)?
equal?
matz.
> ...too many symbols...
> ... it doesn't read naturally...
>... It looks odd...
> ...harder to read...
>...it doesn't seem as natural...
I don’t agree, but I understand 
I am also a believer in bio-diversity.
···
On Sunday 03 November 2002 1:43 pm, Austin Ziegler wrote:
–
“I invented the term Object-Oriented, and I can
tell you I did not have C++ in mind.”
-Alan Kay