<?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"
	>
<channel>
	<title>Comments on: Unrolling Code Closures for Undergraduates</title>
	<atom:link href="http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/feed/" rel="self" type="application/rss+xml" />
	<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/</link>
	<description>Longer than a blog; shorter than a book</description>
	<pubDate>Thu, 28 Aug 2008 20:43:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: bÃ¶rsenspiel</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-87011</link>
		<dc:creator>bÃ¶rsenspiel</dc:creator>
		<pubDate>Mon, 07 May 2007 22:18:21 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-87011</guid>
		<description>donâ€™t equate this with the type erasure problem because generics are syntax sugar *with* particular expected behavior that gets wiped out by the Java implementation, while closures are syntax sugar whose expected behavior would *not* getting wiped out by the implementation. As long as the implementation does not contradict the expected behavior, then we basically shouldnâ€™t care how itâ€™s implemented (information hiding and all).</description>
		<content:encoded><![CDATA[<p>donâ€™t equate this with the type erasure problem because generics are syntax sugar *with* particular expected behavior that gets wiped out by the Java implementation, while closures are syntax sugar whose expected behavior would *not* getting wiped out by the implementation. As long as the implementation does not contradict the expected behavior, then we basically shouldnâ€™t care how itâ€™s implemented (information hiding and all).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Rivera</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-71601</link>
		<dc:creator>Isaac Rivera</dc:creator>
		<pubDate>Mon, 02 Apr 2007 20:22:30 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-71601</guid>
		<description>Ricky,

Agreed. I was trying to show how simple a previous post concern could be. 

However, "if you donâ€™t want it to be called outside the current context, donâ€™t give it out," is not so simple. As you may want subclass or package privacy, no?

Isaac</description>
		<content:encoded><![CDATA[<p>Ricky,</p>
<p>Agreed. I was trying to show how simple a previous post concern could be. </p>
<p>However, &#8220;if you donâ€™t want it to be called outside the current context, donâ€™t give it out,&#8221; is not so simple. As you may want subclass or package privacy, no?</p>
<p>Isaac</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Hanson</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-71538</link>
		<dc:creator>Tim Hanson</dc:creator>
		<pubDate>Mon, 02 Apr 2007 18:00:29 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-71538</guid>
		<description>Higher level abstractions are good only when they don't "leak". This is exactly why the "if" statement is good. I don't really care that it is implemented using gotos.

This is also why implementing generics using type erasure is bad. I do have to know the implementation details. The closure spec seems to fall more into the latter camp.</description>
		<content:encoded><![CDATA[<p>Higher level abstractions are good only when they don&#8217;t &#8220;leak&#8221;. This is exactly why the &#8220;if&#8221; statement is good. I don&#8217;t really care that it is implemented using gotos.</p>
<p>This is also why implementing generics using type erasure is bad. I do have to know the implementation details. The closure spec seems to fall more into the latter camp.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ricky Clarkson</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-71359</link>
		<dc:creator>Ricky Clarkson</dc:creator>
		<pubDate>Mon, 02 Apr 2007 08:59:08 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-71359</guid>
		<description>Elliotte,

Stuffing as many ideas into one line of code as possible seems bad, true, but:
Stuffing as many lines of code into one idea as possible also seems bad.

"He can compress the most words into the smallest idea of any man I know." -- Abraham Lincoln, who was not a Java programmer.

Good programmers can make a good decision about how many ideas per line of code are good.  It's not the language's responsibility to make that decision for you.</description>
		<content:encoded><![CDATA[<p>Elliotte,</p>
<p>Stuffing as many ideas into one line of code as possible seems bad, true, but:<br />
Stuffing as many lines of code into one idea as possible also seems bad.</p>
<p>&#8220;He can compress the most words into the smallest idea of any man I know.&#8221; &#8212; Abraham Lincoln, who was not a Java programmer.</p>
<p>Good programmers can make a good decision about how many ideas per line of code are good.  It&#8217;s not the language&#8217;s responsibility to make that decision for you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ricky Clarkson</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-71357</link>
		<dc:creator>Ricky Clarkson</dc:creator>
		<pubDate>Mon, 02 Apr 2007 08:52:32 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-71357</guid>
		<description>Isaac,

Neal goes through the reasons in this talk: http://video.google.co.uk/videoplay?docid=4051253555018153503

By the way, there's no use in making an anonymous function public/private.  If you don't want it to be called outside the current context, don't give it out.  When you make a StringBuffer, you don't set an access level, so why would you do it for a Function?</description>
		<content:encoded><![CDATA[<p>Isaac,</p>
<p>Neal goes through the reasons in this talk: <a href="http://video.google.co.uk/videoplay?docid=4051253555018153503" rel="nofollow">http://video.google.co.uk/videoplay?docid=4051253555018153503</a></p>
<p>By the way, there&#8217;s no use in making an anonymous function public/private.  If you don&#8217;t want it to be called outside the current context, don&#8217;t give it out.  When you make a StringBuffer, you don&#8217;t set an access level, so why would you do it for a Function?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Rivera</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-70740</link>
		<dc:creator>Isaac Rivera</dc:creator>
		<pubDate>Sat, 31 Mar 2007 18:04:03 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-70740</guid>
		<description>Opps! did not escape my brackets! Here it goes again:

Whatâ€™s wrong with a simple implementation like:

Function&#60;String&#62; f = new Function&#60;String&#62;(String someArg, int anotherArg) {
String result = someArg + â€œ, â€ + anotherArg;
return result;
};

f.setAccess(Function.PUBLIC);

String s = f("foo", 2);</description>
		<content:encoded><![CDATA[<p>Opps! did not escape my brackets! Here it goes again:</p>
<p>Whatâ€™s wrong with a simple implementation like:</p>
<p>Function&lt;String&gt; f = new Function&lt;String&gt;(String someArg, int anotherArg) {<br />
String result = someArg + â€œ, â€ + anotherArg;<br />
return result;<br />
};</p>
<p>f.setAccess(Function.PUBLIC);</p>
<p>String s = f(&#8221;foo&#8221;, 2);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Rivera</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-70739</link>
		<dc:creator>Isaac Rivera</dc:creator>
		<pubDate>Sat, 31 Mar 2007 18:01:06 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-70739</guid>
		<description>What's wrong with a simple implementation like:

Function f = new Function(String someArg, int anotherArg) {
    String result = someArg + ", " + anotherArg;
    return result;
};

f.setAccess(Function.PUBLIC);

We already use all of this syntax and it resembles anonymous class declarations. Its not unlinke closures on some scripting languages either.</description>
		<content:encoded><![CDATA[<p>What&#8217;s wrong with a simple implementation like:</p>
<p>Function f = new Function(String someArg, int anotherArg) {<br />
    String result = someArg + &#8220;, &#8221; + anotherArg;<br />
    return result;<br />
};</p>
<p>f.setAccess(Function.PUBLIC);</p>
<p>We already use all of this syntax and it resembles anonymous class declarations. Its not unlinke closures on some scripting languages either.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fuel</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-70469</link>
		<dc:creator>Fuel</dc:creator>
		<pubDate>Sat, 31 Mar 2007 04:21:16 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-70469</guid>
		<description>pestov,
            Java will be mostly legacy??? on what basis do you state this ?? if your comment is based on the speed of java programs , then you are horribly wrong.</description>
		<content:encoded><![CDATA[<p>pestov,<br />
            Java will be mostly legacy??? on what basis do you state this ?? if your comment is based on the speed of java programs , then you are horribly wrong.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen Colebourne</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-70402</link>
		<dc:creator>Stephen Colebourne</dc:creator>
		<pubDate>Sat, 31 Mar 2007 00:11:09 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-70402</guid>
		<description>How a new language feature is implemented really shouldn't matter to anyone but the compiler writer - it should be transparent. The problems occur when you get leaky abstractions, like generics. The task here and now is to ensure that closures has no leaky abstractions (IMO, BGGA closures does at the moment). Oh, and don't forget FCM !

BTW, John DeHope's first reply is quite an eloquent way of pointing out why Java desperately needs closures (and why it should have had them earlier). Its that sense that we are have to write too much code to achieve our goal (simple, clear, easy to read later, logic). One response is to break everything down to one item per line. IMO, this isn't the right response, but in the absence of closures it may be all we have. Its all explained better in the Kingdom of the Nouns - http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html. And I even agree with Slava in a way - teaching a language without closures no longer seems sensible to me.</description>
		<content:encoded><![CDATA[<p>How a new language feature is implemented really shouldn&#8217;t matter to anyone but the compiler writer - it should be transparent. The problems occur when you get leaky abstractions, like generics. The task here and now is to ensure that closures has no leaky abstractions (IMO, BGGA closures does at the moment). Oh, and don&#8217;t forget FCM !</p>
<p>BTW, John DeHope&#8217;s first reply is quite an eloquent way of pointing out why Java desperately needs closures (and why it should have had them earlier). Its that sense that we are have to write too much code to achieve our goal (simple, clear, easy to read later, logic). One response is to break everything down to one item per line. IMO, this isn&#8217;t the right response, but in the absence of closures it may be all we have. Its all explained better in the Kingdom of the Nouns - <a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" rel="nofollow">http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html</a>. And I even agree with Slava in a way - teaching a language without closures no longer seems sensible to me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Slava Pestov</title>
		<link>http://cafe.elharo.com/blogroll/unrolling-code-closures-for-undergraduates/#comment-70381</link>
		<dc:creator>Slava Pestov</dc:creator>
		<pubDate>Fri, 30 Mar 2007 22:59:41 +0000</pubDate>
		<guid isPermaLink="false">http://cafe.elharo.com/java/unrolling-code-closures-for-undergraduates/#comment-70381</guid>
		<description>Why are you teaching Java to undergraduates? They will be hamstrung for the rest of their career. By the time they graduate Java will be mostly 'legacy' anyway.</description>
		<content:encoded><![CDATA[<p>Why are you teaching Java to undergraduates? They will be hamstrung for the rest of their career. By the time they graduate Java will be mostly &#8216;legacy&#8217; anyway.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
