On Wed, Feb 2, 2011 at 10:23 AM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
On Feb 1, 2011, at 9:27 PM, Yaron Minsky wrote:<br>
<br>
</div><div class="im">> I'm finding it to be rather tough going, mostly because a lot of things that are really easy in scratch seem surprisingly hard in racket.<br>
<br>
</div>[I thought we had discussed this before.]<br>
<br>
Scratch/Alice/Kodu are "low floor, low ceiling" languages. Indeed, "low ceiling" should almost be replaced with "no-escape ceiling". Their inventors know the purpose of such "introductions to programming."</blockquote>
<div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
In contrast, the teaching languages of Racket are 'high floor, smooth path to full power". Our goals are<br>
(1) to help improve students' math skills; what they write down is plain math and yet they get a game<br>
the transfer of skills back to the math curriculum is demonstrable<br>
(2) to teach some basic computational design skills<br>
(3) to provide an entry point from which it is easy to move on to a full-fledged language that has<br>
first-class functions, modules, functor-like component systems, first-class classes,<br>
a rich set of libraries, etc.<br><div class="im"></div></blockquote><div><br>Absolutely. This is why I want to teach my kids Racket! Some of the extra difficulties involved in using Racket go hand-in-hand with the extra power, and I'm happy to pay that cost. But I do think that some of the bumps in the road are unnecessary, and worth fixing. Making structs easier to use, and improving the speed of the graphics both seem like good steps, and seem in line with what you guys are thinking anyway, so I think there's little disagreement.<br>
<br>Something I'm struggling with now pedagogically is how to handle geometry in reasonable way with a kid who doesn't yet know trigonometry. Scratch and logo's approach of using sprites lets you get pretty far without understanding trig, but I've found image.ss to be considerably harder. I'm just starting to try an approach of having two types, a posn and a polr, representing cartesian and polar coordinates respectively, and provide functions for converting back and forth. I'm still not sure how that's going to pan out...<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> I'd be interested in suggestions with is how to deal with updating a struct in a clean way.<br>
<br>
</div>For the 2e languages, I am considering adding a facility for using paths into structure trees to reference values and to update fields. I have a prototype, but things just keep piling up.<br>
<font color="#888888"><br>
-- Matthias<br>
<br>
<br>
<br>
</font></blockquote></div><br>