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

[rule.rule.rule]

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

http://tinyurl.com/fpwes

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

Greetings,

 

[Day]

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

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

 

[Eivind Eklund]

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]

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]

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


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

 

[Nando Sanchez]

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

 

[tho_mica_l]

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.

 

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

 

[Austin Ziegler]

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.

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

-austin

 

[Jari Williamsson]

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

http://tinyurl.com/fpwes

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

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]

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.

 

[Alexey Verkhovsky]

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.

 

[Joe]

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

 

[tho_mica_l]

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.

 

[Rule.rule]

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

 

[Rule.rule]

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

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]

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.


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?

 

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

 

[Rule.rule]

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]

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

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.