## RE: [XP] KISS

Expand Messages
• What would your simplicity score be for max = max(max(a, b), c); ? Seems like 0 to me, unless you require implementing the builtin function max. Wouldn t
Message 1 of 24 , Jun 29, 2005
• 0 Attachment
What would your simplicity score be for "max = max(max(a, b), c);"? Seems like 0 to me, unless you require implementing the builtin function max. Wouldn't the base score be 1 instead of 2, if max(a,b) was implemented as:
if (a > b)
return a;
return b;

But, the above code is really less "simple" than the code below (because it requires more human thought to comprehend):
if (a > b)
return a;
else
return b;

I find the anality of the below implementation to make it less simple, but I suppose that could be a matter of taste:
if (a > b)
max = a;
else
max = b;
return max;

median(a,b,c):
if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
return b;
if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
return c;
return a;
has a simplicity score of 2, which is less than your base of 3.

I prefer the implementation
if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
return b;
else if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
return c;
else
return a;
but it should have a simplicity score of 4 rather than 3 under your formula.

So, simplicity isn't even simple for little toy algorithms. Looks like you might have to make your simplicity measure annoyingly complex. You might have to account for fallthroughs, returns, and the number of terms in a condition. Maybe, "go to" should have a score of 100 and "break" a score of 10 (except in case statements).

I am sure you know that in real systems there are usually tradeoffs between the number of conditions, computational complexity, efficiency, expressiveness, testability, and maintainability. It is never too soon to open the students' mind to the idea that there may not always be a single alternative that is best in every possible way. If you are teaching them in a non-OO language like C, you might want to explain that the tradeoffs were different 20 years ago than they are today (for example, how old programming values and memory constraints lead to the Y2K problem). The tradeoffs might well be different 20 years from now, so open their minds to the possibilities instead of indoctrinating them to some rigid formula.

You might consider having the students rank each other's solutions with respect to simplicity and other characteristics (anonymously, of course). You might throw some of your own solutions in the mix as well. The students would learn a lot more from looking at alternative solutions and thinking about which are better in what ways than trying to satisfy some algorithmic simplicity metric that would be misleading for larger programs.

Steven Gordon, PhD
http://sf.asu.edu/

-----Original Message-----
From: extremeprogramming@yahoogroups.com on behalf of Clark, David
Sent: Tue 6/28/2005 10:59 PM
To: extremeprogramming@yahoogroups.com
Cc:
Subject: [XP] KISS

This isn't strictly XP, but as a group you are so helpful and interested in programming that I am sure some of you will take an interest in this. Apologies to the others.

I teach an introductory programming subject to students who are doing a more technically oriented IT course. The language of implementation is C, under Linux. (These students also do another, gentler, introductory programming subject using VB .NET.) The subject is highly algorithmic. It has a high emphasis on testing.

As part of my end of semester reflection, I think that some things work well. At the end of the subject they can code quite well, they understand testing, and they have had to develop a number of interesting algorithms. One area, however, that is generally not done well is simplicity. Their code works, but it is often a lot more complex than it needs to be. Especially if the algorithm is a bit difficult.

Students adapt to how assignments are marked. So I am thinking that next time I run it I will try to incorporate a "simplicity" component in my marking scheme. Here is the idea. Award 10 marks (points if you are US), say, for simplicity in each assignment question. Then they would get simplicity marks from the formula
10 * base_simplicity_measure / their_simplicity_measure
where base_simplicity_measure is the simplicity measure on my solution.

So what to use for the simplicity measure?
It must be simple, effective, and appropriate for beginning students.
Here is my suggestion (aim is to be as low as possible) :
1 point for each IF
2 points for each IF .. ELSE or case (or conditional).
1 point for a loop
When a loop or selection statement is nested [1, 2, 3, ...] deep, there are additional [1, 3, 5, ...] points.

The hoped-for benefits of having this component in their marks include
more emphasis on simplicity
an awareness that there are other solutions than the one they first come up with
encourages modularity
encourages use of library functions
students start to learn about refactoring

I would appreciate any comments you have on this idea,
thanks,
David

============ Examples ============
Example 1: Max of 3 numbers (a very early illustrative example, before they have done loops).
if (a > b)
if (a > c)
max = a
else
max = c
end
else
if (b > c)
max = b
else
max = c
end
end
This gives a simplicity measure of 8. An experienced programmer would generate a solution with a simplicity measure of 2.

Example 2: Median of 3 numbers (again a very early illustrative example, before they have done loops).
This is a fun example in class, as most students' solutions have holes in them. Finding examples where students' solutions fail reinforces testing. Students' solutions are certainly not simple.
In this case the base simplicity measure is 3.

Example 3: A real example. A question from the students' final assignment.
The base simplicity measure for this question is 10.
Card Shuffle
You have 3 tables, table 1, table2 and table3. There is a line of cards on table1. Table2 and table3 are empty. Each card has on it a single digit in the range [1..9], so that the line of cards makes up a number.
You wish to place the cards on table3 so that they make as large a number as possible. You are allowed the following moves.
a) Take the rightmost card from table1 and place it at the rightmost end of the cards on table3.
b) Take the rightmost card from table1 and place it at the rightmost end of the cards on table2.
c) Take the rightmost card from table2 and place it at the rightmost end of the cards on table3.
For instance if 869 was on table1, then the sequence of moves abac would give the number 986 on table3. If 8679 was on table 1, then the sequence of moves abac would give the number 9687 on table 3. Note you can do better than that in this example.
Examples
input: 869 -> output: 986
input: 8679 -> output: 9867

[Non-text portions of this message have been removed]
• Firstly thank you to all who responded to my posting on a simplicty measure. Several valid and useful points were made. Rather than respond to them all
Message 2 of 24 , Jul 1, 2005
• 0 Attachment
Firstly thank you to all who responded to my posting on a simplicty measure.
Several valid and useful points were made. Rather than respond to them all individually, I will put several responses in the one posting.

Firstly let me remind you that these are beginning students. Some have no experience in programming when they start. This is just their first semester of a 3 year degree. Their assignments are small, but can be challenging for them.

Maintainability
Some suggested that there should be an emphasis on maintainability.
I totally agree with this, and there is. It is one of Bertrand Meyer's "External" quality factors. Things like simplicity, names, constants, etc are "internal" quality factors which help support the external ones. Emphasising these helps push the students in the right direction.

The measure is simplistic
I agree. But it is transparent and accessible to the students. It won't take them very far, but I do think it will help at their level.

The four XP rules of simplicity:
1) Runs all the tests
2) Reveals all the intention.
3) No duplication.
4) Fewest number of classes or methods or functions.
Thank you for reminding me of this. I will use it.
But in the context of my subject, a low count on the simplicity measure will help with 2) 3) and 4). And as for 1), if a student's assignments do not pass all my tests it has to be fixed it up and resubmitted.

Consensus marking
An idea I like very much, but difficult to implement. The assignments are a bit too complex and the solutions so varied and the students too inexperienced for it to be viable. However I do get students to vote on different solutions in class. It works well and I will do more of it.

Bonus marks for simplicity
Another idea I like very much, and will adopt. I already give bonus questions which the keener ones do, but hadn't thought of doing it within an assignment.

max = max(max(a, b), c) has a score of 0
Yes. I can live with that. If they get in the habit of looking for library functions I am delighted.

Compound Booleans
Someone pointed out that median(a,b,c):
if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
return b;
if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
return c;
return a;
has a score of 2.
I had not decided whether to have extra points for compound Booleans. So I waited to see if there were any comments. I do find the above solution easier to read than, for example
one = a
two = b
three = c
if (one > two) // swap one and two
if (one > three) // swap one and three
if (two > three) // swap two and three
return two
The former has a flavour of the "guards" approach in functional programming. It could clearly get out of hand, although there are other marks for style.

Refactoring
No-one mentioned refactoring. But consider from the point of view of a student. They have the program working - passes all tests. Rather than leave it at that, they go for extra simplicity marks, which gives them their first experience of refactoring. Could be valuable.

A final comment
One of the tasks of a lecturer is to get the students' attention. We have to compete with girl (boy) friends, part time work, footy training, other subjects, family, etc. We put a lot of effort into giving feedback, and I devote time to discussing the asssignment when they get them back, but all too often all they look at is the final mark. An advantage of this approach, I hope, would be to get their attention at the right time.

Thanks again,
David

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com]On Behalf Of Clark, David
> Sent: Wednesday, 29 June 2005 4:00 PM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] KISS
>
>
> This isn't strictly XP, but as a group you are so helpful and
> interested in programming that I am sure some of you will
> take an interest in this. Apologies to the others.
>
> I teach an introductory programming subject to students who
> are doing a more technically oriented IT course. The language
> of implementation is C, under Linux. (These students also do
> another, gentler, introductory programming subject using VB
> .NET.) The subject is highly algorithmic. It has a high
> emphasis on testing.
>
> As part of my end of semester reflection, I think that some
> things work well. At the end of the subject they can code
> quite well, they understand testing, and they have had to
> develop a number of interesting algorithms. One area,
> however, that is generally not done well is simplicity. Their
> code works, but it is often a lot more complex than it needs
> to be. Especially if the algorithm is a bit difficult.
>
> Students adapt to how assignments are marked. So I am
> thinking that next time I run it I will try to incorporate a
> "simplicity" component in my marking scheme. Here is the
> idea. Award 10 marks (points if you are US), say, for
> simplicity in each assignment question. Then they would get
> simplicity marks from the formula
> 10 * base_simplicity_measure / their_simplicity_measure
> where base_simplicity_measure is the simplicity measure on my
> solution.
>
> So what to use for the simplicity measure?
> It must be simple, effective, and appropriate for beginning students.
> Here is my suggestion (aim is to be as low as possible) :
> 1 point for each IF
> 2 points for each IF .. ELSE or case (or conditional).
> 1 point for a loop
> When a loop or selection statement is nested [1, 2, 3,
> ...] deep, there are additional [1, 3, 5, ...] points.
>
> The hoped-for benefits of having this component in their marks include
> more emphasis on simplicity
> an awareness that there are other solutions than the
> one they first come up with
> encourages modularity
> encourages use of library functions
> students start to learn about refactoring
>
> I would appreciate any comments you have on this idea,
> thanks,
> David
>
>
> ============ Examples ============
> Example 1: Max of 3 numbers (a very early illustrative
> example, before they have done loops).
> if (a > b)
> if (a > c)
> max = a
> else
> max = c
> end
> else
> if (b > c)
> max = b
> else
> max = c
> end
> end
> This gives a simplicity measure of 8. An experienced
> programmer would generate a solution with a simplicity measure of 2.
>
> Example 2: Median of 3 numbers (again a very early
> illustrative example, before they have done loops).
> This is a fun example in class, as most students' solutions
> have holes in them. Finding examples where students'
> solutions fail reinforces testing. Students' solutions are
> certainly not simple.
> In this case the base simplicity measure is 3.
>
> Example 3: A real example. A question from the students'
> final assignment.
> The base simplicity measure for this question is 10.
> Card Shuffle
> You have 3 tables, table 1, table2 and table3. There is a
> line of cards on table1. Table2 and table3 are empty. Each
> card has on it a single digit in the range [1..9], so that
> the line of cards makes up a number.
> You wish to place the cards on table3 so that they make as
> large a number as possible. You are allowed the following moves.
> a) Take the rightmost card from table1 and place it at the
> rightmost end of the cards on table3.
> b) Take the rightmost card from table1 and place it at the
> rightmost end of the cards on table2.
> c) Take the rightmost card from table2 and place it at the
> rightmost end of the cards on table3.
> For instance if 869 was on table1, then the sequence of moves
> abac would give the number 986 on table3. If 8679 was on
> table 1, then the sequence of moves abac would give the
> number 9687 on table 3. Note you can do better than that in
> this example.
> Examples
> input: 869 -> output: 986
> input: 8679 -> output: 9867
>
>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
>
• ... Cool. Your time permitting, I have a feeling that there s more to learn from this topic. ... Yes ... this makes it important to set these students on the
Message 3 of 24 , Jul 1, 2005
• 0 Attachment
On Friday, July 1, 2005, at 4:00:33 AM, Clark, David wrote:

> Firstly thank you to all who responded to my posting on a
> simplicty measure. Several valid and useful points were made.
> Rather than respond to them all individually, I will put several
> responses in the one posting.

Cool. Your time permitting, I have a feeling that there's more to
learn from this topic.

> Firstly let me remind you that these are beginning students. Some
> have no experience in programming when they start. This is just
> their first semester of a 3 year degree. Their assignments are
> small, but can be challenging for them.

Yes ... this makes it important to set these students on the right
path. While whatever is done needs to be simple, it seems to me that
it is at least equally important that it should be right. Simple,
but right.

> Maintainability

> Some suggested that there should be an emphasis on
> maintainability. I totally agree with this, and there is. It is
> one of Bertrand Meyer's "External" quality factors. Things like
> simplicity, names, constants, etc are "internal" quality factors
> which help support the external ones. Emphasising these helps push
> the students in the right direction.

Yes. Those are important. The sooner we begin to teach them
about beauty and other intangibles, the sooner they'll learn them.

A pal of mine was reminding me last night that young violin students
in the Suzuki method begin by listening to music, over and over
again. This makes me even more interested in the code reading
aspects of the group scoring ideas we've discussed.

> The measure is simplistic

> I agree. But it is transparent and accessible to the students. It
> won't take them very far, but I do think it will help at their
> level.

It might. However, consider this code:

for (i = 0; i < 4; i++) {
score[i] = 0;
}

If I understand them, the rules say that this is more simple:

score[0] = 0;
score[1] = 0;
score[2] = 0;
score[3] = 0;

I don't think so. And I'd think so even less if we had i < 144.

This leads me to believe that a clever enough programmer could
reduce complexity by writing clever code. Another example:

if (roll[frame] == 10)
frame++;
else
frame += 2;

can be replaced, in C, by

frame += 2 - (roll[frame] == 10);

Simpler? I think not.

I was always a bit of a troublemaker in class. If I were in there,
and was getting moderately good at programming, I'd be working with
the other smart kids to create programs that were really hideous but
that got really good scores according to the rules.

We'd still learn a lot ... but I'm not sure it would be the right
things.

That makes me think that maybe I'd offer some kind of bonus for
demonstrating the kind of understanding it would take to write a
high-scoring program that is obviously not simple.

> The four XP rules of simplicity:
> 1) Runs all the tests
> 2) Reveals all the intention.
> 3) No duplication.
> 4) Fewest number of classes or methods or functions.
> Thank you for reminding me of this. I will use it.

... reordering ...

> And as for 1), if a student's assignments do not pass all my tests
> it has to be fixed it up and resubmitted.

Excellent. This is super.

> But in the context of my subject, a low count on the simplicity
> measure will help with 2) 3) and 4).

I'm not entirely sure. Here's some counterpoint, item by item:

> 2) Reveals all the intention.

Here I'm very not sure. The examples above reveal less intention in
their higher-scoring forms, it seems to me. I can always remove a
for statement by unrolling the loop, for loops of known duration.
It's never simpler.

I can often remove an if statement by using a calculation instead,
again with lose of true simplicity.

> 3) No duplication.

Here again I'm not so sure. Unrolling a loop improves my score but
increases duplication.

> 4) Fewest number of classes or methods or functions.

Yes ... but this rule only adds to simplicity if the other two above
are met.

> Consensus marking

> An idea I like very much, but difficult to implement. The
> assignments are a bit too complex and the solutions so varied and
> the students too inexperienced for it to be viable. However I do
> get students to vote on different solutions in class. It works
> well and I will do more of it.

Yes ... I'd think that this would get them thinking about ideas
other than their own. I might spend a lot of time drawing them out
on this. Some might not participate, and that would be too bad. But
the ones who do would really prosper and those who listen would get
something too.

> Bonus marks for simplicity

> Another idea I like very much, and will adopt. I already give
> bonus questions which the keener ones do, but hadn't thought of
> doing it within an assignment.

> max = max(max(a, b), c) has a score of 0
> Yes. I can live with that. If they get in the habit of looking
> for library functions I am delighted.

Arrgh. This is the path of the dark side. It leads toward cryptic
code, and ultimately the fate of the Empire will be in the hands of
these youths.

> Compound Booleans
> Someone pointed out that median(a,b,c):
> if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
> return b;
> if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
> return c;
> return a;
> has a score of 2.
> I had not decided whether to have extra points for compound
> Booleans. So I waited to see if there were any
> comments. I do find the above solution easier to read than, for example
> one = a
> two = b
> three = c
> if (one > two) // swap one and two
> if (one > three) // swap one and three
> if (two > three) // swap two and three
> return two

Do you really find it easier to read? Are you sure it's right? Will
a student be sure it's right?

I don't find either one particularly easy.

If I were looking for a simpler way to do that one, I might go down
this path and see what happens:

if ( a < b && b < c) return b;

And there's my favorite approach, roughly

^(Array with: a with: b with: c) sorted at: 2

> Refactoring

> No-one mentioned refactoring. But consider from the point of
> view of a student. They have the program
> working - passes all tests. Rather than leave it at that, they
> go for extra simplicity marks, which gives
> them their first experience of refactoring. Could be valuable.

Yes, and indeed that's probably how they /should/ do it. I think I
might actually teach / recommend that to them.

> A final comment

> One of the tasks of a lecturer is to get the students' attention.
> We have to compete with girl (boy) friends, part time work, footy
> training, other subjects, family, etc. We put a lot of effort into
> giving feedback, and I devote time to discussing the asssignment
> when they get them back, but all too often all they look at is the
> final mark. An advantage of this approach, I hope, would be to get
> their attention at the right time.

These observations would seem also to favor the more participative
notions.

This is fun. Thanks for bringing it up!

Ron Jeffries
www.XProgramming.com
You are to act in the light of experience as guided by intelligence.
-- Nero Wolfe
• This thread has been quite comprehensive, yet there is one more angle worth considering. Because grading has a subjective component, I would have a
Message 4 of 24 , Jul 1, 2005
• 0 Attachment
This thread has been quite comprehensive, yet there is one more angle worth
considering.

Because grading has a subjective component, I would have a conversation with
subjective components. More than one teacher because you may find as many
opinions as people interviewed. Some may have good ideas.

Victor
• Hi Ron, ... Interesting parallel. I was only four years old, and don t really remember this, but my father told me that: 1) The method involves listening /then
Message 5 of 24 , Jul 1, 2005
• 0 Attachment
Hi Ron,

> A pal of mine was reminding me last night that young
> violin students in the Suzuki method begin by
> listening to music, over and over again. This makes
> me even more interested in the code reading aspects
> of the group scoring ideas we've discussed.

Interesting parallel. I was only four years old, and
don't really remember this, but my father told me that:

1) The method involves listening /then reproducing/, in
very short cycles. So pair programming might actually
be a closer match than peer review.

2) My teacher of course played very well, with a
vibrato and so on. Apparently I refused to cooperate,
claiming that she knew very well I couldn't possibly
reproduce that. Not sure what conclusion to draw from
something about learning most from pairing with someone
with more experience, but not too much? Now that I've
grown up, I would welcome any opportunity to pair with
a genius... though maybe not all the time.

Cheers,

Dominic Williams
http://www.dominicwilliams.net

----
• Ron: You say: max((max(a,b),c) is a path to the dark side, (actually, in APL or J, I d say max/a b c ), ... Which looks a lot like the J solution: 1{/:~a,b,c
Message 6 of 24 , Jul 1, 2005
• 0 Attachment
Ron:

You say:

max((max(a,b),c)

is a path to the dark side, (actually, in APL or J, I'd say "max/a b c"),
yet you promote a phrase like:

> ^(Array with: a with: b with: c) sorted at: 2

Which looks a lot like the J solution:

1{/:~a,b,c

It's an interesting if paradoxical perspective.

All power is not in the dark side.

Later...
-----------------------------------------------------------------------
|\/| Randy A MacDonald | you can't pay for it,
|\\| randymacdo@... | even if you want to.
BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done..
Natural Born APL'er | demo website: http://69.193.255.224/
------------------------------------------------------------{ gnat }-

----- Original Message -----
From: "Ron Jeffries" <ronjeffries@...>
To: <extremeprogramming@yahoogroups.com>
Sent: Friday, July 01, 2005 8:26 AM
Subject: Re: [XP] KISS

> On Friday, July 1, 2005, at 4:00:33 AM, Clark, David wrote:
>
> > Firstly thank you to all who responded to my posting on a
> > simplicty measure. Several valid and useful points were made.
> > Rather than respond to them all individually, I will put several
> > responses in the one posting.
>
> Cool. Your time permitting, I have a feeling that there's more to
> learn from this topic.
>
> > Firstly let me remind you that these are beginning students. Some
> > have no experience in programming when they start. This is just
> > their first semester of a 3 year degree. Their assignments are
> > small, but can be challenging for them.
>
> Yes ... this makes it important to set these students on the right
> path. While whatever is done needs to be simple, it seems to me that
> it is at least equally important that it should be right. Simple,
> but right.
>
> > Maintainability
>
> > Some suggested that there should be an emphasis on
> > maintainability. I totally agree with this, and there is. It is
> > one of Bertrand Meyer's "External" quality factors. Things like
> > simplicity, names, constants, etc are "internal" quality factors
> > which help support the external ones. Emphasising these helps push
> > the students in the right direction.
>
> Yes. Those are important. The sooner we begin to teach them
> about beauty and other intangibles, the sooner they'll learn them.
>
> A pal of mine was reminding me last night that young violin students
> in the Suzuki method begin by listening to music, over and over
> again. This makes me even more interested in the code reading
> aspects of the group scoring ideas we've discussed.
>
> > The measure is simplistic
>
> > I agree. But it is transparent and accessible to the students. It
> > won't take them very far, but I do think it will help at their
> > level.
>
> It might. However, consider this code:
>
> for (i = 0; i < 4; i++) {
> score[i] = 0;
> }
>
> If I understand them, the rules say that this is more simple:
>
> score[0] = 0;
> score[1] = 0;
> score[2] = 0;
> score[3] = 0;
>
> I don't think so. And I'd think so even less if we had i < 144.
>
> This leads me to believe that a clever enough programmer could
> reduce complexity by writing clever code. Another example:
>
> if (roll[frame] == 10)
> frame++;
> else
> frame += 2;
>
> can be replaced, in C, by
>
> frame += 2 - (roll[frame] == 10);
>
> Simpler? I think not.
>
> I was always a bit of a troublemaker in class. If I were in there,
> and was getting moderately good at programming, I'd be working with
> the other smart kids to create programs that were really hideous but
> that got really good scores according to the rules.
>
> We'd still learn a lot ... but I'm not sure it would be the right
> things.
>
> That makes me think that maybe I'd offer some kind of bonus for
> demonstrating the kind of understanding it would take to write a
> high-scoring program that is obviously not simple.
>
> > The four XP rules of simplicity:
> > 1) Runs all the tests
> > 2) Reveals all the intention.
> > 3) No duplication.
> > 4) Fewest number of classes or methods or functions.
> > Thank you for reminding me of this. I will use it.
>
> ... reordering ...
>
> > And as for 1), if a student's assignments do not pass all my tests
> > it has to be fixed it up and resubmitted.
>
> Excellent. This is super.
>
> > But in the context of my subject, a low count on the simplicity
> > measure will help with 2) 3) and 4).
>
> I'm not entirely sure. Here's some counterpoint, item by item:
>
> > 2) Reveals all the intention.
>
> Here I'm very not sure. The examples above reveal less intention in
> their higher-scoring forms, it seems to me. I can always remove a
> for statement by unrolling the loop, for loops of known duration.
> It's never simpler.
>
> I can often remove an if statement by using a calculation instead,
> again with lose of true simplicity.
>
> > 3) No duplication.
>
> Here again I'm not so sure. Unrolling a loop improves my score but
> increases duplication.
>
> > 4) Fewest number of classes or methods or functions.
>
> Yes ... but this rule only adds to simplicity if the other two above
> are met.
>
> > Consensus marking
>
> > An idea I like very much, but difficult to implement. The
> > assignments are a bit too complex and the solutions so varied and
> > the students too inexperienced for it to be viable. However I do
> > get students to vote on different solutions in class. It works
> > well and I will do more of it.
>
> Yes ... I'd think that this would get them thinking about ideas
> other than their own. I might spend a lot of time drawing them out
> on this. Some might not participate, and that would be too bad. But
> the ones who do would really prosper and those who listen would get
> something too.
>
> > Bonus marks for simplicity
>
> > Another idea I like very much, and will adopt. I already give
> > bonus questions which the keener ones do, but hadn't thought of
> > doing it within an assignment.
>
> > max = max(max(a, b), c) has a score of 0
> > Yes. I can live with that. If they get in the habit of looking
> > for library functions I am delighted.
>
> Arrgh. This is the path of the dark side. It leads toward cryptic
> code, and ultimately the fate of the Empire will be in the hands of
> these youths.
>
> > Compound Booleans
> > Someone pointed out that median(a,b,c):
> > if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
> > return b;
> > if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
> > return c;
> > return a;
> > has a score of 2.
> > I had not decided whether to have extra points for compound
> > Booleans. So I waited to see if there were any
> > comments. I do find the above solution easier to read than, for example
> > one = a
> > two = b
> > three = c
> > if (one > two) // swap one and two
> > if (one > three) // swap one and three
> > if (two > three) // swap two and three
> > return two
>
> Do you really find it easier to read? Are you sure it's right? Will
> a student be sure it's right?
>
> I don't find either one particularly easy.
>
> If I were looking for a simpler way to do that one, I might go down
> this path and see what happens:
>
> if ( a < b && b < c) return b;
>
> And there's my favorite approach, roughly
>
> ^(Array with: a with: b with: c) sorted at: 2
>
> > Refactoring
>
> > No-one mentioned refactoring. But consider from the point of
> > view of a student. They have the program
> > working - passes all tests. Rather than leave it at that, they
> > go for extra simplicity marks, which gives
> > them their first experience of refactoring. Could be valuable.
>
> Yes, and indeed that's probably how they /should/ do it. I think I
> might actually teach / recommend that to them.
>
> > A final comment
>
> > One of the tasks of a lecturer is to get the students' attention.
> > We have to compete with girl (boy) friends, part time work, footy
> > training, other subjects, family, etc. We put a lot of effort into
> > giving feedback, and I devote time to discussing the asssignment
> > when they get them back, but all too often all they look at is the
> > final mark. An advantage of this approach, I hope, would be to get
> > their attention at the right time.
>
> These observations would seem also to favor the more participative
> notions.
>
> This is fun. Thanks for bringing it up!
>
> Ron Jeffries
> www.XProgramming.com
> You are to act in the light of experience as guided by intelligence.
> -- Nero Wolfe
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
• ... of a student. They have the program working - passes all tests. Rather than leave it at that, they go for extra simplicity marks, which gives them their
Message 7 of 24 , Jul 1, 2005
• 0 Attachment
--- In extremeprogramming@yahoogroups.com, "Clark, David"
<david.clark@c...> wrote:
>
> Refactoring
> No-one mentioned refactoring. But consider from the point of view
of a student. They have the program working - passes all tests.
Rather than leave it at that, they go for extra simplicity marks,
which gives them their first experience of refactoring. Could be
valuable.
>
> Thanks again,
> David
>
>

You guys are ignoring me again! :-) I know, leave the mad man alone
and he will quietly go away!

I responded saying one should use refactoring and defense.

http://groups.yahoo.com/group/extremeprogramming/message/108471

Now that you have shown some examples and discussed it with them make
simplicity score of some kind and write it on their code printout.
Have each student then write on the code printout a justification for
why the feel it is simple OR let them refactor the solution for
another attempt. If they take the justification approach re-grade the
solution and send it back. Granted you might give it the same grade
as before. They can justify again or refactor. If the take the
refactoring approach re-grade the solution and send it back. Continue
this iterative approach until the student gets a grade they are
satisfied with or the semester ends.

Well, back to making hash marks on the prison wall with my piece of
chalk in my teeth. This white jacket is very uncomfortable.
• ... BUT I DID! Oooo Oooooo Oooooo, Mr. Kotter! http://groups.yahoo.com/group/extremeprogramming/message/108471 Now that you have shown some examples and
Message 8 of 24 , Jul 1, 2005
• 0 Attachment
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<ronjeffries@X...> wrote:
> On Friday, July 1, 2005, at 4:00:33 AM, Clark, David wrote:
>
> > Refactoring
>
> > No-one mentioned refactoring. But consider from the point of
> > view of a student. They have the program
> > working - passes all tests. Rather than leave it at that, they
> > go for extra simplicity marks, which gives
> > them their first experience of refactoring. Could be valuable.
>
> Yes, and indeed that's probably how they /should/ do it. I think I
> might actually teach / recommend that to them.
>
>
> Ron Jeffries

BUT I DID! Oooo Oooooo Oooooo, Mr. Kotter!

http://groups.yahoo.com/group/extremeprogramming/message/108471

Now that you have shown some examples and discussed it with them make
simplicity score of some kind and write it on their code printout.
Have each student then write on the code printout a justification for
why the feel it is simple OR let them refactor the solution for
another attempt. If they take the justification approach re-grade the
solution and send it back. Granted you might give it the same grade
as before. They can justify again or refactor. If the take the
refactoring approach re-grade the solution and send it back. Continue
this iterative approach until the student gets a grade they are
satisfied with or the semester ends.
• This might be feasible with a small enough class (
Message 9 of 24 , Jul 1, 2005
• 0 Attachment
This might be feasible with a small enough class (< 20?), or a larger class with TAs whose judgement can be trusted. Otherwise, it is too impractical given the resource overloading in schools today.

One could cut the load in half by having the students do their assignments in pairs (seems more fair if each student works with a different student on each assignment).

-----Original Message-----
From: extremeprogramming@yahoogroups.com on behalf of SirGilligan
Sent: Fri 7/1/2005 8:27 AM
To: extremeprogramming@yahoogroups.com
Cc:
Subject: Re: [XP] KISS

--- In extremeprogramming@yahoogroups.com, "Clark, David"
<david.clark@c...> wrote:
>
> Refactoring
> No-one mentioned refactoring. But consider from the point of view
of a student. They have the program working - passes all tests.
Rather than leave it at that, they go for extra simplicity marks,
which gives them their first experience of refactoring. Could be
valuable.
>
> Thanks again,
> David
>
>

You guys are ignoring me again! :-) I know, leave the mad man alone
and he will quietly go away!

I responded saying one should use refactoring and defense.

http://groups.yahoo.com/group/extremeprogramming/message/108471

Now that you have shown some examples and discussed it with them make
simplicity score of some kind and write it on their code printout.
Have each student then write on the code printout a justification for
why the feel it is simple OR let them refactor the solution for
another attempt. If they take the justification approach re-grade the
solution and send it back. Granted you might give it the same grade
as before. They can justify again or refactor. If the take the
refactoring approach re-grade the solution and send it back. Continue
this iterative approach until the student gets a grade they are
satisfied with or the semester ends.

Well, back to making hash marks on the prison wall with my piece of
chalk in my teeth. This white jacket is very uncomfortable.

[Non-text portions of this message have been removed]
• ... I promote that as a potential path to the dark side, too. The point of my note was that the simplicity rules, when subverted, lead to dogs and cats living
Message 10 of 24 , Jul 1, 2005
• 0 Attachment
On Friday, July 1, 2005, at 10:37:34 AM, Randy MacDonald wrote:

> You say:

> max((max(a,b),c)

> is a path to the dark side, (actually, in APL or J, I'd say "max/a b c"),
> yet you promote a phrase like:

> > ^(Array with: a with: b with: c) sorted at: 2

I promote that as a potential path to the dark side, too. The point
of my note was that the simplicity rules, when subverted, lead to
dogs and cats living together.

> Which looks a lot like the J solution:

> 1{/:~a,b,c

> It's an interesting if paradoxical perspective.

> All power is not in the dark side.

My eyes don't turn yellow. Would be a good trick, tho ...

Ron Jeffries
www.XProgramming.com
I'm not bad, I'm just drawn that way. -- Jessica Rabbit
• ... Or the simplest form: memset( score, 0, sizeof(score) ); Would that score high for simplicity, or low for obscurity? To an experienced programmer, it is
Message 11 of 24 , Jul 1, 2005
• 0 Attachment
Ron Jeffries wrote:

>>I agree. But it is transparent and accessible to the students. It
>>won't take them very far, but I do think it will help at their
>>level.
>>
>>
>
>It might. However, consider this code:
>
>for (i = 0; i < 4; i++) {
> score[i] = 0;
>}
>
>If I understand them, the rules say that this is more simple:
>
>score[0] = 0;
>score[1] = 0;
>score[2] = 0;
>score[3] = 0;
>
>I don't think so. And I'd think so even less if we had i < 144.
>
>
>
Or the simplest form:

memset( score, 0, sizeof(score) );

Would that score high for simplicity, or low for obscurity?

To an experienced programmer, it is clear, efficient and concise, to a
novice more than a little cryptic. The joys of C.

Ian
• In C, C++, Java: int score[4] = { 0,0,0,0 }; ... -- C. Keith Ray
Message 12 of 24 , Jul 2, 2005
• 0 Attachment
In C, C++, Java:

int score[4] = { 0,0,0,0 };

On Jul 1, 2005, at 3:09 PM, Ian Collins wrote:

> Ron Jeffries wrote:
>
>>> I agree. But it is transparent and accessible to the students. It
>>> won't take them very far, but I do think it will help at their
>>> level.
>>>
>>>
>>
>> It might. However, consider this code:
>>
>> for (i = 0; i < 4; i++) {
>> score[i] = 0;
>> }
>>
>> If I understand them, the rules say that this is more simple:
>>
>> score[0] = 0;
>> score[1] = 0;
>> score[2] = 0;
>> score[3] = 0;
>>
>> I don't think so. And I'd think so even less if we had i < 144.
>>
>>
>>
> Or the simplest form:
>
> memset( score, 0, sizeof(score) );
>
> Would that score high for simplicity, or low for obscurity?
>
> To an experienced programmer, it is clear, efficient and concise, to a
> novice more than a little cryptic. The joys of C.
>
> Ian
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
>
--
C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>

[Non-text portions of this message have been removed]
• Keith, ... And in ruby: score = [0] * 4 Hmm, yummy. :) Is that obscure ? It will read just as well when there are 4, 16 or 256. ... It is, perhaps, the above
Message 13 of 24 , Jul 2, 2005
• 0 Attachment
Keith,

> int score[4] = { 0,0,0,0 };

And in ruby:

score = [0] * 4

Hmm, yummy. :) Is that obscure ? It will read just as well when there
are 4, 16 or 256.

Ian wrote:

> memset( score, 0, sizeof(score) );
> To an experienced programmer, it is clear, efficient and concise

It is, perhaps, the above things to a programmer experienced *in C*.
To people with years of COBOL experience it won't mean nothing.

Cheers,

-[Laurent]-
Error : keyboard missing ! Press F1 to continue.
• To people with years in COBOL? 01 WS-SCORE PIC X OCCURS 4 VALUE ZEROES. Of course, a period ( . ) in COBOL means a whole other thing than with everybody else.
Message 14 of 24 , Jul 3, 2005
• 0 Attachment
To people with years in COBOL?

01 WS-SCORE PIC X OCCURS 4 VALUE ZEROES.

Of course, a period (".") in COBOL means a whole other thing than with
everybody else.

-Jonjon

On 7/2/05, Laurent Bossavit <laurent@...> wrote:
>
> Keith,
>
> > int score[4] = { 0,0,0,0 };
>
> And in ruby:
>
> score = [0] * 4
>
> Hmm, yummy. :) Is that obscure ? It will read just as well when there
> are 4, 16 or 256.
>
> Ian wrote:
>
> > memset( score, 0, sizeof(score) );
> > To an experienced programmer, it is clear, efficient and concise
>
> It is, perhaps, the above things to a programmer experienced *in C*.
> To people with years of COBOL experience it won't mean nothing.
>
> Cheers,
>
> -[Laurent]-
> Error : keyboard missing ! Press F1 to continue.
>
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
> ad-free courtesy of objectmentor.com <http://objectmentor.com>
>
>
>
>
>
>
>

[Non-text portions of this message have been removed]
• From: Jonjon Limjap To: extremeprogramming@yahoogroups.com
Message 15 of 24 , Jul 3, 2005
• 0 Attachment
From: "Jonjon Limjap" <jonlimjap.at.gmail.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, July 03, 2005 6:14 PM
Subject: Re: [XP] KISS

> To people with years in COBOL?
>
> 01 WS-SCORE PIC X OCCURS 4 VALUE ZEROES.
>
> Of course, a period (".") in COBOL means a whole other thing than with
> everybody else.

I think that

01 WS-SCORE COMP OCCURS 4 VALUE ZEROES.

is likely to be closer to the other ones. Of course,
no modern COBOL requires all upper case, either.

John Roth

>
> -Jonjon
>
> On 7/2/05, Laurent Bossavit <laurent@...> wrote:
>>
>> Keith,
>>
>> > int score[4] = { 0,0,0,0 };
>>
>> And in ruby:
>>
>> score = [0] * 4
>>
>> Hmm, yummy. :) Is that obscure ? It will read just as well when there
>> are 4, 16 or 256.
>>
>> Ian wrote:
>>
>> > memset( score, 0, sizeof(score) );
>> > To an experienced programmer, it is clear, efficient and concise
>>
>> It is, perhaps, the above things to a programmer experienced *in C*.
>> To people with years of COBOL experience it won't mean nothing.
>>
>> Cheers,
>>
>> -[Laurent]-
>> Error : keyboard missing ! Press F1 to continue.
>>
>>
>>
>>
>> To Post a message, send it to: extremeprogramming@...
>>
>> To Unsubscribe, send a blank message to:
>> extremeprogramming-unsubscribe@...
>>
>> ad-free courtesy of objectmentor.com <http://objectmentor.com>
>>
>>
>>
>>
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
>
>
>
>
>
>
>
• Oops. You re right... And I meant that to be PIC 9. Yup, am using COBOL 85. Wreaks the head when you switch between that and C#, especially when simplicity
Message 16 of 24 , Jul 3, 2005
• 0 Attachment
Oops. You're right... And I meant that to be PIC 9.

Yup, am using COBOL 85. Wreaks the head when you switch between that and C#,
especially when "simplicity" is of utmost importance. From my experience
simplicity has different meanings in spaghetti, method-driven and OOP
models.

On 7/4/05, yahoogroups@... <yahoogroups@...> wrote:
>
> From: "Jonjon Limjap" <jonlimjap.at.gmail.com@...>
> To: "extremeprogramming@yahoogroups.com"
> <extremeprogramming.at.yahoogroups.com@...>
> Sent: Sunday, July 03, 2005 6:14 PM
> Subject: Re: [XP] KISS
>
>
> > To people with years in COBOL?
> >
> > 01 WS-SCORE PIC X OCCURS 4 VALUE ZEROES.
> >
> > Of course, a period (".") in COBOL means a whole other thing than with
> > everybody else.
>
> I think that
>
> 01 WS-SCORE COMP OCCURS 4 VALUE ZEROES.
>
> is likely to be closer to the other ones. Of course,
> no modern COBOL requires all upper case, either.
>
> John Roth
>
> >
> > -Jonjon
> >
> > On 7/2/05, Laurent Bossavit <laurent@...> wrote:
> >>
> >> Keith,
> >>
> >> > int score[4] = { 0,0,0,0 };
> >>
> >> And in ruby:
> >>
> >> score = [0] * 4
> >>
> >> Hmm, yummy. :) Is that obscure ? It will read just as well when there
> >> are 4, 16 or 256.
> >>
> >> Ian wrote:
> >>
> >> > memset( score, 0, sizeof(score) );
> >> > To an experienced programmer, it is clear, efficient and concise
> >>
> >> It is, perhaps, the above things to a programmer experienced *in C*.
> >> To people with years of COBOL experience it won't mean nothing.
> >>
> >> Cheers,
> >>
> >> -[Laurent]-
> >> Error : keyboard missing ! Press F1 to continue.
> >>
> >>
> >>
> >>
> >> To Post a message, send it to: extremeprogramming@...
> >>
> >> To Unsubscribe, send a blank message to:
> >> extremeprogramming-unsubscribe@...
> >>
> >> ad-free courtesy of objectmentor.com <http://objectmentor.com> <
> http://objectmentor.com>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > To Post a message, send it to: extremeprogramming@...
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@...
> >
> > ad-free courtesy of objectmentor.com <http://objectmentor.com>
> >
> >
> >
> >
> >
> >
> >
>
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
> ad-free courtesy of objectmentor.com <http://objectmentor.com>
>
>
>
>
>
>
>

[Non-text portions of this message have been removed]
• ... Looks right for C/C++. But in Java, I think you can only do new int [4] -- when allocating without initializing. So in Java, it s: int score[] =
Message 17 of 24 , Jul 4, 2005
• 0 Attachment
--- Keith Ray <keithray@m...> wrote:
> In C, C++, Java:
>
> int score[4] = { 0,0,0,0 };

Looks right for C/C++. But in Java, I think you can only do "new int
[4]" -- when allocating without initializing. So in Java, it's:

int score[] = {0,0,0,0};
or
int[] scores = {0,0,0,0};
• ... Of course, COBOL *PROGRAMMERS* may require all upper case. (I wrote some FORTRAN once in all lower case. The project manager went ballistic. ;- But it
Message 18 of 24 , Jul 4, 2005
• 0 Attachment
--- yahoogroups@j... wrote:
> [...] Of course, no modern COBOL requires all upper case, either.

Of course, COBOL *PROGRAMMERS* may require all upper case.

(I wrote some FORTRAN once in all lower case. The project manager
went ballistic. ;-> But it was trivial to translate it to ALL UPPER
CASE with a CP/M PIP command. (And it would be easy in Unix too.))
• ... I had a colleague whose marking guide to his tutors was 1/3 for correctness, 1/3 for programming and 1/3 for elegance . Worked OK, with the right tutors.
Message 19 of 24 , Jul 5, 2005
• 0 Attachment
> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com]On Behalf Of Ron Jeffries
> Sent: Friday, 1 July 2005 10:26 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] KISS
>
>
> On Friday, July 1, 2005, at 4:00:33 AM, Clark, David wrote:

> > Maintainability
>
> > Some suggested that there should be an emphasis on
> > maintainability. I totally agree with this, and there is. It is
> > one of Bertrand Meyer's "External" quality factors. Things like
> > simplicity, names, constants, etc are "internal" quality factors
> > which help support the external ones. Emphasising these helps push
> > the students in the right direction.
>
> Yes. Those are important. The sooner we begin to teach them
> about beauty and other intangibles, the sooner they'll learn them.
I had a colleague whose marking guide to his tutors was "1/3 for correctness, 1/3 for programming and 1/3 for elegance". Worked OK, with the right tutors. The language was Prolog.
>
> > The measure is simplistic
>
> > I agree. But it is transparent and accessible to the students. It
> > won't take them very far, but I do think it will help at their
> > level.
>
> It might. However, consider this code:
>
> for (i = 0; i < 4; i++) {
> score[i] = 0;
> }
>
> If I understand them, the rules say that this is more simple:
>
> score[0] = 0;
> score[1] = 0;
> score[2] = 0;
> score[3] = 0;
>
> I don't think so. And I'd think so even less if we had i < 144.
Agreed. All along I have been concerned with "play the rules" vs "play the game". I was hoping that playing the rules would be enough to ensure playing the game, but will change their use to
a) bonus marks for simplicity (as before)
b) "based on" the simplicity measure
This gives me flexibility to stomp on things like unrolling loops.
>
> I was always a bit of a troublemaker in class. If I were in there,
> and was getting moderately good at programming, I'd be working with
> the other smart kids to create programs that were really hideous but
> that got really good scores according to the rules.
I'd like to have a few more troublemakers of your ability. There are too many students who enrol in a computing degree having no experience in programming and little ability. Mind you, I have a daughter doing a marine science degree who thought marine science was cuddling dolphins.
>
>
> > But in the context of my subject, a low count on the simplicity
> > measure will help with 2) 3) and 4).
>
> I'm not entirely sure. Here's some counterpoint, item by item:
>
> > 2) Reveals all the intention.
>
> Here I'm very not sure. The examples above reveal less intention in
> their higher-scoring forms, it seems to me. I can always remove a
> for statement by unrolling the loop, for loops of known duration.
> It's never simpler.
True at the micro level (see above), but having marked many assignments, I am convinced that the ones which reveal their intention best would have a low simplicity measure.
>
> > 3) No duplication.
>
> Here again I'm not so sure. Unrolling a loop improves my score but
> increases duplication.
I had in mind that duplication would cause an increased count which could be avoided by writing a function.

> > Consensus marking
>
> > An idea I like very much, but difficult to implement. The
> > assignments are a bit too complex and the solutions so varied and
> > the students too inexperienced for it to be viable. However I do
> > get students to vote on different solutions in class. It works
> > well and I will do more of it.
>
> Yes ... I'd think that this would get them thinking about ideas
> other than their own. I might spend a lot of time drawing them out
> on this. Some might not participate, and that would be too bad. But
> the ones who do would really prosper and those who listen would get
> something too.
After each assignment I devote the next tutorial to discussing variations in the assginments I have marked. They get their assifnments back within a week, so it is still relatively fresh, but their focus has already switched to the next assignment. I also spend time discussing differing approaches before the assignmet is due, but it is a bit of a balancing act between giving them ideas and letting them discover for themselves.

>
> > max = max(max(a, b), c) has a score of 0
> > Yes. I can live with that. If they get in the habit of looking
> > for library functions I am delighted.
>
> Arrgh. This is the path of the dark side. It leads toward cryptic
> code, and ultimately the fate of the Empire will be in the hands of
> these youths.
Hmm. Can you elaborate? My experience has been that the learning in a new language is dominated by learning the libraries. And using libraries makes the program easier to read (the reader is familiar with the library function or class) and more likely to be correct (re-inventing the wheel is fun, but the re-invented wheel may contain a buckle).
Mind you, med = max(min(a,max(b,c),min(b,c)) may be taking it a trifle too far.
>
> > Compound Booleans
> > Someone pointed out that median(a,b,c):
> > if ( ((a <= b) && (b <= c)) || ((a >= b) && (b >= c)) )
> > return b;
> > if ( ((a <= c) && (c <= b)) || ((a >= c) && (c >= b)) )
> > return c;
> > return a;
> > has a score of 2.
> > I had not decided whether to have extra points for compound
> > Booleans. So I waited to see if there were any
> > comments. I do find the above solution easier to read than,
> for example
> > one = a
> > two = b
> > three = c
> > if (one > two) // swap one and two
> > if (one > three) // swap one and three
> > if (two > three) // swap two and three
> > return two
>
> Do you really find it easier to read? Are you sure it's right? Will
> a student be sure it's right?
>
> I don't find either one particularly easy.
>
> If I were looking for a simpler way to do that one, I might go down
> this path and see what happens:
>
> if ( a < b && b < c) return b;
Yes. I agree. 6 conditions, each expressed as a guard.
Arrays do make life easier, though.
I remember a student project that had something to do with the lecturers' mailboxes. These were on 3 floors each floor having a grid with a differnt number of mailboxes in the grid. The assignment gave each mailbox a different dentity and the code had page after page of "if mailbox_11 has been selected ...". Looked pretty from the outside, though.

David
• ... My point exactly. Knowing the libraries well is good. Nesting function calls is cryptic and with today s compilers and gigahertz CPUs, unnecessarily so.
Message 20 of 24 , Jul 5, 2005
• 0 Attachment
On Tuesday, July 5, 2005, at 3:56:43 AM, Clark, David wrote:

>> > max = max(max(a, b), c) has a score of 0
>> > Yes. I can live with that. If they get in the habit of looking
>> > for library functions I am delighted.
>>
>> Arrgh. This is the path of the dark side. It leads toward cryptic
>> code, and ultimately the fate of the Empire will be in the hands of
>> these youths.
> Hmm. Can you elaborate? My experience has been that the
> learning in a new language is dominated by learning
> the libraries. And using libraries makes the program easier to
> function or class) and more likely to be correct (re-inventing
> the wheel is fun, but the re-invented wheel
> may contain a buckle).
> Mind you, med = max(min(a,max(b,c),min(b,c)) may be taking it a trifle too far.

My point exactly. Knowing the libraries well is good. Nesting
function calls is cryptic and with today's compilers and gigahertz
CPUs, unnecessarily so.

Ron Jeffries
www.XProgramming.com
Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
of his head. It is, as far as he knows, the only way of coming downstairs,
but sometimes he feels that there really is another way, if only he could
stop bumping for a moment and think of it. And then he feels that perhaps
there isn't. -- A. A. Milne
• ... Of course, it helps when the libraries are best suited to your problem domain ([a,b,c].max in Ruby or a b c followed by some Greek letter in superscript in
Message 21 of 24 , Jul 5, 2005
• 0 Attachment
> >> > max = max(max(a, b), c) has a score of 0
> >> Arrgh. This is the path of the dark side. It leads toward cryptic
> >> code, and ultimately the fate of the Empire will be in the hands of
> >> these youths.
> > My experience has been that the
> > learning in a new language is dominated by learning
> > the libraries. And using libraries makes the program easier to
> > read and more likely to be correct.
> > Mind you, med = max(min(a,max(b,c),min(b,c)) may be taking it a trifle too
> far.
> My point exactly. Knowing the libraries well is good. Nesting
> function calls is cryptic and with today's compilers and gigahertz
> CPUs, unnecessarily so.

Of course, it helps when the libraries are best suited to your problem domain ([a,b,c].max in Ruby or a b c followed by some Greek letter in superscript in APL).

But frankly, using the libraries directly vs building abstractions on them doesn't make the program more likely to be correct any more than writing your program in assembly would. Sure, if you write your own max(anArray) function that abstracts away usage of the max(a,b) function, you might implement it buggily, but by not writing your own max(anArray) function, you're essentially inlining [a specialization of] that same code wherever you need to max() more than two things, and that leads to duplication and THAT leads to a higher chance of bugginess.

I Might Be Wrong (especially about APL),
Devin
• ... went ballistic. ;- 10 years ago, or so, I had the same experience in COBOL. I hadn t done COBOL in a while, and availed myself of the mixed-case
Message 22 of 24 , Jul 5, 2005
• 0 Attachment
Monday, July 04, 2005, 9:43:11 PM, Jeff Grigg wrote:

> --- yahoogroups@j... wrote:
>> [...] Of course, no modern COBOL requires all upper case, either.

> Of course, COBOL *PROGRAMMERS* may require all upper case.

> (I wrote some FORTRAN once in all lower case. The project manager
went ballistic. ;->>

10 years ago, or so, I had the same experience in COBOL. I
hadn't done COBOL in a while, and availed myself of the
mixed-case capabilities of the, then current, compiler to
write a couple of programs. I was told in no uncertain terms
that the company standards required all uppercase.

--

Doug Swartz
daswartz@...
• ... I once had a colleage who resigned rather unexpectely and the person who took over his jobs found one where the (Fortran) variable names were all mixtures
Message 23 of 24 , Jul 5, 2005
• 0 Attachment
> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com]On Behalf Of Jeff Grigg
> Sent: Tuesday, 5 July 2005 12:43 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] KISS in COBOL
>
>
> --- yahoogroups@j... wrote:
> > [...] Of course, no modern COBOL requires all upper case, either.
>
> Of course, COBOL *PROGRAMMERS* may require all upper case.
>
> (I wrote some FORTRAN once in all lower case. The project manager
> went ballistic. ;-> But it was trivial to translate it to ALL UPPER
> CASE with a CP/M PIP command. (And it would be easy in Unix too.))
>
I once had a colleage who resigned rather unexpectely and the person who took over his jobs found one where the (Fortran) variable names were all mixtures of i, 1, o and 0. This was back 30+ years when you didn't declare anything and the printers of the day didn't distinguish between i and 1 or between 0 and o. The rest of us found it rather droll.
• ... The original context was that I could have something that was objective, and that the students would know before they submitted. Clarity is important, and
Message 24 of 24 , Sep 8, 2005
• 0 Attachment
> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com]On Behalf Of
> Steven J. Owens
> Sent: Friday, 9 September 2005 7:26 AM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] KISS
>
>
> > Wednesday, June 29, 2005, 12:59:47 AM, Clark, David wrote:
> > > I teach an introductory programming subject to students [...]
> > > So what to use for the simplicity measure?
>
> As a quick aside, I prefer "clarity" to "simplicity." Clarity is
> something that is easier to point at than simplicty. Even if you can
> still disagree on whether something is clearer or not, you can at
> least discuss more usefully why or how it's clearer or not.
The original context was that I could have something that was objective, and that the students would know before they submitted. Clarity is important, and clearly closely tied to simplicity, but can be in the eye of the author, especially when they are inexperienced.
>
> My rationale is that the more clearly the programmer's intent is
> expressed in the code, the better the compiler can optimize. And
> generally the compiler's optimizations will be better than any that I
> have time/energy/smarts to add... until I measure and find that it's
> not good enough, in which case I'll do a more rigorous performance
> analysis. Add in here the usual arguments against early optimization
> and the usual advice on the right way to do optimization :-).
>
> On Wed, Jun 29, 2005 at 06:30:50AM -0500, Doug Swartz wrote:
> > [...]
> > Simplicity is truly in the eyes of the beholder. The only
> > reason simplicity is important, is because, unlike code written
> > for college courses, code written for industry is usually read
> > many more times than it is written. Thus it is dependent on
> > the experience, skill, and biases of the reader.
> >
> > You could look at using some of the automated complexity
> > calculation algorithms: cyclomatic, essential, .... I'm not a
> > fan of these, but they're, perhaps, better than nothing.
> >
> > Another approach is Steven's suggestion to have the students
> > rate each other's work for simplicity. It is subjective, but
> > it's a good approach because, as noted above, the goal of
> > simplicity is "in the eye of the beholder". I
>
> Does it have to be rated on each project? Maybe follow up each
> project with a review of a solution turned in for the previous class,
> and an examination of how the code could have been simplified and
> refactored. If you want to be brave, you could use a solution from a
> current student, but I'd be wary of the emotions & politics that could
> introduce :-).
I certainly discuss alternate solutions, including students', when I hand back assignments. And it can be valuable. But you have more of their attention before they complete their work than after it.
>
> Or you could make it an extra credit assignment - given this
> solution to the project you last completed, what change would be the
> best way to improve the clarity of the code. Best suggestion gets
> five extra points.
I do give students opportunities to earn bonus marks, and about half of them attempt some bonuses. But it does tail off later in the semester when they have other pressures. I have thought of making your idea an assignment in itself, but have always decided against because the opportunity cost is too high.
cheers,
David
Your message has been successfully submitted and would be delivered to recipients shortly.