[racket] style: nested cond (fine!)
Matthias Felleisen
On Feb 21, 2012, at 8:41 AM, Stephen Bloch wrote:
> On Feb 21, 2012, at 7:18 AM, Rodolfo Carvalho wrote:
>
>> BTW I just found the nested-cond pattern appearing on HtDP, throughout section 9:
>> http://htdp.org/2003-09-26/Book/curriculum-Z-H-13.html
>
> That happens when you follow the HtDP design recipe directly and there are conditionals for two unrelated reasons, e.g.
>
> (cond [(empty? L) ...]
> [(cons? L)
> (cond [(snark? (first L)) ...]
> [(boojum? (first L)) ...]
> [(beeblebrox? (first L)) ...]
> )])
>
> Yes, this COULD be collapsed into ...
We *subtract* points from solutions when students flatten out such conds in 'CS1'. At this stage in their development programmers must be able to go from a quasi-algebraic data definitions to code (and back). If they were to write this code in Java ('CS2'), they wouldn't have conds for the outer part -- they'd use dispatch. Hence I consider this version the only one that is correct -- morally speaking.
Adult/experienced programmers may flatten the cond -- if they know certain conditions hold about the data types involved and **all** programmers who will read their code in the future.
Eli knows all this -- which is why he wrote that the tool cannot be used without human post-processing. It isn't an automatic tool -- it must be placed in context.
-- Matthias
____________________
Racket Users list:
http://lists.racket-lang.org/users
Eli Barzilay
>
> Eli knows all this -- which is why he wrote that the tool cannot be
> used without human post-processing. It isn't an automatic tool -- it
> must be placed in context.
There are two reasons for not being completely automatic. The first
is a silly one: I didn't bother making it completely robust: it's easy
to have easy rules that get false positives if there's a human that
goes over the results to weed them out.
The second reason is what Matthias is talking about: a proper script
would need to have a bunch of settings and a way to easily plug
"style filters" in and out. That could possibly come with a bunch of
pre-configured setups, which would work very well for HtDP since it's
very consistent.
BTW, because of that the HtDP style should also have a bunch of
additional rules that are easy to check -- like a single toplevel
`cond' per function etc. There are also probably a bunch of
variations for different parts in the book.
In any case, with the above disclaimers in mind, and also noting that
it is a kind of a rough first sketch for proper code, I've put it
here:
http://tmp.barzilay.org/code-ayatollah.rkt
(Seeing the "code nazi" comment made the above tentative name obvious
to me, since a number of years ago when I worked in a company, I was
called a "Code Ayatollah", which I took as a compliment...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Stephen Bloch
On Feb 21, 2012, at 11:15 AM, Matthias Felleisen wrote:
> If they were to write this code in Java ('CS2'), they wouldn't have conds for the outer part -- they'd use dispatch.
Only if they were using polymorphic data structures. But most of the Real World uses null-terminated data structures instead, despite that approach's practical disadvantages, so students need to learn how to work with them too -- and CS2 seems like an appropriate place to do that. So yes, they WOULD have a conditional for the outer part.
Stephen Bloch
sbl...@adelphi.edu
Matthias Felleisen
On Feb 21, 2012, at 11:32 AM, Stephen Bloch wrote:
>
> On Feb 21, 2012, at 11:15 AM, Matthias Felleisen wrote:
>
>> If they were to write this code in Java ('CS2'), they wouldn't have conds for the outer part -- they'd use dispatch.
>
> Only if they were using polymorphic data structures. But most of the Real World uses null-terminated data structures instead, despite that approach's practical disadvantages, so students need to learn how to work with them too -- and CS2 seems like an appropriate place to do that. So yes, they WOULD have a conditional for the outer part.
You are right. We must teach students how to be bad OO programmers in CS2. Where else would they learn it? Plus they pay us for it.
Stephen Bloch
> You are right. We must teach students how to be bad OO programmers in CS2. Where else would they learn it? Plus they pay us for it.
No, but we must teach students to read and modify code written by bad OO programmers.
Stephen Bloch
sbl...@adelphi.edu
Matthias Felleisen
How can they do that if we teach them only bad OO programming?
Stephen Bloch
On Feb 21, 2012, at 11:45 AM, Matthias Felleisen wrote:
> How can they do that [read and modify code written by bad OO programmers] if we teach them only bad OO programming?
I wouldn't suggest that, of course. The last time I taught CS2 (or rather CS1 in Java, having been expressly forbidden to use any other language), I had students build lists and trees with polymorphism, then do it again with nulls.
I also had them build a list-of-lista data structure from scratch with a functional API, and use this to solve the "permutations" problem; then I had them do the same problem again using Java's built-in collection classes (which have a very stateful API). The results were enlightening: almost everybody got it working the functional way, but when we did it using Java collection classes, ONE student in the class turned in a solution that FREQUENTLY (not always) produced correct answers.
Matthias Felleisen
Amen.