In a persistent, image-based system where you can edit and debug programs in the very process in which they're running, metaprogramming is a necessity, not an a

In a persistent, image-based system where you can edit and debug programs in the very process in which they're running, metaprogramming is a necessity, not an anti-pattern. You couldn't implement Pharo's class browser, debugger, inspector, or most of its other tools without metaprogramming. Because of metaprogramming, these tools (even the debugger, thanks to context objects) can be implemented without the need for special access to the VM or the use of FFI. I don't want sound too harsh, but Rubyists really seem to have this annoying tendency to speak on certain subjects like OOP, metaprogramming, or dynamic languages generally as if they're authorities on them just by virtue of being Rubyists, when in fact Ruby and Python both are actually rather poor representatives of these concepts, at least compared with Smalltalk or (even more so) Lisp. It would serve us better in these discussions to use the languages that best represent a particular paradigm or concept (like metaprogramming) when considering its merits, just as we would likely use Haskell or Idris (or something more esoteric) when considering the merits of static typing or pure FP.