Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls?
rule.ru...@gmail.com
I added some paragraphs to the Ruby article on Wikipedia:
Type system
- Is Ruby type-safe?
- Is Ruby strongly typed?
Criticism
- Lack of variable declarations
- Dynamic typing
- Overloaded operators
- Reflective and meta-programming features
Some "peer review" appreciated :)
Please feel free to improve upon it, or post comments in this thread.
Greetings,
Day
On Feb 5, 2008 7:20 PM, rule.ru...@gmail.com <rule.ru...@gmail.com>
wrote:
> Criticism
> - Lack of variable declarations
> - Dynamic typing
> - Overloaded operators
> - Reflective and meta-programming features
I find this interesting. I would count all four of these as assets. If
nothing else, I think the Wikipedia article should present the GOOD side of,
say, dynamic typing and meta-programming features (Rails uses meta-stuff
heavily, no?). I don't want to get into more wikidebate, so I'll just say
that.
Ben
Phlip
> - Lack of variable declarations
This is false to facts. You declare a variable by assigning it for the
first time. Hence its strongly bonds with its first variable's type.
> - Dynamic typing
> - Overloaded operators
> - Reflective and meta-programming features
Just because other languages don't have those things don't blame us for
our freedom!
Responding to the subject line, Ruby is _strongly_ typed, like Smalltalk.
There's a difference between OO dynamic typing and strong typesafety.
They are orthogonal, and Ruby has both. You can pass any object into a
function, and it will call .methods() on that object, no matter what
their parent type.
That is so obviously a good thing that many "statically typed" languages
bend over backwards to find some way to provide it. And in Ruby you
cannot accidentally coerce one type into another. Compare Perl, where
variables switch between strings, numbers, and, uh, globs, whenever the
wind blows!
--
Phlip
Eivind Eklund
<rule.ru...@gmail.com> wrote:
> Hi,
>
> I added some paragraphs to the Ruby article on Wikipedia:
>
> Type system
> - Is Ruby type-safe?
> - Is Ruby strongly typed?
Def 8 seems to be wrong; you're looking at what a variable refers to,
rather than the object type. The object type is constant throughout
object lifetime in Ruby (excepting some hacks that I think are
C-based).
Eivind.
Frederick Cheung
On 6 Feb 2008, at 01:49, Day wrote:
> On Feb 5, 2008 7:20 PM, rule.ru...@gmail.com <rule.ru...@gmail.com
> >
> wrote:
>
>> Criticism
>> - Lack of variable declarations
>> - Dynamic typing
>> - Overloaded operators
>> - Reflective and meta-programming features
>
> I find this interesting. I would count all four of these as assets. If
> nothing else, I think the Wikipedia article should present the GOOD
> side of,
> say, dynamic typing and meta-programming features (Rails uses meta-
> stuff
> heavily, no?). I don't want to get into more wikidebate, so I'll
> just say
> that.
Same here. They make it a lot easier to create DSLs that in turn make
your code a lot more readable.
Fred
Curt Sampson
> On Feb 6, 2008 2:20 AM, rule.ru...@gmail.com
> <rule.ru...@gmail.com> wrote:
>
> > I added some paragraphs to the Ruby article on Wikipedia:
> > ...
> > - Is Ruby strongly typed?
>
> Def 8 seems to be wrong; you're looking at what a variable refers to,
> rather than the object type.
I see what you mean here, he should be leaving the variable referring to
the same object, and changing the object itself.
> The object type is constant throughout object lifetime in Ruby....
Well, it depends on how you define "type". It's certainly possible,
without C code, to modfy the behaviour of enough methods on an object
(via defining singleton methods), say a String, to make a reasonable
claim that it's no longer a String but a Number. If it looks like a
duck, and quacks like a duck....
>> On Feb 5, 2008 7:20 PM, rule.ru...@gmail.com
>> <rule.ru...@gmail.com> wrote:
>>
>>> Criticism
>>> - Lack of variable declarations
I'd definitely go with this one. I've been bitten so many times
by doing something along the lines of
foo ||= "blah"
Only to realize that, though it "feels" like a read of an accessor, it's
actually the creation of a local variable. (Usually it bites me in more
complex situations than this, but this is the general gist.)
cjs
--
Curt Sampson <c...@starling-software.com> +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com
Nando Sanchez
problems with your code, write more automated tests then. You call
something a weakness when you need to change it, but what if we get rid
of these things in Ruby? We end up with c#, VB? No way!
You have a sword with 2 blades... you may think one of those blades is a
weakness because you get hurt more frecuently, so you wish a sword with
only one blade, but may be the problem is in the user of the sword.
This reminds me about several good articles related with Dynamic typing
versus Static typing.
Just my 2 cents...
Nando
--
Posted via http://www.ruby-forum.com/.
tho_mica_l
> versus Static typing.
And how little the arguments perpetuated in these articles have
changed
since I first looked into lisp. BTW why don't we all use Lisp or
Smalltalk today?
Ruby is a pretty cool language and the perfect tool for a lot of use
cases. Some optional strictness here and there really wouldn't hurt
though.
Regards,
Thomas.
Phlip
> And how little the arguments perpetuated in these articles have
> changed
> since I first looked into lisp. BTW why don't we all use Lisp or
> Smalltalk today?
Much of what we use derived from them. MS Windows's windowing layer started as a
Smalltalk prototype, for example.
> Ruby is a pretty cool language and the perfect tool for a lot of use
> cases. Some optional strictness here and there really wouldn't hurt
> though.
Excuse me while I mentally count the ways I know how to extend Ruby classes to
make them more strict...
--
Phlip
Austin Ziegler
Counter-argument: it wouldn't help, either. Many people manage to
develop lots of useful software in Ruby without it.
-austin
--
Austin Ziegler * halos...@gmail.com * http://www.halostatue.ca/
* aus...@halostatue.ca * http://www.halostatue.ca/feed/
* aus...@zieglers.ca
Jari Williamsson
I find the section about "Reflective and meta-programming features"
strange or perhaps even wrong:
1. Just about EVERY Ruby script use meta-programming features (through
attr_accessor, attr_reader, etc), so why would these features be "poorly
suited for business or large-scale application development"?
2. The given example about difficulty to grasp a class definition just
doesn't make sense. Why would it matter how a class definition looks in
a duck-typed language?
Also, the example in the section "Lack of variable declarations"
contains the following text:
"A simple typo in a variable-name can cause erroneous output from the
program, and still go undetected for a long time."
IMO, this should be added:
"...for a long time, IF PROPER TESTS AREN'T WRITTEN."
Best regards,
Jari Williamsson
tho_mica_l
> 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.
Alexey Verkhovsky
> 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]
Joe
http://www.codecommit.com/blog/ruby/adding-type-checking-to-ruby
Thought it was interesting. So you can easily add type checking to
your functions if you desire to do so.
Joe
On Feb 7, 2008 11:24 AM, tho_mica_l <mica...@gmail.com> wrote:
Phlip
> About the optional strictness, I saw this on reddit.
> http://www.codecommit.com/blog/ruby/adding-type-checking-to-ruby
>
> Thought it was interesting. So you can easily add type checking to your
> functions if you desire to do so.
So long as type checking is just DbC-lite, can we go ahead and do real
DbC?
--
Phlip
tho_mica_l
> 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.
Rule.rule
> On Feb 6, 2008 2:20 AM,rule.rule.r...@gmail.com
>
> <rule.rule.r...@gmail.com> wrote:
> > Hi,
>
> > I added some paragraphs to theRubyarticle on Wikipedia:
>
> > Type system
> > - IsRubytype-safe?
> > - IsRubystrongly typed?
>
> Def 8 seems to be wrong; you're looking at what a variable refers to,
> rather than the object type. The object type is constant throughout
> C-based).
>
> Eivind.
OK, I see what you mean...
So this might then be a better example of the type of an object
changing at runtime in Ruby...
x = 4
class Fixnum
def twice
to_i * 2
end
end
puts x.twice
Rule.rule
> [Note: parts of this message were removed to make it a legal post.]
>
> wrote:
>
> > Criticism
> > - Lack of variable declarations
> > - Dynamic typing
> > - Overloaded operators
> > - Reflective and meta-programming features
>
> I find this interesting. I would count all four of these as assets. If
> nothing else, I think the Wikipedia article should present the GOOD side of,
> say, dynamic typing and meta-programming features (Rails uses meta-stuff
> heavily, no?). I don't want to get into more wikidebate, so I'll just say
> that.
>
> Ben
Sure. Each of these feature have an upside, too, of course.
Might be better to have a section called "Cons and Pros" instead of
"Criticism"
Rule.rule
> > Criticism
> > - Lack of variable declarations
>
> This is false to facts. You declare a variable by assigning it for the
> first time. Hence its strongly bonds with its first variable's type.
>
> > - Dynamic typing
> > - Overloaded operators
> > - Reflective and meta-programming features
>
> Just because other languages don't have those things don't blame us for
> our freedom!
>
> There's a difference between OO dynamic typing and strong typesafety.
> They are orthogonal, andRubyhas both.
Well, if you read the actual wiki article I was referring to,
you'd see that "strongly type" and "type-safety" have been defined in
many different ways
by different people, so one would first at least have to agree on what
definition
we are talking about.
> You can pass any object into a
> function, and it will call .methods() on that object, no matter what
> their parent type.
>
> That is so obviously a good thing that many "statically typed" languages
> bend over backwards to find some way to provide it. And inRubyyou
> cannot accidentally coerce one type into another. Compare Perl, where
> variables switch between strings, numbers, and, uh, globs, whenever the
> wind blows!
Well, doesnt that sometimes happen in Ruby, too?
Like the examples I included
in the article: (2+3.5) (implicit conversion Fixnum to Float) and (if
42 then "a" else "b" end) (implicit conversion from Fixnum to
TrueClass))
Or if you by "variables switch" mean this?
x = 2; x = "a"
That can happen in Ruby, too, right?
> Phlip
Rule.rule
> I see all the "criticism" items as strengths inRuby. If you have
> problems with your code, write more automated tests then.
Well, usually you dont even know there is a "problem with you code"
until a bug or runtime-error hits you. Which might be far later than
you
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, no matter how
clever your framework is.
Which means you can actually never test more than 0% of all possible
inputs.
And minimum -- particularly when depending on runtime error-checking
-- 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.
> You call
> something a weakness when you need to change it, but what if we get rid
> of these things inRuby? We end up with c#, VB? No way!
My purpose was never to "get rid" of anything, just to point out some
problematic areas, in my opinion, in some types of applications.
Or simply point to some "Pros and Cons", tradeoffs, etc.
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,
if Im allowed to think so... :)
Phlip
> Which means you can actually never test more than 0% of all possible
> inputs.
That's no excuse not to write automated tests.
> And minimum -- particularly when depending on runtime error-checking --
> 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.
How about you don't write the line of code until you have a test that
correctly detects it's not there?
Put them together, and dynamic typing with unit tests is more efficient
than static typing and unit tests. You simply get more freedom to
simplify your code by mixing and matching objects in different ways.
--
Phlip
http://assert2.rubyforge.org/
Rule.rule
<jari.williams...@mailbox.swipnet.se> wrote:
> 2. The given example about difficulty to grasp a class definition just
> doesn't make sense. Why would it matter how a class definition looks in
> a duck-typed language?
eehhr... very strange-looking question to me...
Did you EVER try to analyze and understand, or debug, code that
somebody ELSE wrote?
In an OOP language, how do you ever manage to do that, without looking
at the class-definitions?
Or more generally, how would you analyze ANY piece of code without
knowing how the (built-in and user-defined) types are defined?
Moises Trovo
irb(main):001:0> 4.class
=> Fixnum
irb(main):002:0> (4.to_i*2).class
=> Fixnum
The type doesn't change in your example.
Arlen Cuss
On Thu, Feb 21, 2008 at 3:18 AM, Moises Trovo <moises...@gmail.com>
wrote:
> ...
>
> irb(main):001:0> 4.class
> => Fixnum
> irb(main):002:0> (4.to_i*2).class
> => Fixnum
>
> The type doesn't change in your example.
>
>
Moreover, the type will never change in its lifetime, as Eivind mentioned.
Sure, they have plenty of methods that return different types (String#split,
Integer#to_f, Symbol#to_proc [1.9/Rails]...), but nothing alters the
object's type itself.
Arlen
Rule.rule
Well, I certainly beg to disagree.
By any meaningful type-semantics, the type must be considered
to change when the set of methods it responds to changes.
That Ruby still calls it by the same name, apparently, only aggravates
the confusion here.
I guess, in Ruby, a type is best defined by its behaviour?
Before the redefinition of Fixnum above, for example, calling 3.twice
would throw an exception,
while after, it will return a value, which is obviously a different
behaviour.
Eric Mahurin
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).
ThoML
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.
Rule.rule
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?
Bill Kelly
From: "Rule.rule" <rule.ru...@gmail.com>
>
> 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
s.ross
> 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. :)
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.
Rule.rule
> 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:
http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
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 :)
> Regards,
>
> Bill
Bill Kelly
From: "Rule.rule" <rule.ru...@gmail.com>>> 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:
> http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
>
> 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.
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
from :0
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
Yukihiro Matsumoto
In message "Re: Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls?"
on Fri, 22 Feb 2008 11:25:01 +0900, "Rule.rule" <rule.ru...@gmail.com> writes:
|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:
| http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
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.
Rick DeNatale
> 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.
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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Todd Benson
>
> Type system
> - Is Ruby type-safe?
> - Is Ruby strongly typed?
>
> - Lack of variable declarations
> - Overloaded operators
> - Reflective and meta-programming features
>
>
> http://tinyurl.com/fpwes
>
> Please feel free to improve upon it, or post comments in this thread.
>
The concept that water is fluid but can only either erode rock over a
long period or infiltrate and then break it quickly by freezing comes
to mind.
Just a thought.
Small rant ahead...
I've been concerned about using Ruby meta-programming features for
some time. People talk about fast development and then go on about
the requirement for lengthy unit tests; brag about them, even. We're
talking about tests that cannot catch every edge case in a complicated
application. Mix that with rigid standards/conventions in a
development environment -- another requirement, all in the interest of
productivity, of course -- and the turn around for product is better,
but not by much. Not to mention maintenance/support/refactoring,
which can be costly in hours. The same goes, it seems, for other
dynamic-based languages.
I'd like someday to see a long-based economic study for a business
adapting Ruby in lieu of, say, Java (I really don't like Java that
much btw :)
Todd
Phlip
> 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.
The discussion page is for discussing the WP article itself - not for discussing
the target of the article.
Todd Benson wrote:
> I've been concerned about using Ruby meta-programming features for
> some time. People talk about fast development and then go on about
> the requirement for lengthy unit tests; brag about them, even.
Lengthy unit tests do not catch edge-case problems - in any language.
The test cases required to avoid endless debugging, under a dynamic language,
are remarkably short - often shorter than for a statically typed language.
The test cases don't match each type-check. They actually do the exact opposite.
They help absolve the need for any type checking. Program behavior can emerge
from mixing and matching its objects, without obsessing about each one's exact type.
> I'd like someday to see a long-based economic study for a business
> adapting Ruby in lieu of, say, Java (I really don't like Java that
> much btw :)
I work at a successful, profitable Ruby shop which will not go back to Java.
'Nuff said!
--
Phlip
http://assert2.rubyforge.org/
Eric Mahurin
On Fri, Feb 22, 2008 at 6:26 AM, Rick DeNatale <rick.d...@gmail.com>
wrote:
> On 2/22/08, Yukihiro Matsumoto <ma...@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.
>
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.
Phlip
> 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,
Yet = is a special case of syntactic sugar. It just created a new x with
new contents. The = is not a message, and objects strongly defend their
type when receiving messages:
2.replace('a') # this probably won't work!
> and you also have untyped lists/arrays, etc, in the language.
They are strongly typed, and dynamic.
In my C++ days, I could refactor by changing the type of an array, and
allow the compiler to find every line I must upgrade. That is a false
convenience (and C++ is also not particularly strongly typed, either!).
> Looks too much like Perl or something, to me :)
Perl lets you put a '2' in a string and then do math on it. Weak typing
is not dynamic typing, because you can't rely on the + message doing
something _different_ based on its type.
> 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?
They all had wall-to-wall unit tests, right?
--
Phlip
Rule.rule
> From: "Rule.rule" <rule.rule.r...@gmail.com>> >> 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:
> > http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
>
> > "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.
>
> 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++.
>
> of messages that object responds to at any given point in time.
> 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.)
>
> type cannot necessarily be usefully determined by looking at
> the object class's inheritance hierarchy. Nonetheless, one
>
> 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.)
>
> 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>
>
>
> >> 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,
ThoML
> 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.
Alexey Verkhovsky
> 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.
--
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]