On Jan 9, 2006, at 3:33 PM, Gregory B. wrote:
If you remember from our first New Haven Rubyists meeting, there was a
decent amount of tension from the Java guys in the house. People who
tend to lean on the compiler for support feel like they’re going to
fall flatfaced upon entering Ruby.
I remember. I’m just trying to understand the concern at a finer
level of detail. I feel like a therapist trying to coax a
reluctant patient to talk about their nightmares. 
Gary W.
Gregory B. wrote:
…
The fear in part has to do with type checking. Ruby being typeless
Ruby is not typeless.
James
–
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
On 1/9/06, Isaac G. [email protected] wrote:
Eivind E. wrote:
At this cost, the type and variable declarations had better give us a
lot. In practice, I find that they give me very little, bug wise:
Maybe 5% of my simplest bugs are detected by them. The advantages I
get are in the speed of the compiled code, and as documentation.
However, these benefits are too small to be worthwhile for the size
projects I presently do (one and two person projects).Does a language with type-inference require as many type and variable
declarations as a language without type-inference?
Does a reference to declaring types and variables make it clear to you
that we’re talking about a language where you have to declare types
and variables, and not one based on type inference?
Is the C++ type system the same as the SML type system?
Does the SML type system include declaring types and variables to the
degree of taking up roughly half the code?
Will programmers who passively suffer compiler type-checking detect as
many bugs as programmers who actively use ‘type-full’ programming as a
checking-tool?
Will people that use the annoying technique of asking bad rethorical
questions get on your nerves too?
Really, and in all friendliness, the question isn’t if they’ll detect
as many bugs. The question is if those that tries to use types as a
checking tool find so many bugs and/or get so many other benefits that
the costs introduced by the types are worth it. The answer will vary
by language, by environment, by programmer, and by methodology used.
I believe the static type system of SML or Haskell may well be worth
it - I’ve just not worked enough with it to know.
For me, in the environment I work in, with the ways I work with Ruby,
I’ve found that very few of my bugs would be caught by extra type
checking. I just don’t end up with wrongly typed data much at all,
and in the few cases where I do, the errors have come up immediately.
Since I wrote my type checking library, I’ve not had a subtle bug that
would be caught by more type checking. Before I wrote the type
checking library, I thought that adding more type checking would catch
a significant amount of bugs. When I added more type checking and
found that it got in the way, I started looking for cases where it
would have helped. I found very few, and they’ve so far shown up
immediately (as methods missing).
Eivind.
On 1/9/06, [email protected] [email protected] wrote:
On Jan 9, 2006, at 3:33 PM, Gregory B. wrote:
If you remember from our first New Haven Rubyists meeting, there was a
decent amount of tension from the Java guys in the house. People who
tend to lean on the compiler for support feel like they’re going to
fall flatfaced upon entering Ruby.I remember. I’m just trying to understand the concern at a finer
level of detail. I feel like a therapist trying to coax a
reluctant patient to talk about their nightmares.
I’ve asked my CS advisor to come up with her concerns in the form of
specific questions. If she does so, I’ll post them here.
On 1/9/06, James B. [email protected] wrote:
Gregory B. wrote:
…
The fear in part has to do with type checking. Ruby being typelessRuby is not typeless.
Aren’t all ruby objects under the hood of type VALUE?
sandal@karookachoo:~$ irb
irb(main):001:0> 3.type
(irb):1: warning: Object#type is deprecated; use Object#class
=> Fixnum
So… aren’t we supposed to ignore type now?
Please elaborate on what you meant by this, because I am interested.
( My conception of ruby’s type system might have been wrong)
On 1/9/06, [email protected] [email protected] wrote:
I remember. I’m just trying to understand the concern at a finer
level of detail. I feel like a therapist trying to coax a
reluctant patient to talk about their nightmares.Just to be clear. I’m not thinking of Greg as the patient. I’m talking
about the folks who are ‘fearful’ of Ruby and other similar language
environments.
However, this does NOT neccessarily mean I am in no need of therapy
Eivind E. wrote:
declarations as a language without type-inference?
Does a reference to declaring types and variables make it clear to you
that we’re talking about a language where you have to declare types
and variables, and not one based on type inference?
No
Is the C++ type system the same as the SML type system?
Does the SML type system include declaring types and variables to the
degree of taking up roughly half the code?
Depends how you write it
Will programmers who passively suffer compiler type-checking detect as
many bugs as programmers who actively use ‘type-full’ programming as a
checking-tool?Will people that use the annoying technique of asking bad rethorical
questions get on your nerves too?
Not as much as those who make wild generalizations 
On Jan 9, 2006, at 3:57 PM, [email protected] wrote:
reluctant patient to talk about their nightmares.
Just to be clear. I’m not thinking of Greg as the patient. I’m talking
about the folks who are ‘fearful’ of Ruby and other similar language
environments.
Gary W.
Gregory B. wrote:
Aren’t all ruby objects under the hood of type VALUE?
How far under the hood do we want to look?
sandal@karookachoo:~$ irb
irb(main):001:0> 3.type
(irb):1: warning: Object#type is deprecated; use Object#class
=> FixnumSo… aren’t we supposed to ignore type now?
Please elaborate on what you meant by this, because I am interested.
( My conception of ruby’s type system might have been wrong)
I’m going to punt and refer you to this:
which, hopefully, is both correct and reasonably complete.
The short answer is, Ruby objects have a type, which essentially is “the
type that responds to those methods I happen to respond to.”
In /most/ cases, asking an object for its class is sufficient for
determining type, but that gets back to the real topic: Not all objects
of, say, class String are assured to respond to the same messages, and
to the extent that so-called String objects differ in their
message-acceptance, they are different types.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
Hi –
On Tue, 10 Jan 2006, Gregory B. wrote:
On 1/9/06, James B. [email protected] wrote:
Gregory B. wrote:
…
The fear in part has to do with type checking. Ruby being typelessRuby is not typeless.
Aren’t all ruby objects under the hood of type VALUE?
But Ruby != Ruby-under-the-hood 
sandal@karookachoo:~$ irb
irb(main):001:0> 3.type
(irb):1: warning: Object#type is deprecated; use Object#class
=> FixnumSo… aren’t we supposed to ignore type now?
The reason #type is deprecated is not that there’s no such thing as
type, but that having a #type method that returns the object’s class
leads people to think that type and class are the same. In fact, my
understanding is that the only reason Matz resorted to a #type method
was that there were problems getting the parser to treat “class” as a
method name, even with an explicit receiver.
Please elaborate on what you meant by this, because I am interested.
( My conception of ruby’s type system might have been wrong)
The type of a Ruby object, as I understand it, is basically its
capabilities, at a given point during runtime. So objects have types
– but the types themselves are anonymous and, in a sense, circular.
(The type of x is “the type that objects that do what x does have”.)
David
–
David A. Black
[email protected]
“Ruby for Rails”, from Manning Publications, coming April 2006!
However, to the outsider, this is only an explanation of “how” to
overcome the apparent “flaw”. I’d like to do as good a job I can of
explaining why it isn’t a flaw, when practiced correctly.
There seems to be some sort of logical fallacy at play here, but I
can’t sniff out what it is. Arguing from authority? Begging the
question?
You seem to be half-asking for good answers to “Is Ruby’s openness a
flaw?” and at the same time looking for good answers to the argument
“Why Ruby’s openness isn’t a flaw.”
I would argue that it IS a flaw…for some people, use cases, or
programming styles. At the same time, I would then argue that it’s also
a huge feature…for some people, use cases, or programming styles.
Don’t try to convince people that they’re wrong for wanting a compiler
to catch certain typos for them without writing use cases. Don’t tell
them “if you include libraries A and B in your application, and B
modifies A in a way that neither’s documentation covers…that’s a
feature! You should embrace it, not hate it!”
Instead, convince them that use cases are more secure than the false
sense of security syntax- and static-checking provide. Acknowledge that
there ARE some downsides to the openness, but that they are outweighed
by the freedom provided.
This thread is not about a language war, but touches on issues at the
fringes of one. Remember that no one language is the Right language for
all cases. There may be cases where the openness of Ruby makes it the
wrong choice.
To convince people that Ruby is Right for cases where they are clinging
to a few misconceptions:
The combination of 2c and 2d should give the listener a good idea of
cost/benefits. 2b may give the user an ‘ah-ha’ moment, realizing they
have misconceptions, or have been relying on a false sense of security.
On 1/9/06, [email protected] [email protected] wrote:
Aren’t all ruby objects under the hood of type VALUE?
But Ruby != Ruby-under-the-hood
True.
understanding is that the only reason Matz resorted to a #type method
was that there were problems getting the parser to treat “class” as a
method name, even with an explicit receiver.
interesting
Please elaborate on what you meant by this, because I am interested.
( My conception of ruby’s type system might have been wrong)The type of a Ruby object, as I understand it, is basically its
capabilities, at a given point during runtime. So objects have types
– but the types themselves are anonymous and, in a sense, circular.
(The type of x is “the type that objects that do what x does have”.)
Hence duck-typing, no?
On 1/9/06, Phrogz [email protected] wrote:
Instead, convince them that use cases are more secure than the false
sense of security syntax- and static-checking provide. Acknowledge that
there ARE some downsides to the openness, but that they are outweighed
by the freedom provided.This thread is not about a language war, but touches on issues at the
fringes of one. Remember that no one language is the Right language for
all cases. There may be cases where the openness of Ruby makes it the
wrong choice.
This is what I’m trying to do:
I am not trying to prove that Ruby’s openness is right for everything
and everyone, but rather show that it is right and does work for
Ruby.
This is something that a lot of people are critical of, and I’d like
to try to explain it without terribly too much bias.
On 1/9/06, James B. [email protected] wrote:
Gregory B. wrote:
Please elaborate on what you meant by this, because I am interested.
( My conception of ruby’s type system might have been wrong)I’m going to punt and refer you to this:
http://www.rubygarden.org/ruby?TypesInRuby
which, hopefully, is both correct and reasonably complete.
This page did explain what I was wondering, thanks.
The short answer is, Ruby objects have a type, which essentially is “the
type that responds to those methods I happen to respond to.”In /most/ cases, asking an object for its class is sufficient for
determining type, but that gets back to the real topic: Not all objects
of, say, class String are assured to respond to the same messages, and
to the extent that so-called String objects differ in their
message-acceptance, they are different types.
So would it be agreeable that comparing static typing to duck typing
is truly an apples to oranges comparison?
That a state driven environment simply cannot be easily compared to a
behavior driven environment?
And if that’s the case, would we benefit most by explaining what
exactly a behavior driven system looks like and how to best use it to
meet your needs, while avoiding pitfalls?
Maybe this would avoid language wars and instead incourage people to
just think a little bit differently when they sit down to try out
ruby.
Some of the anxiety that those from a statically-typed background
experience when coming to a dynamically-typed language stems from the
environment that they have been swimming in.
If you spend much of your time answering the compilers complaints
about type-related issues, and you find yourself writing reams of
boilerplate just to get similar types to perform essentially the same
behavior, you might come to believe that static typing must be
important.
Of course, once you dive in and truly immerse yourself in a dynamic
language you get comfortable with duck typing. You don’t even give it
much thought until you have to explain to someone why it is not that
dangerous after all.
When the language is not getting in your way, you are free to focus on
your problem domain rather than worry about how to get the language
out your way.
On Tuesday 10 January 2006 02:01 pm, Paul N. wrote:
Some of the anxiety that those from a statically-typed background
experience when coming to a dynamically-typed language stems from the
environment that they have been swimming in.
Or for some of us it’s just the opposite. I started on a Heathkit ET6800
Microprocessor Trainer with a 8 bit 6800 processor programmed in
hexidecimal.
I spent a week trying to program it to play music using Gotos, which was
what
many people still used in 1982. Then a programmer buddy told me about
modular
programming (functionally decompose into subroutines), and I easily
programmed it. That gave me a love of encapsulation, and an absolute
fear of
spaghetti programming, self modifying code, global variables, and the
like.
When I got to C, I was grateful for type checking and local variables.
SteveT
Steve L.
Well put.
~ ryan ~
If you like, you can use the method_added callback to see when a class
gets
updated.
For example, putting the following code before your unit tests will give
you
an indication of where methods are added. Of course it would probably be
best to require a file with this code.
Of course this doesn’t cover everything (like methods being added via
eval
or changing instance variables), but it seems with better analysis tools
and
libraries, this hole can be covered.
See
http://weblog.freeopinion.org/articles/2006/01/06/find-out-where-a-method-was-added-in-rubyfor
more details.
draft implementation.
class MethodDefinitionContainer
class << self
def instance
@instance = Hash.new unless defined? @instance
@instance
end
include Enumerable
def [](key)
key = key.to_sym
instance[key]
end
def []=(key, value)
key = key.to_sym
instance[key] = [] if instance[key].nil?
instance[key] << value
end
def each
instance.each do |key, value|
yield(key, value)
end
end
end
end
class Object
def self.method_added(id)
MethodDefinitionContainer[self.to_s + ‘.’ + id.to_s] = caller[0]
end
end
sorted_keys = MethodDefinitionContainer.instance.keys.sort
sorted_keys.each do |key|
puts key
values = MethodDefinitionContainer[key]
values.each do |value|
puts “\t” + value
end
end
Gregory B. [email protected] wrote:
On 1/8/06, James B. [email protected] wrote:
This of course, has many benefits, but the bottom line is that
Java was built with a security model to prevent things like
this, while ruby was built to be open from the ground up to
facilitate this.Prevent what? One can build twisty, loopy, self-modifying code in
Java, too. It’s just painful; maybe that’s part of The Plan.
Though that’s funny, I really think it was part of the plan for
Java. They made no attempt to make doing it convenient or useful
(though that can be said for a lot of Java things), which is part of
the way they can discourage developers from being ‘wild and crazy’
…which is all part of the appealing-to-management[0] concept of
programmers as being generic-and-replaceable cogs in the project
development wheel.
If programmers have too much (ie. any) ability to be “wild and crazy”
(== creative), that could be considered as dangerous to project
“integrity”.
Of course, the sad thing is that there’s some truth in that. And much
like knowledge, a little truth (especially when taken out of context)
is a dangerous thing.
There is no inherent security from code that is too clever for its
own good.
That’s true. We are really addressing the illusion of security. Or
at least a superficial level of security. I think a lot of people
are just scared by how damn convenient and common such practices are
in Ruby, even if their language is capable of doing similar things.
I think it’s part of the old no-such-thing-as-a-free-lunch notion.
Some people (and they’re not necessarily stupid people) have trouble
with a concept like “Ruby is just a better and more powerful language
than Java”. They presume that there has to be a cost for that extra
power.
And the idea that you pay for extra power by losing “safety” (whatever
“safety” means in this context) is a seductive one, because it has so
many physical-world parallels. Though it’s dreadfully simplistic at
best (and just plain wrong at worst).
So… just about any management will read “increasing power” as
“losing safety” which translates to “increasing risk” and
INCREASING RISK IS BAD so no Ruby/Python/Smalltalk/Lisp for you,
heathen. Get back to being an indistinguishable cog in the low-risk,
industry-best-practice[1] Java machine!
Ahem. Not that I’m venting or anything.
Pete.
[0] I know, I know. Not all managment. But definitely some.
[1] Where industry-best-practice => what-everyone-else-is-doing
=> if-everyone-else-is-doing-it-I-can’t-be-blamed-if-it-fails-,
because-I-didn’t-choose,-the-industry-did.
These links may be relevant to the general thread
Mob Software, by Richard P. Gabriel & Ron Goldman, and Programming
Bottom-Up, by Paul Graham
http://www.dreamsongs.com/MobSoftware.html
http://www.paulgraham.com/progbot.html
James
–
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
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