3 ms·

...You know, they could just limit monkey-patching, and drop call/cc and a few other features (not having call/cc opens a lot of options), and they'd have a dra

...You know, they could just limit monkey-patching, and drop call/cc and a few other features (not having call/cc opens a lot of options), and they'd have a dramatically easier system to work with, right? When was the last time somebody used call/cc in ruby code, anyways? By current implementation, it's only useful for thought experiments and toys, and we have Scheme for that. In short, deoptimization seems like a case of solving one of the sinister black tendrils of the problem, not the root cause.

ricardobeat 10y ago
Miniruby already exists.
- qwertyuiop924 10y ago
  Does Miniruby have call/cc?
onetwotree 10y ago
The problem with limiting monkey-patching is that it's used extensively and with great variety in Rails (and other popular Ruby projects). Monkey patching, done correctly, will "settle" over time. That is, once your rails app has called all the dynamic finder methods it's ever going to use, and `require`d all of the `active_support` extensions it'll need, it's done monkey patching. Of course, there are programming mistakes that can open a huge bag of worms, such as using `OpenStruct`s. Generally, anything that will smash the global method cache[1] is also going to require the kind of `iseq` deoptimization that this pull is about (in fact, smashing the global method cache is a simple case of deoptimization). This is why deoptimization is so useful - it's almost never going to happen after your app has settled, but it's necessary to maintain correctness while `active_support` is being loaded and adding all of those yummy methods to core classes. `call_cc` can go to hell though - I've never seen a program that uses it ;-) [1] https://github.com/charliesome/charlie.bz/blob/master/posts/things-that-clear-rubys-method-cache.md https://github.com/charliesome/charlie.bz/blob/master/posts/...
- qwertyuiop924 10y ago
  Yeah, but there's got to be a less needlessly overcomplicated way of doing this. It's ridiculous. As for call_cc (or to use its "real" name call/cc, or call-with-current-continuation), my usual response to those that propose dropping call/cc (usually proposing shift/reset or similar as a replacement) is "over my dead body," but that's Scheme: supporting weird experiments is part of Scheme's job, and there's at least one high-quality implementation of Scheme that uses Cheney-on-the-MTA compilation, which makes call/cc fast enough for Real Work. In ruby, the situation is different: call/cc is slow, expensive, and Ruby is a language for getting stuff done, not academic experiments about control structure.
eropple 10y ago
Dropping call/cc would represent a mindset that would immediately make me skeptical regarding Ruby's future. Limiting monkey-patching would make me immediately drop Ruby. The language's value to me is that I can bend it to do lots of stuff in ways I understand and control. Going away from that removes the reason for Ruby to exist. What you call "the root cause" is literally why I use Ruby.
- qwertyuiop924 10y ago
  The thing is, I don't think that we need to kill everything to fix this. You can certainly fix the ruby compiler so that monkey-patching is fast, and you don't have to deoptimize for this sort of thing. Call/cc, OTOH, should be dropped from Ruby. It's caused a great deal of pain for the devs, and it's not nearly as important as it is in something like Scheme. They could implement the similar (though not as cool) shift/reset, and have much of the power of call/cc, an easier implementation, and perf that's practical.
  - chrisseaton 10y ago
    > You can certainly fix the ruby compiler so that monkey-patching is fast, and you don't have to deoptimize for this sort of thing. Do you have a concrete idea for how to support monkey patching without deoptimisation and have it be fast? If you do, congratulations it's a major breakthrough in language research and you should write a paper.
    - qwertyuiop924 10y ago
      I was kind of joking about that. Or something. Seeing as I'm not a compiler/interpreter expert, I honestly don't know what I was thinking posting that. Seriously, what was I thinking? But I'm just thinking this is utterly nuts: Not that I'm degrading your accomplishments. If it's really that hard a problem, than the fact that you have solved it at all is impressive. But the fact that we have to go to those lengths at all is crazy. Part of why it seems so nuts to me is probably because I don't know enough about Ruby's internals. As I understand it, A class's methods are kept in a datstructure, associating them with their identity (I think it was a hashtable at some point, although this may have changed) - A vtable, in C++ parlance. When you monkeypatch a method, you're either adding a function to the vtable, or changing which function a vtable entry points to. I don't know why you have to deoptimize to do that. past-me should have probably understood the problem better before he made claims he couldn't back about it, but there's nothing I can about it now, save apologize for being stupid, and ask for an explanation. Which is what I'm doing now.

ricardobeat 10y ago

Miniruby already exists.

qwertyuiop924 10y ago
Does Miniruby have call/cc?

onetwotree 10y ago

The problem with limiting monkey-patching is that it's used extensively and with great variety in Rails (and other popular Ruby projects). Monkey patching, done correctly, will "settle" over time. That is, once your rails app has called all the dynamic finder methods it's ever going to use, and `require`d all of the `active_support` extensions it'll need, it's done monkey patching. Of course, there are programming mistakes that can open a huge bag of worms, such as using `OpenStruct`s. Generally, anything that will smash the global method cache[1] is also going to require the kind of `iseq` deoptimization that this pull is about (in fact, smashing the global method cache is a simple case of deoptimization). This is why deoptimization is so useful - it's almost never going to happen after your app has settled, but it's necessary to maintain correctness while `active_support` is being loaded and adding all of those yummy methods to core classes. `call_cc` can go to hell though - I've never seen a program that uses it ;-) [1] https://github.com/charliesome/charlie.bz/blob/master/posts/things-that-clear-rubys-method-cache.md https://github.com/charliesome/charlie.bz/blob/master/posts/...

qwertyuiop924 10y ago
Yeah, but there's got to be a less needlessly overcomplicated way of doing this. It's ridiculous. As for call_cc (or to use its "real" name call/cc, or call-with-current-continuation), my usual response to those that propose dropping call/cc (usually proposing shift/reset or similar as a replacement) is "over my dead body," but that's Scheme: supporting weird experiments is part of Scheme's job, and there's at least one high-quality implementation of Scheme that uses Cheney-on-the-MTA compilation, which makes call/cc fast enough for Real Work. In ruby, the situation is different: call/cc is slow, expensive, and Ruby is a language for getting stuff done, not academic experiments about control structure.

eropple 10y ago

Dropping call/cc would represent a mindset that would immediately make me skeptical regarding Ruby's future. Limiting monkey-patching would make me immediately drop Ruby. The language's value to me is that I can bend it to do lots of stuff in ways I understand and control. Going away from that removes the reason for Ruby to exist. What you call "the root cause" is literally why I use Ruby.

qwertyuiop924 10y ago
The thing is, I don't think that we need to kill everything to fix this. You can certainly fix the ruby compiler so that monkey-patching is fast, and you don't have to deoptimize for this sort of thing. Call/cc, OTOH, should be dropped from Ruby. It's caused a great deal of pain for the devs, and it's not nearly as important as it is in something like Scheme. They could implement the similar (though not as cool) shift/reset, and have much of the power of call/cc, an easier implementation, and perf that's practical.
- chrisseaton 10y ago
  > You can certainly fix the ruby compiler so that monkey-patching is fast, and you don't have to deoptimize for this sort of thing. Do you have a concrete idea for how to support monkey patching without deoptimisation and have it be fast? If you do, congratulations it's a major breakthrough in language research and you should write a paper.
  - qwertyuiop924 10y ago
    I was kind of joking about that. Or something. Seeing as I'm not a compiler/interpreter expert, I honestly don't know what I was thinking posting that. Seriously, what was I thinking? But I'm just thinking this is utterly nuts: Not that I'm degrading your accomplishments. If it's really that hard a problem, than the fact that you have solved it at all is impressive. But the fact that we have to go to those lengths at all is crazy. Part of why it seems so nuts to me is probably because I don't know enough about Ruby's internals. As I understand it, A class's methods are kept in a datstructure, associating them with their identity (I think it was a hashtable at some point, although this may have changed) - A vtable, in C++ parlance. When you monkeypatch a method, you're either adding a function to the vtable, or changing which function a vtable entry points to. I don't know why you have to deoptimize to do that. past-me should have probably understood the problem better before he made claims he couldn't back about it, but there's nothing I can about it now, save apologize for being stupid, and ask for an explanation. Which is what I'm doing now.