Looks like AOP-style feature. AOP is definitely powerful though there
was a debate
<TheServerSide | Your Java Community discussing server side development its
potential of being dangerous. Even strong-type language Java has several AOP
implementations, some of which modify byte-codes on the fly (poor java guys
don't have open class). Not to mention the usage in Rails (ex.
before_filter, acts_as_*).
I feel that Ruby is more implicit than Python in style, which is actually
similar to our natural languages, though we may sometimes misunderstand each
others.
···
On 12/28/05, Austin Ziegler <halostatue@gmail.com> wrote:
See my
own Transaction::Simple for an example -- it injects its functionality
into any class that requests it. In Ruby, that's definitely not code
smell. In Python? I don't know.
Rubyists are mostly people who know how not to aim at their foot, and
are skilled in first-aid just in case. But what happens when the code
is delivered and moves into maintenance mode? It falls into the hands
of code-slaves who are just dying to sacrifice toes and heap the blame
straight on you is what. I'm assuming it's these -- probably not
Rubyist -- people who are being refered to as the "second generation".
I think you're probably right, and it's a valid concern. I just don't
think it's a valid reason for eschewing Ruby.
Surely, if you delivered Pascal code instead of Ruby code, it would be
less likely that the bozo trying to make a one-line change is going to
end up deleting 25 million rows from your customer's database or
something.
That's really only because while it might take a ten-line change to do
the same thing in Pascal, that one line in Ruby has the functionality of
about twenty lines of Pascal code. There are things I like about
Pascal, but this isn't one of them.
By the way . . .
I have, in the past, found myself thinking Python might be the Pascal of
scripting languages, and you got me thinking about that again.
···
On Fri, Dec 23, 2005 at 08:53:18AM +0900, Steven Lumos wrote:
--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
Rubyists are mostly people who know how not to aim at their foot, and
are skilled in first-aid just in case. But what happens when the code
is delivered and moves into maintenance mode?
My code goes into maintenance mode almost as soon as
I've written 40 lines, i.e., I try to go depth-first
and then flesh out the skeleton as priorities dictate.
This is all done while creating a safety-net, a custom-
application debugger, through test-first development.
(Note: I've never had need of Ruby's debugger.)
The maintenance folks (me initially) are left with
executable, non-lying specifications for how everything
should behave and recipes for building new safety net.
"open class" is so strong (often too strong), we can break things
easily. In other word, Ruby trust you to give you sharp knives, where
Python don't. From the Python point of view, it's wrong, I guess.
I understood that 100%, and agree with it similarly. Keep in mind, I'm
mostly coming to Ruby from the direction of Perl -- the Swiss Army
Chainsaw to some -- and have no problem with being handed a sharp tool
and being told to be careful with it.
Perhaps more imporantly than how this relates to my agreement, though,
is the fact that I think you have hit on a fundamental point of
divergence between the Python community and most of the rest of the
"very powerful and succinct scripting language" communities out there
(particularly Lisp, Perl, and Ruby come to mind). Python is,
essentially, to this family of languages as Pascal is to the family of
languages that includes stuff like C++, Objective C, and so on.
Some languages are designed primarily to empower the programmer,
trusting that the programmer will be smart enough to avoid doing
something suicidal with that power. Python strikes me, on reflection,
as a language designed primarily to protect the programmer, trusting
that the programmer will be smart enough to use it effectively despite
limitations.
I've had for a long time a kind of semi-formulated idea about all this
in my head, and have never expressed it clearly. Let me try, and
probably fail.
In the Perl world, there was ("was" as in, I'm not in that world any
more) a perennial sense that all this "shooting in the foot" stuff was
a kind of test of personal resistance and fortitude. It felt
sometimes like the power of the language was mainly serving to allow
people to demonstrate how careful and wise they were. I don't say
that the best Perl programmers fell into this pattern, but in a wider
sense it definitely seemed that knowing about the "rope", and
maintaining a healthy distance from it, was a kind of badge of honor.
In Ruby, I see it differently. This is where I start having trouble
expressing it. It's a kind of wish that the gravitational forces be
aligned differently: instead of showing one's strength by pulling
away from the vortex, perhaps the powerful things in the language
could be *used* in productive ways, so that one falls *toward* them,
but without danger.
I'm not sure what this means, in practical terms.
David
···
On Fri, 23 Dec 2005, Chad Perrin wrote:
On Fri, Dec 23, 2005 at 07:36:48AM +0900, why the lucky stiff wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
On 12/22/05, James Britt <james_b@neurogami.com> wrote:
> Bob Hutchison wrote:
> ...
>
> > Just be careful where you aim that thing.
>
>
> Oh, inspiration for Yet Another Ruby Slogan:
>
> Ruby: You'll Shoot Your Eye Out.
I agree. But these issues and a few others (e.g. types, inheritance,
encapsulation, modules, namespaces) are often combined, or conflated,
deliberately, into a single solution
These are powerful tools and their power increases by using them
together, I suppose that the danger (the point of the article) may as
well, but you would have to show me a case. The "danger" issues appear
to be specific case issues and not with their combined use.
...in Ruby, what if some clever 'programmer'
decides to fix a problem by replacing a method without removing the
original from the source?
Trust
It is possible to intentionally write code to pass a unit test and
later fail. Of course you could argue that some higher level set of
tests should fail and start a "arms race" with your devious
programming the and rest of the responsible coders writing unit tests.
Of course you could just take the poor misguided soul aside and
explain the error of their ways -- show them how to write a proper
unit test for the original method that was in error and then correct
it. Of course if you could just fire the numbnut too If you work
in an environment where you cannot trust the developers powerful tool
may be better replaced with straight jackets -- as always select the
best tool for your environment and task.
A little more than just a documentation issue I think, but certainly
related. What if a soon-to-be-unemployed 'programmer' built up a
string in memory, maybe computing the name somehow, then evaled it?
Trust...
I'd be more concerned with having to re-factor a controller and
breaking a bunch of URLs (but I don't know Rails well enough to know
if this is actually a possible issue).
Internal to the application good coding in Rails uses url_for type
helpers that will generally deal with all of this correctly. External
to the app, if it is a concern routes can be pretty easily manipulated
-- but this is a good point for externally linked sites, action names
are "pushed" into your URL interface by default and they should be
carefully considered.
Cheers,
Bob
Happy Holidays and thank you for taking the time to respond
pth
···
On 12/23/05, Bob Hutchison <hutch@recursive.ca> wrote:
> Yes, the equivalent of "method_missing" has been used for many things
> in Smalltalk. Glorifying in how we can hack "doesNotUnderstand:"
> avoids having to admit that there's been a problem with the language.
The problem being: in Smalltalk the language there is no explicit way
in the language to add a method to a class at runtime?
Adding a method to a class at runtime is trivial, simply send the
message "compile: aMethodSourceString" to the class.
afaict Over the years Smalltalk has accumulated a bunch of really
clever programming techniques to work-around the lack of meta protocols
for controlling message passing.
afaict CLOS provides directly what Smalltalk can only accomplish
indirectly - so we should celebrate "doesNotUnderstand:" trickery as
clever programming rather than clever language design.
···
On Dec 23, 2005, at 12:47 AM, Isaac Gouy wrote:
Maybe so, but the Smalltalk *environment* allows the programmer to do
exactly the same thing as the browser or debugger at runtime (though
only on a class level). In some implementations, there is a method
that changes an object's class, and that combined with the ability to
create a new class at runtime... (well, this is hard to manage, and
some implementations will, effectively, only redefine the parent
class of an object). This excessive use/dependency on
doesNotUnderstand is not necessary in Smalltalk.
Isn't re-opening a class very similar to some of the better methods
in the paper below? At the very least, the associated problems are
similar
What are the Python folks doing as an alternative?
>
> "This comparison highlights that the most commonly used technique
> based
> on the specialization of the doesNotUnderstand: method is not the best
> one. As a first explanation of this situation, one should note that
> the
> ability to directly execute a method has only lately been
> introduced in
> the interpreters (methods valueWithReceiver:arguments: on
> CompiledMethod class in VisualWorks and
> executeWithReceiver:andArguments: in IBM Smalltalk). Moreover, this
> comparison shows that the techniques based on VM lookup method or
> method wrappers should be considered by more programmers than it is
> currently the case."
>
> "Evaluating Message Passing Control Techniques in Smalltalk"
> http://www.iam.unibe.ch/~scg/Archive/Papers/
> Duca99aMsgPassingControl.pdf
Also, to generalize, it seems that the Ruby community is perhaps less
sensitive to code smells or more tollerant of magic compared to the
Python community, which I guess was my larger point.
Is it less sensitive to code smells, or is it something that isn't
considered a code smell in Ruby? I think that the Ruby community is as
.. rough on code smell as any community, but we consider different
things smelly than the Python community does.
It's a little of both -- clearly there's some awareness among Ruby
programmers that opening classes introduces some possible issues. And
the "sharp tools" comments imply that there's potential to cut
yourself, but people feel that's okay. There's always a danger to any
technique; the question is how much danger is okay, depending on how
complex the problem at hand is. I get a sense that prevailing opinion
in the Ruby community accepts a balance with more danger than in
Python.
Well, I can think of two applicable "dangers," off the top of my head: the danger of coding the wrong thing (i.e. bugs), and the danger of taking to long to do it (i.e. un-maintainability) (and, of course, they're related). Many factors play a role in this, including unit tests, coding skills, code complexity, the language semantics at hand... And I think Rubyists are just tackling those two dangers with a different combination of tools than the Pythonistas -- not saying that "more danger is okay."
Devin
···
On 28/12/05, Ian Bicking <ianb@colorstudy.com> wrote:
There seems to be alot of industry inertia on static time tools. Better
runtime tools would make a dynamic language such as Ruby more mainstream.
A number of people have proposed that the runtime tools can work with good
unit tests in place to exercise all of the code paths.
The breakpoint library is a good start but there is more potential. For
example, a tool that analyzes the runtime paths and graphs an object's
dependencies would be nice.
···
On 12/22/05, Bil Kleb <Bil.Kleb@nasa.gov> wrote:
Steven Lumos wrote:
>
> Rubyists are mostly people who know how not to aim at their foot, and
> are skilled in first-aid just in case. But what happens when the code
> is delivered and moves into maintenance mode?
My code goes into maintenance mode almost as soon as
I've written 40 lines, i.e., I try to go depth-first
and then flesh out the skeleton as priorities dictate.
This is all done while creating a safety-net, a custom-
application debugger, through test-first development.
(Note: I've never had need of Ruby's debugger.)
The maintenance folks (me initially) are left with
executable, non-lying specifications for how everything
should behave and recipes for building new safety net.
In Ruby, I see it differently. This is where I start having trouble
expressing it. It's a kind of wish that the gravitational forces be
aligned differently: instead of showing one's strength by pulling
away from the vortex, perhaps the powerful things in the language
could be *used* in productive ways, so that one falls *toward* them,
but without danger.
Wrapping unrubyish things behind a rubyish interface so other people can do things in the Ruby way without endangering themself?
Of course this doesn't work when the very thing you are trying to do is unrubyish and not just its implementation.
Oh, and I didn't define "rubyish" and its opposite on purpose because I can't.
One thing that Open objects are useful for are creating
"seams<http://c2.com/cgi/wiki?SoftwareSeam>"
and making the object easier to test. Bearing this in mind, systems that use
open objects can be made more reliable than systems that dont.
···
On 12/28/05, Devin Mullins <twifkak@comcast.net> wrote:
Ian Bicking wrote:
>Austin Ziegler wrote:
>
>
>>On 28/12/05, Ian Bicking <ianb@colorstudy.com> wrote:
>>
>>
>>>Also, to generalize, it seems that the Ruby community is perhaps less
>>>sensitive to code smells or more tollerant of magic compared to the
>>>Python community, which I guess was my larger point.
>>>
>>>
>>Is it less sensitive to code smells, or is it something that isn't
>>considered a code smell in Ruby? I think that the Ruby community is as
>>.. rough on code smell as any community, but we consider different
>>things smelly than the Python community does.
>>
>>
>
>It's a little of both -- clearly there's some awareness among Ruby
>programmers that opening classes introduces some possible issues. And
>the "sharp tools" comments imply that there's potential to cut
>yourself, but people feel that's okay. There's always a danger to any
>technique; the question is how much danger is okay, depending on how
>complex the problem at hand is. I get a sense that prevailing opinion
>in the Ruby community accepts a balance with more danger than in
>Python.
>
Well, I can think of two applicable "dangers," off the top of my head:
the danger of coding the wrong thing (i.e. bugs), and the danger of
taking to long to do it (i.e. un-maintainability) (and, of course,
they're related). Many factors play a role in this, including unit
tests, coding skills, code complexity, the language semantics at hand...
And I think Rubyists are just tackling those two dangers with a
different combination of tools than the Pythonistas -- not saying that
"more danger is okay."
There seems to be alot of industry inertia on static time tools. Better
runtime tools would make a dynamic language such as Ruby more mainstream.
A number of people have proposed that the runtime tools can work with good
unit tests in place to exercise all of the code paths.
The breakpoint library is a good start but there is more potential. For
example, a tool that analyzes the runtime paths and graphs an object's
dependencies would be nice.
The ruby-breakpoint library is not yet everything I would like it to be.
I might even morph it into a Smalltalk style IDE in the future.
However, as soon as I have that PowerBook I owe myself I will work on finishing the basic functionality of the GUI client. After that we'll see what else is possible. I have high hopes on GTK2 and Glade and all that. It makes it easy to keep the code in a clean and sane state.
The code visible on there is the code of the GUI itself. It is written in wxRuby and ugly. wxRuby tends to be in the way way too often.
I want this to work well on OS X, though, which means that it should run without an X server. There's a port of GTK going on that should achieve just that. I'd like to test this, but am still missing the PowerBook. It should reach me soon enough, though...
And Ruby-GTK just rocks.
The more help I can get on this the better. But I'm also interested in other development tools that actually make use of Ruby's dynamic nature instead of working around it... (For example the method name completion in jEdit's Ruby plug in is insanely clever. We need more of that kind of thing!)
I don't think that was the intent of that statement at all.
···
On Sat, Dec 24, 2005 at 04:58:52AM +0900, Florian Groß wrote:
dblack@wobblini.net wrote:
>In Ruby, I see it differently. This is where I start having trouble
>expressing it. It's a kind of wish that the gravitational forces be
>aligned differently: instead of showing one's strength by pulling
>away from the vortex, perhaps the powerful things in the language
>could be *used* in productive ways, so that one falls *toward* them,
>but without danger.
Wrapping unrubyish things behind a rubyish interface so other people can
do things in the Ruby way without endangering themself?
In Ruby, I see it differently. This is where I start having trouble
expressing it. It's a kind of wish that the gravitational forces be
aligned differently: instead of showing one's strength by pulling
away from the vortex, perhaps the powerful things in the language
could be *used* in productive ways, so that one falls *toward* them,
but without danger.
Wrapping unrubyish things behind a rubyish interface so other people can
do things in the Ruby way without endangering themself?
I don't think that was the intent of that statement at all.
You're right: it wasn't
I think the best example is still the idea of something along the
lines of Ruby Behaviors or selector namespaces -- that is, a way to
make changes to core Ruby that are block- or file- or
namespace-scoped. (Ruby Behaviors was my attempt; there have been
others, and selector namespaces is a possible way this kind of thing
might happen in Ruby 2.) The idea is to harness the power, rather
than look at it as something that only serves the purpose of not being
used.
Basically it seems to me that if a language is designed with this kind
of power, and it's unuseable (or nearly so), that has to mean that the
design doesn't make sense. I am convinced that Ruby's design makes
sense. I think it just hasn't been fully explored and exploited.
Mind you, there are several "Behaviors"-like libraries (better written
than Behaviors, in fact), yet I don't personally know of anyone who
uses them. So maybe the demand for this isn't so great... but I
continue to believe that if there were some way to make limited-scope
core changes built into the language, it *would* be used. And it
would take a lot of pressure off the RCR process
Anyway, that's an example -- for me probably the best one -- of what I
mean by finding ways to fall *toward* the power of the language,
instead of constantly pushing away from it.
David
···
On Sat, 24 Dec 2005, Chad Perrin wrote:
On Sat, Dec 24, 2005 at 04:58:52AM +0900, Florian Groß wrote:
dblack@wobblini.net wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
