|
In order to prevent students from taking the assignment too literally, give them examples.
I mean, give them an example of an assignment, then give them a solution for this assignment that corresponds to taking the assignment too literally, and after that give them a solution that you think is way more appropriate.
Then do this with another example assignment, and its own solutions that are "too literal" and that are "appropriate".
Then do this with yet another example assignment, and its own solutions that are "too literal" and that are "appropriate".
If you do this a few times, the students will eventually understand.
|
|
|
|
|
In the "old days", we (noobs) had to submit a "flow chart" for review / approval before starting to code.
But I guess that now flies in the face of being "agile". Or that's not how "functional programming" works.
Anybody know what a "flow chart" is? How about an ERD?
|
|
|
|
|
Yea the new style is "throw code at the test cases and see what sticks"..
|
|
|
|
|
Add to that that some people are better with pictures versus others that prefer text versus the spoken word ...
Different levels of comprehension right from the outset.
|
|
|
|
|
I take it you are teaching then?
In my university days I had an eye opening experience across two courses. The first course we had an prof who would give us an assignment and award a C to work that did the strictest literal thing asked for, this prof asked us to always think about over delivering, optimizing, adding useful features, etc.
The second course we had a different prof. On the first assignment I actually forgot about it until the day it was due, so I rush coded the bare strict literal requirements given to us. I got 98/100 A. I was confused, adding to the situation most of my classmates (who had also been in the previous course with me) were receiving D's and F's... and they were pissed.
Turned out different profs wanted different things, the second prof was a true believer that we code to the requirements literally, period. The first not so much, he liked seeing extra effort.
I am just sharing this in reply to your post, as it may be that your students already had a prof like my second one?
|
|
|
|
|
Yours is an excellent description of college: close to 80% of a student's effort is determining exactly what a professor wants. The other 20% is simply providing that.
In of itself, that is not a bad thing; it is quite relevant to the remainder of life. In a job, you have to determine what the boss wants and adapt. At home, you have to determine a significant other's expectations. In each case, you get to decide whether to modify your behavior to remain in the situation or cut your losses and move on.
School is a little rougher. It is possible to drop a course if you cannot alter yourself to match the instructor's expectations, but sometimes, no other routes exist and you find you must change to meet your goal.
To the overall question, very few companies truly want "creativity". A unique solution is difficult for others to interpret and modify in the future. Ironically, creativity is also not a spontaneous, natural choice for most: indeed, as many have indicated, our elementary and secondary schools truly drown it out in most students well before college. The more a student remains in the sciences - computer, math, physics - the less creative he is. This tends to be the selling point of liberal arts: an exposure to more options that may not pertain to a future career, but will open the individual to different perspectives, and by association, be more "creative".
In short, don't expect a student to easily "think outside the box"; all have been taught from preschool to "color within the lines", "line up alphabetically", "be quiet and courteous". As members of society, we all follow a LOT of rules. Creativity can be curated, but it doesn't come easily.
|
|
|
|
|
Harold,
We are creatures of pattern recognition. For most of our lives, in school, and in math, we are asked to do X. If we do anything other than X, we get in trouble. It creates this literal interpretation trap, IMO.
My recommendation is to simply retrain them. Come up with 10 assignments with 3-4 answers that could be considered acceptable. And grade them out. The goal being to teach them how to think through what the problem is asking.
Again, IMO, students should be reading 10 times more code, and analyzing it, than writing it. But alas, they would barely do the reading they were supposed to do anyways. LOL.
I remember getting in trouble for the opposite. We were asked to write a C Program that would prompt for INPUT format (binary, hex, octal, decimal), and an OUTPUT format (same set). Then the user would type in a number in the input format, and our job was to output it properly in their output format. My implementation effectively did (scanf(inputFormat,value); printf(outputFormt,value);) and the teacher went all crazy on me, that I failed to write the code that converted the values, and that I did not show I understood... Blah Blah Blah. I told her it demonstrated that I understand that they are just integers, and the format is really a display/input issue.
So, the point is that the students should be learning by example. The example problems should actually have multiple answers. What you feel are good and bad answers, and why. Get the students thinking about things that cannot fit into memory. Our teachers would give us small test files, and then the TA would use these HUGE files that would never fit into memory. The program would fail, and we would have to go back and rewrite it. All Valuable stuff, IMO.
But I don't think it is fair to ask a NEW programmer to be a good programmer, without teaching the difference between the good and the bad. Without giving them the requisite examples.
Finally, it is fair to HINT the problems:
- You should not try to load everything into an array at once
- You could write this without using a BRANCH statement
- Extra Credit for making the loop count a variable
And the only other comment. Utilize the TA to solve the problems first. Most of them are
closer to the students. And if they need a hint, then the students will certainly need a hint.
Allow the TA to suggest rewording.
Finally. This might be crazy. But spend 10 minutes after class answering questions about the
homework assignment. I usually had 3-4 kids who just wanted to confirm I was okay with the simplest
answer. A bunch stayed after, confused and listening. And a few had those questions that made you think they were late for Basket Weaving  ))) (or just confused)
It is IMPOSSIBLE to make a question Fool Proof.
I never said write it like that! (This sentence has 7 meanings, depending on what word you emphasize. And that is part of the problem).
|
|
|
|
|
I would say you're not writing the assignments correctly if you're not getting the results you anticipate.
Keep the assignment goals (requirements) clear and separate from tutor 'hints' at the anticipated solution. Better yet just point the students in the direction of the relevant topics that will help resolve the assignment.
If you want to emulate the real world, then they won't get hints at the solution. They will get vague requirements or specifications. Probably with contradictions. In this scenario the students that ask questions to clarify the gaps ought to find a path to a better grade. Unless they get lucky and guess right. That happens a lot too.
|
|
|
|
|
just curious. recently I start to use extension methods in my projects.
diligent hands rule....
|
|
|
|
|
I use them.
I dunno about "extensively". Let's say they are pretty common.
|
|
|
|
|
For common tasks, and when it makes sense. Absolutely!
|
|
|
|
|
Very much so! Done properly, they make the code so much more compact and readable.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Not only does proper use of extension methods do this it also "cleans" up the API. For instance, Visual Basic has a StrReverse(string) method, but the underlying dotNet framework's Reverse() extension method for System.String doesn't return a string. It returns an array of characters. I'll add extension methods for this type of situation.
|
|
|
|
|
As per Super Lloyd - I use them, I don't know about 'extensively', but, 'when it seems to make sense'
|
|
|
|
|
|
I have an assembly full of them.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Like all other language features, I use them when it's appropriate.
That means sometimes I do, and sometimes I don't. It depends on what the method is doing and whether it makes more sense as an extension method or as a property / standard method.
If you need to add functionality to a sealed class such as String then it makes a lot of sense. If the class is your own, then it's just silly to use extension methods ... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: If the class is your own, then it's just silly to use extension methods
No it's not!
On a few occasions I've created an interface, ISomething, and before writing any implementation I wrote a few extension methods I knew I needed.
And then I wrote the implementations (and got so much functionality out of the box!) 
Kind of like collections and LINQ, all M$ "own" classes, but they still have lots of extension methods.
|
|
|
|
|
Hi Sandor, I'd really appreciate seeing an example of Extension Methods for an Interface.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
The entire LINQ library depends upon it.
For example the Count() extension method on collections may look as follows:
public static class Extensions
{
public static int Count<T>(this IEnumerable<T> collection)
{
int count = 0;
using (var enumerator = collection.GetEnumerator())
{
while (enumerator.MoveNext())
{
count += 1;
}
}
return count;
}
}The actual extension method checks for null and tries to cast to ICollection<T> and ICollection for the Count property first, but it's an extension on an interface.
There are LOTS of them...
|
|
|
|
|
thanks for this example!
diligent hands rule....
|
|
|
|
|
Sander Rossel wrote: On a few occasions I've created an interface, ISomething, and before writing any implementation I wrote a few extension methods I knew I needed.
Still doesn't make sense to me. If the interface is your own, you should write the method to the interface as it makes sense to be in its scope. If you need behavior without having to implement everywhere, you're looking for an abstract class.
Extension methods provide a clean way to have helper methods to class you cannot modify. Otherwise you're just creating spaghetti code and killing a few principles.
Although M$ does with it's own classes, it makes sense, specially to not break backwards compatibility when implementing new frameworks (like LINQ), so yes, they own the code, but they should not modify it, as LINQ is implemented in a whole different scope.
If you are developing frameworks, with attachable components, that extend other standalone components, yes, it makes sense to have extension methods on your own code, otherwise I agree that's "silly".
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I wholeheartedly disagree
Extension methods are nothing more than static helper methods that are treated as instance methods by the editor (and the compiler?).
I don't think there is a principle against creating static helper methods and it's certainly not creating spaghetti, especially since the methods read as instance methods (editor trick or not).
An abstract class is heavy weaponry, every implementor must now inherit the abstract class and since you can only inherit once this puts a serious limitation on implementors.
If you can't inherit you don't get the functionality. You could create a wrapper, but that's just a lot of boilerplate code.
Besides, inheritance is added complexity/spaghetti too!
public interface ISomething
{
IEnumerable<object> Stuff { get; }
}
public static class SomethingExtensions
{
public static bool HasStuff(this ISomething something)
{
return something.Stuff.Any();
}
}How is this not awesome? Every implementor now gets HasStuff for free without the need for inheritance!
You agree that extension methods are clean for LINQ and when dealing with third party code, but for your own code it's suddenly spaghetti? Sounds like double standards to me 
modified 18-Oct-16 3:38am.
|
|
|
|
|
As OG pointed out when adding functionality to sealed class then yes, but otherwise I consider between extension methods and inheritance. Mainly because I often need more functionality than just a method and perhaps even new instance variables.
But yes I use them when I see fit.
|
|
|
|
|
I'm sure the OP means extension methods for native .Net objects, such as string, Type, DateTime, etc.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
