<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Thinking about picking the Groovy DSL book up again</title>
	<atom:link href="http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/</link>
	<description>Where technology and art disappear</description>
	<lastBuildDate>Fri, 06 Aug 2010 14:55:00 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: James</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-138</link>
		<dc:creator>James</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-138</guid>
		<description>Naturally, I think it&#039;s a good idea; DSL&#039;s really are starting to get on a wider radar for people, though I think there&#039;s still a lack of clarity about them.  And in the DSL materials I&#039;ve seen, there&#039;s typically a dearth of good examples.  The questions of why to use certain DSL techniques, the advantages and disadvantages of, say, metaprogramming over higher order functions, doesn&#039;t really get covered.  In short, I think there&#039;s a market.

As for dumping Java...again, I agree.  Just yesterday, I was writing something in Ruby for my 99%-Java job and had to remember &quot;Hey! I don&#039;t have to write a complicated method call here; I can just send in a closure.&quot;  Which is to say, the techniques which Python, Ruby, and yes, even Groovy make so easy and clear are simply out of mind when typically writing Java.  Java just isn&#039;t expressive enough to cleanly support a wide array of DSL techniques, and there&#039;s really no point in attempting to ignore it for the sake of a larger market.  Good examples are much more important than language choice in that regard.

In short, I definitely think the book is worth a second look.</description>
		<content:encoded><![CDATA[<p>Naturally, I think it&#8217;s a good idea; DSL&#8217;s really are starting to get on a wider radar for people, though I think there&#8217;s still a lack of clarity about them.  And in the DSL materials I&#8217;ve seen, there&#8217;s typically a dearth of good examples.  The questions of why to use certain DSL techniques, the advantages and disadvantages of, say, metaprogramming over higher order functions, doesn&#8217;t really get covered.  In short, I think there&#8217;s a market.</p>
<p>As for dumping Java&#8230;again, I agree.  Just yesterday, I was writing something in Ruby for my 99%-Java job and had to remember &#8220;Hey! I don&#8217;t have to write a complicated method call here; I can just send in a closure.&#8221;  Which is to say, the techniques which Python, Ruby, and yes, even Groovy make so easy and clear are simply out of mind when typically writing Java.  Java just isn&#8217;t expressive enough to cleanly support a wide array of DSL techniques, and there&#8217;s really no point in attempting to ignore it for the sake of a larger market.  Good examples are much more important than language choice in that regard.</p>
<p>In short, I definitely think the book is worth a second look.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-139</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-139</guid>
		<description>Mainly the areas I&#039;ve always wanted to be able to use DSL are in configuration where I have to deal with lots of XML.

DSLs to replace some of the following:
Spring / Camel / xBean / Hibernate

a cookbook style where I can pick up examples and use them would be very helpful to me.</description>
		<content:encoded><![CDATA[<p>Mainly the areas I&#8217;ve always wanted to be able to use DSL are in configuration where I have to deal with lots of XML.</p>
<p>DSLs to replace some of the following:<br />
Spring / Camel / xBean / Hibernate</p>
<p>a cookbook style where I can pick up examples and use them would be very helpful to me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-140</link>
		<dc:creator>Sam</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-140</guid>
		<description>First off, don&#039;t bother with DSLs in Java.  That&#039;s pretty much a dead-end.  If I&#039;m gonna write a DSL, it&#039;s going to be in Groovy.  Second, please continue writing.  There&#039;s very little info out there about how to formulate a DSL.  I would love to see a book walk through an example of an actual business problem and walk me through how to build out a DSL that addresses the problem while working with rich domain objects.  Nobody talks about this shit (not even Neal Ford) and until somebody figures it out, DSLs won&#039;t really go anywhere (or they will be horribly designed).  This technology is in it&#039;s infancy so there&#039;s a huge opening here for someone to come in, figure it out, and kick some ass.</description>
		<content:encoded><![CDATA[<p>First off, don&#8217;t bother with DSLs in Java.  That&#8217;s pretty much a dead-end.  If I&#8217;m gonna write a DSL, it&#8217;s going to be in Groovy.  Second, please continue writing.  There&#8217;s very little info out there about how to formulate a DSL.  I would love to see a book walk through an example of an actual business problem and walk me through how to build out a DSL that addresses the problem while working with rich domain objects.  Nobody talks about this shit (not even Neal Ford) and until somebody figures it out, DSLs won&#8217;t really go anywhere (or they will be horribly designed).  This technology is in it&#8217;s infancy so there&#8217;s a huge opening here for someone to come in, figure it out, and kick some ass.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Warner Onstine</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-141</link>
		<dc:creator>Warner Onstine</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-141</guid>
		<description>@Sam
What kind of business problems would you like to see covered? I ask as there are alot that could be covered, but not everyone would be interested.

@James and @Richard
What I was thinking is that this would be not necessarily cookbook style but one that would show different types of DSL techniques and where their application makes sense given a specific problem. Not sure if this fits in with what Sam was thinking about. Each technique would probably be given a good 4-5 pages to go over and might look something like this:
- Technique
- Problems it addresses
- Example of implementing the technique in Groovy for a specific problem
- Related techniques

Each technique would then be grouped into an overall category for easy relating. What those groups are I&#039;m not sure yet. What I may do is start this out as a Wiki so that everyone can see what I&#039;m thinking and comment on it.</description>
		<content:encoded><![CDATA[<p>@Sam<br />
What kind of business problems would you like to see covered? I ask as there are alot that could be covered, but not everyone would be interested.</p>
<p>@James and @Richard<br />
What I was thinking is that this would be not necessarily cookbook style but one that would show different types of DSL techniques and where their application makes sense given a specific problem. Not sure if this fits in with what Sam was thinking about. Each technique would probably be given a good 4-5 pages to go over and might look something like this:<br />
- Technique<br />
- Problems it addresses<br />
- Example of implementing the technique in Groovy for a specific problem<br />
- Related techniques</p>
<p>Each technique would then be grouped into an overall category for easy relating. What those groups are I&#8217;m not sure yet. What I may do is start this out as a Wiki so that everyone can see what I&#8217;m thinking and comment on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arek</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-142</link>
		<dc:creator>Arek</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-142</guid>
		<description>It will be nice to have some book about DSL in Groovy. I think it should compare Groovy solutions with &quot;real&quot; DSL in Java (I mean JavaCC or ANTLR).

For me personally it will be good to read about some DSL solution which could replace XML. Currently I&#039;m using a lot of XML binding. In this solution I can have full cycle of using some external files: it can be created by human (developer), loaded into application and changed into Java Beans, changed by application by user (in GUI or in other way), saved to disc again as XML, etc.
I never come to any DSL solution which will be similar. It looks like it is only half way when creation, and parsing is considered, but not serialization.

By the way you are aware about this coming book: http://www.martinfowler.com/dslwip/</description>
		<content:encoded><![CDATA[<p>It will be nice to have some book about DSL in Groovy. I think it should compare Groovy solutions with &#8220;real&#8221; DSL in Java (I mean JavaCC or ANTLR).</p>
<p>For me personally it will be good to read about some DSL solution which could replace XML. Currently I&#8217;m using a lot of XML binding. In this solution I can have full cycle of using some external files: it can be created by human (developer), loaded into application and changed into Java Beans, changed by application by user (in GUI or in other way), saved to disc again as XML, etc.<br />
I never come to any DSL solution which will be similar. It looks like it is only half way when creation, and parsing is considered, but not serialization.</p>
<p>By the way you are aware about this coming book: <a href="http://www.martinfowler.com/dslwip/" rel="nofollow">http://www.martinfowler.com/dslwip/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Warner Onstine</title>
		<link>http://www.warneronstine.com/2008/03/26/thinking-about-picking-the-dsl-book-up-again/comment-page-1/#comment-143</link>
		<dc:creator>Warner Onstine</dc:creator>
		<pubDate>Wed, 31 Dec 1969 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">urn:uuid:{a.guid}#comment-143</guid>
		<description>@Arek
Yep, very aware of the Martin Fowler book, but he doesn&#039;t cover Groovy at all.</description>
		<content:encoded><![CDATA[<p>@Arek<br />
Yep, very aware of the Martin Fowler book, but he doesn&#8217;t cover Groovy at all.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
