Hi,
I added some paragraphs to the Ruby article on Wikipedia:
Type system
Criticism
Some “peer review” appreciated 
http://tinyurl.com/fpwes
Please feel free to improve upon it, or post comments in this thread.
Greetings,
On Feb 5, 2008 7:20 PM, [email protected]
[email protected]
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
On Feb 6, 2008 2:20 AM, [email protected]
[email protected] 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.
On 6 Feb 2008, at 01:49, Day wrote:
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
On 2008-02-06 15:56 +0900 (Wed), Eivind E. wrote:
On Feb 6, 2008 2:20 AM, [email protected]
[email protected] 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, [email protected]
[email protected] 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
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 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
On Feb 7, 2008 11:24 AM, tho_mica_l [email protected] 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.
Counter-argument: it wouldn’t help, either. Many people manage to
develop lots of useful software in Ruby without it.
-austin
[email protected] wrote:
- Reflective and meta-programming features
Some “peer review” appreciated
http://tinyurl.com/fpwesPlease 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:
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”?
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 W.
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.
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.
On Feb 6, 7:56 am, Eivind E. [email protected] wrote:
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
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 6, 2:49 am, Day [email protected] wrote:
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”
On Feb 7, 4:11 pm, Nando S. [email protected] wrote:
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… 
On Feb 7, 8:10 pm, Jari W.
[email protected] wrote:
- 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?
On Feb 6, 3:20 am, Phlip [email protected] wrote:
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 Sun, Feb 17, 2008 at 7:59 PM, Rule.rule [email protected]
wrote:
- IsRubytype-safe?
OK, I see what you mean…
endputs 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.
On Thu, Feb 21, 2008 at 3:18 AM, Moises T. [email protected]
wrote:
…
irb(main):001:0> 4.class
=> Fixnum
irb(main):002:0> (4.to_i*2).class
=> FixnumThe 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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs