Let me preface this post by saying that I'm no Ruby expert. I like it. It's fun. But I won't claim extensive knowledge on it.
So when this guy blogs about a Python quality that he feel is better than a Ruby quality:
It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong.
In message "Re: Diff of opinion on dynamic stuff" on Fri, 23 Dec 2005 06:27:50 +0900, "Drew Mills" <drewmi...@gmail.com> writes:
| In Ruby they call it "opening a class" and think it's a cool | feature. I will assert: we are right, they are wrong. | | -- http://blog.ianbicking.org/theres-so-much-more-than-rails.html | |I am curious what this means. Is Python against dynamic stuff? And |Ruby for it? And so we just agree to disagree? Or do I misunderstand?
"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.
> Let me preface this post by saying that I'm no Ruby expert. I like it. > It's fun. But I won't claim extensive knowledge on it.
> So when this guy blogs about a Python quality that he feel is better > than a Ruby quality:
> It's the second generation that's going to be less enthused, > that's going to stare in bafflement at these classes that > mysteriously spawn methods, and trying to figure out what's > going when there's an exception in dynamically generated > code. You can monkeypatch code in Python pretty easily, but we > look down on it enough that we call it "monkeypatching". In > Ruby they call it "opening a class" and think it's a cool > feature. I will assert: we are right, they are wrong.
> I am curious what this means. Is Python against dynamic stuff? And > Ruby for it? And so we just agree to disagree? Or do I misunderstand?
I think what he is complaining about are some of the dynamically created convenience methods provided by ActiveRecord when dealing with the Model for a database. Things like Person.find_by_user_name are methods which are implemented using method_missing to do specific searches of database tables. Because these aren't "real methods", Ian feels they could be hard to debug. He probably has a point. But in this case I think the convenience overrides the occasional weird bug. I don't keep up with the Rails list and haven't done much Rails programming yet, but it might be interesting to see how many problems there are related to these kind of methods. I suspect in reality there are many less than what Mr. Bicking might think.
Also his lack of Ruby knowledge is showing in that he is talking about method_missing implementations being like "opening a class", which they aren't. They are basically dynamic method dispatch.
There are a lot of neat things that can be done with method_missing that are very powerful and convenient. I certainly do not subscribe the Pythonic "it is better not to have something powerful if it can be occasionally dangerous" philosophy that Mr. Bicking is describing. I suspect most other Rubyists (and Matz) have the same opinion.
Regarding the issue of "re-opening a class", there is certainly room for abuse here. Again in my opinion the convenience and flexibility this provides probably out-weigh the risks. Others may not agree. But there are a lot of major Ruby libraries that would be totally different and/or impossible if we didn't have this feature. Rails and RubyGems both come to mind, as well as a lot of the code provided in the standard library. All I know is that I really cringe when I look back at Java code which requires separate utility classes for special String methods instead of just adding them to the String class (which you cannot do in Java without the source code for it.) To me it makes sense to just re-open the class and add the methods there, where they belong. But I've been programming Ruby for quite a while, so maybe I'm just brainwashed ;)
> Let me preface this post by saying that I'm no Ruby expert. I like > it. > It's fun. But I won't claim extensive knowledge on it.
> So when this guy blogs about a Python quality that he feel is better > than a Ruby quality:
> It's the second generation that's going to be less enthused, > that's going to stare in bafflement at these classes that > mysteriously spawn methods, and trying to figure out what's > going when there's an exception in dynamically generated > code. You can monkeypatch code in Python pretty easily, but we > look down on it enough that we call it "monkeypatching". In > Ruby they call it "opening a class" and think it's a cool > feature. I will assert: we are right, they are wrong.
> I am curious what this means. Is Python against dynamic stuff? And > Ruby for it? And so we just agree to disagree? Or do I > misunderstand?
Well, Python is plenty dynamic. I think he is complaining about Ruby's ability to re-open a class. This can make it difficult to find the complete definition of a class (imagine doing this in a completely random way in multiple files). So while it can be abused, it can also be an incredible simplification of the code you write. One thing it does is flattens inheritance hierarchies, you don't need to introduce specialising classes just to add a few methods. Using xampl as an illustration: the Ruby version of xampl generates 1 class for every 3 generated by the Java version of xampl, one of those classes is eliminated because I can re-open classes (the other is eliminated due to duck typing). Another thing reopening classes does is, obviously, to allow you to extend the built in Ruby classes (they are just classes after all). I suppose Ian would think things even worse because in Ruby you can do this to objects as well as classes.
This 'monkeypatching' is very similar to concepts in Smalltalk and CLOS (Common Lisp's object system). Nobody in those communities complains too much (though Smalltalk's browser reassembles classes for you, and new CLOS programmers are sometimes at a bit of a loss because in CLOS methods may belong to two or more classes and it doesn't seem that the obvious thing to do is the right thing). Ruby just makes thing a lot easier.
Yukihiro Matsumoto wrote: > "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.
Matz has put us in great danger. But Rubyist are okay with it I guess. I am strangely at peace with this perilous language in my home!
Superman does dangerous things to solve problems, too. He'll bend a street pole around a villianous guy. People, stop cheering.
Yukihiro Matsumoto wrote: > "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.
A chef will tell you that sharp knives are safer than dull ones, since they do not have to be forced.
-- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
On 12/22/05, Joel VanderWerf <vj...@path.berkeley.edu> wrote:
> Yukihiro Matsumoto wrote: > > "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.
> A chef will tell you that sharp knives are safer than dull ones, since > they do not have to be forced.
If these two quotes together aren't a perfect Ruby quotable quote, I don't know what is.
<tongue_in_cheek>
And now we have another weapon in the Python vs Ruby war:
Python: Dull Ruby: Sharp
</tongue_in_cheek>
Seriously though, a Python vs Ruby war is kind of dumb, since it is like brothers fighting.
why the lucky stiff <ruby-t...@whytheluckystiff.net> writes:
> Yukihiro Matsumoto wrote: >> "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.
> Matz has put us in great danger. But Rubyist are okay with it I > guess. I am strangely at peace with this perilous language in my > home!
> Superman does dangerous things to solve problems, too. He'll bend a > street pole around a villianous guy. People, stop cheering.
> _why
I'm going to play devil's advocate and hopefully somebody with some direct experience will chime in.
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".
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.
>> Is Python against dynamic stuff? And Ruby for it?
Certainly Python can't be against all dynamic stuff. Ain't that dynamic stuff what Eckel and others *like* about Python compared to Java -- 'latent typing', etc.? And can't you make the same sort of arguments against duck/latent typing that the blogger makes against open classes and dynamically generated code? For example:
"It's the second generation that's going to be less enthused, that's going to stare in bafflement at these methods that mysteriously accept any type, and trying to figure out what's going on when there's an exception in dynamically typed code."
Or you could even complain about operator overloading, which isn't even a dynamic feature:
"It's the second generation that's going to be less enthused, that's going to stare in bafflement at these operators that can mysteriously be overridden to do anything, and trying to figure out what's going when there's an exception in an overridden '+' operator."
Of course, he could still be correct -- maybe duck typing and operator loading are safe enough, and open classes are too dangerous. But it's still kind of interesting that a Python guy is criticizing Ruby for being *too* dynamic, flexible and open. That's of course the argument of the static typing crowd against dynamic typing. I guess he must hate class-less languages like Self (or even Javascript).
Maybe that's the core difference between the Python and Ruby philosophies? Ruby is even more dynamic and 'open'?
Ruby isn't Self, but seems closer to the idea that essence of OO is that objects respond to messages. Precisely how you create an object, whether via a closed class, an open class, a Javascript constructor, or whatever is less essential from that point of view. Whereas other languages seem to be much more class-centric.
I worked my way through a Python book a few years ago, but I've forgotten most of it. Are classes objects in Python?
On Fri, Dec 23, 2005 at 07:36:48AM +0900, why the lucky stiff wrote:
> Yukihiro Matsumoto wrote: > >"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.
. . and thus, I have more explanation and understanding of why Python just "feels wrong" to me. One of the reasons I like Perl is that it doesn't limit me "for my own good". I guess I prefer a swiss army chainsaw over a plastic scalpel. [1]
> Matz has put us in great danger. But Rubyist are okay with it I guess. > I am strangely at peace with this perilous language in my home!
> Superman does dangerous things to solve problems, too. He'll bend a > street pole around a villianous guy. People, stop cheering.
Nice to know your emails are as entertaining as your excellent Ruby tutorial.
[1] No offense intended to the "plastic scalpel" contingent. There's nothing objectively wrong with precision wedded to safety limitations. I simply find it to be subjectively distasteful.
On Fri, Dec 23, 2005 at 08:53:18AM +0900, 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? 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. -- 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.
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.
> > 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.
On Fri, 23 Dec 2005, Chad Perrin wrote: > On Fri, Dec 23, 2005 at 07:36:48AM +0900, why the lucky stiff wrote: >> Yukihiro Matsumoto wrote: >>> "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.
Bob Hutchison wrote: > On Dec 22, 2005, at 4:27 PM, Drew Mills wrote:
> > Let me preface this post by saying that I'm no Ruby expert. I like > > it. > > It's fun. But I won't claim extensive knowledge on it.
> > So when this guy blogs about a Python quality that he feel is better > > than a Ruby quality:
> > It's the second generation that's going to be less enthused, > > that's going to stare in bafflement at these classes that > > mysteriously spawn methods, and trying to figure out what's > > going when there's an exception in dynamically generated > > code. You can monkeypatch code in Python pretty easily, but we > > look down on it enough that we call it "monkeypatching". In > > Ruby they call it "opening a class" and think it's a cool > > feature. I will assert: we are right, they are wrong.> > > > -- http://blog.ianbicking.org/theres-so-much-more-than-rails.html
> > I am curious what this means. Is Python against dynamic stuff? And > > Ruby for it? And so we just agree to disagree? Or do I > > misunderstand?
> Well, Python is plenty dynamic. I think he is complaining about > Ruby's ability to re-open a class. This can make it difficult to find > the complete definition of a class (imagine doing this in a > completely random way in multiple files). So while it can be abused, > it can also be an incredible simplification of the code you write. > One thing it does is flattens inheritance hierarchies, you don't > need to introduce specialising classes just to add a few methods. > Using xampl as an illustration: the Ruby version of xampl generates 1 > class for every 3 generated by the Java version of xampl, one of > those classes is eliminated because I can re-open classes (the other > is eliminated due to duck typing). Another thing reopening classes > does is, obviously, to allow you to extend the built in Ruby classes > (they are just classes after all). I suppose Ian would think things > even worse because in Ruby you can do this to objects as well as > classes.
> This 'monkeypatching' is very similar to concepts in Smalltalk and > CLOS (Common Lisp's object system). Nobody in those communities > complains too much (though Smalltalk's browser reassembles classes > for you, and new CLOS programmers are sometimes at a bit of a loss > because in CLOS methods may belong to two or more classes and it > doesn't seem that the obvious thing to do is the right thing). Ruby > just makes thing a lot easier.
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.
"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."
On Dec 22, 2005, at 5:30 PM, Patrick Hurley wrote:
> I think there are two conflated issues here. First open classes and > their abuse and second dynamic method creation. I think they distinct > enough they should be considered separately.
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 -- the Class. For an absolutely excellent explanation of the reasoning see Bertrand Meyer's <http:// en.wikipedia.org/wiki/Bertrand_Meyer> Object Oriented Software Construction 2nd Edition where he lays out Eiffel (which you really have to try seriously before you dismiss it). For an absolutely excellent experience of what happens when you relax some of this give CLOS -- or Ruby -- a try.
> Considering open classes, I find many of the conventions used in > Rails, once they are understood, simplify the resulting code. Given > this, it is worth pointing out that Rails is fairly unique in Ruby > development being a mainstream library that does modify base classes. > Additionally very few of the enhancements to the base classes are > "non-obvious" even a non-programmer will recognize the purpose of > item.pluralize. It is arguable and I would not disagree that this is > still thin ice. Using different Ruby libraries may cause issues—it > would be good if such changes could be better scoped. Still in > practice I have encountered none of the sort of problems I have would > expected. And unit tests are still the best medicine
Xampl also modifies existing classes. It will, optionally, write a file that shows you exactly what it did, but the changes are very uniform and predictable. From what I've seen of Rails the changes it makes are also uniform and predictable (I don't know if it will write a file). Furthermore, it looks as though the demands of Rails and xampl are independent. I've found that the biggest problem comes from putting requirements on the inheritance structure of extended objects. Ruby lets you side-step that problem very neatly (Java does not -- it is horribly complex what you have to do).
Unit tests are necessary I think. But they are not sufficient. Back in the Old Days when we worked in assembler, there was this horrid practice of 'patching' that worked by loading the original code then over-writing parts, maybe just a few bytes, of that with new code that fixed problems. This was a nightmare. Assembler is bad enough, patches are over top. Now, in Ruby, what if some clever 'programmer' decides to fix a problem by replacing a method without removing the original from the source? Though this is better than the assembler situation it is still outrageous... well, at least I'd be outraged not to mention enraged :-) And unit tests won't detect this behaviour.
Never-the-less, I *like* open classes. They are very powerful, very useful.
> The second issue of dynamic method generation (which I think was the > meat of the above quote) seems more like a documentation issue than > anything else. Consider a different framework that used a data file to > code generate a large number of access methods into a database, > similar to the functionality which is dynamically generated within > ActiveRecord—would this be the monkey patching that is so troubling? > Similarly, while it can take some acclimation, who cannot understand > code like:
> item_list = Item.find_all_upc(upc)
> Yes, you would look long and hard to find this particular method in > the API, but once the convention is understood (as it should be by > anyone who has developed in Rails for more than a day or two) it is > very intuitive.
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? The fact that the original method is also generated, and that you know that because Rails is consistent, will only make it harder to even recognise what is happening.
(I still like this capability, don't forget, just pointing out a stupid thing to do)
> In the end, I think it is a matter of trust. Any programming language > worth using, can be used poorly. Ruby and Python are no exception in > this regard. Writing good code which by definition is maintainable > code by both first and second generation coders is difficult. Rails > uses much of the power of the Ruby language to map the code to the > problem domain (database driven web applications).
I agree. But a lot of people think programmers need safety shields.
> As always the devil is in the details. I would be very curious which > aspects of Ruby/Rails development in particular anyone thinks will be > a long term maintenance issue.
Not the code generation part I think, in fact, it might turn out to be a major boon to maintenance (fix it in one place kind of thing). 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).
On 12/23/05, Bob Hutchison <hu...@recursive.ca> wrote:
> 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
> 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?
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."
