<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Karel heads for the stars</title>
	<link>http://blog.thingoid.com/2004/03/karel-star/</link>
	<description></description>
	<pubDate>Thu, 28 Aug 2008 03:51:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Trevor</title>
		<link>http://blog.thingoid.com/2004/03/karel-star/#comment-7</link>
		<dc:creator>Trevor</dc:creator>
		<pubDate>Wed, 26 Oct 2005 23:54:43 +0000</pubDate>
		<guid>http://blog.thingoid.com/2004/03/karel-star/#comment-7</guid>
		<description>&lt;p&gt;Hello Tracy and thanks for your comments. It's great to get feedback as detailed and thoughtful as yours - I'm only sorry that I haven't been able to respond earlier.&lt;/p&gt;

&lt;p&gt;Anyway, to take your comments in turn:&lt;/p&gt;

&lt;h4&gt;Style&lt;/h4&gt;

&lt;p&gt;Yep, even now there are still some lingering styling problems on this site - the side-effect of an automated conversion between authoring systems. I'm exceptionally grateful for your pointing out some particularly egregious faults on this page, which I hope I've addressed (except for the readability issue, which I probably won't be in a position to test and fix for a month or two).&lt;/p&gt;

&lt;h4&gt;Content&lt;/h4&gt;

&lt;p&gt;In listing 2, you are right that it would be neater if XMaker had a turnAround() statement at the end. However, for my purposes this adds little except two extra turns on every diagonal. But for purity I agree that the robot should really end in it's beginning state.&lt;/p&gt;

&lt;p&gt;On the other hand, I do not agree with your recommendation to return the four robots to the centre.  The final position of all robots is specified in fig 1, which shows that four robots stop at the ends of the vertical and horizontal arms, not back in the middle - so that is what the writer of Example04 should expect to see. Programming problems for Karel are often effectively instructions to "make this shape" where the final positions of the robots may or may not be relevant, but in this case I argue that they are.&lt;/p&gt;

&lt;p&gt;Regarding your recommendation for listing 5, isn't this simply reproducing the same approach as XMaker (listing 2) just in a more complex way? That is, your suggested call to super.makeShape(); is functionally equivalent to a call to a local makeLine(); function (similar to makeDiagonal() in XMaker). That said, I agree that it's a neat way of illustrating inheritance and calls to superclass methods - and probably more straightforward.&lt;/p&gt;

&lt;p&gt;I don't want to sound defensive (because I'm not) or like I'm rejecting your comments out of hand (because I don't). In fact I've added to the article a suggestion for readers to try out and experiment with your recommendations as a means to further learning.&lt;/p&gt;

&lt;h4&gt;Thanks&lt;/h4&gt;

&lt;p&gt;Thanks again for the comments and feedback. I'm glad that you're finding a use for the &lt;a href="/category/programming/karel/" rel="nofollow"&gt;Karel series&lt;/a&gt;.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hello Tracy and thanks for your comments. It&#8217;s great to get feedback as detailed and thoughtful as yours - I&#8217;m only sorry that I haven&#8217;t been able to respond earlier.</p>
<p>Anyway, to take your comments in turn:</p>
<h4>Style</h4>
<p>Yep, even now there are still some lingering styling problems on this site - the side-effect of an automated conversion between authoring systems. I&#8217;m exceptionally grateful for your pointing out some particularly egregious faults on this page, which I hope I&#8217;ve addressed (except for the readability issue, which I probably won&#8217;t be in a position to test and fix for a month or two).</p>
<h4>Content</h4>
<p>In listing 2, you are right that it would be neater if XMaker had a turnAround() statement at the end. However, for my purposes this adds little except two extra turns on every diagonal. But for purity I agree that the robot should really end in it&#8217;s beginning state.</p>
<p>On the other hand, I do not agree with your recommendation to return the four robots to the centre.  The final position of all robots is specified in fig 1, which shows that four robots stop at the ends of the vertical and horizontal arms, not back in the middle - so that is what the writer of Example04 should expect to see. Programming problems for Karel are often effectively instructions to &#8220;make this shape&#8221; where the final positions of the robots may or may not be relevant, but in this case I argue that they are.</p>
<p>Regarding your recommendation for listing 5, isn&#8217;t this simply reproducing the same approach as XMaker (listing 2) just in a more complex way? That is, your suggested call to super.makeShape(); is functionally equivalent to a call to a local makeLine(); function (similar to makeDiagonal() in XMaker). That said, I agree that it&#8217;s a neat way of illustrating inheritance and calls to superclass methods - and probably more straightforward.</p>
<p>I don&#8217;t want to sound defensive (because I&#8217;m not) or like I&#8217;m rejecting your comments out of hand (because I don&#8217;t). In fact I&#8217;ve added to the article a suggestion for readers to try out and experiment with your recommendations as a means to further learning.</p>
<h4>Thanks</h4>
<p>Thanks again for the comments and feedback. I&#8217;m glad that you&#8217;re finding a use for the <a href="/category/programming/karel/" rel="nofollow">Karel series</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tracy Kouns</title>
		<link>http://blog.thingoid.com/2004/03/karel-star/#comment-2</link>
		<dc:creator>Tracy Kouns</dc:creator>
		<pubDate>Fri, 16 Sep 2005 14:08:07 +0000</pubDate>
		<guid>http://blog.thingoid.com/2004/03/karel-star/#comment-2</guid>
		<description>&lt;p&gt;I really like this approach of introducing abstract classes at a very early stage in the students' programming education.  I do, however, have a some recommendations.&lt;/p&gt;

&lt;h4&gt;Style&lt;/h4&gt;

&lt;p&gt;As of 9/16/05 this page needs some attention to the html and css.  See Listing 2, Listing 4, Listing 5, and the end of the first paragraph in Super Methods.  Also, all of the listings in all 4 parts appear really small in Firefox.&lt;/p&gt;

&lt;h4&gt;&lt;a id="tracyrecommends"&gt;&lt;/a&gt;Content&lt;/h4&gt;

&lt;p&gt;In Listing 2, XMaker, I would recommend adding turnAround(); as the last statement in makeDiagonal().  This would cause the Robot to not only wind up in its original starting location but again face its original direction at the time of the method call.&lt;/p&gt;

&lt;p&gt;In Listing 4, LineMaker, I would recommend adding the following code to the end of the makeShape() method.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;turnAround();
move();
move();
move();
move();
turnAround();&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This again puts the Robot in its original location and direction at the time of the method call.&lt;/p&gt;

&lt;p&gt;With the above changes, the makeShape() method in Listing 5, CrossMaker, could then be written as follows.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;public void makeShape()
{
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
}&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;I would like this approach better because the CrossMaker "is a" LineMaker. It therefore seems NOT to be the best approach that it then creates more Robots when called to makeShape().  This currently tends to leave side effects (unintended visible evidence from the method).  The writer of Example04 would probably be expecting to see one or possibly two Robots in the output.  As it is currently, it displays five Robots.
This new approach would still lend itself to a good example of using inheritance with calls to a super method.&lt;/p&gt;

&lt;p&gt;Thanks for making these great lessons available.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I really like this approach of introducing abstract classes at a very early stage in the students&#8217; programming education.  I do, however, have a some recommendations.</p>
<h4>Style</h4>
<p>As of 9/16/05 this page needs some attention to the html and css.  See Listing 2, Listing 4, Listing 5, and the end of the first paragraph in Super Methods.  Also, all of the listings in all 4 parts appear really small in Firefox.</p>
<h4><a id="tracyrecommends"></a>Content</h4>
<p>In Listing 2, XMaker, I would recommend adding turnAround(); as the last statement in makeDiagonal().  This would cause the Robot to not only wind up in its original starting location but again face its original direction at the time of the method call.</p>
<p>In Listing 4, LineMaker, I would recommend adding the following code to the end of the makeShape() method.</p>
<pre><code>turnAround();
move();
move();
move();
move();
turnAround();</code></pre>
<p>This again puts the Robot in its original location and direction at the time of the method call.</p>
<p>With the above changes, the makeShape() method in Listing 5, CrossMaker, could then be written as follows.</p>
<pre><code>public void makeShape()
{
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
  super.makeShape();
  turnLeft();
}</code></pre>
<p>I would like this approach better because the CrossMaker &#8220;is a&#8221; LineMaker. It therefore seems NOT to be the best approach that it then creates more Robots when called to makeShape().  This currently tends to leave side effects (unintended visible evidence from the method).  The writer of Example04 would probably be expecting to see one or possibly two Robots in the output.  As it is currently, it displays five Robots.<br />
This new approach would still lend itself to a good example of using inheritance with calls to a super method.</p>
<p>Thanks for making these great lessons available.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
