Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls?

Hi,

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 :slight_smile:

     http://tinyurl.com/fpwes

Please feel free to improve upon it, or post comments in this thread.

Greetings,

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

···

On Feb 5, 2008 7:20 PM, rule.rule.rule@gmail.com <rule.rule.rule@gmail.com> wrote:

Criticism
- Lack of variable declarations
- Dynamic typing
- Overloaded operators
- Reflective and meta-programming features

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.

···

On Feb 6, 2008 2:20 AM, rule.rule.rule@gmail.com <rule.rule.rule@gmail.com> wrote:

Hi,

I added some paragraphs to the Ruby article on Wikipedia:

Type system
- Is Ruby type-safe?
- Is Ruby strongly typed?

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

···

rule.rule.rule@gmail.com wrote:

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 :slight_smile:

     Ruby (programming language) - Wikipedia

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 :slight_smile:

Todd

···

On Tue, Feb 5, 2008 at 7:20 PM, rule.rule.rule@gmail.com <rule.rule.rule@gmail.com> wrote:

Hi,

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 :slight_smile:

     Ruby (programming language) - Wikipedia

Please feel free to improve upon it, or post comments in this thread.

Greetings,

Same here. They make it a lot easier to create DSLs that in turn make your code a lot more readable.

Fred

···

On 6 Feb 2008, at 01:49, Day wrote:

On Feb 5, 2008 7:20 PM, rule.rule.rule@gmail.com <rule.rule.rule@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.

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

···

On Feb 6, 7:56 am, Eivind Eklund <eekl...@gmail.com> wrote:

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
object lifetime inRuby(excepting some hacks that I think are
C-based).

Eivind.

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"

···

On Feb 6, 2:49 am, Day <iam...@gmail.com> wrote:

[Note: parts of this message were removed to make it a legal post.]

On Feb 5, 2008 7:20 PM,rule.rule.r...@gmail.com <rule.rule.r...@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

> 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!

Responding to the subject line,Rubyis _strongly_ typed, like Smalltalk.
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?

···

On Feb 6, 3:20 am, Phlip <phlip2...@gmail.com> wrote:

  Phlip

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?

···

On Feb 7, 8:10 pm, Jari Williamsson <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?

> 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....

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

···

On 2008-02-06 15:56 +0900 (Wed), Eivind Eklund wrote:

On Feb 6, 2008 2:20 AM, rule.rule.rule@gmail.com > <rule.rule.rule@gmail.com> wrote:

On Feb 5, 2008 7:20 PM, rule.rule.rule@gmail.com >> <rule.rule.rule@gmail.com> wrote:

--
Curt Sampson <cjs@starling-software.com> +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com

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.

···

On Sun, Feb 17, 2008 at 7:59 PM, Rule.rule <rule.rule.rule@gmail.com> wrote:

On Feb 6, 7:56 am, Eivind Eklund <eekl...@gmail.com> wrote:
> 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
> object lifetime inRuby(excepting some hacks that I think are
> 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

I see all the "criticism" items as strengths in Ruby. If you have
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/.

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

···

On Thu, Feb 21, 2008 at 3:18 AM, Moises Trovo <moises.trovo@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.

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.

···

On Feb 20, 5:18 pm, Moises Trovo <moises.tr...@gmail.com> wrote:

On Sun, Feb 17, 2008 at 7:59 PM,Rule.rule<rule.rule.r...@gmail.com> wrote:
> On Feb 6, 7:56 am, Eivind Eklund <eekl...@gmail.com> wrote:
> > 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
> > object lifetime inRuby(excepting some hacks that I think are
> > 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 inRuby...

> x = 4

> class Fixnum
> def twice
> to_i * 2
> end
> end

> puts x.twice

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.

This reminds me about several good articles related with Dynamic typing
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.

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... :slight_smile:

···

On Feb 7, 4:11 pm, Nando Sanchez <rubyna...@yahoo.com> wrote:

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 viahttp://www.ruby-forum.com/.

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).

Counter-argument: it wouldn't help, either. Many people manage to
develop lots of useful software in Ruby without it.

-austin

···

On Feb 7, 2008 11:24 AM, tho_mica_l <micathom@gmail.com> wrote:

> This reminds me about several good articles related with Dynamic typing
> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

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.

Joe

···

On Feb 7, 2008 11:24 AM, tho_mica_l <micathom@gmail.com> wrote:

> This reminds me about several good articles related with Dynamic typing
> 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.