From: Josh Cheek Date: 2012-05-15T02:46:05+09:00 Subject: Re: I'm looking for a Metaprogramming Project --00163662e5eaede98a04c002a89d Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 14, 2012 at 12:17 PM, Marc Heiler wrote: > > What should I make to show off metaprogramming? > > The first thing is to laugh into the face of anyone who is > "metaprogramming". > > Metaprogramming is a fashion run that is hopefully soon dying out. > > It is synonymous to admit that whoever is using "meta" to solve > any given problem in Ruby there is: > > (a) no better solution (which would be sad, ruby is such a great > language) > (b) an ego boost to show off how to solve problems in convoluted and > ugly ways > (c) the bane of KEEPING THINGS SIMPLE, in an ever rising complexity for > marginal gains > > I don't say that "metaprogramming" has no valid use cases. For example, > I tend to use a config object for my projects, which allows one to call > any method on it, and that object tries to make sense of it when > possible. > > But that is really nothing "meta" I can see here. > > Meta is the new Agile - buzzwords with no values that will die soon. > > -- > Posted via http://www.ruby-forum.com/. > > Honestly, metaprogramming is just programming. It's consistent with what you do everywhere else in Ruby. The real metaprogramming is anything that involves a keyword. When you think about what that stuff does, it's really crazy. But since we're accustomed to it, we don't notice so much. I don't think metaprogramming adds that much overhead. Things like method_missing and const_missing are the ones that add actual overhead for me, because they're invisible when reflecting on the object. But defining methods doesn't seem crazy to me. The struct example I provided doesn't seem complex, you're just asking for a class with a specific set of methods, and a known initializer and set of behaviours. class_eval and instance_eval can also add complexity as things that seem like benign refactorings can break due to unexpected method lookups. Honestly, using modules to create large inheritance structures seems much more problematic to me. When the entire world is loaded into your environment, you can't think about one thing without thinking about everything. The overhead associated with this is tremendous, and for me greatly exceeds any pain I've felt from dynamically adding / responding to methods. -Josh --00163662e5eaede98a04c002a89d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2012 at 12:17 PM, Marc Heiler <lists@ruby-forum.com= > wrote:
> What should I make to show off metaprogramming?

The first thing is to laugh into the face of anyone who is
"metaprogramming".

Metaprogramming is a fashion run that is hopefully soon dying out.

It is synonymous to admit that whoever is using "meta" to solve any given problem in Ruby there is:

(a) no better solution (which would be sad, ruby is such a great
language)
(b) an ego boost to show off how to solve problems in convoluted and
ugly ways
(c) the bane of KEEPING THINGS SIMPLE, in an ever rising complexity for
marginal gains

I don't say that "metaprogramming" has no valid use cases. Fo= r example,
I tend to use a config object for my projects, which allows one to call
any method on it, and that object tries to make sense of it when
possible.

But that is really nothing "meta" I can see here.

Meta is the new Agile - buzzwords with no values that will die soon.

--
Posted via http://= www.ruby-forum.com/.


Honestly, metaprogramming is just p= rogramming. It's consistent with what you do everywhere else in Ruby. T= he real metaprogramming is anything that involves a keyword. When you think= about what that stuff does, it's really crazy. But since we're acc= ustomed to it, we don't notice so much.

I don't think metaprogramming adds that much overhe= ad. Things like method_missing and const_missing are the ones that add actu= al overhead for me, because they're invisible when reflecting on the ob= ject. But defining methods doesn't seem crazy to me. The struct example= I provided doesn't seem complex, you're just asking for a class wi= th a specific set of methods, and a known initializer and set of behaviours= .

class_eval and instance_eval can also add complexity as= things that seem like benign refactorings can break due to unexpected meth= od lookups.

Honestly, using modules to create larg= e inheritance structures seems much more problematic to me. When the entire= world is loaded into your environment, you can't think about one thing= without thinking about everything. The overhead associated with this is tr= emendous, and for me greatly exceeds any pain I've felt from dynamicall= y adding / responding to methods.

-Josh
--00163662e5eaede98a04c002a89d--