Forum: Ruby Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 03:29
(Received via mailing list)
After my first day back at my University, I was quickly reminded that
not everyone in the world embraces the "You'll shoot your eye out"
nature of Ruby as much as we all do.  I just started a course on
object oriented design in C++ and naturally the issues of security
came up as soon as the fact that I had been working in Ruby had been
mentioned.

Rather than spending an hour arguing for why Ruby's openness makes
*my* life easier, I decided that i'd do a little research and digging
around and then form an O'Reilly blog article on the topic.  As part
of that research, I'm asking the RubyTalk community for some well
founded opinions that make the case for dynamicity and openness,
particularly the meta-programming tricks many of us have become
acquainted with.

I'd also like to hear places that people would NOT use ruby due to
it's open nature, and the reasons for that.  I'd like this article to
be more a technical piece on why a little bit of life on the wild side
can be a wise decision, and also why it can be less of a dangerous
endeavor than some might believe when done correctly.  I'd like to
avoid zealotry and flamage and my meta-programming-fu can kick your
static ass type things, and instead focus on the nuts and bolts of the
issue.

Anything you can offer up would be much appreciated, your experiences
on various projects, resources you've found that address this topic,
experiences with 'secure' languages who's benefits did not outweigh
the costs, insight on the benefits on an open design baked into a
language, functionality that would be difficult or impossible to
replicate in a more rigid setting, etc.

My goal is to produce a well formed article that will show the
cautious incomer to Ruby that  we're not simply running with scissors
over here :)

I do have a few of my own ideas on the topic, and I will contribute
them for your review and suggestions if they are not brought up by
others.  I'd like to base this article heavily on the experiences of
those active in the community, so please do share!

Thanks

-Greg
Bf6862e2a409078e13a3979c00bba1d6?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-01-08 05:29
(Received via mailing list)
On Sun, Jan 08, 2006 at 11:28:17AM +0900, Gregory Brown wrote:
} After my first day back at my University, I was quickly reminded that
} not everyone in the world embraces the "You'll shoot your eye out"
} nature of Ruby as much as we all do.  I just started a course on
} object oriented design in C++ and naturally the issues of security
} came up as soon as the fact that I had been working in Ruby had been
} mentioned.
}
} Rather than spending an hour arguing for why Ruby's openness makes
} *my* life easier, I decided that i'd do a little research and digging
} around and then form an O'Reilly blog article on the topic.  As part
} of that research, I'm asking the RubyTalk community for some well
} founded opinions that make the case for dynamicity and openness,
} particularly the meta-programming tricks many of us have become
} acquainted with.
[...]

I'm not clear on what openness we're talking about. Do you mean one or
more
of the following:

1) all the source code of an app is visible and can be scanned for
   vulnerabilities

2) the source code for the interpreter is available and can be scanned
for
   vulnerabilities

3) duck typing allows unintended objects to be used in unintended ways

4) the ability to add/replace methods in existing classes allows library
   internals to be inspected or modified

} Thanks
} -Greg
--Greg
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 06:02
(Received via mailing list)
On 1/7/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:

> I'm not clear on what openness we're talking about. Do you mean one or more
> of the following:

> 3) duck typing allows unintended objects to be used in unintended ways
>
> 4) the ability to add/replace methods in existing classes allows library
>    internals to be inspected or modified

These two.

Which are considered as features by most, but often as vulnerabilities
by outsiders :)
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-08 06:55
(Received via mailing list)
Gregory Brown wrote:
> of that research, I'm asking the RubyTalk community for some well
> founded opinions that make the case for dynamicity and openness,
> particularly the meta-programming tricks many of us have become
> acquainted with.

Here's a common case for me.  I often have some code that needs to
escape or transform a string for some purpose. Rather than write

  stuff << NameSpacedUtilClass.some_modifier( my_string )

I prefer

  stuff << my_string.some_modifier

because I prefer Tell, Don't Ask.  It tends to make for crisper, clearer
code.  And I can do that because I can add custom behavior to Strings.

I believe that is simpler and more correct than subclassing String to
get my custom String-like class with custom behavior.

I've also grown found of being able to find and slurp in code files and
instantiate classes based on some string.  My blogging software allows
one to specify an output format as part of the URL. The code knows how
to break up the path_info string and recognize when, say, there is a
request for rss or xfml or OOo or whatever,  It knows that there is a
file named rss.rb or xfml.rb or whatever.rb, with a class named (ready
now?) Rss or Xfml or Whatever.  And so on.  So I can easily add new
output formats by dropping rendering coding into a running app.

Now, I acquired this taste coding while Java in the late '90s, so this
is not a Ruby thing per se, but I find it easier and more natural in
Ruby.  The idea of convention over configuration is quite old (well, as
software ideas go), but dynamic languages strike me as more friendly in
this regard.  Far fewer hoops.  I don't get tied down in interfaces and
'extends' or 'implements' or any of that crap.  Code just needs to be
where it is expected and Do The Right Thing when asked.

The URL as [command line|method(arguments)|encoded message] is also not
special to Ruby apps, with a history in PHP/Java/Perl, but again somehow
Ruby makes it easier for me.  The line between plain text and program
command is flexible.  I like that.

The availability of method_missing allows one to completely decouple the
exposed API (the messages understood by an object) from the
implementation (the methods inside an object), allowing for more robust,
less brittle code.

Plus the ability to do sketch-driven development,
code/run/tweak/test/code while adjusting designs and goals suits my
temperament.

It seems to help me evolve DSLs, and follow the adage, "Build a
language, not an application."

>
> I'd also like to hear places that people would NOT use ruby due to
> it's open nature, and the reasons for that.  I'd like this article to
> be more a technical piece on why a little bit of life on the wild side
> can be a wise decision, and also why it can be less of a dangerous
> endeavor than some might believe when done correctly.  I'd like to
> avoid zealotry and flamage and my meta-programming-fu can kick your
> static ass type things, and instead focus on the nuts and bolts of the
> issue.

Good question.    I don't have a real answer.  Perhaps for medical
equipment software or something where risk factors are so high that
every and all means to ensure program correctness are required.  That
means static typing, unit and functional tests,  whatever you can get
your hands on.

Maybe.


James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-08 07:11
(Received via mailing list)
On Jan 8, 2006, at 12:01 AM, Gregory Brown wrote:

>> library
>>    internals to be inspected or modified
>
> These two.
>
> Which are considered as features by most, but often as vulnerabilities
> by outsiders :)

If there are vulnerabilities, who are the attackers?  I think there are
reasonable issues to discuss in this area but I think the language
choice
kind of skews the discussion.  Why is the situation characterized as a
'security' issue?  Why are the contents of a library viewed as some sort
of national secret that must be protected from prying eyes/objects?
What is being 'protected'?  Why? From Whom?

I don't think C/C++/Java library designers view programmers of client
code as actively hostile, like some sort of foreign agent trying to
sneak
in to commit sabotage, yet it sounds like that is the scenario that
is in
their mind when they ask how Ruby/Python/Perl/Smalltalk/etc can
"protect" against
such problems.

I think it is really just a matter of phrasing the concern in
a different way:

    In a statically typed language, the compiler can help to identify
    programming errors during the compilation process instead of
    at run time.  What tools and/or techniques can be used with Ruby to
    identify programming errors before the code is put into production?

Gary Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 07:17
(Received via mailing list)
On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> I think it is really just a matter of phrasing the concern in
> a different way:
>
>     In a statically typed language, the compiler can help to identify
>     programming errors during the compilation process instead of
>     at run time.  What tools and/or techniques can be used with Ruby to
>     identify programming errors before the code is put into production?
>

Actually, this is not the issue at hand.  This really *does* boil down
to language design in this case.  With Ruby's openness and
meta-programming, even well tested programs can be modified and
redefined dynamically.

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.

The question is not about security as in exploits necessarily, but as
in unpredictable behavior and the like.  In practice, well formed ruby
is every bit as reliable as anything else, and what I'd like to do is
show *why*
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-08 07:38
(Received via mailing list)
Gregory Brown wrote:
>>
>
Prevent what? One can build twisty, loopy, self-modifying code in Java,
too.  It's just painful; maybe that's part of The Plan.

There is no inherent security from code that is too clever for its own
good.

James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 07:38
(Received via mailing list)
On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> If there are vulnerabilities, who are the attackers?  I think there are
> reasonable issues to discuss in this area but I think the language
> choice

This is a good point.  It's hard to make a general statement about
security when you are not sure who you are securing against.  I think
that the key issues are secondary libraries modifying other software
and making it unreliable (Such as namespace collisions, unexpected
redefinitions, etc), and the ability to make a set of software behave
in irratic ways by modifying it's internals via metaprogramming and
the like.

I mean, my general advice when it comes to ruby when asked about
security is that I basically respond, "There is none, but it's not as
bad as you'd expect.  Write proper test suites, code responsibly, and
make sure you nail down those edge cases.  Continuous integration is a
must,  and idiomatic code with proper style will help make the API
less likely to cause damage (such as the use of ! and other
indicators).

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.

I agree that your rephrasing is probably a more sane way to address
the concerns, but we need to consider that there are those who just
assume security is an integral part of their language, and I'd love to
compile a good article about why that's not always necessary, and in
fact, can be less useful than a more open platform.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 07:44
(Received via mailing list)
On 1/8/06, James Britt <james_b@neurogami.com> 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'

> 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.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-08 07:59
(Received via mailing list)
On Jan 8, 2006, at 1:14 AM, Gregory Brown wrote:
> Actually, this is not the issue at hand.  This really *does* boil down
> to language design in this case.  With Ruby's openness and
> meta-programming, even well tested programs can be modified and
> redefined dynamically.

Yes but the testing should identify if the modifications and
redefinitions accomplished their goal, i.e. is the code correct?

It isn't like the code is *randomly* modifying code (like certain
languages that allow pointers to any place in memory!).  The
modifications are explicit and purposeful and so I think should
be able to be tested as well as any other code.


Gary Wright
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-08 08:02
(Received via mailing list)
On Jan 8, 2006, at 1:37 AM, Gregory Brown wrote:
> This is a good point.  It's hard to make a general statement about
> security when you are not sure who you are securing against.  I think
> that the key issues are secondary libraries modifying other software
> and making it unreliable (Such as namespace collisions, unexpected
> redefinitions, etc),
>

I can understand the namespace issues.  How can I as a programmer
know exactly what is being modified when I add require 'X' to my
program?  This is an area that of Ruby that has lots of room
for improvement--in documentation of library/class behavior as well
as in possible new language features.


> and the ability to make a set of software behave
> in irratic ways by modifying it's internals via metaprogramming and
> the like.
>

I don't buy this in the sense that I don't see how this could be
a concern for a dynamic language and not for a static language.
You are still writing code that has to be tested.  Whether it is
hard to understand meta-programming or hard to understand data
structures that simulate meta-programming.  It is still an issue
of software correctness and I don't see how static vs. dynamic
changes that issue in any significant way.


Gary Wright
5c7bdd14d6885c8275eaf78be41d120a?d=identicon&s=25 Eero Saynatkari (Guest)
on 2006-01-08 08:29
(Received via mailing list)
On 2006.01.08 14:01, Gregory Brown wrote:
> These two.
>
> Which are considered as features by most, but often as vulnerabilities
> by outsiders :)

You might perhaps point out that professional Smalltalk, Lisp and other
dynamic-language programs have much fewer occurrences of exploits and
ordinary bugs than their static counterparts (this is also relatively
speaking). You can probably find supporting studies if you really want.

I do not have anything in particular to offer for ruby except that above
two are fairly easily and mostly thwarted by proper unit and functional
testing (which one should be doing anyway).

If one were inclined to actually argue a point, one might mention  some
of C++'s vulnerabilities: buffer overflows, pointers, memory handling
and so on.

It is, by the way, possible to override C++ methods, access modifiers
and such at runtime as well. These attacks are much more insidious there
as the programmers will not be prepared for them. Google for details.


E
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 08:38
(Received via mailing list)
On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> It isn't like the code is *randomly* modifying code (like certain
> languages that allow pointers to any place in memory!).  The
> modifications are explicit and purposeful and so I think should
> be able to be tested as well as any other code.

I agree with this and actually am not one who has concerns at all
about ruby's security or lack thereof.  I am a major proponent of the
openness.

However, it's not random modification but the modification of library
A by library B (or the modification of something in the standard
library by Library C which could effect A, B, and C) that could be a
real concern.

But this is why rubygems allows you to run the unit tests for a
library BEFORE you install it, and if you've inspected these unit
tests, optionally adding in the potential edge cases you might expect
to encounter... this would solve a lot of issues.

So that's my suggestion as one potential 'solution' to the proposed
'problem'.
However, the issue is real and deserved to be addressed.  So is it the
consensus of the community that our tests are the core of our safety
net?   Or do we have / need extra precautions?

Would it be nice to have a sort of direct access to the standard
library and core units, as well as the units of all installed
libraries, so that these are called on install time or run time or
whenever you need it?  Would it be nice to know that library A broke
something in B that library C needed?  Or is the practical occurance
of this small enough due to responsible coding and a strong tendency
towards comprehensive testing that we needn't worry about it.

It's this i'm not fully sure of, neither in my own convictions nor in
what the community tends to believe.  Getting this out in the open
will be a good thing.

I'm a firm believer in Ruby's open design, I'm a strong proponent of
dynamic code, strongly tested but agile software, and pretty much all
things that are common in Ruby.  I'd love to have a definite answer
when the issue of security is brought up though.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 08:41
(Received via mailing list)
On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> of software correctness and I don't see how static vs. dynamic
> changes that issue in any significant way.

Honestly, I don't see this issue either.  It's just a common point the
static people tend to make.  Though it is understandable that the fact
that the behavior of your software can change quite drastically once
it's out of your hands in Ruby moreso than some other languages, this
boils down to good practice and responsibility.  If you're opening up
a class and adding / removing some code, it's your responsibility to
ensure it doesn't break things.

If you're a library maintainer (like many of us are), it's your job to
identify and test your edge cases.  I don't see this being any
different than anything else.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 08:44
(Received via mailing list)
On 1/8/06, Eero Saynatkari <ruby-ml@magical-cat.org> wrote:

> If one were inclined to actually argue a point, one might mention  some
> of C++'s vulnerabilities: buffer overflows, pointers, memory handling
> and so on.

This is a good point.  In languages like C++, your security can really
go to hell through improper memory management.  This is much less
likely to happen in Ruby.
38a8230ed3d5c685558b4f0aad3fc74b?d=identicon&s=25 Joe Van Dyk (Guest)
on 2006-01-08 09:20
(Received via mailing list)
On 1/7/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> >> ways
> If there are vulnerabilities, who are the attackers?  I think there are
> reasonable issues to discuss in this area but I think the language
> choice
> kind of skews the discussion.  Why is the situation characterized as a
> 'security' issue?  Why are the contents of a library viewed as some sort
> of national secret that must be protected from prying eyes/objects?
> What is being 'protected'?  Why? From Whom?

From who?  Probably stupid programmers who would look up the library's
implementation and uh, look at it?

I dunno actually.
Ded98dc06a045924f0d48b2e46fdf229?d=identicon&s=25 Henrik Martensson (Guest)
on 2006-01-08 10:56
(Received via mailing list)
On Sun, 2006-01-08 at 08:44, Gregory Brown wrote:
> On 1/8/06, Eero Saynatkari <ruby-ml@magical-cat.org> wrote:
>
> > If one were inclined to actually argue a point, one might mention  some
> > of C++'s vulnerabilities: buffer overflows, pointers, memory handling
> > and so on.
>
> This is a good point.  In languages like C++, your security can really
> go to hell through improper memory management.  This is much less
> likely to happen in Ruby.

It is a good point when comparing Ruby and C++, but it is unlikely to
impress Java programmers.

I believe it will be a better strategy to argue the strengths of Ruby,
rather than the weaknesses of other languages. For example, on the Java
side, there are frameworks who aim to make software designs more loosely
coupled, for example IoC frameworks, AOP extensions, etc. These
frameworks emulate a dynamic approach to software development. Some of
these, like Spring, are very good. Nevertheless, learning those
frameworks requires a considerable investment in time and effort. The
proliferation of different frameworks makes it hard to get by knowing
just one or two. (One thing that maybe shouldn't be brought up is that
often corporate policies, rather than technical considerations, dictate
which framework gets used. For example, many companies use EJB and
various EJB frameworks even though it is not appropriate for the
development they do.)

Ruby, as we know, has many AOP features built in. The dynamic typing
removes the need for complex interface based designs. More important,
the Ruby features are easy to learn, easy to use, and because they are
built-in, they don't run the risk of being prohibited by corporate
policies.


/Henrik

--

http://www.henrikmartensson.org/  - Reflections on software development
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-08 16:03
(Received via mailing list)
On Jan 8, 2006, at 2:40 AM, Gregory Brown wrote:
> Though it is understandable that the fact
> that the behavior of your software can change quite drastically once
> it's out of your hands in Ruby moreso than some other languages, this
> boils down to good practice and responsibility.  If you're opening up
> a class and adding / removing some code, it's your responsibility to
> ensure it doesn't break things.

One of the things I really liked about Bertrand Meyer's _Object Oriented
Software Engineering_ was his 'programming by contract' point of view.
I've found that concept to be useful in almost any program I've written
after reading that book regardless of the language I've used.

One of the most useful ideas is the notion that if client code
refuses to adhere to the pre-conditions then all bets are off and the
library code has no responsibility to ensure correct behavior.

To a certain extent I think the concerns that static people have about
Ruby seem to be concerns about what happens if they violate the contract
by not ensuring the pre-conditions *at run-time*.  The response
should be:
Why is that my problem?  The water is under the bridge at that point.
Game over.

More important is answering:
	How can I discover the pre-conditions associated with Ruby code
	How can I avoid writing code that breaks the pre-conditions?
	How can I determine the post-conditions?

So if there are valid criticism of the Ruby approach I think it could
be said
that often times the pre-conditions (and post-conditions) are not
documented
very well (especially with regard to meta-programming).

Documentation can help but I think there is room for language
features in this
area also (e.g. structured annotations).  Namespaces will also
help to localize effects and provide a framework for describing those
effects.

Quick Question:  What core classes are modified by ActiveRecord or Og?
Quick Answer: Lots but good luck finding a concise description.


Gary Wright
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 18:34
(Received via mailing list)
On Jan 8, 2006, at 12:14 AM, Gregory Brown wrote:

> Actually, this is not the issue at hand.  This really *does* boil down
> to language design in this case.  With Ruby's openness and
> meta-programming, even well tested programs can be modified and
> redefined dynamically.
>
> 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.

Sentences like the above always read to me as:  "Java was designed to
protect the programmer from doing programmer things."  Always sounds
funny to me.

James Edward Gray II
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 18:43
(Received via mailing list)
On Jan 8, 2006, at 1:37 AM, Gregory Brown wrote:

> However, it's not random modification but the modification of library
> A by library B (or the modification of something in the standard
> library by Library C which could effect A, B, and C) that could be a
> real concern.

It's a blessing and a curse, like most things.  Infinite power,
infinite responsibility, and all that rot.

It came up here recently, in fact.  Until Ruby 1.8.3, Logger didn't
allow users to specify the output format.  Because of that, some
people hacked into the class and replaced the proper guts to make it
work.  It was nice to be able to do this, but of course the Logger
API was updated and some projects, including Rails, broke.  Rails has
since been patched to work around this, of course.

Here's a thought though...  Let's forget for a moment *how* it
happened and just look at *what* happened.  Short story:  An upgrade
introduced an incompatibility bug with some dependent software.  That
happens with tons of projects in every language and is only even of
note here because of *how* the incompatibility was introduced.

James Edward Gray II
8ae090eb7e9142e627fd25cbd3e1a7d5?d=identicon&s=25 Peter Lacey (Guest)
on 2006-01-08 18:46
(Received via mailing list)
On Jan 8, 2006, at 2:44 AM, Gregory Brown wrote:

>
Don't let the java guys off so easily, either.

- In Java it's possible to add classes to a package unless that
package is sealed.
- When inner classes are compiled in Java they are converted to
ordinary classes. Any private fields of the containing class are
converted to public fields.
- Cloning an object in Java bypasses its constructor.
- Non-clonable classes can be extended and the child can implement
cloneable.
- Java objects can be serialized exposing state, including private
fields.
- Non-serializable objects can be sub-classed just like non-cloneable
objects.
- Serialized objects can be deserialized, bypassing the constructor.
- Static fields are essentially globals, discoverable and settable by
anyone.

All of these can be addressed with good, but tedious, coding
practices, but still when trying to secure Java code from another
programmer, you have your work cut out for you.  This is especially
tricky in Java "frameworks" and development tools that routinely
serialize/deserialize objects and use reflection to create objects at
runtime.

Pete
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 18:49
(Received via mailing list)
On Jan 8, 2006, at 9:00 AM, gwtmp01@mac.com wrote:

> One of the things I really liked about Bertrand Meyer's _Object
> Oriented
> Software Engineering_ was his 'programming by contract' point of view.
> I've found that concept to be useful in almost any program I've
> written
> after reading that book regardless of the language I've used.
>
> One of the most useful ideas is the notion that if client code
> refuses to adhere to the pre-conditions then all bets are off and the
> library code has no responsibility to ensure correct behavior.

This is an excellent point, in my opinion.  If I write code like:

   not_my_object.instance_eval { @secret_value += 1 }

I know I'm crossing the line.  When it eventually breaks, I'll know
who's fault it is.  For now though, I'm telling Ruby, "Just trust me;
I know what I'm doing here."  The great part is that she believes me
and does it.  ;)

James Edward Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 21:05
(Received via mailing list)
On 1/8/06, James Edward Gray II <james@grayproductions.net> wrote:
> > refuses to adhere to the pre-conditions then all bets are off and the
> > library code has no responsibility to ensure correct behavior.
>
> This is an excellent point, in my opinion.  If I write code like:
>
>    not_my_object.instance_eval { @secret_value += 1 }
>
> I know I'm crossing the line.  When it eventually breaks, I'll know
> who's fault it is.  For now though, I'm telling Ruby, "Just trust me;
> I know what I'm doing here."  The great part is that she believes me
> and does it.  ;)

This is definitely a point worth making, that *most* people know that
meta-programming is dangerous stuff, so their either extremely careful
or their pretty open about letting you know that their efforts may
well have unsavory effects.

The key point to be made, I believe, is that ruby puts all the
power... and the responsibility, in the programmers hands.  Which in
my opinion, is where it should be anyway.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 21:08
(Received via mailing list)
On 1/8/06, James Edward Gray II <james@grayproductions.net> wrote:

> I know I'm crossing the line.  When it eventually breaks, I'll know
> who's fault it is.  For now though, I'm telling Ruby, "Just trust me;
> I know what I'm doing here."  The great part is that she believes me
> and does it.  ;)

Let's think of examples where this certainly is true and results in
good things.  The first one that came to my head, and the example I
used in class was automated memoization.  I'd like to hear some of the
greater hacks and accomplishments people have seen/done using the
openness and dynamicity of ruby as a feature, instead of a risk.
(There are plenty of them out there).

Does anyone have a good example of a domain specific language that
heavily uses metaprogramming to make it 'work' ?
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 21:14
(Received via mailing list)
On Jan 8, 2006, at 2:04 PM, Gregory Brown wrote:

> This is definitely a point worth making, that *most* people know that
> meta-programming is dangerous stuff

If you are compiling this information for a written piece, I suggest
beginning with some definitions.  I do not consider the above example
metaprogramming, for example, just a violation of encapsulation.  :)

James Edward Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 21:23
(Received via mailing list)
On 1/8/06, James Edward Gray II <james@grayproductions.net> wrote:

> > This is definitely a point worth making, that *most* people know that
> > meta-programming is dangerous stuff
>
> If you are compiling this information for a written piece, I suggest
> beginning with some definitions.  I do not consider the above example
> metaprogramming, for example, just a violation of encapsulation.  :)

Well that depends on who put the secret value there, doesn't it? ;)

But good point.  How would you (the community) define
meta-programming, open class system, and the dynamic nature of ruby?
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 21:29
(Received via mailing list)
On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:

> How would you (the community) define meta-programming

Code that writes code.

> open class system

Classes that can be changed (methods added, removed, etc.) at runtime.

> and the dynamic nature of ruby?

That's a lot harder.  :)

I like to think that Ruby does away with much of the compile time vs
runtime separation and that is a big source of it's dynamic nature.

You will need a better definition than that though, of course...  ;)

James Edward Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 22:02
(Received via mailing list)
On 1/8/06, James Edward Gray II <james@grayproductions.net> wrote:
> On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:
>
> > How would you (the community) define meta-programming
>
> Code that writes code.

I think this is most of the way there.  From the wikipedia:

"Metaprogramming is the writing of programs that write or manipulate
other programs (or themselves) as their data or that do part of the
work that is otherwise done at runtime during compile time."

http://en.wikipedia.org/wiki/Meta-programming

> > open class system
>
> Classes that can be changed (methods added, removed, etc.) at runtime.

It's probably worthwhile to note that this makes things like irb
possible, no?
Seeing as the 'main' area of Ruby is just within an Object.

Classes can be fully manipulated too, I'm not sure if this is part of
a complete definition or not.  That classnames themselves are first
class values and can be manipulated as such.

> > and the dynamic nature of ruby?

> I like to think that Ruby does away with much of the compile time vs
> runtime separation and that is a big source of it's dynamic nature.

I like this idea.  My professor had the misconception about ruby that
you could modify a class however you wanted, but could not remove it's
original set of methods or undefine fields or things like that.  This
misconception is due to the fact that static languages really do tend
to make their class definitions rather solid, where they're as free as
anything else in ruby :P
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-08 22:08
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, James Edward Gray II wrote:

> On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:
>
>> How would you (the community) define meta-programming
>
> Code that writes code.

Do you mean it's synonymous with code generation?  I don't think I'd
make that association -- not that I have a great definition for it.
In fact, I tend to think of metaprogramming in Ruby as programming
that someone things would seem cooler if it were called meta :-)
Another way to put which is: in Ruby, I'm not sure there's really a
strict line.

Then there's reflection and/or introspection, which I think are part
of it.  If you examine what methods exist on a given object, rather
than just calling them, that's reflective and also could be called
metaprogramming. But, again, I don't really have a definition.  Ruby
lets you eat the tablecloth, so to speak.

>
> You will need a better definition than that though, of course...  ;)

"Ruby is dynamic, like human nature" -- Matz, RubyConf 2001 (or 2002;
I think 2001).


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-08 22:11
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

>>> open class system
>>
>> Classes that can be changed (methods added, removed, etc.) at runtime.
>
> It's probably worthwhile to note that this makes things like irb possible, no?
> Seeing as the 'main' area of Ruby is just within an Object.
>
> Classes can be fully manipulated too, I'm not sure if this is part of
> a complete definition or not.  That classnames themselves are first
> class values and can be manipulated as such.

I'd make a distinction between the "classes are objects too" thing,
and the matter of what you can do *to* classes.  They could, for
example, be frozen, but still be first-class objects.  So there are
separate things going on.

> anything else in ruby :P
Another key aspect of dynamicness in Ruby is that objects are not
constrained by the set of capabilities with which they are born --
essentially, the divergence of type from class.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-08 22:17
(Received via mailing list)
Gregory Brown wrote:
>
> Well that depends on who put the secret value there, doesn't it? ;)
>
> But good point.  How would you (the community) define
> meta-programming, open class system, and the dynamic nature of ruby?

An element (the key element?) of meta-programming is the creation or
modification of methods, classes, and modules based on runtime
information.  I.e. run-time introduction of new behavior.

So, as JEGII pointed  out, merely bypassing encapsulation is not
metaprogramming by this (rough) definition.


But the means of introducing new behavior needs some examination; I can
think of ways of adding new behavior that probably wouldn't strike many
people as examples of metaprogramming.


James

"One man's meta is another man's poison."
    or
"I never meta program I didn't like."

(I'm getting flashbacks of Whatsamatta U.  Paging Jay Ward ...)

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 22:23
(Received via mailing list)
On 1/8/06, James Britt <james_b@neurogami.com> wrote:
> >
> So, as JEGII pointed  out, merely bypassing encapsulation is not
> metaprogramming by this (rough) definition.

How does this sound for a definition:

"When code is designed to dynamically write or modify it's own code or
other code, this is considered to be Meta-programming.  This often
makes heavy use of reflection and introspection, two key tools for
dynamic manipulation of code."
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-08 22:45
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

> How does this sound for a definition:
>
> "When code is designed to dynamically write or modify it's own code or

s/'// :-)

> other code, this is considered to be Meta-programming.  This often
> makes heavy use of reflection and introspection, two key tools for
> dynamic manipulation of code."

I'm not sure I'd say that reflection and introspection (and by the
way, is there an established difference between those two terms?) are
"manipulation" techniques.  In fact, they're sort of non-manipulation
techniques; they give you information about what's going on, without
actually changing anything.

(I'm still chickening out of trying to define metaprogramming myself
:-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-08 22:45
(Received via mailing list)
On Sunday 08 January 2006 12:32 pm, James Edward Gray II wrote:
> Sentences like the above always read to me as:  "Java was designed to
> protect the programmer from doing programmer things."  Always sounds
> funny to me.

Hi Edward,

I like being protected from myself. I'm an excellent analyst, designer,
and
yes, coder. But I'm somewhat careless. I make mistakes. That's why I'm
glad I
have a cover on my circular saw. That's why I'm glad my electric stove
has
lights saying which burners are still hot. And that's why I enjoy
programming
in languages like Ruby, Python and Java, that protect me from myself.

I spent 10 years coding in C, and every time I had to track down
intermittents
that usually turned out to be one uninitialized variable, or a picket
fence
condition where I went off the end of the allocated array by one, or
forgot
to free a variable or freed it twice, and that kind of thing.

I know a lot of people who never make mistakes. They can code C all day
long
and never get a segfault. They needn't be protected from themselves. But
not
all excellent programmers are like them.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-01-08 22:54
(Received via mailing list)
On Jan 8, 2006, at 3:42 PM, Steve Litt wrote:

> On Sunday 08 January 2006 12:32 pm, James Edward Gray II wrote:
>> Sentences like the above always read to me as:  "Java was designed to
>> protect the programmer from doing programmer things."  Always sounds
>> funny to me.
>
> Hi Edward,

James actually.  ;)

> And that's why I enjoy programming in languages like Ruby, Python
> and Java, that protect me from myself.

Wow, that's a might unusual alliance of languages.  I wonder how most
Java programmers would feel about being lumped in with Python and
Ruby on safety...

James Edward Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 23:03
(Received via mailing list)
On 1/8/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> Hi --
>
> On Mon, 9 Jan 2006, Gregory Brown wrote:
>
> > How does this sound for a definition:
> >
> > "When code is designed to dynamically write or modify it's own code or
>
> s/'// :-)

Thanks :)

> > other code, this is considered to be Meta-programming.  This often
> > makes heavy use of reflection and introspection, two key tools for
> > dynamic manipulation of code."
>
> I'm not sure I'd say that reflection and introspection (and by the
> way, is there an established difference between those two terms?)

I suppose not, but they were your words.  Perhaps the only difference
between them is that introspection is looking within oneself and
reflection is slightly more general.   Maybe they're the same thing.
I don't know.

> are "manipulation" techniques.  In fact, they're sort of non-manipulation
> techniques; they give you information about what's going on, without
> actually changing anything.

Right.  I didn't intend to mean that they were manipulation
techniques, but that they were important tools for meta-programming.
If meta-programming is a manipulation technique, say... giving you a
haircut.  Would you rather use a mirror (reflection) or not? ;)

How can I best rephrase, rewrite, etc the definition to show that
reflection is a key tool for doing manipulation, not something that
does manipulation itself?
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 23:06
(Received via mailing list)
On 1/8/06, Steve Litt <slitt@earthlink.net> wrote:
> That's why I'm glad my electric stove has
> lights saying which burners are still hot. And that's why I enjoy programming
> in languages like Ruby, Python and Java, that protect me from myself.

Java:  Yes. (in the average scenario)
Python:  Pretty much kinda maybe.
Ruby: You'll shoot your eye out!  ;)
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-08 23:21
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

> How can I best rephrase, rewrite, etc the definition to show that
> reflection is a key tool for doing manipulation, not something that
> does manipulation itself?

I still don't have what I consider a complete fix on what we
collectively mean by metaprogramming, but I think I'd say that Ruby's
R&I facilities are preconditions of, or create a hospitable
environment for, metaprogrammming techniques.

For example:

   unless obj.respond_to?(meth)      # R&I
     obj.singleton_class.class_eval {
       define_method(meth) &block    # metaprogramming, arguably
     }
   end

(using my favorite non-existent method, singleton_class :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 23:27
(Received via mailing list)
On 1/8/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> R&I facilities are preconditions of, or create a hospitable
> environment for, metaprogrammming techniques.

Agreed. It's what makes us barbers instead of butchers, a nice big
mirror :)
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-08 23:36
(Received via mailing list)
On Mon, Jan 09, 2006 at 06:52:20AM +0900, James Edward Gray II wrote:
> On Jan 8, 2006, at 3:42 PM, Steve Litt wrote:
>
> >And that's why I enjoy programming in languages like Ruby, Python
> >and Java, that protect me from myself.
>
> Wow, that's a might unusual alliance of languages.  I wonder how most
> Java programmers would feel about being lumped in with Python and
> Ruby on safety...

Surprised, at least.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-08 23:39
(Received via mailing list)
On Sunday 08 January 2006 04:52 pm, James Edward Gray II wrote:
> > And that's why I enjoy programming in languages like Ruby, Python
> > and Java, that protect me from myself.
>
> Wow, that's a might unusual alliance of languages.  I wonder how most
> Java programmers would feel about being lumped in with Python and
> Ruby on safety...

Hi James,

Compare them to C :-). Or Perl.

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-08 23:45
(Received via mailing list)
On 1/8/06, Steve Litt <slitt@earthlink.net> wrote:

> Compare them to C :-). Or Perl.

I'm really not sure at all on this but could well written C or Perl be
safer than Ruby?
I'm thinking the answer to that is 'yes', but I'm not sure at all why
(and what expense it would come at )
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-08 23:48
(Received via mailing list)
On Sunday 08 January 2006 05:04 pm, Gregory Brown wrote:
> On 1/8/06, Steve Litt <slitt@earthlink.net> wrote:
> > That's why I'm glad my electric stove has
> > lights saying which burners are still hot. And that's why I enjoy
> > programming in languages like Ruby, Python and Java, that protect me from
> > myself.
>
> Java:  Yes. (in the average scenario)
> Python:  Pretty much kinda maybe.
> Ruby: You'll shoot your eye out!  ;)

Everyone says that, but I don't see it (til it hits me in the eye? :-).

Maybe I'm just used to C, where the slightest mistake leads to a subtle
bug
that happens every couple weeks.

Sure, if I went out of my way I could make Ruby do corruptable things,
whereas
with C I cannot avoid it.

Ruby has beautiful encapsulation. Yeah it could be defeated, but you'd
really
have to try. I want my language to protect me from my own mistakes, not
from
my own death wish.

Personally, I'd NEVER gratuitously add a method or instance var to a
class at
runtime. If I needed more methods than the class provided, I'd subclass
it. I
mean, how hard is it to subclass something, especially in Ruby. Adding
methods and instance variables to classes in real time reminds me of
senators
who add a social security amendment to a defense bill -- it's just bad
business that can lead to no good.

If someone can show me an advantage to adding methods and instance
variables
in real time, and that advantage can't be realized with normal OOP
techniques, I'll keep an open mind. But unless it offers me a unique
benefit
that I need, I wouldn't do it.

It's easy to use Ruby in a manner that respects encapsulation and a
known
state, and if used that way, I'll leave my goggles at home :-)

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-08 23:54
(Received via mailing list)
On Sunday 08 January 2006 05:42 pm, Gregory Brown wrote:
> On 1/8/06, Steve Litt <slitt@earthlink.net> wrote:
> > Compare them to C :-). Or Perl.
>
> I'm really not sure at all on this but could well written C or Perl be
> safer than Ruby?
> I'm thinking the answer to that is 'yes', but I'm not sure at all why
> (and what expense it would come at )

C is like using a punch press without safety interfaces. A very careful
person
could use it safely, but an inattentive person would lose his thumb.

Ruby is like a punch press with a safety interface. You'd need to try
very
hard to lose your thumb.

Now it just might be that a very careful and attentive C punch press
operator
could operate more safely than a drunk and depressed Ruby punch press
operator, but that's not a fair comparison IMHO.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 00:06
(Received via mailing list)
On 1/8/06, Steve Litt <slitt@earthlink.net> wrote:

> If someone can show me an advantage to adding methods and instance variables
> in real time, and that advantage can't be realized with normal OOP
> techniques, I'll keep an open mind. But unless it offers me a unique benefit
> that I need, I wouldn't do it.

Well, that's kind of what this whole thread is about.  There are a lot
of really great ruby applications that take advantage of this kind of
dynamicity, and we're trying to come up with a decent explanation of
exactly that... why it's advantageous. But...

> It's easy to use Ruby in a manner that respects encapsulation and a known
> state, and if used that way, I'll leave my goggles at home :-)

This is a good point.  The language doesn't force you to go
willy-nilly.  It just grants you that freedom, which can be VERY nice,
if you know what you're doing.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 00:15
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Steve Litt wrote:

>
> my own death wish.
>
> Personally, I'd NEVER gratuitously add a method or instance var to a class at
> runtime. If I needed more methods than the class provided, I'd subclass it. I
> mean, how hard is it to subclass something, especially in Ruby. Adding
> methods and instance variables to classes in real time reminds me of senators
> who add a social security amendment to a defense bill -- it's just bad
> business that can lead to no good.

I'm not sure what you mean by adding an instance variable to a class,
but as for methods, they're all defined at runtime.

   class C
     def m
     end
   end

That code gets executed, and then there's a class called C with an
instance method m.

I'm not sure what it is that you consider subclassing to be a better
choice than.  Are you talking about define_method?  Or the practice of
reopening core classes?


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 00:24
(Received via mailing list)
On Jan 8, 2006, at 5:47 PM, Steve Litt wrote:
> Personally, I'd NEVER gratuitously add a method or instance var to
> a class at
> runtime. If I needed more methods than the class provided, I'd
> subclass it.

I'm not sure I follow this.  You think that subclassing at runtime is
better
in some way than simply adding a method to a class? It is hard to
talk about
this stuff in the abstract.  For example, I feel differently about
dynamically
adding methods to Array than I would to a class I created to solve a
particular
problem.

I think it does take a certain amount of paradigm shifting to see
solutions to
problems that involve dynamically creating methods in classes or on
particular
objects.  Until you make that shift those facilities seem quite
abstract.

For example, in Rails you can call methods like:

	Model.find_by_date
	Model.find_by_name
	Model.find_by_city
	Model.find_by_city_and_date

Those methods don't exist until you call them at which point they are
defined
and added to the class.  It doesn't make sense to add *all* the possible
combinations as methods to start with, when you can just create them
on demand.
Only a small subset of all the possible variations will ever by used
by a
particular application anyway.  Using subclasses in this case doesn't
help. How
would you decide which methods to put in the subclass?   You would have
to lock in some choices and that would prevent you from, for example,
having
a fully dynamic query interface to your application.


Gary Wright
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-09 00:39
(Received via mailing list)
On Mon, Jan 09, 2006 at 07:52:05AM +0900, Steve Litt wrote:
> could use it safely, but an inattentive person would lose his thumb.
>
> Ruby is like a punch press with a safety interface. You'd need to try very
> hard to lose your thumb.
>
> Now it just might be that a very careful and attentive C punch press operator
> could operate more safely than a drunk and depressed Ruby punch press
> operator, but that's not a fair comparison IMHO.

Interesting analogy.  Let's expand on that a bit:

C is a punch press with no particular safety features, and in fact it
has just barely enough integrated structure to do its job.  You can
create guides and the like, but you have to manhandle them into place
yourself.

Java is a punch press operator that has a bunch of guides, protective
flanges to prevent your fingers getting too close to the business end,
and so on.  It has little levers to move stuff in and out of place
easily for different jobs.  The downside is that it allows certain job
types, and for anything else you have to start redesigning and modifying
the machine.  Of course, you could always reach a hand in there and hit
the button if you really want to lose a thumb, but you might have to tie
a string around the dead-man switch.

Ruby lets you define what "safety" means, and configures itself
accordingly.  It has sane defaults.  It's also a programmable punch
press, so it can pretty much do the work on its own without your
interference.  If you program it well, you don't have to be anywhere
near the thing, and thus don't have to worry about your thumbs.  If you
program it poorly, it might suddenly start shuddering across the floor
in its hungry quest for your thumbs.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-09 01:16
(Received via mailing list)
gwtmp01@mac.com wrote:
> better
> problems that involve dynamically creating methods in classes or on
> Those methods don't exist until you call them at which point they are
> defined
> and added to the class.

Really? I  thought they were simply reparsed by method_missing into
messages of the form find( <assorted criteria>) asinvoked, not turned in
"permanent" methods.  Interesting.

Which raises a question:  Is it metaprogramming if I use method_missing
to parse messages, see if it can reformulate the message into a known,
workable form, and then redispatch by invoking 'send'?  No code writing,
no method adding.

Is that not simply the point of method_missing; i.e., it is simply a
Ruby/OO idiom.  Messages need not map to methods.

And then isn't adding them as methods just an optimization technique to
avoid the cost of calling method_missing on repeated invocations? It's
memoization for behavior.

Is memoization metaprogramming, or is it only metaprogramming when
behavior is altered?


James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 02:07
(Received via mailing list)
On Jan 8, 2006, at 7:15 PM, James Britt wrote:
> Really? I  thought they were simply reparsed by method_missing into
> messages of the form find( <assorted criteria>) asinvoked, not
> turned in "permanent" methods.  Interesting.

I'm not a rail's guru, but that was my recollection when I looked
into this a couple months ago.  It seems like an obvious optimization.


Gary Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 03:58
(Received via mailing list)
On 1/8/06, James Britt <james_b@neurogami.com> wrote:

> Is memoization metaprogramming, or is it only metaprogramming when
> behavior is altered?

I'm a lot more liberal (and maybe naive) in my definition of
metaprogramming.
I think that creating dynamic behavior at runtime is indeed
metaprogramming, even if it hasn't altered the underlying behavior of
the class itself.

Whenever I sere something to the effect of <finish me later> in the
code, I'm thinking that I'm writing a method that is using some sort
of meta programming.

If i'm not accessing methods or fields I defined before the program
began, and I'm getting some sort of behavior that the program
assembled at runtime, I consider that meta programming, regardless of
changes or lack thereof to underlying state / behavior.

What do others think about this?
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 04:04
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

> Whenever I sere something to the effect of <finish me later> in the
> code, I'm thinking that I'm writing a method that is using some sort
> of meta programming.
>
> If i'm not accessing methods or fields I defined before the program
> began, and I'm getting some sort of behavior that the program
> assembled at runtime, I consider that meta programming, regardless of
> changes or lack thereof to underlying state / behavior.
>
> What do others think about this?

Interestingly, <finish me later> is, in a sense, what yielding
implies.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-09 04:29
(Received via mailing list)
On Sunday 08 January 2006 06:14 pm, dblack@wobblini.net wrote:
> >> Java:  Yes. (in the average scenario)
> >
>
>
> I'm not sure what it is that you consider subclassing to be a better
> choice than.  Are you talking about define_method?  Or the practice of
> reopening core classes?
>
>
> David

Hi David,

I don't know for sure, because when I read about this stuff my first
reaction
was "I'm not gonna do that!"

I got the impression I could do this:

myclass = MyClass.new
myclass.never_seen_before_attribute = 5

As I said, I didn't research it because I considered its use to be a
negative,
but stored it in the back of my mind in case I had to maintain code like
that.

SteveT
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-09 04:32
(Received via mailing list)
On Sunday 08 January 2006 06:21 pm, gwtmp01@mac.com wrote:
> this stuff in the abstract.  For example, I feel differently about
> abstract.
> and added to the class.  It doesn't make sense to add *all* the possible
>
>
> Gary Wright

Hi Gary,

I'm trying to understand this. If Model.find_by_city was never defined,
how
can it know what to do? I think I'm missing some big chunk of Ruby
knowledge
here.

Are you saying that when Model.find_by_city is executed, the model looks
at
the database, discovers there's a city column, and on the fly constructs
a
method to search the table by city?

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-01-09 04:32
(Received via mailing list)
Steve Litt wrote:
> but stored it in the back of my mind in case I had to maintain code like
> that.
>

No, that is a little more dangerous.

Only a class that specifically supported that kind of behavior
would allow such a thing. See the 'ostruct' (OpenStruct)
library. Its author created it mostly as a toy, I think, but
it has been used in many situations. (I would not personally
suggest that *all* objects should behave that way.)

By the way, it's very instructive to look at the code for ostruct.


Hal
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-01-09 04:35
(Received via mailing list)
Steve Litt wrote:
>
> I'm trying to understand this. If Model.find_by_city was never defined, how
> can it know what to do? I think I'm missing some big chunk of Ruby knowledge
> here.
>
> Are you saying that when Model.find_by_city is executed, the model looks at
> the database, discovers there's a city column, and on the fly constructs a
> method to search the table by city?
>

What you're missing is method_missing.  :)

When a method doesn't exist, method_missing gets called. There's a
default
one that raises an exception, but you can override it with any behavior
you want.

The name of the called method is passed in, e.g., "find_by_city"; so if
you
parse it and see that it has the form "find_by_X" then you can know that
X
is (supposed to be) a field name. Then you just handle it.

A variation on this is to define the method so that next time,
method_missing
will not be called on that name.

Makes sense?


Hal
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-09 05:05
(Received via mailing list)
Gregory Brown wrote:
> of really great ruby applications that take advantage of this kind of
> if you know what you're doing.
I think my message-oriented programming post on O'Reilly demonstrates
the sort of thing metprogramming and reflection/introspection affords a
developer, or at least the sort thing it leads some of us to do.

http://www.oreillynet.com/ruby/blog/2006/01/moping...

Without Ruby's degree of developer freedom, it becomes
hard-to-impossible to rearrange the language to best express your
intentions.

The B&D languages may make claims to a certain amount of security, but
code that is hard for humans to read and understand is code that is
harder to maintain without introducing subtle bugs.  The code may
compile and run without errors, but it may not be doing quite what it is
supposed to.

James


P.S. Looks like rubyurl.com is having issues, if Robby is lurking.


--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 05:32
(Received via mailing list)
On Jan 8, 2006, at 10:30 PM, Steve Litt wrote:
> Are you saying that when Model.find_by_city is executed, the model
> looks at
> the database, discovers there's a city column, and on the fly
> constructs a
> method to search the table by city?

I think Hal already answered this, but yes.  If your class defines
the instance method 'method_missing' then Ruby will call it when it
can't
find a method definition.  It would look something like this (not
tested):

class Model

   def method_missing(method_name, *args)
     if method_name.to_s =~ /^find_by_(.*)/
       # respond to find_by call
     else
       super   # results in standard method not found exception
     end
   end

end

(Note that the first argument to method_missing is an instance of
Symbol, not
String so you need to call to_s on it in order to compare it to the
regular expression.  What is the difference between a Symbol and String
you ask?  Um, read the archives.)

This feature of Ruby's method dispatch protocol allows a class to
implement methods on demand.  It can even install a definition for
the missed method so that the *next* time it will be called directly
instead of being intercepted by method_missing.

Very handy.


Gary Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 05:47
(Received via mailing list)
On 1/8/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

> Interestingly, <finish me later> is, in a sense, what yielding
> implies.

But is that yet another piece of the puzzle?  Is the fact that ruby
can pass around blocks of codes as just another object part of what
makes it suitable for metaprogramming?

When does plain old dynamicity cross the line to become
'metaprogramming'?
That's the million dollar question we've yet to answer :)
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 05:53
(Received via mailing list)
On 1/8/06, Hal Fulton <hal9000@hypermetrics.com> wrote:

> Only a class that specifically supported that kind of behavior
> would allow such a thing. See the 'ostruct' (OpenStruct)
> library. Its author created it mostly as a toy, I think, but
> it has been used in many situations. (I would not personally
> suggest that *all* objects should behave that way.)

Not all objects, but if your goal is to hold a ton of 'never before
seen' attributes, it certainly does help.

I had this exact issue with Ruport, and created a sort of abstract
node for a tree structure, using OStruct.  See it here:

http://www.oreillynet.com/ruby/blog/2006/01/so_wro...

Probably a bad idea for most things, but it cut me about a 100 lines
in Ruport :)
Ace7fa5337acbdf5897a6fc035897580?d=identicon&s=25 J. Ryan Sobol (Guest)
on 2006-01-09 07:00
(Received via mailing list)
Indispensable uses of Ruby meta-programing.

1) Module.attr and friends are probably the simplest (and strongest)
uses that highlight the advantages of meta-programming.

2) Rails' ActiveRecord.

3) Dwemthy's Creature class.  http://poignantguide.net/dwemthy/

When boiled down, Dwemthy's Creature class creates a domain-specific
mini-language that is actual Ruby code.

I'm pretty sure someone else brought up domain-specific languages in
this thread, but here are some links to learn more about them.

http://en.wikipedia.org/wiki/Domain-specific_language
http://en.wikipedia.org/wiki/Domain-
specific_language#Advantages_and_Disadvantages_of_DSLs

DSL's are used everywhere: in Sendmail configuration files, Windows
resource files, World of Warcraft UI scripting, etc.  One obvious
advantage of embedded mini-languages, like sub-classes of Creature,
over external ones, like configuration files, is the ability to apply
Ruby's tools, like the irb, directly on the language.

~ ryan ~
2cef22e5d84ec3cdc107a5f9f97537e5?d=identicon&s=25 Todd (Guest)
on 2006-01-09 09:30
(Received via mailing list)
From: "Todd" <toddkennethbenson@yahoo.com>
Newsgroups: comp.lang.ruby
Subject: Re: Ideas on "Why Living Dangerous can be A Good Thing" in
Ruby?
Date: Sun, 08 Jan 2006 13:16:52 -0800


James Edward Gray II wrote:
> On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:
>
> > How would you (the community) define meta-programming
>
> Code that writes code.

A shiver goes up my spine :)

>
> > open class system
>
> Classes that can be changed (methods added, removed, etc.) at runtime.

Scary.

> > and the dynamic nature of ruby?
>
> That's a lot harder.  :)
>
> I like to think that Ruby does away with much of the compile time vs
> runtime separation and that is a big source of it's dynamic nature.
>
> You will need a better definition than that though, of course...  ;)
>
> James Edward Gray II

The programmer in me loves Ruby for it's relative simplicity (coupled
with relative complexity if need be).  The IT and DBA in me shudders at
the thought that such a thing exists, simply because data integrity
should be paramount!  More important than your family, for God's sake!
It has to be something you can put your foot on and be sure it won't
move.

I mean, here you have a black box that a few moments from now may not
be a black box anymore!  It may turn green...  It may pop out at you
like those fond memories of the jack-in-the-box.  You look at it, prod
it, it isn't reliable (you posit), it doesn't come up like the sun in
the morning every day, and start to feel there's some deep and dark
sinister purpose waiting to be unleashed.  This program, this thing,
suddenly feels like almost sort of a Pandora's box.  In that moment of
inspiration, you quickly walk away feeling better about yourself for
suggesting another, more 'stable', language that you can use.  The CIO
will be proud :)

At least, that was my first impression.  That, until I started seeing
how impressive not only the coding practices were, but also the
incredible knowledge base in the Ruby community.  Not to mention how
it has made my life a bit easier.

It is rather simple to program malicious code in Ruby, but that may be
quite
possible in any programming medium.

Todd
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 09:43
(Received via mailing list)
On 1/9/06, Todd <toddkennethbenson@yahoo.com> wrote:

>
> At least, that was my first impression.  That, until I started seeing
> how impressive not only the coding practices were, but also the
> incredible knowledge base in the Ruby community.  Not to mention how
> it has made my life a bit easier.

I'd like to quote this snippet as the beginning of my article, is that
okay?

This brings up an interesting point though.  In Ruby, idioms are more
than just 'good practice'.  They really do matter, because they are
our biggest sense of 'security'.  This of course leaves the
responsibilities in the hands of the coders, but from my experience,
the majority of the well known applications adhere to good style, and
their developers are consistant at being idiomatic in their
application design.  The same can not necessarily be said for the
majority in other languages.
Ded98dc06a045924f0d48b2e46fdf229?d=identicon&s=25 Henrik Martensson (Guest)
on 2006-01-09 09:52
(Received via mailing list)
On Sun, 2006-01-08 at 23:47, Steve Litt wrote:

>
> If someone can show me an advantage to adding methods and instance variables
> in real time, and that advantage can't be realized with normal OOP
> techniques, I'll keep an open mind. But unless it offers me a unique benefit
> that I need, I wouldn't do it.

I recently wrote some code where I had to retrieve an attribute from a
REXML attribute list  based on its name and namespace. The REXML
attribute list does have a method for retrieving attributes based on
namespace prefix and name, but this is not very useful. A namespace
aware XML processor, such as an XSLT processor, can, without breaking
any rules, change prefixes at will.

I couldn't just subclass the attribute list, because the REXML parser
would not use my subclass when building a node tree from an XML
document. However, I could do this:

module REXML
  class Attributes
    def get_attribute_ns(namespace, name)
      each_attribute() { |attribute|
        if name == attribute.name &&
          namespace == attribute.namespace()
          return attribute
        end
      }
      nil
    end
  end
end


Which enabled me to write code like this:

actual_attribute =
actual_attributes.get_attribute_ns(expected_namespace, expected_name)

I could have solved the problem with an external helper class instead,
but that would, in my opinion, have been a clumsier solution.


/Henrik

--

http://www.henrikmartensson.org/  - Reflections on software development
2cef22e5d84ec3cdc107a5f9f97537e5?d=identicon&s=25 Todd (Guest)
on 2006-01-09 09:58
(Received via mailing list)
James Edward Gray II wrote:
> On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:
>
> > How would you (the community) define meta-programming
>
> Code that writes code.

A shiver goes up my spine :)

>
> > open class system
>
> Classes that can be changed (methods added, removed, etc.) at runtime.

Scary.

> > and the dynamic nature of ruby?
>
> That's a lot harder.  :)
>
> I like to think that Ruby does away with much of the compile time vs
> runtime separation and that is a big source of it's dynamic nature.
>
> You will need a better definition than that though, of course...  ;)
>
> James Edward Gray II

The programmer in me loves Ruby for it's relative simplicity (coupled
with relative complexity if need be).  The IT and DBA in me shudders at
the thought that such a thing exists, simply because data integrity
should be paramount; more important than your family, for God's sake!
It has to be something you can put your foot on and be sure it won't
move.

I mean, here you have a black box that a few moments from now may not
be a black box anymore!  It may turn green...  It may pop out at you
like those fond memories of the jack-in-the-box.  You look at it, prod
it, it isn't reliable (you posit), it doesn't come up like the sun in
the morning every day, and start to feel there's some deep and dark
sinister purpose waiting to be unleashed.  This program, this thing,
suddenly feels like almost sort of a Pandora's box.  In that moment of
inspiration, you quickly walk away feeling better about yourself for
suggesting another, more 'stable', language that we can use.  The CIO
will be proud :)

At least, that was my first impression.  That, until I started seeing
how impressive not only the coding practices were, but also the
incredible knowledge base in the Ruby community.  Not to mention how it
has made my life a bit easier.

Todd
2cef22e5d84ec3cdc107a5f9f97537e5?d=identicon&s=25 Todd (Guest)
on 2006-01-09 10:25
(Received via mailing list)
James Edward Gray II wrote:
> On Jan 8, 2006, at 2:21 PM, Gregory Brown wrote:
>
> > How would you (the community) define meta-programming
>
> Code that writes code.

A shiver goes up my spine :)

>
> > open class system
>
> Classes that can be changed (methods added, removed, etc.) at runtime.

Scary.

> > and the dynamic nature of ruby?
>
> That's a lot harder.  :)
>
> I like to think that Ruby does away with much of the compile time vs
> runtime separation and that is a big source of it's dynamic nature.
>
> You will need a better definition than that though, of course...  ;)
>
> James Edward Gray II

The programmer in me loves Ruby for it's relative simplicity (coupled
with relative complexity if need be).  The IT and DBA in me shudders at
the thought that such a thing exists, simply because data integrity
should be paramount; more important than your family, for God's sake!
It has to be something you can put your foot on and be sure it won't
move.

I mean, here you have a black box that a few moments from now may not
be a black box anymore!  It may turn green...  It may pop out at you
like those fond memories of the jack-in-the-box.  You look at it, prod
it, it isn't reliable (you posit), it doesn't come up like the sun in
the morning every day, and start to feel there's some deep and dark
sinister purpose waiting to be unleashed.  This program, this thing,
suddenly feels like almost sort of a Pandora's box.  In that moment of
inspiration, you quickly walk away feeling better about yourself for
suggesting another, more 'stable', language that we can use.  The CIO
will be proud :)

At least, that was my first impression.  That, until I started seeing
how impressive not only the coding practices were, but also the
incredible knowledge base in the Ruby community.  Not to mention how it
has made my life a bit easier.

Todd
A6d3a37b5badfdd2f47655aa0e46604e?d=identicon&s=25 Eivind Eklund (Guest)
on 2006-01-09 13:56
(Received via mailing list)
On 1/8/06, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> I mean, my general advice when it comes to ruby when asked about
> security is that I basically respond, "There is none, but it's not as
> bad as you'd expect.  Write proper test suites, code responsibly, and
> make sure you nail down those edge cases.  Continuous integration is a
> must,  and idiomatic code with proper style will help make the API
> less likely to cause damage (such as the use of ! and other
> indicators).

There's documentation for how to do good APIs here:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign

I hope that's useful; feel free to edit and add/change/add discussion.

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

Let's look at it as a cost/benefit analysis.  The cost of declaring
variables and types end up as roughly half the code size.  That's
twice the amount to write, and, more importantly twice the amount to
read, twice the amount of places to change when refactoring, etc.  It
also means that there's a lot of things we can't do, because we are
"protected" from it.

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

I've implemented a system for doing run time checks of type
declarations, it's available from RPA (as types) and from
http://people.freebsd.org/~eivind/ruby/types/  This allows very
flexible type checks for Ruby programs, adding whatever amount of type
discipline you want.  In practice, I found this to just get in the way
- it detected very few bugs, and added more stuff to change when I did
refactoring.

Eivind.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 14:05
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Steve Litt wrote:

>> That code gets executed, and then there's a class called C with an
>
> that.
I think you mean method_missing.  It has nothing to do with instance
variables; it's just a hook or callback that you can define to
intercept calls to non-existent methods.  What you do at that point is
up to you.  You can also just not define it, in which case a call to a
non-existent message will raise an exception.

There's nothing inherently dangerous or non-deterministic about
method_missing.  It's basically a control-flow technique.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 14:11
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

> That's the million dollar question we've yet to answer :)
It's not that central a question to me.  In my own work with Ruby, I
can go from one month to the next without ever thinking about what
metaprogramming is, or whether or not I'm doing anything that people
would put in that category -- whereas thinking about the dynamic
nature of Ruby I've always found not only interesting but
enlightening.

I definitely don't think that metaprogramming is an extreme or higher
form of dynamism.  It's just a meta form of programming :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 14:27
(Received via mailing list)
Hi --

On Mon, 9 Jan 2006, Gregory Brown wrote:

> This brings up an interesting point though.  In Ruby, idioms are more
> than just 'good practice'.  They really do matter, because they are
> our biggest sense of 'security'.  This of course leaves the
> responsibilities in the hands of the coders, but from my experience,
> the majority of the well known applications adhere to good style, and
> their developers are consistant at being idiomatic in their
> application design.  The same can not necessarily be said for the
> majority in other languages.

I agree -- really "Ruby" in the sense we're talking about is more than
just the language; it's also the coding practices, and the fact that
there are ways (including, but not limited to, discussion with other
Rubyists) of making good decisions about what to do.

I have to say, I'm quite surprised that the image of Ruby that's
emerging in this thread is, at least in large part, of a sort of
mine-field that we all have to tiptoe our way through -- as if the
language is a malevolent force that we write programs in spite of, and
in triumph over, rather than in harmony with.  I've never perceived it
that way, and I wish I could find the words to turn the tide for
others.

I guess it comes down to this: worrying that something like dynamic
method redefinition is going to "bite" you, or "shoot you in the
foot", or whatever, at random times, without warning, is a bit like
worrying that your C program is going to erase all the files on your
hard drive.  If you don't want it to, don't tell it to, and it won't.

Most of the real issues in this realm have to do with modifying core
classes.  The main reason not to do this is that if someone else uses
your code as part of a program, your changes will affect their code
too.  Under circumstances where that can't happen, there's no reason
not to.

Meanwhile, other dynamic-programming things -- like defining
method_missing, creating classes batch-wise, whatever -- are cut from
exactly the same cloth as the Ruby that interprets your script in the
first place.  They're an opportunity to think expansively about what
you can do.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
2cef22e5d84ec3cdc107a5f9f97537e5?d=identicon&s=25 Todd (Guest)
on 2006-01-09 16:54
(Received via mailing list)
Gregory Brown wrote:

[snippet]

>
> I'd like to quote this snippet as the beginning of my article, is that okay?

Sure, whatever you think is best for your article.

> This brings up an interesting point though.  In Ruby, idioms are more
> than just 'good practice'.  They really do matter, because they are
> our biggest sense of 'security'.  This of course leaves the
> responsibilities in the hands of the coders, but from my experience,
> the majority of the well known applications adhere to good style, and
> their developers are consistant at being idiomatic in their
> application design.  The same can not necessarily be said for the
> majority in other languages.

Well said.

OT, why did my original post show up on this group three times?  I seem
to be having an issue with 3 lately.  Hmmmm...

Todd
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-09 17:18
(Received via mailing list)
On Monday 09 January 2006 08:26 am, dblack@wobblini.net wrote:

> I guess it comes down to this: worrying that something like dynamic
> method redefinition is going to "bite" you, or "shoot you in the
> foot", or whatever, at random times, without warning, is a bit like
> worrying that your C program is going to erase all the files on your
> hard drive.  If you don't want it to, don't tell it to, and it won't.

To get Ruby to do bad stuff, you need to enunciate quite clearly that
you want
it to do something bad. To get C to do something bad, a muffled mumble
could
be interpreted (compiled :-) by C to do something bad.

Nobody's infallable. C is much more unforgiving of programmer error than
Ruby.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
2cef22e5d84ec3cdc107a5f9f97537e5?d=identicon&s=25 Todd (Guest)
on 2006-01-09 17:34
(Received via mailing list)
Todd wrote:
> Gregory Brown wrote:
>
> [snippet]
>
> >
> > I'd like to quote this snippet as the beginning of my article, is that okay?
>

BTW, I should mention that using a quote like that may -- to your
intented audience -- sound a bit pretentious as the start of an
article.  You need a lead-in for something like that.  Well, you need
most everything that came beforehand in this thread, or at least a
summary of it.

Todd
8979474815030ad4a5d59718d1905715?d=identicon&s=25 Isaac Gouy (Guest)
on 2006-01-09 19:20
(Received via mailing list)
Eivind Eklund wrote:
> http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign
> read, twice the amount of places to change when refactoring, etc.  It
> also means that there's a lot of things we can't do, because we are
> "protected" from it.
>
> 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?

Is the C++ type system the same as the SML type system?

Will programmers who passively suffer compiler type-checking detect as
many bugs as programmers who actively use 'type-full' programming as a
checking-tool?
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 19:47
(Received via mailing list)
On 1/9/06, Todd <toddkennethbenson@yahoo.com> wrote:
> BTW, I should mention that using a quote like that may -- to your
> intented audience -- sound a bit pretentious as the start of an
> article.  You need a lead-in for something like that.  Well, you need
> most everything that came beforehand in this thread, or at least a
> summary of it.

I plan to go in reverse of that ;)  I *want* it to sound pretentious,
because your observation is the common one you hear from someone who
hasn't done much ruby or seen it actively working.  I'm not sure if
I'm going to use it at this point, but I thought it was a good example
of the common concerns.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 19:53
(Received via mailing list)
On 1/9/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

> I have to say, I'm quite surprised that the image of Ruby that's
> emerging in this thread is, at least in large part, of a sort of
> mine-field that we all have to tiptoe our way through -- as if the
> language is a malevolent force that we write programs in spite of, and
> in triumph over, rather than in harmony with.  I've never perceived it
> that way, and I wish I could find the words to turn the tide for
> others.

David, if it wasn't fully clear, I was being somewhat facetious when I
was talking about "Living Dangerous".  However, I think I will use the
title "The Open Nature of Ruby" because it sounds a lot more positive
and friendly.

You make a wonderful point.  I doubt very many people who are doing
ruby actively day to day think "Oh my god... what havoc is this code
going to unleash".  In fact, from my experience, Ruby has seemed to
comfort me and give me confidence more than most any other language.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 19:56
(Received via mailing list)
On 1/9/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

> would put in that category -- whereas thinking about the dynamic
> nature of Ruby I've always found not only interesting but
> enlightening.

Same here.  My concern is with the fear it seems to cause in people
migrating from the static world.  I honestly am very lazy and simply
do not want to argue the static vs. dynamic typing, early binding vs
open class structure, compile vs. runtime arguments anymore.  So, I'm
trying to write a well formed article I can point people to ;)

> I definitely don't think that metaprogramming is an extreme or higher
> form of dynamism.  It's just a meta form of programming :-)

well said.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 20:26
(Received via mailing list)
On Jan 9, 2006, at 1:55 PM, Gregory Brown wrote:
> My concern is with the fear it seems to cause in people
> migrating from the static world.

What is being feared?   I'm still not entirely
sure I understand what specific concerns lead to insecurity
about using a dynamic language like Ruby.  I'll bet if you
did some search of the literature you might find some
useful history on this debate as it relates to Smalltalk
and/or CLOS.

I'm not saying there aren't valid concerns.  What I'm saying
is: can those concerns be elaborated beyond some general
notion of 'fear' or 'security' and wouldn't that help construct
a more appropriate response?

Gary Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 21:36
(Received via mailing list)
On 1/9/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> and/or CLOS.
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.  We know that this isn't true, but
I am not entirely sure how to address it, though this thread has given
me some ideas.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 21:51
(Received via mailing list)
On 1/9/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:

> I'm not saying there aren't valid concerns.  What I'm saying
> is: can those concerns be elaborated beyond some general
> notion of 'fear' or 'security' and wouldn't that help construct
> a more appropriate response?

The fear in part has to do with type checking.  Ruby being typeless
scares people who tend to believe that type checking is absolutely
essential to 'safe' programming.  But as David Black and many others
had mentioned, safety is in the hands of the programmer.

I personally have never crashed my computer using Ruby.  On the
gripping hand, I've done many unsavory things in C, and at least a
couple in Perl.  These were 'accidents'.

I think that it's worthwhile to point that since low-level management
is not something we need to do in Ruby, such accidents are far less
likely to happen.  I think that this type of thing makes up the
lionshare of bugs and vulnerabilities.  You hear about overflow
exploits on a day to day basis... you very rarely hear of the l33t
h4x0r using metaprogramming to destroy a system.

People are afraid that without the type checking safety net, that the
program will begin to act unpredictable or will be capable of doing
random unsavory things.

The bottom line is, if you're in a production environment, you should
have all of your projects running against a comprehensive test suite.
Continuous integration should be assumed.  Though it's universally
agreeable that regardless of the language you choose, you 'should' be
doing this, I do believe the popular opinion in most of the
experienced ruby core community is that you *MUST* be doing this.

And you know what?  It takes me about 30 seconds to find out what
jimmy's evil little gem has done to my system when I run my units on
all my projects to make sure they haven't broken with the addition of
a new library.

I mean, come on, does anyone add a require 'foo' from the wild into
production code WITHOUT running their units?  If they do, well then
all bets are off.

The biggest thing that those with a fear of dynamicity need to
recognize is that it's not as if we're programming in Java or C++ but
just removing the type checking and other 'security' measures.  We're
programming in a language that was designed from the ground up to be
used in the way we're using it.

Reflection and introspection in Ruby are so good we can actually use
it to PREVENT  unsavory effects through using it in our unit tests.
Things like method_missing and respond_to? and the ability to search
our entire object space are features, not bugs.

This type of design allows for things like inversion of control /
dependency injection, which can be used to cleanly tack on logging and
unit testing features WITHOUT having to pollute methods with secondary
code.

I think that things like automated memoization make me LESS likely to
screw up than it would to roll my own in every single method that
needs it.

Ruby is no different than any other language.  Bad code and bad coders
will cause problems, good code and good coders will solve problems.
Simply because it was not a design goal to make the programmer feel
safe and 'secure', but rather to make them feel powerful is NOT a
flaw.

Wow... i'm ranting here.  Better here than in my article I suppose,
but there are my answers to our still yet to be precisely defined
questions ;)

Let me know what you think.
-Greg
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 22:00
(Received via mailing list)
On Jan 9, 2006, at 3:33 PM, Gregory Brown 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 Wright
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-09 22:00
(Received via mailing list)
Gregory Brown 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
http://www.artima.com/rubycs/ - 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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 22:03
(Received via mailing list)
On 1/9/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
>
> On Jan 9, 2006, at 3:33 PM, Gregory Brown 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.
A6d3a37b5badfdd2f47655aa0e46604e?d=identicon&s=25 Eivind Eklund (Guest)
on 2006-01-09 22:06
(Received via mailing list)
On 1/9/06, Isaac Gouy <igouy@yahoo.com> wrote:
> Eivind Eklund 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.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-01-09 22:09
(Received via mailing list)
On Jan 9, 2006, at 3:57 PM, gwtmp01@mac.com 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 Wright
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 23:07
(Received via mailing list)
On 1/9/06, James Britt <james_b@neurogami.com> wrote:
> Gregory Brown wrote:
> > ...
> > The fear in part has to do with type checking.  Ruby being typeless
>
> Ruby 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)
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 23:13
(Received via mailing list)
On 1/9/06, gwtmp01@mac.com <gwtmp01@mac.com> 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 ;)
8979474815030ad4a5d59718d1905715?d=identicon&s=25 Isaac Gouy (Guest)
on 2006-01-09 23:13
(Received via mailing list)
Eivind Eklund 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 ;-)
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-01-09 23:43
(Received via mailing list)
Hi --

On Tue, 10 Jan 2006, Gregory Brown wrote:

> On 1/9/06, James Britt <james_b@neurogami.com> wrote:
>> Gregory Brown wrote:
>>> ...
>>> The fear in part has to do with type checking.  Ruby being typeless
>>
>> Ruby 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
> => Fixnum
>
> So... 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
dblack@wobblini.net

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-09 23:46
(Received via mailing list)
Gregory Brown 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
> => 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)

I'm going to punt and refer you to this:

http://www.rubygarden.org/ruby?TypesInRuby

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.



James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - 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
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-09 23:58
(Received via mailing list)
On 1/9/06, dblack@wobblini.net <dblack@wobblini.net> 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? ;)
Ec9233451f7c6ba37a83388b87a1f565?d=identicon&s=25 Phrogz (Guest)
on 2006-01-09 23:58
(Received via mailing list)
> 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:

1) Identify clear problems, or perceived problems.
2) One by one, lay out:
2a) What the problem is in Ruby.
2b) Why it isn't (or is) a problem in the 'standard' language of
choice.
2c) How you can remove or mitigate the problem in Ruby using additional
features or changed coding styles. If you can't, say so.
2d) What benefits are made possible by the features of Ruby that cause
the problem.

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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-10 00:08
(Received via mailing list)
On 1/9/06, Phrogz <gavin@refinery.com> 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:
http://rubygarden.org/ruby?TheOpenNatureOfRuby

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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-01-10 00:11
(Received via mailing list)
On 1/9/06, James Britt <james_b@neurogami.com> wrote:
> Gregory Brown 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.
4d7bf65b4675b3e9575617929ab123f1?d=identicon&s=25 Paul Novak (Guest)
on 2006-01-10 20:03
(Received via mailing list)
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.
Ace7fa5337acbdf5897a6fc035897580?d=identicon&s=25 J.Ryan Sobol (Guest)
on 2006-01-10 20:19
(Received via mailing list)
Well put.

~ ryan ~
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-10 20:34
(Received via mailing list)
On Tuesday 10 January 2006 02:01 pm, Paul Novak 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 Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
A0599814ceddc2e283792f4e47c57f5e?d=identicon&s=25 Brian Takita (Guest)
on 2006-01-10 23:38
(Received via mailing list)
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/...
more details.

# A class like this can be in a library somewhere. This is a rough
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

# End library code

class Object
    def self.method_added(id)
        MethodDefinitionContainer[self.to_s + '.' + id.to_s] = caller[0]
    end
end

####
# Unit tests are run here
####

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
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-12 00:17
(Received via mailing list)
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
http://www.artima.com/rubycs/ - 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
055f96bd55507df17729ab06fc1edcf9?d=identicon&s=25 Peter Wright (Guest)
on 2006-01-12 13:10
(Received via mailing list)
Gregory Brown <gregory.t.brown@gmail.com> wrote:
> On 1/8/06, James Britt <james_b@neurogami.com> 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. :)
032840ea43aa284451ad8d19b3a32ddb?d=identicon&s=25 Jonas Hartmann (Guest)
on 2006-01-12 17:52
(Received via mailing list)
Gregory Seidman wrote:
...
> 3) duck typing allows unintended objects to be used in unintended ways
>
> 4) the ability to add/replace methods in existing classes allows library
>    internals to be inspected or modified
Also I consider myself a bad programmer I want to share my opinion on
this:

4) is about social security. the private and protected stuff I know of
java and all those things enable the tool language to be used by
management to enforce devision of work.

the management and team leaders can create a work model and thus can set
define who is responsible for what within the tools of work - the
programming language.

this opens a discussion I cannot join cause I am not working in larger
companies with high distances between management and workers
(=programmers).

I think what java (and possible c++, but i don't know) offers can be
archived in another way - but well, not by using ruby itself. Further I
think it is the wrong place to implement such "security" features in
work processes cause it can HINDER and reduce efficiency, creativity,
output. I think working with a modular application model in mind may
solve this. If you got commercial software written by software giants
(this is where, i think, these "security" models, added onto the
object-orientation-model cause it was just possible, apply) you can
instead of taking your time to develop and implement a language-side
"security"-model take your time and specify interfaces between parts,
modules, of your software. different teams will work on different
modules then which will run in different VMs communicating via inter
process messaging or via databases for example.

maybe my view is very narrow, but well, maybe it helps.
This topic is locked and can not be replied to.