AspectJ is code generation

Post #110,904 by tuberculosis 7/22/03 1:00:28 PM 8/21/07 5:46:10 AM Reply	AspectJ is code generation and thus violates Blanchard's law (Systems that require code generation lack sufficient power to tackle the problem at hand). I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:46:10 AM EDT Expand All History
Post #110,915 by JimWeirich 7/22/03 2:19:07 PM Reply	A comment and a question ... Todd: I don't "get" aspect oriented programming. Its significant lack of adoption (even in the Smalltalk world which can do it without code generation) suggests that a lot of other developers don't find it that useful either. AOP is still maturing and I don't think most people understand how to use it effectively. Besides, I have a theory that a highly dynamic language with good reflection will do the many AOP-ish things without the need for full AOP. In other words, there is less need in Smalltalk for AOP. Now for the question regarding Blanchard's law ... In Ruby, we can write ... class Point\n attr_accessor :x, :y\n ...\n end which will generate four methods (getters and setters for both x and y). It is essentially the same as writing ... class Point\n def x\n @x\n end\n def y\n @y\n end\n def x=(value)\n @x = value\n end\n def y=(value)\n @y = value\n end\n ...\n end Does this count as code generation? -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,919 by tuberculosis 7/22/03 2:37:04 PM 8/21/07 5:46:27 AM Reply	Not really the code is trivial and amounts to naked attributes. C++ templates OTOH do count - as does Java RMI/C++ CORBA (generation of proxies as a standard development technique - primarily required to satisfy the compiler in a FOO environment). My GLORP interface library will create missing attributes and accessors based on schema requirements - but this is hardly "code generation" - rather its dynamic object reshaping. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:46:27 AM EDT Expand All History
Post #110,932 by JimWeirich 7/22/03 3:57:21 PM Reply	Pushing the limits of Blanchard's Law As you might guess, I like to push the limits a bit. Hope you don't mind. (I'll even tie this question back to message based OO). I hadn't heard of Blanchard's law, so a google search brought up this ... Yeah but it [dynamic Java proxies] breaks Blanchard's law of code generation. Dynamic proxies basically construct classes and load them on the fly by generating code to forward interface calls to implementations. So the system relies on code generation (binary code generation in this case) to do its thing. -- tblanchard@mac.com ([link\|http://lists.xml.org/archives/xml-dev/200210/msg01206.html\|http://lists.xml.org...210/msg01206.html]) I'm assuming this is the Blanchard for whom the law is named. Keeping the above quote in mind, consider the following code ... class SlowProxy\n def initialize(target)\n @target = target\n end\n def method_missing(sym, args, &block)\n @target.send(sym, args, &block)\n end\nend It uses method_missing (Ruby's equivalent of doesNotUnderstand) to forward messages to the proxy target. It works great, but is a bit slower than a hand written proxy because :method_missing overhead. We can rewrite it slightly to do the following ... class FastProxy\n def initialize(target)\n @target = target\n end\n\n def method_missing(sym, args, &block)\n define_forwarding_method(sym)\n self.send(sym, args, &block)\n end\n\n def define_forwarding_method(sym)\n self.instance_eval %{\n def #{sym.to_s}(args, &block)\n @target.#{sym.to_s}(args, &block)\n end\n }\n end\nend The first time a method is called on the proxy, it dynamically defines a specific forwarding method of that name. Further calls of that same method will no longer go through the :method_missing mechanism. The code generation piece is quite similar to that in the attribute example earlier. But since this dynamic proxy generates method definitions on the fly (just as the Java version does), does that mean this code runs afoul of Blanchard's law as well? It would seem it does. Seems inconsistent to me. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,933 by ChrisR 7/22/03 4:09:32 PM Reply	I don't think the basic argument is so much against code generation - especially runtime code generation - so much as it is about using code generation at compile time to trick the compiler into bypassing the static type checking. Smalltalk can generate code on the fly as well, and methods can be attached dynamically in much the same way that you showed in Ruby. One question, though. Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing. Just thinking that same methods are temporary methods (closures or delegates), that have a limited lifetime or change according to the context.
Post #110,940 by JimWeirich 7/22/03 4:35:10 PM Reply	Re: I don't think the basic argument is so much ChrisR: [...] as it is about using code generation at compile time to trick the compiler into bypassing the static type checking But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages. Oh well. Moving on. ChrisR: Can you detach/destroy a method from the object? That is, can you reverse out the process in Ruby to make it revert back to the method_missing. Yes. remove_method(symbol) will remove it from the current class, but leaves any definitions in the super classes intact. undef_method(symbol) will remove it from the entire class hierarchy. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,946 by ChrisR 7/22/03 5:03:54 PM Reply	Should probably let Todd defend his Laws....but.... :-) But that's not what he said ... and such an interpretation sounds like an arbitrary restriction designed to punish statically typed languages. I'm guessing, but I don't think the question is whether code generation (or macros) is inherently and evil in and of itself - it can be a useful technique in limited circumstances. The problem is when you begin to rely on such techniques as a workaround to the Type system - and yes it's biased against Static Typing because ST tends to want to prevent you from doing things. In the case you cite, you could have handled the missing_method with any number of techniques - including generating a function on the fly.
Post #110,948 by JimWeirich 7/22/03 5:14:31 PM Reply	Still sounds arbitrary ... ChrisR: and yes it's biased against Static Typing because ST tends to want to prevent you from doing things. So it is OK to do if you don't need it. But if it you do need it, then it is not ok. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #110,951 by ChrisR 7/22/03 5:20:45 PM Reply	On par with "Eval" Which was how we got into this thread in the first place. Eval and Dynamic Code generation are powerful features. The problem is that when you start requiring these facilitaties to get around the barrier put up by the compile (aka Static Typing), then they are no longer luxories. It is indicative of the fact that you are fighting the language in order to achieve your ends. Of course, it's the Blanchard Law, so I'll let him be more specific about the intents. Just trying to further the conversation. :-)
Post #110,963 by tuberculosis 7/22/03 6:10:00 PM 8/21/07 5:51:08 AM Reply	Well said Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:51:08 AM EDT Expand All History
Post #110,964 by tuberculosis 7/22/03 6:11:20 PM 8/21/07 5:51:13 AM Reply	No its not Your example does not rely on code generation to work - it uses it as an optimization. You could (and do) make it work without the code generation. There's the razor. If the only way to accomplish a task is code generation - then the tool is not appropriate for the task. As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:51:13 AM EDT Expand All History
Post #110,982 by JimWeirich 7/22/03 7:48:18 PM Reply	Ok, I get it. I was trying to use the law in determining when code generation is a good idea. That's not what the law is for. It is a measure of the power and/or flexibility of your implementation language. I'm ok with that. Todd: As to whether this is designed by me to punish static languages. Turnabout is fair play. :-P Heh, clever line. :-) -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van As to whether this is designed by me to punish static languages. Turnabout is fair play. :-PEmde Boas)
Post #110,987 by tuberculosis 7/22/03 8:17:05 PM 8/21/07 5:51:33 AM Reply	Yep Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower Edited by tuberculosis Aug. 21, 2007, 05:51:33 AM EDT Expand All History
Post #110,937 by FuManChu 7/22/03 4:28:15 PM Reply	Oh yeah I had dinner with THAT Blanchard once. Much clearer thinker than our Todd. :D I'm gonna go build my own theme park! With Blackjack! And hookers! In fact, forget the park!
Post #118,380 by ben_tilly 9/21/03 5:20:53 PM Reply	What is your reasoning for this "law"? Sorry that I am coming to this thread late... When I hear something like that I automatically think that the underlying reasoning is sort of like that which lies behind using structured flow control mechanisms rather than goto. Namely that the structured mechanisms make it easier to express your thoughts in ways which you or someone else can figure out later. For instance this is why I prefer to see closures where eval could do the job. And I have heard similar reasoning from Paul Graham on why it is better to use macros rather than eval as well. Was that your reasoning, or did you have a different motivation? Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #118,427 by drewk 9/22/03 10:32:55 AM Reply	OT re: coming to this thread late Man, this is going to be like when Scott put in the [link\|http://z.iwethey.org/forums/actions/content/random\|Random Post] link. === Implicitly condoning stupidity since 2001.

Welcome to IWETHEY!