Please stop responding to this anonymous rule.rule.rule TROLL.
It seems s/he created this gmail account just for asking this question
and IMHO s/he mixes up dichotomies like dynamic/static, strong/weak
typing. According to recent edit of the wiki page, s/he is not alone
though.
I am sorry if I got totally misunderstood by some here,
just need to point out my intention was certainly none of "trolling".
I only recently started to really "catch up" on Ruby (and Rails) and
trying to get my grips around this innovative and peculiar language.
But I do have a long background in OOP, as well as functional
languages and -- *shudder* -- type-theory,
and also long experience with several industrial projects both
building and maintaining large-scale applications.
While I certainly can see the strong sides and potentials in Ruby, I
also found some characteristics
that, from my own background and experience, would seem obviously
problematic in real-life development.
If my posts look "biased", it is not because I dont see the good
things in Ruby
-- they are, well, good things and they just dont concern me.
While the ones I brought up on wiki, certainly do concern me.
And, right or wrong, I felt a worthwhile way of possibly getting some
more understanding
or clarification of those issues, would be to summarize and put them
up on the web,
to get some feedback from other users that may have different
experience -- thats all.
Finally: If you -- for whatever reason -- dont like this thread, why
dont you just ignore it and let those who want or not want to
participate or read it, simply decide by themselves?
On Feb 21, 5:16 am, Eric Mahurin <eric.mahu...@gmail.com> wrote:
[Note: parts of this message were removed to make it a legal post.]
Please stop responding to this anonymous rule.rule.rule TROLL.
The obviously biased comments he put on wikipedia about ruby should be
removed. The ranting seems to be all about typing. Compare to the Python
page that has about the same typing (duck) as Ruby (with different syntax).
But more importantly a general problem with just saying "test your code",
is that most real-life applications have an infinite number of
possible different inputs,
and you can only test a finite number of input-cases
And all that static typing does for this line of argument is to
restrict the number of input cases to a somewhat smaller infinity. And
not even in a way that excludes interesting defects, either.
Empirically, those who develop in dynamic languages commonly observe two things:
1. Use of static typing (at least, as implemented by current
mainstream static languages) causes accidental complexity. Complexity
== bugs.
2. Software written in Python or Ruby does not appear to be more
defect-prone in production, than software written in Java or C#.
-- one would like to ensure every code-line is executed at least once during every test.
Already this goal alone, is far from a trivial task in real-life applications.
In practice, nobody should ever rely on automated tests alone, anyway.
And gunning for 100% code coverage by automated tests is waste,
because automated tests have their cost. For some parts of the
application code that cost doesn't justify the benefits.
By the way, decent code coverage is far easier to achieve with dynamic
typing and open classes. Mocking out awkward integration boundaries is
a breeze, even when those integration boundaries are third-party and
not designed for testability.
I think Ruby is a very interesting and fun tool to use and experiment
with, but might still not be the totally ideal one for every possible task
and application on earth,
Oh, well... show me such a tool, and I will forget about Ruby in a
heartbeat. Pending that, for a pretty wide set of applications, Ruby
sucks the least.
On Sun, Feb 17, 2008 at 4:34 PM, Rule.rule <rule.rule.rule@gmail.com> wrote:
--
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
Counter-argument: it wouldn't help, either. Many people manage to
develop lots of useful software in Ruby without it.
Yes, but why not accomodate those poor souls in the ruby community who
would like to be able to do these sorts of things. I mean this doesn't
imply to turn ruby into java 1.0 or something. In an ideal world,
people who don't want variable definitions wouldn't have to use them.
I myself don't care much about them for smaller scripts. But it's
really astonishing to me that among all language I know of to some
extent and that I use from time to time, PHP is the only one that
takes a truely pragmatic stance on this issue. Most other languages
are either 100% tight-assed or never out of bed. (Please enclose the
preceding sentence in irony tags or whatever you like.) I really don't
understand why it's so hard to somehow ... well, be neither, stay
within the middle etc.
I'd take an issue with two statements in that article:
Lack of variable declarations ... makes a language a poor choice for development of large applications
Bullshit.
Ruby is great for building large apps of certain kind. At
ThoughtWorks, we've done a few relatively big business apps in Ruby
(20 man-years kind of big in one case), and I have yet to hear anyone
from these teams argue that it was a bad choice of a language.
These guys have some non-trivial amount of Ruby code, too:
http://www.revolutionhealth.com/ Last I heard, they did not think it
was a bad choice.
Some caveats apply. A team has to have ingrained discipline around
unit tests and continuous integration. Once you have that, compiler is
just an extremely weak and limited form of unit testing. I know the
arguments for static type systems - in practice, it's not that
valuable.
Reflective and meta-programming features -- While these features can be very interesting in experimental or
research-type programming, they are generally poorly suited for business or large-scale application development
Bullshit.
These features are downright AWESOME in business or large-scale
application development. They are what makes Ruby framework APIs so
nice. Example: mock object libraries in Ruby are capable of mocking
out individual methods on pretty much anything in the runtime. This
capability alone prevents a ton of accidental design complexity in a
typical business app.
Again, you need team discipline to discourage clever coding for the
sake of clever coding.
--
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]
Thought it was interesting. So you can easily add type checking to
your functions if you desire to do so.
Well, there are various way to add something in this line to the
language. E.g., one could easily do something like this:
class Class
def let(value)
unless self === value
raise TypeError, 'expected %s but got %s' %
[self.name, value.class.name]
end
value
end
end
irb(main)> String.let a = 1
TypeError: expected String but got Fixnum
irb(main)> String.let a = "foo"
=> "foo"
But the idea of type definitions and argument checks would of course
be
to give the compiler/interpreter a chance to perform some sanity
checks
at load/compile time. For this to happen, ruby would have to
understand
these definitions though and try to make some sense out of them. Now
I
know the counter-arguments since this isn't the first time this was
discussed. I nevertheless wish that ruby had some sense for
types/interfaces and from time to time I take the freedom to write
this.
Thomas.
I only recently started to really "catch up" on Ruby (and Rails) and
trying to get my grips around this innovative and peculiar language.
But I do have a long background in OOP, as well as functional
languages and -- *shudder* -- type-theory,
and also long experience with several industrial projects both
building and maintaining large-scale applications.While I certainly can see the strong sides and potentials in Ruby, I
also found some characteristics
that, from my own background and experience, would seem obviously
problematic in real-life development.
If you have a really long background in OOP, you probably started
with Smalltalk right? (Since its inventor, Alan Kay, coined the
term Object Oriented.)
<grin>
Anyway - Ruby has strong/dynamic typing like Smalltalk. (Ignoring
Smalltalk's #become ... 
There are plenty of examples of "real-life" development in both
Ruby and Smalltalk...
If your prior OOP experience has been solely with watered-down
OOP languages like C++ or Java, then, my condolences. But static
typing is not required for "real-life" development.
Regards,
Bill
From: "Rule.rule" <rule.rule.rule@gmail.com>
I second the condolences. I don't know what background, specifically, rule.rule comes from but I come from a C/C++ one (and yes, even Smalltalk). What people who've seen (ice cream|hotdogs) made is that if you knew what went into them you'd never eat them. Well, I feel the same about C++. C was a perfectly fine language, and ISO C was even ok, although not as nice because it was beginning to acquire syntactic angst.
The hoop-jumping required to create a C++ front-end and runtime is absolutely nuts. Remember, no matter how well intentioned the implementation, object orientation is grafted onto C to form C++. It was not a guiding principle in the underlying language design. Java, bless its heart, is so C++ influenced that it's hard to love and C# is almost exactly the same.
Breakaway languages that are both object oriented and dynamic are coming into the mainstream in Python and Ruby. In the "hmmmm, let's wait and see" category for me are Haskell and Erlang, although large projects already entrust their success to these languages. Lua may be considered out of the mainstream, yet I believe the UI for Adobe Lightroom was written using it.
The moral of the story is that the number of languages in use today is expanding and dynamic typing does not appear to be holding anybody back. It didn't hold back a generation of Perl programmers or PHP programmers and it's unlikely to hold back Ruby programmers. Looked at another way: If Ruby can make you more productive, make your code more readable and concise at the same time(!), and can be tested thoroughly, then programmers have more time to fix edge case bugs that one might attribute to incorrect type inferencing.
Another $.02 from my piggy-bank.
On Feb 21, 2008, at 5:08 PM, Bill Kelly wrote:
If your prior OOP experience has been solely with watered-down
OOP languages like C++ or Java, then, my condolences. But static
typing is not required for "real-life" development.
If you have a really long background in OOP, you probably started
with Smalltalk right? (Since its inventor, Alan Kay, coined the
term Object Oriented.)
Hi Bill,
No, smalltalk is one language I never used, I'm afraid.
My first experience with OOP was a dialect called Pascal-Plus in the
early 80'ies, then C++, Delphi, Java...
<grin>
Anyway -Rubyhas strong/dynamic typing
Dynamic, sure.
But re strongly, yes, I have seen this claim in several places
(including from Matz).
As I pointed out on wiki, though, it seems to depend on what
definition one refers to.
It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
there:
Ruby (programming language) - Wikipedia
But Ruby immediately clashes with my own "intuitive concept" of
"strongly typed",
when you can do things like:
x = 2; x = "a"
without getting an error,
and you also have untyped lists/arrays, etc, in the language.
Looks too much like Perl or something, to me
like Smalltalk. (Ignoring
Smalltalk's #become ...
There are plenty of examples of "real-life" development in bothRubyand Smalltalk...
If your prior OOP experience has been solely with watered-down
OOP languages like C++ or Java, then, my condolences.
OK, I humbly have to accept your condolences then
But static typing is not required for "real-life" development.
Obviously not, I have also seen a few sizable systems entirely built
in PHP or Perl or whatever,
after they started out as a "pilot" and later they didnt have the
funds to rebuild them,
decided to go live with what they had, and kept expanding on it...
But how easy and fun are they to maintain and extend, when over the
years the
original creators leave the project and new people join, etc?
With Ruby, I need more experience to judge, I guess
On Feb 22, 2:08 am, Bill Kelly <bi...@cts.com> wrote:
Regards,
Bill
Anyway - Ruby has strong/dynamic typing
Dynamic, sure.
But re strongly, yes, I have seen this claim in several places
(including from Matz).
As I pointed out on wiki, though, it seems to depend on what
definition one refers to.
It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
there:
Ruby (programming language) - WikipediaBut Ruby immediately clashes with my own "intuitive concept" of
"strongly typed",
when you can do things like:
x = 2; x = "a"
without getting an error,
and you also have untyped lists/arrays, etc, in the language.
OK; well... the closest to what I had in mind appears to be #6.
However, the caveat warning that #6 is difficult to prove mathematically seems spurious to me.
If one can write ruby code that evades ruby's type system, it's
a bug in the language implementation. So it's like having a caveat
for C++ that says, the compiler is supposed to generate valid
assembly code for all valid input statements, but this is very
difficult to prove mathematically. . . . Yes, it may be difficult
to prove that there are no implementation bugs in C++ compilers,
but we don't go around adding asterisks to that effect when
talking about C++.
In Ruby, an object's type is essentially related to which set
of messages that object responds to at any given point in time.
Classes, in Ruby are more useful for implementation inheritance,
than in establishing an object's type. Ruby is much more dynamic
than that; a given object need not necessarily respond to all
the methods provided by its superclass (it could undefine some
or all of those methods, for example.)
In Ruby, variables don't have types, objects do. And an object's
type cannot necessarily be usefully determined by looking at
the object class's inheritance hierarchy. Nonetheless, one cannot evade Ruby's type system as one can in C++:
class Dog { public: void bark(); };
class Cat { public: void meow(); };
Dog *dog = new Dog();
((Cat *) dog)->meow();
In C++, the above results in undefined behavior. (Possibly crash.)
The equivalent in Ruby does NOT result in undefined behavior.
class Dog; def bark; puts "Woof!"; end; end
class Cat; def meow; puts "Mew!"; end; end
cat = Dog.new
cat.meow
NoMethodError: undefined method `meow' for #<Dog:0x2c6cf40>
In Ruby, we have merely tried to send an object a message it doesn't respond to. That is a perfectly well-defined scenario
in the language, and the type system has not been violated or
evaded.
If it helps clarify, the following statements:
cat = Dog.new
cat.meow
...are semantically equivalent to:
some_object = Dog.new
some_object.send(:meow)
...In the latter, it should be clear that we are merely
attempting to send an object referenced by the variable
<some_object> a particular message, :meow.
Ultimately, it's really a fairly elegant and beautiful and
simple type system: Messages are sent to objects, which either
respond to them or they don't.
Sadly, I'm no math whiz - but "objects respond to messages or
they don't" doesn't strike me as likely to be as hard to prove mathematically as #6 on the wiki page tries to claim.
One more example...
What should we call the 'type' of the following object?
class Psychotic
def method_missing(name, *args)
if name.to_s.length == 6
raise(NoMethodError, "I don't like six-letter method names, such as #{name}!")
else
puts "Awesome! I'm so happy you called my method #{name} !"
end
end
end
x = Psychotic.new
=> #<Psychotic:0x279af38>
Here, we have an object that will happily respond to ANY method called on it...
x.hello
Awesome! I'm so happy you called my method hello !
x.lets_be_friends
Awesome! I'm so happy you called my method lets_be_friends !
x + x
Awesome! I'm so happy you called my method + !
...EXCEPT methods of exactly six letters:
x.hooray
NoMethodError: I don't like six-letter method names, such as hooray!
from (irb):46:in `method_missing'
from (irb):55
What is the type of that object? (I'm not sure what to call its type,
but nevertheless its type still can't be disabled or evaded!)
Welcome to Ruby. <grin>
But static typing is not required for "real-life" development.
Obviously not, I have also seen a few sizable systems entirely built
in PHP or Perl or whatever,
after they started out as a "pilot" and later they didnt have the
funds to rebuild them,
decided to go live with what they had, and kept expanding on it...But how easy and fun are they to maintain and extend, when over the
years the
original creators leave the project and new people join, etc?
In 2.5 decades of programming so far, the two worst codebases
I've had to maintain so far were in C, and Java. I wouldn't
blame that language for that, just the coders.
Regards,
Bill
From: "Rule.rule" <rule.rule.rule@gmail.com>
On Feb 22, 2:08 am, Bill Kelly <bi...@cts.com> wrote:
from :0
Hi,
But re strongly, yes, I have seen this claim in several places
(including from Matz).
As I pointed out on wiki, though, it seems to depend on what
definition one refers to.
It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
there:
Ruby (programming language) - Wikipedia
Yes, I admit I use definition #3 and #6 of strong typing.
But Ruby immediately clashes with my own "intuitive concept" of
"strongly typed",
when you can do things like:
x = 2; x = "a"
without getting an error,
and you also have untyped lists/arrays, etc, in the language.Looks too much like Perl or something, to me
It seems that definition #3 and #6 are the only right definitions for
me, when we have the term "static typing" for your "intuitive
concept". I am not going to deny your intuitiveness, however.
At least, the Wikipedia entry for Ruby is not the right place to
describe the definition of type-safety and strong typing, since same
thing happens on language with similar type concept, like Python,
Lisp, or Smalltalk. They should have their own entries if they didn't
have yet.
matz.
In message "Re: Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls?" on Fri, 22 Feb 2008 11:25:01 +0900, "Rule.rule" <rule.rule.rule@gmail.com> writes:
At the very least that section should be moved from the main article
to the discussion page, it strikes me as violating wikipedias NPOV
policy.
I'd also argue that this whole issue of "type safety" should be
abstracted a bit to talk about safety in general. My experience is
that those who demand "type safety" are concerned about the type of
bugs which happen when executable code which depends on assumptions
about the format of the date it operates on which is bound at compile
time encounters data which violates those assumptions. highly "type
safe" languages like C++ bind a lot of such assumptions into the
executable code, Java less so, Smalltalk less than that, and Ruby the
least of the four.
http://talklikeaduck.denhaven2.com/articles/2008/02/08/whose-variable-is-it-anyway
The difference it seems to me is that at one end the philosophy is
"check the credentials at the door, and if they pass, let whatever
happens happen", and at the other end, it's "trust but verify."
Trust but verify is actually safer in the end because it tends to keep
really bad things from happening when the credentials are confused or
forged, albeit at some cost of overhead. It also provides more
flexibility and does away with the programmer overhead of "high
ceremony" languages like C++ and Java.
And years of development of dynamic languages like Lisp, Smalltalk,
and Self have shown how to minimize, or even eliminate in some cases,
the overhead of late binding.
On 2/22/08, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
At least, the Wikipedia entry for Ruby is not the right place to
describe the definition of type-safety and strong typing, since same
thing happens on language with similar type concept, like Python,
Lisp, or Smalltalk. They should have their own entries if they didn't
have yet.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Thank you very much, Bill.
Most worthwhile input, and just the kind of feedback I was hoping for
when I started this thread
Anyways, I think I had a realization here -- that a type-identifier in
any earlier language I have seen, are considered to be a Constant.
Once it's defined, it's defined and doesn't change.
While a type-identifier (or class-identifier) in Ruby should rather be
looked upon as a Variable.
Just as an ordinary variable, it can mean different things in
different places within a scope (or even within an expression, I
guess).
That is certainly a new dimension, and obviously would require quite
different frameworks for mathematical/logical analysis, for example.
As a trivial example,
if you have a function F that takes an argument of type A and returns
a result of type A,
well, actually the type A may have changed between the point of
invocation of the function and the point where the result is returned.
Hmmm... by meta-programming, actually, the function F may also have
changed during the call, I guess...
OK, will digest this for a while...
Best regards,
On Feb 22, 6:20 am, Bill Kelly <bi...@cts.com> wrote:
From: "Rule.rule" <rule.rule.r...@gmail.com>
> On Feb 22, 2:08 am, Bill Kelly <bi...@cts.com> wrote:
>> Anyway -Rubyhas strong/dynamic typing
> Dynamic, sure.
> But re strongly, yes, I have seen this claim in several places
> (including from Matz).
> As I pointed out on wiki, though, it seems to depend on what
> definition one refers to.
> It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
> there:
> Ruby (programming language) - Wikipedia> ButRubyimmediately clashes with my own "intuitive concept" of
> "strongly typed",
> when you can do things like:
> x = 2; x = "a"
> without getting an error,
> and you also have untyped lists/arrays, etc, in the language.OK; well... the closest to what I had in mind appears to be #6.
However, the caveat warning that #6 is difficult to prove
mathematically seems spurious to me.If one can writerubycode that evadesruby'stype system, it's
a bug in the language implementation. So it's like having a caveat
for C++ that says, the compiler is supposed to generate valid
assembly code for all valid input statements, but this is very
difficult to prove mathematically. . . . Yes, it may be difficult
to prove that there are no implementation bugs in C++ compilers,
but we don't go around adding asterisks to that effect when
talking about C++.InRuby, an object's type is essentially related to which set
of messages that object responds to at any given point in time.
Classes, inRubyare more useful for implementation inheritance,
than in establishing an object's type. Rubyis much more dynamic
than that; a given object need not necessarily respond to all
the methods provided by its superclass (it could undefine some
or all of those methods, for example.)InRuby, variables don't have types, objects do. And an object's
type cannot necessarily be usefully determined by looking at
the object class's inheritance hierarchy. Nonetheless, one
cannot evadeRuby'stype system as one can in C++:class Dog { public: void bark(); };
class Cat { public: void meow(); };
Dog *dog = new Dog();
((Cat *) dog)->meow();In C++, the above results in undefined behavior. (Possibly crash.)
The equivalent inRubydoes NOT result in undefined behavior.class Dog; def bark; puts "Woof!"; end; end
class Cat; def meow; puts "Mew!"; end; endcat = Dog.new
cat.meowNoMethodError: undefined method `meow' for #<Dog:0x2c6cf40>
InRuby, we have merely tried to send an object a message it
doesn't respond to. That is a perfectly well-defined scenario
in the language, and the type system has not been violated or
evaded.If it helps clarify, the following statements:
cat = Dog.new
cat.meow..are semantically equivalent to:
some_object = Dog.new
some_object.send(:meow)..In the latter, it should be clear that we are merely
attempting to send an object referenced by the variable
<some_object> a particular message, :meow.Ultimately, it's really a fairly elegant and beautiful and
simple type system: Messages are sent to objects, which either
respond to them or they don't.Sadly, I'm no math whiz - but "objects respond to messages or
they don't" doesn't strike me as likely to be as hard to
prove mathematically as #6 on the wiki page tries to claim.One more example...
What should we call the 'type' of the following object?
>> class Psychotic
>> def method_missing(name, *args)
>> if name.to_s.length == 6
>> raise(NoMethodError, "I don't like six-letter method names, such as #{name}!")
>> else
>> puts "Awesome! I'm so happy you called my method #{name} !"
>> end
>> end
>> end
>> x = Psychotic.new=> #<Psychotic:0x279af38>
Here, we have an object that will happily respond to ANY method
called on it...>> x.hello
Awesome! I'm so happy you called my method hello !>> x.lets_be_friends
Awesome! I'm so happy you called my method lets_be_friends !>> x + x
Awesome! I'm so happy you called my method + !
..EXCEPT methods of exactly six letters:
>> x.hooray
NoMethodError: I don't like six-letter method names, such as hooray!
from (irb):46:in `method_missing'
from (irb):55
from :0What is the type of that object? (I'm not sure what to call its type,
but nevertheless its type still can't be disabled or evaded!)Welcome toRuby. <grin>
>> But static typing is not required for "real-life" development.
> Obviously not, I have also seen a few sizable systems entirely built
> in PHP or Perl or whatever,
> after they started out as a "pilot" and later they didnt have the
> funds to rebuild them,
> decided to go live with what they had, and kept expanding on it...> But how easy and fun are they to maintain and extend, when over the
> years the
> original creators leave the project and new people join, etc?In 2.5 decades of programming so far, the two worst codebases
I've had to maintain so far were in C, and Java. I wouldn't
blame that language for that, just the coders.Regards,
Bill
Thank you very much, Bill.
Most worthwhile input, and just the kind of feedback I was hoping for
when I started this thread
Anyways, I think I had a realization here -- that a type-identifier in
any earlier language I have seen, are considered to be a Constant.
Once it's defined, it's defined and doesn't change.
While a type-identifier (or class-identifier) in Ruby should rather be
looked upon as a Variable.
Just as an ordinary variable, it can mean different things in
different places within a scope (or even within an expression, I
guess).
That is certainly a new dimension, and obviously would require quite
different frameworks for mathematical/logical analysis, for example.
As a trivial example,
if you have a function F that takes an argument of type A and returns
a result of type A,
well, actually the type A may have changed between the point of
invocation of the function and the point where the result is returned.
Hmmm... by meta-programming, actually, the function F may also have
changed during the call, I guess...
OK, will digest this for a while...
Best regards,
On Feb 22, 6:20 am, Bill Kelly <bi...@cts.com> wrote:
From: "Rule.rule" <rule.rule.r...@gmail.com>
> On Feb 22, 2:08 am, Bill Kelly <bi...@cts.com> wrote:
>> Anyway -Rubyhas strong/dynamic typing
> Dynamic, sure.
> But re strongly, yes, I have seen this claim in several places
> (including from Matz).
> As I pointed out on wiki, though, it seems to depend on what
> definition one refers to.
> It seems to me, Matz is using Defs #3 and/or #6 in the list I gave
> there:
> Ruby (programming language) - Wikipedia> ButRubyimmediately clashes with my own "intuitive concept" of
> "strongly typed",
> when you can do things like:
> x = 2; x = "a"
> without getting an error,
> and you also have untyped lists/arrays, etc, in the language.OK; well... the closest to what I had in mind appears to be #6.
However, the caveat warning that #6 is difficult to prove
mathematically seems spurious to me.If one can writerubycode that evadesruby'stype system, it's
a bug in the language implementation. So it's like having a caveat
for C++ that says, the compiler is supposed to generate valid
assembly code for all valid input statements, but this is very
difficult to prove mathematically. . . . Yes, it may be difficult
to prove that there are no implementation bugs in C++ compilers,
but we don't go around adding asterisks to that effect when
talking about C++.InRuby, an object's type is essentially related to which set
of messages that object responds to at any given point in time.
Classes, inRubyare more useful for implementation inheritance,
than in establishing an object's type. Rubyis much more dynamic
than that; a given object need not necessarily respond to all
the methods provided by its superclass (it could undefine some
or all of those methods, for example.)InRuby, variables don't have types, objects do. And an object's
type cannot necessarily be usefully determined by looking at
the object class's inheritance hierarchy. Nonetheless, one
cannot evadeRuby'stype system as one can in C++:class Dog { public: void bark(); };
class Cat { public: void meow(); };
Dog *dog = new Dog();
((Cat *) dog)->meow();In C++, the above results in undefined behavior. (Possibly crash.)
The equivalent inRubydoes NOT result in undefined behavior.class Dog; def bark; puts "Woof!"; end; end
class Cat; def meow; puts "Mew!"; end; endcat = Dog.new
cat.meowNoMethodError: undefined method `meow' for #<Dog:0x2c6cf40>
InRuby, we have merely tried to send an object a message it
doesn't respond to. That is a perfectly well-defined scenario
in the language, and the type system has not been violated or
evaded.If it helps clarify, the following statements:
cat = Dog.new
cat.meow..are semantically equivalent to:
some_object = Dog.new
some_object.send(:meow)..In the latter, it should be clear that we are merely
attempting to send an object referenced by the variable
<some_object> a particular message, :meow.Ultimately, it's really a fairly elegant and beautiful and
simple type system: Messages are sent to objects, which either
respond to them or they don't.Sadly, I'm no math whiz - but "objects respond to messages or
they don't" doesn't strike me as likely to be as hard to
prove mathematically as #6 on the wiki page tries to claim.One more example...
What should we call the 'type' of the following object?
>> class Psychotic
>> def method_missing(name, *args)
>> if name.to_s.length == 6
>> raise(NoMethodError, "I don't like six-letter method names, such as #{name}!")
>> else
>> puts "Awesome! I'm so happy you called my method #{name} !"
>> end
>> end
>> end
>> x = Psychotic.new=> #<Psychotic:0x279af38>
Here, we have an object that will happily respond to ANY method
called on it...>> x.hello
Awesome! I'm so happy you called my method hello !>> x.lets_be_friends
Awesome! I'm so happy you called my method lets_be_friends !>> x + x
Awesome! I'm so happy you called my method + !
..EXCEPT methods of exactly six letters:
>> x.hooray
NoMethodError: I don't like six-letter method names, such as hooray!
from (irb):46:in `method_missing'
from (irb):55
from :0What is the type of that object? (I'm not sure what to call its type,
but nevertheless its type still can't be disabled or evaded!)Welcome toRuby. <grin>
>> But static typing is not required for "real-life" development.
> Obviously not, I have also seen a few sizable systems entirely built
> in PHP or Perl or whatever,
> after they started out as a "pilot" and later they didnt have the
> funds to rebuild them,
> decided to go live with what they had, and kept expanding on it...> But how easy and fun are they to maintain and extend, when over the
> years the
> original creators leave the project and new people join, etc?In 2.5 decades of programming so far, the two worst codebases
I've had to maintain so far were in C, and Java. I wouldn't
blame that language for that, just the coders.Regards,
Bill
Exactly. In addition to the highly biased comments about typing, you'll see
the same thing about operator overloading and reflective/meta programming.
I'm guessing that whoever wrote these comments came from Java since it is
statically typed and is against operator overloading. These comments also
came from someone who has little experience with Ruby. I'd call this
troll-like behavior.
On Fri, Feb 22, 2008 at 6:26 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On 2/22/08, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> At least, the Wikipedia entry for Ruby is not the right place to
> describe the definition of type-safety and strong typing, since same
> thing happens on language with similar type concept, like Python,
> Lisp, or Smalltalk. They should have their own entries if they didn't
> have yet.At the very least that section should be moved from the main article
to the discussion page, it strikes me as violating wikipedias NPOV
policy.
While a type-identifier (or class-identifier) in Ruby should rather be
looked upon as a Variable.
Actually a class rather can be thought of as an object assigned to a
constant (if I'm not mistaken):
irb(main):002:0> class A
irb(main):003:1> end
=> nil
irb(main):004:0> A.class
=> Class
irb(main):006:0> A.superclass
=> Object
if you have a function F that takes an argument of type A and returns
a result of type A,
well, actually the type A may have changed between the point of
invocation of the function and the point where the result is returned.
You mustn't forget that a ruby program isn't a closed system where
every
part is defined at compile time. If you remove eval & friends, you
could
perform some whole system analysis and to some extent formally prove
the
correctness of a program, I think. This isn't really news though.