<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_22_146235</id>
	<title>Metaprogramming Ruby</title>
	<author>samzenpus</author>
	<datestamp>1269282180000</datestamp>
	<htmltext>scottl writes <i>"Metaprogramming Ruby is the first book to give an in-depth and readable explanation of how dynamic programming works in Ruby. It is both readable and accurate and will be a valuable resource to intermediate and probably advanced Ruby programmers for some time to come."</i> Keep reading for the rest of scottl's review.</htmltext>
<tokenext>scottl writes " Metaprogramming Ruby is the first book to give an in-depth and readable explanation of how dynamic programming works in Ruby .
It is both readable and accurate and will be a valuable resource to intermediate and probably advanced Ruby programmers for some time to come .
" Keep reading for the rest of scottl 's review .</tokentext>
<sentencetext>scottl writes "Metaprogramming Ruby is the first book to give an in-depth and readable explanation of how dynamic programming works in Ruby.
It is both readable and accurate and will be a valuable resource to intermediate and probably advanced Ruby programmers for some time to come.
" Keep reading for the rest of scottl's review.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31586046</id>
	<title>Whoops.</title>
	<author>SanityInAnarchy</author>
	<datestamp>1269368220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Tell me that's not more "maintainable" than hundreds of lines of XML config files.</p></div><p>Now that I think about it, those hundreds of lines of XML config files are going to have to be interpreted by <i>something</i> to turn them into method calls -- so again, it's going to result in metaprogramming, unless you define your schema <i>again</i> by repeating all those methods and properties inside your model source as method and property definitions.</p></div>
	</htmltext>
<tokenext>Tell me that 's not more " maintainable " than hundreds of lines of XML config files.Now that I think about it , those hundreds of lines of XML config files are going to have to be interpreted by something to turn them into method calls -- so again , it 's going to result in metaprogramming , unless you define your schema again by repeating all those methods and properties inside your model source as method and property definitions .</tokentext>
<sentencetext>Tell me that's not more "maintainable" than hundreds of lines of XML config files.Now that I think about it, those hundreds of lines of XML config files are going to have to be interpreted by something to turn them into method calls -- so again, it's going to result in metaprogramming, unless you define your schema again by repeating all those methods and properties inside your model source as method and property definitions.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574424</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112</id>
	<title>These techniques are horrid for maintainability.</title>
	<author>Anonymous</author>
	<datestamp>1269287040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>These "metaprogramming" techniques, regardless of whether they're done in Ruby or JavaScript or Lua or some other language, cause nothing but problems when it comes to maintainability.</p><p>Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.</p><p>Errors are missed because they only happen in obscure cases at runtime, but would have otherwise been caught when using less-dynamic techniques. Even working code becomes unnecessarily complex, and really can only be understood by stepping through it, line by line, using a debugger.</p><p>When I catch my developers using these techniques, we have a nice little chat about writing maintainable code, and then their code gets reworked. Far too often, what small amount of time might be saved in the first place ends up being lost 50 or 100 times over while debugging. We don't play that game.</p></htmltext>
<tokenext>These " metaprogramming " techniques , regardless of whether they 're done in Ruby or JavaScript or Lua or some other language , cause nothing but problems when it comes to maintainability.Sure , they might help the programmer write the code in slightly less time , but then they make it damn near impossible to debug later on.Errors are missed because they only happen in obscure cases at runtime , but would have otherwise been caught when using less-dynamic techniques .
Even working code becomes unnecessarily complex , and really can only be understood by stepping through it , line by line , using a debugger.When I catch my developers using these techniques , we have a nice little chat about writing maintainable code , and then their code gets reworked .
Far too often , what small amount of time might be saved in the first place ends up being lost 50 or 100 times over while debugging .
We do n't play that game .</tokentext>
<sentencetext>These "metaprogramming" techniques, regardless of whether they're done in Ruby or JavaScript or Lua or some other language, cause nothing but problems when it comes to maintainability.Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.Errors are missed because they only happen in obscure cases at runtime, but would have otherwise been caught when using less-dynamic techniques.
Even working code becomes unnecessarily complex, and really can only be understood by stepping through it, line by line, using a debugger.When I catch my developers using these techniques, we have a nice little chat about writing maintainable code, and then their code gets reworked.
Far too often, what small amount of time might be saved in the first place ends up being lost 50 or 100 times over while debugging.
We don't play that game.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573258</id>
	<title>Kaiser Chiefs edition</title>
	<author>Cloud K</author>
	<datestamp>1269287460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> <tt>&lt;\% 4.times do \%&gt;Ruby, &lt;\% end \%&gt; Aa aaaaaaaaaaaaah</tt></p></div> </blockquote></div>
	</htmltext>
<tokenext>Ruby , Aa aaaaaaaaaaaaah</tokentext>
<sentencetext> Ruby,  Aa aaaaaaaaaaaaah 
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574710</id>
	<title>Re:These techniques are horrid for maintainability</title>
	<author>K. S. Kyosuke</author>
	<datestamp>1269249660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.

Errors are missed because they only happen in obscure cases at runtime, but would have otherwise been caught when using less-dynamic techniques. Even working code becomes unnecessarily complex, and really can only be understood by stepping through it, line by line, using a debugger.</p></div><p>I guess that when you're working with shitheads who don't know the limits of their competency, you're screwed anyway. No matter what language is involved, they always creep up. I once noted an apparently incompetent programmer - that is incompetent in general as a programmer - who, despite this fact, never forgot to remark that he "absolutely loves C++ templates and tries to do anything with them". You can imagine the results. Java incompetents will probably abuse threads. Good programmers know that there are both safe tools in their language meant to be used daily, and powerful, but attention requiring tools to solve difficult problems when they arise. Sane people don't just go about abusing Lisp macros, Forth parsing words and Java reflection "because they can".</p></div>
	</htmltext>
<tokenext>Sure , they might help the programmer write the code in slightly less time , but then they make it damn near impossible to debug later on .
Errors are missed because they only happen in obscure cases at runtime , but would have otherwise been caught when using less-dynamic techniques .
Even working code becomes unnecessarily complex , and really can only be understood by stepping through it , line by line , using a debugger.I guess that when you 're working with shitheads who do n't know the limits of their competency , you 're screwed anyway .
No matter what language is involved , they always creep up .
I once noted an apparently incompetent programmer - that is incompetent in general as a programmer - who , despite this fact , never forgot to remark that he " absolutely loves C + + templates and tries to do anything with them " .
You can imagine the results .
Java incompetents will probably abuse threads .
Good programmers know that there are both safe tools in their language meant to be used daily , and powerful , but attention requiring tools to solve difficult problems when they arise .
Sane people do n't just go about abusing Lisp macros , Forth parsing words and Java reflection " because they can " .</tokentext>
<sentencetext>Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.
Errors are missed because they only happen in obscure cases at runtime, but would have otherwise been caught when using less-dynamic techniques.
Even working code becomes unnecessarily complex, and really can only be understood by stepping through it, line by line, using a debugger.I guess that when you're working with shitheads who don't know the limits of their competency, you're screwed anyway.
No matter what language is involved, they always creep up.
I once noted an apparently incompetent programmer - that is incompetent in general as a programmer - who, despite this fact, never forgot to remark that he "absolutely loves C++ templates and tries to do anything with them".
You can imagine the results.
Java incompetents will probably abuse threads.
Good programmers know that there are both safe tools in their language meant to be used daily, and powerful, but attention requiring tools to solve difficult problems when they arise.
Sane people don't just go about abusing Lisp macros, Forth parsing words and Java reflection "because they can".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576560</id>
	<title>Re:Not dynamic programming...</title>
	<author>JanneM</author>
	<datestamp>1269257280000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>"dynamic programming" is an overloaded term in the English language. All natural languages have many such terms. Sometimes the meanings are related, sometimes they are completely different. When you have learned a meaning of a term, do not assume that is the sole correct meaning. You risk sounding like a pedant or a fool as a result.</p></htmltext>
<tokenext>" dynamic programming " is an overloaded term in the English language .
All natural languages have many such terms .
Sometimes the meanings are related , sometimes they are completely different .
When you have learned a meaning of a term , do not assume that is the sole correct meaning .
You risk sounding like a pedant or a fool as a result .</tokentext>
<sentencetext>"dynamic programming" is an overloaded term in the English language.
All natural languages have many such terms.
Sometimes the meanings are related, sometimes they are completely different.
When you have learned a meaning of a term, do not assume that is the sole correct meaning.
You risk sounding like a pedant or a fool as a result.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572962</id>
	<title>know your audience</title>
	<author>Anonymous</author>
	<datestamp>1269286500000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>valuable resource<nobr> <wbr></nobr>... for some time to come.</p></div></blockquote><p>These are some carefully-chosen words. Ruby is evolving faster than any other language, it seems. You blink your eyes and the XML parser you were using is out-of-favor; everyone has switched to the new one which really is much improved. This can be frustrating in that you must work to keep up with the Ruby world, but all these changes really to seem to be bringing the best of the best ideas to the surface.</p><p>Combine this rapid change with Ruby's metaprogramming ability and you see a programming language ecosystem in which evolution is sure to favor that little OO language from Japan...</p></div>
	</htmltext>
<tokenext>valuable resource ... for some time to come.These are some carefully-chosen words .
Ruby is evolving faster than any other language , it seems .
You blink your eyes and the XML parser you were using is out-of-favor ; everyone has switched to the new one which really is much improved .
This can be frustrating in that you must work to keep up with the Ruby world , but all these changes really to seem to be bringing the best of the best ideas to the surface.Combine this rapid change with Ruby 's metaprogramming ability and you see a programming language ecosystem in which evolution is sure to favor that little OO language from Japan.. .</tokentext>
<sentencetext>valuable resource ... for some time to come.These are some carefully-chosen words.
Ruby is evolving faster than any other language, it seems.
You blink your eyes and the XML parser you were using is out-of-favor; everyone has switched to the new one which really is much improved.
This can be frustrating in that you must work to keep up with the Ruby world, but all these changes really to seem to be bringing the best of the best ideas to the surface.Combine this rapid change with Ruby's metaprogramming ability and you see a programming language ecosystem in which evolution is sure to favor that little OO language from Japan...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576190</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>metamatic</author>
	<datestamp>1269255780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages.</p></div></blockquote><p>You make it sound like that's a bad thing.</p><p>I prefer multi-paradigm languages because they let me pick the paradigm that best suits the problem.</p></div>
	</htmltext>
<tokenext>Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages.You make it sound like that 's a bad thing.I prefer multi-paradigm languages because they let me pick the paradigm that best suits the problem .</tokentext>
<sentencetext>Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages.You make it sound like that's a bad thing.I prefer multi-paradigm languages because they let me pick the paradigm that best suits the problem.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</id>
	<title>Smalltalk and LISP for the History Major</title>
	<author>Anonymous</author>
	<datestamp>1269289260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I develop in Ruby more than I'd like now and here's what I've seen as a past and present programmer who's used Java, C#, PHP, Perl, Smalltalk, LISP, C++, C, Python, Lua, and Visual Basic amongst others on real projects. Generally, I prefer Ruby to most languages, but only because it reminds me of other languages I'd yet still rather work with instead of Ruby ironically.</p><p>It's good to see Ruby improve and gain popularity, but like so many other languages lately (C#, Java, etc.), it seems to want to imitate Smalltalk poorly. Rather I'd like to see Ruby library authors, language devs, and framework zealots pay a little more attention to what is already out there. It reminds me of high school when you hang out with that friend who thinks whenever they discover something for the first time, they must have invented it. Ruby on Rails unfortunately gives the language a lot of bad press and needs to turn down the idiot volume.</p><p>Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages. It is like the kid who can't make up its mind. Even when it tries to emulate, it does it poorly, for example with hashes as hacks on named parameters in Obj C and Smalltalk (and<nobr> <wbr></nobr>.NET 4 now). This leads to wildly inconsistent libraries, methodologies, etc. Are you Perl? Are you Python? Are you CL or Haskell? I love a lot of things from all the languages I work with, but at some point you need focus, direction, and a firm point of view. This is one reason I love Smalltalk and Common Lisp. The two are wildly different in many ways, but share a strong stance of what is acceptable and useful in the language. In other words, these languages are well designed and have a good crap filter.</p><p>Ruby comes off amateurish at best in comparison and makes me feel like I'm working with the new web 3.0 PHP crowd. It's really sad because I love a good language or two, but it's just dumb to try to accomplish such lofty tasks without proper knowledge, leadership, and vision. When you think about it, you have to be kind of an asshole to want to create a new language with all that we have out there. It'd be one thing if it was so radically different as that would represent revolution, but Ruby is so derivative that I often wonder what value added. I tell myself when people do something like this, it must be curiosity + the inner nerd, but that still does not make it ok in my mind. What I wouldn't give if those same people would learn to actually understand and grasp more established languages in Smalltalk and Lisp, or hell even C++. It's not that I fear change, it's just that there's something to be said for experience and well tested languages that have gone through the growing pains already for better or worse. If there was something truly different, that made even functional programming seem trite, then I'd definitely hop on it to learn if nothing else, but Ruby isn't like that.</p><p>Finally, I have a problem in the fact that Ruby is not defined in itself. There's a lot of discussion about this if you google so I won't go into it, but historically, strong languages are able to do this because the internal mechanisms are fast enough and adequately expressive to allow for this. It is definitely a strength of a language if it can be built from the ground up in itself due to elegant design. Smalltalk is probably the best example of this, but owes a lot to earlier effort. Why can't Ruby do the same (too late)?</p><p>Generally, I am rather happy people are discovering Ruby. It allows me to keep certain languages like Lisp and Smalltalk largely my secret. While people build glorified Microsoft Access apps and then later are let down by scalability, performance, inconsistencies, lack of proper internationalization support, deployment tools, stability, etc., I'm happily being 10x more productive in my languages of choice. Unfortunately the world is a cruel place and employers love jumping on the bandwagon. I had the pleasure of seeing this with Java, where everyone thought</p></htmltext>
<tokenext>I develop in Ruby more than I 'd like now and here 's what I 've seen as a past and present programmer who 's used Java , C # , PHP , Perl , Smalltalk , LISP , C + + , C , Python , Lua , and Visual Basic amongst others on real projects .
Generally , I prefer Ruby to most languages , but only because it reminds me of other languages I 'd yet still rather work with instead of Ruby ironically.It 's good to see Ruby improve and gain popularity , but like so many other languages lately ( C # , Java , etc .
) , it seems to want to imitate Smalltalk poorly .
Rather I 'd like to see Ruby library authors , language devs , and framework zealots pay a little more attention to what is already out there .
It reminds me of high school when you hang out with that friend who thinks whenever they discover something for the first time , they must have invented it .
Ruby on Rails unfortunately gives the language a lot of bad press and needs to turn down the idiot volume.Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages .
It is like the kid who ca n't make up its mind .
Even when it tries to emulate , it does it poorly , for example with hashes as hacks on named parameters in Obj C and Smalltalk ( and .NET 4 now ) .
This leads to wildly inconsistent libraries , methodologies , etc .
Are you Perl ?
Are you Python ?
Are you CL or Haskell ?
I love a lot of things from all the languages I work with , but at some point you need focus , direction , and a firm point of view .
This is one reason I love Smalltalk and Common Lisp .
The two are wildly different in many ways , but share a strong stance of what is acceptable and useful in the language .
In other words , these languages are well designed and have a good crap filter.Ruby comes off amateurish at best in comparison and makes me feel like I 'm working with the new web 3.0 PHP crowd .
It 's really sad because I love a good language or two , but it 's just dumb to try to accomplish such lofty tasks without proper knowledge , leadership , and vision .
When you think about it , you have to be kind of an asshole to want to create a new language with all that we have out there .
It 'd be one thing if it was so radically different as that would represent revolution , but Ruby is so derivative that I often wonder what value added .
I tell myself when people do something like this , it must be curiosity + the inner nerd , but that still does not make it ok in my mind .
What I would n't give if those same people would learn to actually understand and grasp more established languages in Smalltalk and Lisp , or hell even C + + .
It 's not that I fear change , it 's just that there 's something to be said for experience and well tested languages that have gone through the growing pains already for better or worse .
If there was something truly different , that made even functional programming seem trite , then I 'd definitely hop on it to learn if nothing else , but Ruby is n't like that.Finally , I have a problem in the fact that Ruby is not defined in itself .
There 's a lot of discussion about this if you google so I wo n't go into it , but historically , strong languages are able to do this because the internal mechanisms are fast enough and adequately expressive to allow for this .
It is definitely a strength of a language if it can be built from the ground up in itself due to elegant design .
Smalltalk is probably the best example of this , but owes a lot to earlier effort .
Why ca n't Ruby do the same ( too late ) ? Generally , I am rather happy people are discovering Ruby .
It allows me to keep certain languages like Lisp and Smalltalk largely my secret .
While people build glorified Microsoft Access apps and then later are let down by scalability , performance , inconsistencies , lack of proper internationalization support , deployment tools , stability , etc. , I 'm happily being 10x more productive in my languages of choice .
Unfortunately the world is a cruel place and employers love jumping on the bandwagon .
I had the pleasure of seeing this with Java , where everyone thought</tokentext>
<sentencetext>I develop in Ruby more than I'd like now and here's what I've seen as a past and present programmer who's used Java, C#, PHP, Perl, Smalltalk, LISP, C++, C, Python, Lua, and Visual Basic amongst others on real projects.
Generally, I prefer Ruby to most languages, but only because it reminds me of other languages I'd yet still rather work with instead of Ruby ironically.It's good to see Ruby improve and gain popularity, but like so many other languages lately (C#, Java, etc.
), it seems to want to imitate Smalltalk poorly.
Rather I'd like to see Ruby library authors, language devs, and framework zealots pay a little more attention to what is already out there.
It reminds me of high school when you hang out with that friend who thinks whenever they discover something for the first time, they must have invented it.
Ruby on Rails unfortunately gives the language a lot of bad press and needs to turn down the idiot volume.Ruby also seems to have some diarrhea of the programming language where it wants to mix paradigms from so many other languages.
It is like the kid who can't make up its mind.
Even when it tries to emulate, it does it poorly, for example with hashes as hacks on named parameters in Obj C and Smalltalk (and .NET 4 now).
This leads to wildly inconsistent libraries, methodologies, etc.
Are you Perl?
Are you Python?
Are you CL or Haskell?
I love a lot of things from all the languages I work with, but at some point you need focus, direction, and a firm point of view.
This is one reason I love Smalltalk and Common Lisp.
The two are wildly different in many ways, but share a strong stance of what is acceptable and useful in the language.
In other words, these languages are well designed and have a good crap filter.Ruby comes off amateurish at best in comparison and makes me feel like I'm working with the new web 3.0 PHP crowd.
It's really sad because I love a good language or two, but it's just dumb to try to accomplish such lofty tasks without proper knowledge, leadership, and vision.
When you think about it, you have to be kind of an asshole to want to create a new language with all that we have out there.
It'd be one thing if it was so radically different as that would represent revolution, but Ruby is so derivative that I often wonder what value added.
I tell myself when people do something like this, it must be curiosity + the inner nerd, but that still does not make it ok in my mind.
What I wouldn't give if those same people would learn to actually understand and grasp more established languages in Smalltalk and Lisp, or hell even C++.
It's not that I fear change, it's just that there's something to be said for experience and well tested languages that have gone through the growing pains already for better or worse.
If there was something truly different, that made even functional programming seem trite, then I'd definitely hop on it to learn if nothing else, but Ruby isn't like that.Finally, I have a problem in the fact that Ruby is not defined in itself.
There's a lot of discussion about this if you google so I won't go into it, but historically, strong languages are able to do this because the internal mechanisms are fast enough and adequately expressive to allow for this.
It is definitely a strength of a language if it can be built from the ground up in itself due to elegant design.
Smalltalk is probably the best example of this, but owes a lot to earlier effort.
Why can't Ruby do the same (too late)?Generally, I am rather happy people are discovering Ruby.
It allows me to keep certain languages like Lisp and Smalltalk largely my secret.
While people build glorified Microsoft Access apps and then later are let down by scalability, performance, inconsistencies, lack of proper internationalization support, deployment tools, stability, etc., I'm happily being 10x more productive in my languages of choice.
Unfortunately the world is a cruel place and employers love jumping on the bandwagon.
I had the pleasure of seeing this with Java, where everyone thought</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573466</id>
	<title>Re:Not dynamic programming...</title>
	<author>shutdown -p now</author>
	<datestamp>1269288360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>The author, who I've seen speak, instead writes about "metaprogramming" which in my personal opinion is a silly catch phrase to sell talks and books when actually he's just talking about using some of the advanced functionality present in Ruby (and also JavaScript) to do things that would be done with macros or can't be done at all in traditional object oriented and procedural languages.</p></div><p> <a href="http://en.wikipedia.org/wiki/Metaprogramming" title="wikipedia.org">"Metaprogramming"</a> [wikipedia.org] is an old term with a well-established definition, and if simplified to C/C++ audience, that definition would by and large look like "things that are done with macros". So I'm not sure what your problem is. So far as I can see, he is using the term correctly.</p></div>
	</htmltext>
<tokenext>The author , who I 've seen speak , instead writes about " metaprogramming " which in my personal opinion is a silly catch phrase to sell talks and books when actually he 's just talking about using some of the advanced functionality present in Ruby ( and also JavaScript ) to do things that would be done with macros or ca n't be done at all in traditional object oriented and procedural languages .
" Metaprogramming " [ wikipedia.org ] is an old term with a well-established definition , and if simplified to C/C + + audience , that definition would by and large look like " things that are done with macros " .
So I 'm not sure what your problem is .
So far as I can see , he is using the term correctly .</tokentext>
<sentencetext>The author, who I've seen speak, instead writes about "metaprogramming" which in my personal opinion is a silly catch phrase to sell talks and books when actually he's just talking about using some of the advanced functionality present in Ruby (and also JavaScript) to do things that would be done with macros or can't be done at all in traditional object oriented and procedural languages.
"Metaprogramming" [wikipedia.org] is an old term with a well-established definition, and if simplified to C/C++ audience, that definition would by and large look like "things that are done with macros".
So I'm not sure what your problem is.
So far as I can see, he is using the term correctly.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574956</id>
	<title>The ecosystem is, not the language.</title>
	<author>Peter Cooper</author>
	<datestamp>1269250560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Ruby's <em>ecosystem</em> evolves very quickly, sure, but the underlying language doesn't. Ruby written 10 years ago isn't significantly different to that written now. It's the libraries that are being used that have changed, but Perl has become susceptible to that in the last few years too (consider Perl5i and all the Perl 6-isms that are entering Perl 5).</p></htmltext>
<tokenext>Ruby 's ecosystem evolves very quickly , sure , but the underlying language does n't .
Ruby written 10 years ago is n't significantly different to that written now .
It 's the libraries that are being used that have changed , but Perl has become susceptible to that in the last few years too ( consider Perl5i and all the Perl 6-isms that are entering Perl 5 ) .</tokentext>
<sentencetext>Ruby's ecosystem evolves very quickly, sure, but the underlying language doesn't.
Ruby written 10 years ago isn't significantly different to that written now.
It's the libraries that are being used that have changed, but Perl has become susceptible to that in the last few years too (consider Perl5i and all the Perl 6-isms that are entering Perl 5).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572910</id>
	<title>Great book but...</title>
	<author>Anonymous</author>
	<datestamp>1269286260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>the narrative style can drive you nuts.</p></htmltext>
<tokenext>the narrative style can drive you nuts .</tokentext>
<sentencetext>the narrative style can drive you nuts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576672</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>Endymion</author>
	<datestamp>1269257760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Ruby has its (serious) faults, but the multi-paradigm nature of it is not one of them. It's probably the main reason I like the language. Yes, it's not perfect in any given programming style, but the mix of styles is a huge convenience. It's nice to be able to use LISP-like features at times, but still be able to bank out quick, traditional imperative-style code when it's appropriate.</p><p>This isn't to say they shouldn't take more from Smalltalk and LISP. Those rough edges are just slightly bad enough to bet in the way. I have high hopes that these problems will be fixed in the future, though.</p><p>What's particularly nice about Ruby, over the theoretically nicer LISP/Smalltalk/etc, is that Ruby is actually <i>used</i> fairly often...</p></htmltext>
<tokenext>Ruby has its ( serious ) faults , but the multi-paradigm nature of it is not one of them .
It 's probably the main reason I like the language .
Yes , it 's not perfect in any given programming style , but the mix of styles is a huge convenience .
It 's nice to be able to use LISP-like features at times , but still be able to bank out quick , traditional imperative-style code when it 's appropriate.This is n't to say they should n't take more from Smalltalk and LISP .
Those rough edges are just slightly bad enough to bet in the way .
I have high hopes that these problems will be fixed in the future , though.What 's particularly nice about Ruby , over the theoretically nicer LISP/Smalltalk/etc , is that Ruby is actually used fairly often.. .</tokentext>
<sentencetext>Ruby has its (serious) faults, but the multi-paradigm nature of it is not one of them.
It's probably the main reason I like the language.
Yes, it's not perfect in any given programming style, but the mix of styles is a huge convenience.
It's nice to be able to use LISP-like features at times, but still be able to bank out quick, traditional imperative-style code when it's appropriate.This isn't to say they shouldn't take more from Smalltalk and LISP.
Those rough edges are just slightly bad enough to bet in the way.
I have high hopes that these problems will be fixed in the future, though.What's particularly nice about Ruby, over the theoretically nicer LISP/Smalltalk/etc, is that Ruby is actually used fairly often...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31575208</id>
	<title>Re:These techniques are horrid for maintainability</title>
	<author>mr\_bubb</author>
	<datestamp>1269251580000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext>You sound like a tool.</htmltext>
<tokenext>You sound like a tool .</tokentext>
<sentencetext>You sound like a tool.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572782</id>
	<title>Mac fags vs Ruby fags</title>
	<author>Anonymous</author>
	<datestamp>1269285840000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Who do you think spews more smug? Mac fags or ruby fags?</p></htmltext>
<tokenext>Who do you think spews more smug ?
Mac fags or ruby fags ?</tokentext>
<sentencetext>Who do you think spews more smug?
Mac fags or ruby fags?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870</id>
	<title>Hmm</title>
	<author>Anonymous</author>
	<datestamp>1269286140000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think most people give a crap about Ruby in general. Why not just use a programming language that does it right?</p></htmltext>
<tokenext>I do n't think most people give a crap about Ruby in general .
Why not just use a programming language that does it right ?</tokentext>
<sentencetext>I don't think most people give a crap about Ruby in general.
Why not just use a programming language that does it right?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573890</id>
	<title>fu0ck...</title>
	<author>Anonymous</author>
	<datestamp>1269289920000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext>are 7He important</htmltext>
<tokenext>are 7He important</tokentext>
<sentencetext>are 7He important</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573348</id>
	<title>Re:Not dynamic programming...</title>
	<author>thms</author>
	<datestamp>1269287820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The summary mentions dynamic programming; but this book contains nothing about dynamic programming. (A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly.)</p></div><p>Yes, "calling code dynamically" is not the <i>classic</i> dynamic programming approach: Think of <a href="http://en.wikipedia.org/wiki/Pascal's\_triangle" title="wikipedia.org">Pascal's triangle</a> [wikipedia.org], each field is the sum of it's two predecessor in the previous row. You could calculate such a field by calling a <b>recursive function</b>, as parent suggests, <b>but that is very inefficient</b>: Consider the first two calls, to the top-left and top-right. These then do another call, and they overlap (rhombus-like): The top-right of the left with the top-left of the right. Here you could re-use the result if you had cached it, but since you start from the bottom you can't do that. And the redundancies become worse and worse the higher you go up.</p><p>
So a dynamic programming approach is to start from the top and remember the result for a row, then start the next one. It is used where recursion might <i>describe</i> the problem properly, but makes it's implementation inefficient. Doing long Levenshtein distance calculations (transforming one string into another with a minimum of steps) is done in this way as well, resulting in <b>O(n^2)</b> runtime instead of, err, something like O(2^n) runtime IIRC because you have to do a recursive call for an insertion, a deletion or a replacement, i.e. <i>3 calls</i>, while navigating through all possible character substitution paths in the string1 vs string2 matrix.</p></div>
	</htmltext>
<tokenext>The summary mentions dynamic programming ; but this book contains nothing about dynamic programming .
( A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly .
) Yes , " calling code dynamically " is not the classic dynamic programming approach : Think of Pascal 's triangle [ wikipedia.org ] , each field is the sum of it 's two predecessor in the previous row .
You could calculate such a field by calling a recursive function , as parent suggests , but that is very inefficient : Consider the first two calls , to the top-left and top-right .
These then do another call , and they overlap ( rhombus-like ) : The top-right of the left with the top-left of the right .
Here you could re-use the result if you had cached it , but since you start from the bottom you ca n't do that .
And the redundancies become worse and worse the higher you go up .
So a dynamic programming approach is to start from the top and remember the result for a row , then start the next one .
It is used where recursion might describe the problem properly , but makes it 's implementation inefficient .
Doing long Levenshtein distance calculations ( transforming one string into another with a minimum of steps ) is done in this way as well , resulting in O ( n ^ 2 ) runtime instead of , err , something like O ( 2 ^ n ) runtime IIRC because you have to do a recursive call for an insertion , a deletion or a replacement , i.e .
3 calls , while navigating through all possible character substitution paths in the string1 vs string2 matrix .</tokentext>
<sentencetext>The summary mentions dynamic programming; but this book contains nothing about dynamic programming.
(A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly.
)Yes, "calling code dynamically" is not the classic dynamic programming approach: Think of Pascal's triangle [wikipedia.org], each field is the sum of it's two predecessor in the previous row.
You could calculate such a field by calling a recursive function, as parent suggests, but that is very inefficient: Consider the first two calls, to the top-left and top-right.
These then do another call, and they overlap (rhombus-like): The top-right of the left with the top-left of the right.
Here you could re-use the result if you had cached it, but since you start from the bottom you can't do that.
And the redundancies become worse and worse the higher you go up.
So a dynamic programming approach is to start from the top and remember the result for a row, then start the next one.
It is used where recursion might describe the problem properly, but makes it's implementation inefficient.
Doing long Levenshtein distance calculations (transforming one string into another with a minimum of steps) is done in this way as well, resulting in O(n^2) runtime instead of, err, something like O(2^n) runtime IIRC because you have to do a recursive call for an insertion, a deletion or a replacement, i.e.
3 calls, while navigating through all possible character substitution paths in the string1 vs string2 matrix.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573076</id>
	<title>Re:Not dynamic programming...</title>
	<author>Anonymous</author>
	<datestamp>1269286920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>When the author said dynamic, he was using it to refer to the <a href="http://en.wikipedia.org/wiki/Dynamic\_programming\_language" title="wikipedia.org">dynamic language</a> [wikipedia.org] features of Ruby, not dynamic programming.</p></htmltext>
<tokenext>When the author said dynamic , he was using it to refer to the dynamic language [ wikipedia.org ] features of Ruby , not dynamic programming .</tokentext>
<sentencetext>When the author said dynamic, he was using it to refer to the dynamic language [wikipedia.org] features of Ruby, not dynamic programming.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574424</id>
	<title>Re:These techniques are horrid for maintainability</title>
	<author>SanityInAnarchy</author>
	<datestamp>1269248700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>These "metaprogramming" techniques, regardless of whether they're done in Ruby or JavaScript or Lua or some other language, cause nothing but problems when it comes to maintainability.</p></div><p>If done poorly, sure.</p><p><div class="quote"><p>Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.</p></div><p>Then your debugging tools suck, or the metaprogramming was abused. Banning it isn't like banning goto, it's like banning exception handling. Just because you can abuse it and ignore all errors doesn't mean you should never be able to intercept an exception.</p><p><div class="quote"><p>Errors are missed because they only happen in obscure cases at runtime,</p></div><p>Can you give an example of such an "obscure" case?</p><p>I can see errors being missed because they only happen at runtime, but guess what? Them's the breaks. If you don't like it, you need to stop using Ruby or JavaScript or Lua, and stick to languages like Java, and make sure you always used checked exceptions, and you still won't catch all of them.</p><p>Runtime errors happen. That's what unit tests are for.</p><p><div class="quote"><p>Even working code becomes unnecessarily complex,</p></div><p>Metaprogramming can make code much shorter, more readable, and more maintainable. If there's some additional complexity at runtime, so be it.</p><p><div class="quote"><p>When I catch my developers using these techniques, we have a nice little chat about writing maintainable code, and then their code gets reworked.</p></div><p>If I was working for you (and I'm glad I'm not), I'd look forward to educating you on maintainability.</p><p>Let's look at an example: attr\_accessor. It wouldn't be Ruby without it. You probably allow it, and it probably makes sense to you to allow it. It's also an example of metaprogramming -- while it's built into the language, and probably hand-tweaked in C for speed, it really makes much more sense once you understand that logically, attr\_accessor itself could have been written using define\_method.</p><p>How about another example: Any decent ORM. Either it's going to use metaprogramming to define your schema (like DataMapper does with 'property'), or it's going to use metaprogramming to expose your existing schema (like Rails does by reading your database). Tell me that's not more "maintainable" than hundreds of lines of XML config files.</p><p>Or I'll use a real-world example from the appengine-jruby project:</p><blockquote><div><p><nobr> <wbr></nobr><tt>.<br>
&nbsp; &nbsp; &nbsp; &nbsp; def parent\_property(name)<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; define\_method("#{name}\_id") do<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; k = key.first<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; k.kind\_of?(AppEngine::Datastore::Key) &amp;&amp; k.parent<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; end<br>
&nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; belongs\_to\_entity(name, false)<br>
&nbsp; &nbsp; &nbsp; &nbsp; end</tt></p></div> </blockquote><p>And in actual code:</p><blockquote><div><p> <tt>class Foo<br><nobr> <wbr></nobr>...<br>
&nbsp; parent\_property<nobr> <wbr></nobr>:parent<br>end</tt></p></div> </blockquote><p>That defines a method 'parent\_id' which returns the current id of the 'parent' of the current record (an Appengine-specific concept), and a method 'parent' which returns the actual entity of the parent. But notice I passed the symbol<nobr> <wbr></nobr>:parent explicitly -- I could just as easily have passed something else. (Why would I want to? Because maybe I need a parent method for some other reason, but I don't want to lose this functionality.)</p><p>Metaprogramming techniques <i>can</i> be abused. So can anything. Goto is harmful, but sometimes it's useful to be able to return a value from the middle of several nested loops without having to terminate each explicitly. Perl can look like line noise, and while it won't ever really be beautiful, you can write maintainable, readable Perl. You can write COBOL in any language.</p><p>So yes, it can be abused, but it's also an extremely powerful technique, and you are crippling your programmers and taking a hit on both productivity and maintainability by banning it.</p></div>
	</htmltext>
<tokenext>These " metaprogramming " techniques , regardless of whether they 're done in Ruby or JavaScript or Lua or some other language , cause nothing but problems when it comes to maintainability.If done poorly , sure.Sure , they might help the programmer write the code in slightly less time , but then they make it damn near impossible to debug later on.Then your debugging tools suck , or the metaprogramming was abused .
Banning it is n't like banning goto , it 's like banning exception handling .
Just because you can abuse it and ignore all errors does n't mean you should never be able to intercept an exception.Errors are missed because they only happen in obscure cases at runtime,Can you give an example of such an " obscure " case ? I can see errors being missed because they only happen at runtime , but guess what ?
Them 's the breaks .
If you do n't like it , you need to stop using Ruby or JavaScript or Lua , and stick to languages like Java , and make sure you always used checked exceptions , and you still wo n't catch all of them.Runtime errors happen .
That 's what unit tests are for.Even working code becomes unnecessarily complex,Metaprogramming can make code much shorter , more readable , and more maintainable .
If there 's some additional complexity at runtime , so be it.When I catch my developers using these techniques , we have a nice little chat about writing maintainable code , and then their code gets reworked.If I was working for you ( and I 'm glad I 'm not ) , I 'd look forward to educating you on maintainability.Let 's look at an example : attr \ _accessor .
It would n't be Ruby without it .
You probably allow it , and it probably makes sense to you to allow it .
It 's also an example of metaprogramming -- while it 's built into the language , and probably hand-tweaked in C for speed , it really makes much more sense once you understand that logically , attr \ _accessor itself could have been written using define \ _method.How about another example : Any decent ORM .
Either it 's going to use metaprogramming to define your schema ( like DataMapper does with 'property ' ) , or it 's going to use metaprogramming to expose your existing schema ( like Rails does by reading your database ) .
Tell me that 's not more " maintainable " than hundreds of lines of XML config files.Or I 'll use a real-world example from the appengine-jruby project : .
        def parent \ _property ( name )           define \ _method ( " # { name } \ _id " ) do             k = key.first             k.kind \ _of ?
( AppEngine : : Datastore : : Key ) &amp;&amp; k.parent           end             belongs \ _to \ _entity ( name , false )         end And in actual code : class Foo .. .   parent \ _property : parentend That defines a method 'parent \ _id ' which returns the current id of the 'parent ' of the current record ( an Appengine-specific concept ) , and a method 'parent ' which returns the actual entity of the parent .
But notice I passed the symbol : parent explicitly -- I could just as easily have passed something else .
( Why would I want to ?
Because maybe I need a parent method for some other reason , but I do n't want to lose this functionality .
) Metaprogramming techniques can be abused .
So can anything .
Goto is harmful , but sometimes it 's useful to be able to return a value from the middle of several nested loops without having to terminate each explicitly .
Perl can look like line noise , and while it wo n't ever really be beautiful , you can write maintainable , readable Perl .
You can write COBOL in any language.So yes , it can be abused , but it 's also an extremely powerful technique , and you are crippling your programmers and taking a hit on both productivity and maintainability by banning it .</tokentext>
<sentencetext>These "metaprogramming" techniques, regardless of whether they're done in Ruby or JavaScript or Lua or some other language, cause nothing but problems when it comes to maintainability.If done poorly, sure.Sure, they might help the programmer write the code in slightly less time, but then they make it damn near impossible to debug later on.Then your debugging tools suck, or the metaprogramming was abused.
Banning it isn't like banning goto, it's like banning exception handling.
Just because you can abuse it and ignore all errors doesn't mean you should never be able to intercept an exception.Errors are missed because they only happen in obscure cases at runtime,Can you give an example of such an "obscure" case?I can see errors being missed because they only happen at runtime, but guess what?
Them's the breaks.
If you don't like it, you need to stop using Ruby or JavaScript or Lua, and stick to languages like Java, and make sure you always used checked exceptions, and you still won't catch all of them.Runtime errors happen.
That's what unit tests are for.Even working code becomes unnecessarily complex,Metaprogramming can make code much shorter, more readable, and more maintainable.
If there's some additional complexity at runtime, so be it.When I catch my developers using these techniques, we have a nice little chat about writing maintainable code, and then their code gets reworked.If I was working for you (and I'm glad I'm not), I'd look forward to educating you on maintainability.Let's look at an example: attr\_accessor.
It wouldn't be Ruby without it.
You probably allow it, and it probably makes sense to you to allow it.
It's also an example of metaprogramming -- while it's built into the language, and probably hand-tweaked in C for speed, it really makes much more sense once you understand that logically, attr\_accessor itself could have been written using define\_method.How about another example: Any decent ORM.
Either it's going to use metaprogramming to define your schema (like DataMapper does with 'property'), or it's going to use metaprogramming to expose your existing schema (like Rails does by reading your database).
Tell me that's not more "maintainable" than hundreds of lines of XML config files.Or I'll use a real-world example from the appengine-jruby project: .
        def parent\_property(name)
          define\_method("#{name}\_id") do
            k = key.first
            k.kind\_of?
(AppEngine::Datastore::Key) &amp;&amp; k.parent
          end
  
          belongs\_to\_entity(name, false)
        end And in actual code: class Foo ...
  parent\_property :parentend That defines a method 'parent\_id' which returns the current id of the 'parent' of the current record (an Appengine-specific concept), and a method 'parent' which returns the actual entity of the parent.
But notice I passed the symbol :parent explicitly -- I could just as easily have passed something else.
(Why would I want to?
Because maybe I need a parent method for some other reason, but I don't want to lose this functionality.
)Metaprogramming techniques can be abused.
So can anything.
Goto is harmful, but sometimes it's useful to be able to return a value from the middle of several nested loops without having to terminate each explicitly.
Perl can look like line noise, and while it won't ever really be beautiful, you can write maintainable, readable Perl.
You can write COBOL in any language.So yes, it can be abused, but it's also an extremely powerful technique, and you are crippling your programmers and taking a hit on both productivity and maintainability by banning it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574050</id>
	<title>Re:Not dynamic programming...</title>
	<author>Anonymous</author>
	<datestamp>1269290520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What Ruby usually "metaprogramming" is typically hardly even that.  Sticking methods on base classes is not metaprogramming.  Metaprogramming is writing programs that produce or manupulate programs.  Stuff like template programming in C++ for example, or program-transforming lisp macros, or the weird CPS-transformation stuff Seaside does for Smalltalk.</p><p>But hey whatever sells a book.  And because it's about Ruby, it automatically is better than all that old busted corporate crap like using static types or following actually modular design.</p></htmltext>
<tokenext>What Ruby usually " metaprogramming " is typically hardly even that .
Sticking methods on base classes is not metaprogramming .
Metaprogramming is writing programs that produce or manupulate programs .
Stuff like template programming in C + + for example , or program-transforming lisp macros , or the weird CPS-transformation stuff Seaside does for Smalltalk.But hey whatever sells a book .
And because it 's about Ruby , it automatically is better than all that old busted corporate crap like using static types or following actually modular design .</tokentext>
<sentencetext>What Ruby usually "metaprogramming" is typically hardly even that.
Sticking methods on base classes is not metaprogramming.
Metaprogramming is writing programs that produce or manupulate programs.
Stuff like template programming in C++ for example, or program-transforming lisp macros, or the weird CPS-transformation stuff Seaside does for Smalltalk.But hey whatever sells a book.
And because it's about Ruby, it automatically is better than all that old busted corporate crap like using static types or following actually modular design.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573252</id>
	<title>FYI</title>
	<author>Anonymous</author>
	<datestamp>1269287460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pragprog has an AWESOME book coming out that I can't wait to see reviewed called "SQL Antipatterns". Check out the sample chapter on selecting a random row from the database. Freaking brilliant stuff.</p></htmltext>
<tokenext>Pragprog has an AWESOME book coming out that I ca n't wait to see reviewed called " SQL Antipatterns " .
Check out the sample chapter on selecting a random row from the database .
Freaking brilliant stuff .</tokentext>
<sentencetext>Pragprog has an AWESOME book coming out that I can't wait to see reviewed called "SQL Antipatterns".
Check out the sample chapter on selecting a random row from the database.
Freaking brilliant stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</id>
	<title>Not dynamic programming...</title>
	<author>Anonymous</author>
	<datestamp>1269286380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>The summary mentions dynamic programming; but this book contains nothing about dynamic programming. (A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly.)</p><p>The author, who I've seen speak, instead writes about "metaprogramming" which in my personal opinion is a silly catch phrase to sell talks and books when actually he's just talking about using some of the advanced functionality present in Ruby (and also JavaScript) to do things that would be done with macros or can't be done at all in traditional object oriented and procedural languages.</p><p>If you're buying this book thinking it contains some new breakthrough paradigm, and you're already familiar with the ins and outs of Ruby prepare to be disappointed.  If your background is Java or C++ and you've just learned enough to get by until now it'll probably be an eye-opener.</p></htmltext>
<tokenext>The summary mentions dynamic programming ; but this book contains nothing about dynamic programming .
( A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly .
) The author , who I 've seen speak , instead writes about " metaprogramming " which in my personal opinion is a silly catch phrase to sell talks and books when actually he 's just talking about using some of the advanced functionality present in Ruby ( and also JavaScript ) to do things that would be done with macros or ca n't be done at all in traditional object oriented and procedural languages.If you 're buying this book thinking it contains some new breakthrough paradigm , and you 're already familiar with the ins and outs of Ruby prepare to be disappointed .
If your background is Java or C + + and you 've just learned enough to get by until now it 'll probably be an eye-opener .</tokentext>
<sentencetext>The summary mentions dynamic programming; but this book contains nothing about dynamic programming.
(A particular method suitable to problems with optimal substructure that can be used in a subset of cases where recursion can be used and typically generates results very quickly.
)The author, who I've seen speak, instead writes about "metaprogramming" which in my personal opinion is a silly catch phrase to sell talks and books when actually he's just talking about using some of the advanced functionality present in Ruby (and also JavaScript) to do things that would be done with macros or can't be done at all in traditional object oriented and procedural languages.If you're buying this book thinking it contains some new breakthrough paradigm, and you're already familiar with the ins and outs of Ruby prepare to be disappointed.
If your background is Java or C++ and you've just learned enough to get by until now it'll probably be an eye-opener.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31578720</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>IAmGarethAdams</author>
	<datestamp>1269271320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think you a word out</htmltext>
<tokenext>I think you a word out</tokentext>
<sentencetext>I think you a word out</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574774</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576296</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>Anonymous</author>
	<datestamp>1269256200000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Ruby wasn't intended to be an "enterprise ready" language or anything like taking over the world and become popular whatsoever (the Rails guys are solely responsible for Ruby notoriety). Ruby is about the fun in programming, a hobby. Ruby supports all of the programming paradigms it can because it makes it more fun, nothing more, nothing less. You can write extremely perl-ish code in Ruby, you can write purely procedural code too even if the underlying mechanism is OO, you can write Smalltalk-ish code using all of its object facilities and the hash hack you mentioned to act like named parameters and so on. It's not acting in a professional and serious manner, and I don't think people should use Ruby in production-ready code but it's a little fun language that can be made to fit your mind, instead of fitting your mind to a straight-jacket. Don't diss it because the Rails people have been bullshitting their way into selling a novelty language to ignorant sheeps, the creator of Ruby, Matz, never tried to "sell" his language and make it the new buzzword of the tubes.</p></htmltext>
<tokenext>Ruby was n't intended to be an " enterprise ready " language or anything like taking over the world and become popular whatsoever ( the Rails guys are solely responsible for Ruby notoriety ) .
Ruby is about the fun in programming , a hobby .
Ruby supports all of the programming paradigms it can because it makes it more fun , nothing more , nothing less .
You can write extremely perl-ish code in Ruby , you can write purely procedural code too even if the underlying mechanism is OO , you can write Smalltalk-ish code using all of its object facilities and the hash hack you mentioned to act like named parameters and so on .
It 's not acting in a professional and serious manner , and I do n't think people should use Ruby in production-ready code but it 's a little fun language that can be made to fit your mind , instead of fitting your mind to a straight-jacket .
Do n't diss it because the Rails people have been bullshitting their way into selling a novelty language to ignorant sheeps , the creator of Ruby , Matz , never tried to " sell " his language and make it the new buzzword of the tubes .</tokentext>
<sentencetext>Ruby wasn't intended to be an "enterprise ready" language or anything like taking over the world and become popular whatsoever (the Rails guys are solely responsible for Ruby notoriety).
Ruby is about the fun in programming, a hobby.
Ruby supports all of the programming paradigms it can because it makes it more fun, nothing more, nothing less.
You can write extremely perl-ish code in Ruby, you can write purely procedural code too even if the underlying mechanism is OO, you can write Smalltalk-ish code using all of its object facilities and the hash hack you mentioned to act like named parameters and so on.
It's not acting in a professional and serious manner, and I don't think people should use Ruby in production-ready code but it's a little fun language that can be made to fit your mind, instead of fitting your mind to a straight-jacket.
Don't diss it because the Rails people have been bullshitting their way into selling a novelty language to ignorant sheeps, the creator of Ruby, Matz, never tried to "sell" his language and make it the new buzzword of the tubes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31575456</id>
	<title>6do7l</title>
	<author>Anonymous</author>
	<datestamp>1269252720000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext>Software lawyers sImilarly 6risly</htmltext>
<tokenext>Software lawyers sImilarly 6risly</tokentext>
<sentencetext>Software lawyers sImilarly 6risly</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574212</id>
	<title>Re:Hmm</title>
	<author>K. S. Kyosuke</author>
	<datestamp>1269291180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>"Why not just use a programming language that does it right?"</p></div><p>Unfortunately, most people *don't* program in Factor.</p></div>
	</htmltext>
<tokenext>" Why not just use a programming language that does it right ?
" Unfortunately , most people * do n't * program in Factor .</tokentext>
<sentencetext>"Why not just use a programming language that does it right?
"Unfortunately, most people *don't* program in Factor.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574774</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>Anonymous</author>
	<datestamp>1269249960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>-1 Troll</p><p>Writing a wall of text doesn't</p></htmltext>
<tokenext>-1 TrollWriting a wall of text does n't</tokentext>
<sentencetext>-1 TrollWriting a wall of text doesn't</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573820</id>
	<title>Re:These techniques are horrid for maintainability</title>
	<author>Anonymous</author>
	<datestamp>1269289680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Boy am I glad I don't work for you. While metaprogramming certainly isn't right for every case, it is literally perfect for some. Best tool for the job, and all.</p></htmltext>
<tokenext>Boy am I glad I do n't work for you .
While metaprogramming certainly is n't right for every case , it is literally perfect for some .
Best tool for the job , and all .</tokentext>
<sentencetext>Boy am I glad I don't work for you.
While metaprogramming certainly isn't right for every case, it is literally perfect for some.
Best tool for the job, and all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31590426</id>
	<title>Re:Smalltalk and LISP for the History Major</title>
	<author>soliptic</author>
	<datestamp>1269344160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As someone who is <em>not</em> an experienced programmer in all those languages, merely someone who has dabbled in a handful of them and read <em>about</em> programming much more than he's actually done it... Well, in the abstract, your argument is enticing, convincing even.  However there is one glaring counterargument which stands out to even a peon like me, which you have apparently not addressed.  It's this:</p><p><div class="quote"><p>When you think about it, you have to be kind of an asshole to want to create a new language with all that we have out there. It'd be one thing if it was so radically different as that would represent revolution, but Ruby is so derivative that I often wonder what value added.</p></div><p>If Smalltalk <em>Already Did It (Better)</em>&reg;, and Smalltalk has been around for x decades, then how come Ruby has come into widespread use in a way that Smalltalk never managed in all that time?</p><p>I don't pretend to know the answer to that.  I just think whatever the answer is, there's your answer to what value Ruby added.</p><p>If your answer is merely "hype and marketing, <em>-sneer-</em>" then I'm afraid you immediately lose credibility in my eyes.  For one thing, perhaps I'm naive but I'd like to think there has to be more to it than that. (It's not like developers make a habit of choosing their stack based on lifestyle ads in colour supplements.)  For another, it's not an answer anyway, because there was nothing stopping Smalltalk advocates employing the same hype and marketing.</p></div>
	</htmltext>
<tokenext>As someone who is not an experienced programmer in all those languages , merely someone who has dabbled in a handful of them and read about programming much more than he 's actually done it... Well , in the abstract , your argument is enticing , convincing even .
However there is one glaring counterargument which stands out to even a peon like me , which you have apparently not addressed .
It 's this : When you think about it , you have to be kind of an asshole to want to create a new language with all that we have out there .
It 'd be one thing if it was so radically different as that would represent revolution , but Ruby is so derivative that I often wonder what value added.If Smalltalk Already Did It ( Better )   , and Smalltalk has been around for x decades , then how come Ruby has come into widespread use in a way that Smalltalk never managed in all that time ? I do n't pretend to know the answer to that .
I just think whatever the answer is , there 's your answer to what value Ruby added.If your answer is merely " hype and marketing , -sneer- " then I 'm afraid you immediately lose credibility in my eyes .
For one thing , perhaps I 'm naive but I 'd like to think there has to be more to it than that .
( It 's not like developers make a habit of choosing their stack based on lifestyle ads in colour supplements .
) For another , it 's not an answer anyway , because there was nothing stopping Smalltalk advocates employing the same hype and marketing .</tokentext>
<sentencetext>As someone who is not an experienced programmer in all those languages, merely someone who has dabbled in a handful of them and read about programming much more than he's actually done it... Well, in the abstract, your argument is enticing, convincing even.
However there is one glaring counterargument which stands out to even a peon like me, which you have apparently not addressed.
It's this:When you think about it, you have to be kind of an asshole to want to create a new language with all that we have out there.
It'd be one thing if it was so radically different as that would represent revolution, but Ruby is so derivative that I often wonder what value added.If Smalltalk Already Did It (Better)®, and Smalltalk has been around for x decades, then how come Ruby has come into widespread use in a way that Smalltalk never managed in all that time?I don't pretend to know the answer to that.
I just think whatever the answer is, there's your answer to what value Ruby added.If your answer is merely "hype and marketing, -sneer-" then I'm afraid you immediately lose credibility in my eyes.
For one thing, perhaps I'm naive but I'd like to think there has to be more to it than that.
(It's not like developers make a habit of choosing their stack based on lifestyle ads in colour supplements.
)  For another, it's not an answer anyway, because there was nothing stopping Smalltalk advocates employing the same hype and marketing.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576738</id>
	<title>Re:Not dynamic programming...</title>
	<author>daver00</author>
	<datestamp>1269258120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The 'programming' in dynamic programming does not refer to writing computer programs, it is a branch of mathematics that grew out of the original convex optimization problems. Dantzig was a military 'programmer' in the 40s, the simplex algorithm was developed as a solution to problems that could be posed as a linear objective function with linear constraints. Programming in this sense was a word used by the military to describe how operations would be organised. Dynamic programming is an extension of linear programming and refers to mathematics, not computer code.</p></htmltext>
<tokenext>The 'programming ' in dynamic programming does not refer to writing computer programs , it is a branch of mathematics that grew out of the original convex optimization problems .
Dantzig was a military 'programmer ' in the 40s , the simplex algorithm was developed as a solution to problems that could be posed as a linear objective function with linear constraints .
Programming in this sense was a word used by the military to describe how operations would be organised .
Dynamic programming is an extension of linear programming and refers to mathematics , not computer code .</tokentext>
<sentencetext>The 'programming' in dynamic programming does not refer to writing computer programs, it is a branch of mathematics that grew out of the original convex optimization problems.
Dantzig was a military 'programmer' in the 40s, the simplex algorithm was developed as a solution to problems that could be posed as a linear objective function with linear constraints.
Programming in this sense was a word used by the military to describe how operations would be organised.
Dynamic programming is an extension of linear programming and refers to mathematics, not computer code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573194</id>
	<title>Re:Not dynamic programming...</title>
	<author>bunratty</author>
	<datestamp>1269287280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If it's at all like <a href="http://hop.perl.plover.com/" title="plover.com">Higher-Order Perl</a> [plover.com], it certainly isn't some new breakthrough paradigm. It's LISP re-invented. I hope the author understands LISP (or better yet, Scheme) so he doesn't re-invent it poorly.</htmltext>
<tokenext>If it 's at all like Higher-Order Perl [ plover.com ] , it certainly is n't some new breakthrough paradigm .
It 's LISP re-invented .
I hope the author understands LISP ( or better yet , Scheme ) so he does n't re-invent it poorly .</tokentext>
<sentencetext>If it's at all like Higher-Order Perl [plover.com], it certainly isn't some new breakthrough paradigm.
It's LISP re-invented.
I hope the author understands LISP (or better yet, Scheme) so he doesn't re-invent it poorly.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31580028</id>
	<title>Re:Hmm</title>
	<author>Jane Q. Public</author>
	<datestamp>1269286020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Methinks I smell a Python aficianado.
<br> <br>
(Whitespace? Really? Are you kidding?)
<br> <br>
All I have to say is: being the fastest-growing programming language right now, Ruby must have something going for it.</htmltext>
<tokenext>Methinks I smell a Python aficianado .
( Whitespace ? Really ?
Are you kidding ?
) All I have to say is : being the fastest-growing programming language right now , Ruby must have something going for it .</tokentext>
<sentencetext>Methinks I smell a Python aficianado.
(Whitespace? Really?
Are you kidding?
)
 
All I have to say is: being the fastest-growing programming language right now, Ruby must have something going for it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573348
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573820
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576296
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574956
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572962
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576560
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576738
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31575208
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576190
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31580028
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573076
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574710
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573194
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573466
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31590426
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31586046
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574424
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_22_146235_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31578720
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574774
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573252
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572910
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573714
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576296
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576190
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574774
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31578720
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576672
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31590426
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572944
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574050
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573076
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576560
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573112
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574424
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31586046
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574710
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573820
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31575208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573194
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573348
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31573466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31576738
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572870
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31580028
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574212
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_22_146235.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31572962
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_22_146235.31574956
</commentlist>
</conversation>
