tag:blogger.com,1999:blog-9944221.post4205182655447066894..comments2023-11-03T06:15:55.087-05:00Comments on Meme Agora: Ruby Matters: Meta-programming, Synthesis, and GenerationNeal Fordhttp://www.blogger.com/profile/12839796402858974817noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-9944221.post-68233127204235151302007-09-10T22:34:00.000-05:002007-09-10T22:34:00.000-05:00>>>>>>>>>>Some developer tools modify the bytecode...>>>>>>>>>><BR/>Some developer tools modify the bytecode of the methods to add functionalities (spies, traces, etc) without modify its source.<BR/><<<<<<<<<<<BR/><BR/>Which is exactly my point. I didn't mean to imply (impune?) Smalltalk by saying that its meta-programming (which is, I agree, hopelessly overloaded itself) is somehow deficient or weak. In fact, it is probably better thought out than Ruby's. My point (and the only real point of comparison) is that the <I>tools</I> in Smalltalk handled much of this type of coding, whereas we don't have these tools in Ruby. The end result is close to the same, but the Domain Specific Language aspects are preserved in Ruby because we don't have the tool.Neal Fordhttps://www.blogger.com/profile/12839796402858974817noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-35937584243446940512007-09-10T17:31:00.000-05:002007-09-10T17:31:00.000-05:00I believe you are missing the point about Smalltal...I believe you are missing the point about Smalltalk "meta programming".<BR/>In some way, the entire Smalltalk system is meta, because all the classes and methods are "generated" by other objects of the system.<BR/>But many meta programming is done by aggregating and/or composing objects, or instantiating new ones. <BR/><BR/>Hardly ever you hear a Smalltalker talking about "generating code", we use objects, we don't generate code, the method "has" source (aka code), which if lost can be "regenerated" from its internals.<BR/>Some developer tools modify the bytecode of the methods to add functionalities (spies, traces, etc) without modify its source.<BR/><BR/>The only "code generation" technique I see from time to time is the instantiation of some sort of "spec" (windowing, ORM, etc.), which ends instantiating objects.<BR/><BR/>The "semantic" is not lost if the entities are properly reified.<BR/>For example, in one of the available ORM frameworks, the has_many is a message sent to a spec/definition: <BR/><BR/><B>define:</B> #children <B>as:</B> (<I>SortedCollection</I> <B>of:</B> <I>Person</I>).<BR/><BR/>Regards.Estebanhttps://www.blogger.com/profile/02779362875929301975noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-61224114696444253332007-09-06T09:58:00.000-05:002007-09-06T09:58:00.000-05:00>>>>>>>>>>One of the readers insist that you proba...>>>>>>>>>><BR/>One of the readers insist that you probably know nothing about Glorp or Magritte.<BR/><<<<<<<<<<<BR/><BR/>That is true -- I know nothing about OR mapping frameworks in Smalltalk. But posing this as strictly a discussion about OR mapping misses the point entirely. I'm talking about the meta-programming technique, not this implementation. <BR/><BR/>>>>>>>>>>><BR/>because everything in Smalltalk is more unified - including having an internal IDE - makes extensions that much more easy than Ruby, basically making DSL-like features unnecessary<BR/><<<<<<<<<<<BR/>This is also true, tragically so in the Smalltalk world. DSLs are about abstractions, revealing intent. You can build the same features in tools (ala my example) but you lose the intent of what you were doing. I'm sure that lots of Smalltalkers will disagree with my assertions. That's fine: it isn't a zero-sum game. But to provide tooling like Smalltalk does entails conscious trade-offs. I like the trade-offs made by Ruby so far, and don't like the ones imposed on Smalltalk by the environment. You mileage may vary. But, eventually Ruby will get sophisticated tools, but it would be very difficult to re-wire Smalltalk to provide some of the affordances in Ruby.Neal Fordhttps://www.blogger.com/profile/12839796402858974817noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-43152309140492632052007-09-06T08:27:00.000-05:002007-09-06T08:27:00.000-05:00Hello Neal, great post. I think you nailed it.I'v...Hello Neal, great post. I think you nailed it.<BR/><BR/>I've took the liberty to translate this post literally into brazilian portuguese, I hope you don't mind but coincidentally I was in the middle of a <A HREF="http://www.akitaonrails.com/2007/9/6/traduo-ruby-importa-meta-programao-sntese-e-gerao#comment-960" REL="nofollow">very hot discussion</A> regarding Ruby and Smalltalk. <BR/><BR/>One of the readers insist that you probably know nothing about Glorp or Magritte. Mainly Glorp which, he says, "there is no need for something like a has_many because things like this are meta-programmed directly in runtime" and he goes on saying, "which ressembles Django-like models". Whatever that means ... can you get it?<BR/><BR/>He also claims Smalltalk superiority because he implies that it doesn't have to do 'low level stuff' like the new <A HREF="http://errtheblog.com/post/10722" REL="nofollow">Ambition gem</A> that was just released to get to the same results. He probably is criticizing the use of the ParseTree level to inject higher abstractions.<BR/><BR/>He concludes saying that "because everything in Smalltalk is more unified - including having an internal IDE - makes extensions that much more easy than Ruby, basically making DSL-like features unnecessary". <BR/><BR/>I'm eager to know what do you think about those claims.AkitaOnRailshttps://www.blogger.com/profile/05539202931163964720noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-87312773813363706912007-09-06T04:14:00.000-05:002007-09-06T04:14:00.000-05:00There is another aspect of this that is at least w...There is another aspect of this that is at least worth mentioning.<BR/><BR/>The Smalltalk way of generating the code is done in your time. You as a developer crystallise how the design is to be implemented by clicking on that button.<BR/><BR/>In Ruby this crystallisation happens each time the code is run.<BR/><BR/>The trade off here is not only in flexibility, but also in risk. It is much harder to break parts of a Smalltalk implementation by changing the meta-programming. But of course a bug fix has to be manually applied in Smalltalk but in Ruby you get it for free.<BR/><BR/>Another aspect that is important for some purposes is when all of this happens. Smalltalk won't have any run-time overhead because the hard work has already been done. With Ruby this work must be done each time the code is run.<BR/><BR/>This is one thing that meta-programming is increasingly used for in C++ as it allows algorithms to be specified at a high level, but parts of them to be executed within the compiler rather than at run-time.Kirit Sælensmindehttps://www.blogger.com/profile/02188707816239176630noreply@blogger.com