thssccb@iitmax.IIT.EDU (catherine c bareiss) (04/19/89)
I am designing a beginning programming course.
The structure is to be as follows:
One day a week, a lecture on a topic (using psuedo code).
One this day, all students would attend.
The second day of the week, the class would be broken into different
languages where syntax would be taught.
The third day would be a lab day where they would learn on the
computer.
I am looking for a list of topics to cover in the first day.
I am also looking for text books if any have been developed for this.
Any recommendations would be very helpful.
By the way, this is my first posting to the net, so I hope everything
is right.
Thanks in advance
Cathy Bareissciriello@lafcol.UUCP (Patrick Ciriello II) (04/27/89)
Was the text book I used as a freshman at Drew University. It is very well organized, and has very good examples. I believe that it is currently in it's second edition. For more info, contact BBURD@DRUNIVAC over BITNET. He will know more of the particulars (where to get it, etc). The course that used this book was in intro course designed for those who were going to be CS majors. If your course is for non-majors, this may be a little more than you need. Pat Ciriello II Supervisor of Networking and Tech. Services Lafayette College
weyrich@csun1.UUCP (Orville Weyrich) (05/01/89)
From article <2130@iitmax.IIT.EDU>, by thssccb@iitmax.IIT.EDU (catherine c bareiss): > I am designing a beginning programming course. > The structure is to be as follows: > One day a week, a lecture on a topic (using psuedo code). > One this day, all students would attend. > The second day of the week, the class would be broken into different > languages where syntax would be taught. I would suggest that you look into the book "Programming Principles: An Introduction" by John Motil, which was originally published by Allyn and Bacon but which I think is now being published by William C. Brown. This text separates the theoretical discusion from the syntax discussion very nicely, and I like the content. There is probably also a Modula-2 version of the book out now, but I am not sure that the separation of the theory and of the syntax is as pronounced. -- Orville R. Weyrich, Jr. | UUCP : ...gatech!csun1!weyrich Department of Computer Science | INTERNET: weyrich@csun1.cs.uga.edu University of Georgia | Athens, GA 30602 USA | MA BELL : (404) 542-1082
nick@cs.hw.ac.uk (Nick Taylor) (05/03/89)
In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: >I am designing a beginning programming course. > >The structure is to be as follows: > One day a week, a lecture on a topic (using psuedo code). ^^^^^^^^^^^^^^^^^ Is this a good idea? I know it is becoming more and more common to do this but I harbour deep suspicions that it might actually make the learning task more confusing. I would be interested in people's comments on the use of pseudo-code as an aid to programming language teaching - especially for teaching a first language. Nick Taylor "Life... Don't talk to me about life!" - Marvin BSP, PA, PD(LHS) Department of Computer Science JANET : NICK@UK.AC.HW.CS Heriot-Watt University ARPANET : NICK@CS.HW.AC.UK 79 Grassmarket /\ / o __ /_ UUCP : ...!UKC!CS.HW.AC.UK!NICK Edinburgh EH1 2HJ / \ / / / /__) Tel : +44 31 225 6465 Ext. 532 United Kingdom / \/ (_ (___ / \ Fax : +44 31 449 5153
brian@cat28.CS.WISC.EDU (Brian Miller) (05/05/89)
In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes: >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: >>I am designing a beginning programming course. >> >>The structure is to be as follows: >> One day a week, a lecture on a topic (using psuedo code). > ^^^^^^^^^^^^^^^^^ > >Is this a good idea? I know it is becoming more and more common to do this >but I harbour deep suspicions that it might actually make the learning task >more confusing. I would be interested in people's comments on the use of >pseudo-code as an aid to programming language teaching - especially for >teaching a first language. I agree. Pseudo-code is a waste of time. Teach the language and its principles (sp?). My assembly language teacher spent a week-and-a-half outlining a hypothetical computer and no one in the class appreciated it. Remember, pseudo-code in any form is itself a descriptive language. This means you have to spend time to familiarize your students with _it_, as well as the real language. If you think that it is important that the students see that language X (the real language you may teach) is not the _only_ way to talk to a computer or to outline an algorithm, then introduce them to a second real language a well. The more real world you give your students, the less pissed-off the hard to please ones will be and the more awakened the "slow" ones will be.
rang@cpsin3.cps.msu.edu (Anton Rang) (05/05/89)
In article <2680@puff.cs.wisc.edu> brian@cat28.CS.WISC.EDU (Brian Miller) writes: In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes: >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: >>I am designing a beginning programming course. >> >>The structure is to be as follows: >> One day a week, a lecture on a topic (using psuedo code). > ^^^^^^^^^^^^^^^^^ > >Is this a good idea? I know it is becoming more and more common to do this I agree. Pseudo-code is a waste of time. Teach the language and its principles (sp?). I disagree, at least in part; perhaps my understanding of pseudo-code is different from yours. Teaching a *flexible* method of pseudo-coding is basically equivalent to teaching top-down design principles. Now, I've seen classes which put a particular style of pseudo-code on a pedestal (the intro to BASIC course here, for one); that seems a little ridiculous to me. (Their idea of pseudo-code is making up new keywords for BASIC statements...well, almost.) Pseudo-code should be a way to design algorithms and programs without having to worry about the syntactic sugar or limitations of a particular language. For instance, consider this pseudo-code for a merge sort: Merge sort routine (one parameter, some data to sort). 1. If there is only one item to sort, just return (already sorted). 2. Split the data into two sets. 3. Sort each set, using the merge sort routine recursively. 4. Join the two sets together. This is my conception of what pseudo-code *should* be like. This can be treated like an outline, with more detailed instructions added for each part (i.e. 4a, 4b, etc. detailing the final join operation). More and more detail can be added, perhaps including information about the data structures chosen, until it is detailed enough to easily turn into code: Merge sort routine (one parameter, a linked list). 1. If there is only one item to sort, just return (already sorted). a. Check if the next-item pointer of the list's head is nil. b. Just return if it is; if not, go on. 2. Split the data into two sets. a. Set up two empty temporary lists. b. Go through the input, one item at a time. (i) Add it to either list (alternate between them). ... Again, flexible pseudo-code is good--it prevents the student from having to worry about details like "how do I test if there is only one item?" or "how to I find a value in a record when I have a pointer to it?" until they actually write the routine. Now, what passes for pseudo-code in many textbooks is much too strict for this; I think it constrains creativity (though no more than forcing students to implement an algorithm directly in some language). Just my thoughts... Anton +---------------------------+------------------------+-------------------+ | Anton Rang (grad student) | "VMS Forever!" | VOTE on | | Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! | +---------------------------+------------------------+-------------------+ | Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu". | +---------------------------+------------------------+-------------------+
pilgrimk@lafcol.UUCP (Kenwyn A. Pilgrim) (05/05/89)
(Nick Taylor) writes:
# > One day a week, a lecture on a topic (using psuedo code).
#
# Is this a good idea? I know it is becoming more and more common to do this
# but I harbour deep suspicions that it might actually make the learning task
# more confusing.
Here's my $0.17:
What should be emphasized is the technique used in producing the solution
(in psuedo code) and not the language specifics on how to implement
the solution. Esp. when dealing with the C language.
Pascal usually closely resembles the psuedo code but there may be
times when psuedo code does a better job of clarifying things than Pascal
jargon. Never made my learning task any more confusing. Actually
clarified it (esp. in case of recursive sol'ns!)
So what did I just say? I'm all for psuedo-code!
And thanks to ABHAY SAWANT (sp?) for posting that TSR.TPU.
I'm looking forward to using it.
-KenwynJZEM%MARIST.BITNET@cunyvm.cuny.edu (William J. Joel) (05/05/89)
Per the recent discussion on whether to use pseudo-code or not, I must agree with it's use, as long as the instructor does not teach a fixed syntax for it. The purpose of PC is to give the student a sense of structure without worrying about the syntax. I have seen too many texts, that could have been excellent, succomb to the heavy use of a rigid pseudo-code. When you get to the actual language you are using to demonstrate impelmentations of the topics covered, then syntax becomes important. Note that I did not say you were teaching the language. In a CS-1 course, the topics are important. The language is also important is as much as it conveys the meaning of the topics.
stephen@ziebmef.uucp (Stephen M. Dunn) (05/05/89)
We at McMaster University used Oh! Pascal, 2nd ed., for our second- year course (a second course, the first being in FORTRAN). I found the book to be fairly useful, although it is aimed more at a first course, which is what the original poster had in mind. In the introduction, Doug Cooper (co-author with Michael Clancy gives two electronic addresses: dbcooper@BERKELEY and ucbvax\!dbcooper. Don't ask me if either works. He suggests that errors in the book or suggestions be sent to him; he probably wouldn't mind an enquiry that may lead to higher sales, though. Regards, Stephen -- ------------------------------------------------------------------------------- ! Stephen M. Dunn stephen@ziebmef.UUCP ! DISCLAIMER: Who'd ever ! ! (I am currently pondering a witticism to go here) ! claim such dumb ideas? ! -------------------------------------------------------------------------------
balcer@demon.siemens.com (Marc J Balcer) (05/05/89)
In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes: >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: >> One day a week, a lecture on a topic (using psuedo code). > >Is this a good idea? ... >but I harbour deep suspicions that it might actually make the learning task >more confusing... After about 4-5 weeks in the introductory Pascal course, I'll start using a pseudocode when explaining algorithms. Example: set total to zero for every element in table do add its value to the total write the value end print the total Invariably there will be the student(s) who have not yet mastered even the most fundamental detail of Pascal syntax and many others for whom the syntax is not "second nature." Some will copy down the pseudocode word-for-word and then type it in and try to run it. (It happens) It's very difficult for students, when confronted with several very similar notations, to keep straight "this is design language," "this is Pascal," "this is Scheme." Now in a Data Structures or Compiler Design class, there's usually very little problem with using pseudocode. It's a convenient, informal shorthand. These students have mastered the syntax of their programming language. >... an aid to programming language teaching - especially for >teaching a first language. > Many of us who teach programming (er, I mean "introductory computer science") courses have struggled with this. It would certainly be nice to have students who complete the first year of CS able to: - see a computer as more than just a "Pascal box" - think about a problem at a more abstract level than the implementation language - see Computer Science as more than "just learning languages" yet also able to plan and write clear, coherent programs. One popular approach is to teach the course either "language-free" or using several languages at once. We justify this by saying (and rightly so) that a computer scientist must be capable of working with several different notations. BUT can we expect that every student will be immediately capable of making these kinds of "context switches?" I'm not sure. --------------------------------------------------------------------------- Marc J. Balcer [balcer@demon.siemens.com] Siemens Research Center, 755 College Road East, Princeton, NJ 08540
brian@cat50.CS.WISC.EDU (Brian Miller) (05/05/89)
In article <1035@lafcol.UUCP> pilgrimk@lafcol.UUCP (Kenwyn A. Pilgrim) writes: >Here's my $0.17: >Pascal usually closely resembles the psuedo code but there may be >times when psuedo code does a better job of clarifying things than Pascal >jargon. I see your $.17 and raise you $.05: :-) If that really is the case (and I agree that it is), then academic languages like pascal still have a ways to go in my book.
ciriello@lafcol.UUCP (Patrick Ciriello II) (05/06/89)
In article <2394@brahma.cs.hw.ac.uk>, nick@cs.hw.ac.uk (Nick Taylor) writes: > In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: > >I am designing a beginning programming course. > > > >The structure is to be as follows: > > One day a week, a lecture on a topic (using psuedo code). > ^^^^^^^^^^^^^^^^^ > > Is this a good idea? I know it is becoming more and more common to do this > but I harbour deep suspicions that it might actually make the learning task > more confusing. Well, if you write your pseude code so that it is OBVIOUSLY english ( i.e. using full sentences, etc) then I don't think the students would become confused. They are learning and idea without the mechanics. On the other hand, you might want to incorporate the Reserved Words of the language to be taught inside your 'english' ( which may have to be fudged a little ) so that while they are learning the ideas on the surface, they are also becoming familiar with the specific mechanics associated with that particular language. Pat (the Dragon that is WHITE) Disclaimer: I have no idea what I am talking about .. press 'n' now ....
rg@psgdc (Dick Gill) (05/06/89)
In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes: >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: >>I am designing a beginning programming course. >> >>The structure is to be as follows: >> One day a week, a lecture on a topic (using psuedo code). > ^^^^^^^^^^^^^^^^^ > >Is this a good idea? I know it is becoming more and more common to do this >but I harbour deep suspicions that it might actually make the learning task >more confusing.... I started programming in the 60's when it was a good deal more *art* than *science* !:-) and have a couple of thoughts on the topic. It is important that the begining programmer understand that the first step in writing software is to structure a clear and logical solution to the problem begin solved. This exercise involve primarily logic and imagination, and is largely independent of the language used to write the program. A pseudo code that stresses the logical steps being performed could be very useful here, particularly if it keeps the students from rushing to write *real* programs before they have figured out how to solve the problem! -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dick Gill Professional Solutions Group (703)761-1163 ..uunet!psgdc!rg The quality of the circus here in Washington depends on the clowns you elect.
art@buengc.BU.EDU (A. R. Thompson) (05/07/89)
In article <206@psgdc> rg@psgdc.UUCP (Dick Gill) writes: >[...] >It is important that the begining programmer understand that >the first step in writing software is to structure a clear and >logical solution to the problem begin solved. It has been my experience that the biggest difficulty beginners have is learning how to state the problem clearly and concisely. I have found that once students grasp the idea of clean problem statement that the solutions come rather easily.
ciriello@lafcol.UUCP (Patrick Ciriello II) (05/08/89)
In article <206@psgdc>, rg@psgdc (Dick Gill) writes: > In article <2394@brahma.cs.hw.ac.uk> nick@cs.hw.ac.uk (Nick Taylor) writes: > >In article <2130@iitmax.IIT.EDU> thssccb@iitmax.IIT.EDU (catherine c bareiss) writes: > >>I am designing a beginning programming course. > >> [ stuff deleted ] > I started programming in the 60's when it was a good deal more > *art* than *science* !:-) and have a couple of thoughts on > the topic. I consider programming more of an art than a science myself. I compare writning a large system to the writing of a symphony. > It is important that the begining programmer understand that > the first step in writing software is to structure a clear and > logical solution to the problem begin solved. > [stuff deleted] Absolutely. Understanding the way to approach a problem and solve it is much more important that learning the syntax of a particular language. Perhaps that is where CSCI course need to be bolstered up. More problem solving and less 'programming'. Of course, you need both, but I wonder where the emphasis should really be? Pat ( the DRAGON that is WHITE )
xpress@Portia.Stanford.EDU (Brad Hochberg) (05/09/89)
Some classes here at Stanford use Doug Cooper's Condensed Pascal. It is a
compressed and revised Oh! Pascal!. Plus it includes the complete Standard
Pascal User Reference Manual. It is generally aimed more to students who have
had a little prior programming experience whereas Oh! Pascal! is geared a
little more towards beginners. They are both excellent. Personally I prefer
Condensed Pascal. Plus it is a great reference guide.
--Brad
--
Brad Hochberg | "The only time I show any consistency these days
Stanford University | days is when I'm making a cup of tea."
xpress@portia.stanford.edu | --Mats Wilander, after getting bounced in the
| in the first round of the WCT Finals in Dallasduncan@dduck.ctt.bellcore.com (Scott Duncan) (05/09/89)
In article <1085@lafcol.UUCP> ciriello@lafcol.UUCP (Patrick Ciriello II) writes: > >I consider programming more of an art than a science myself. >I compare writning a large system to the writing of a symphony. Depending on how large you mean, I do not know that any symphony was ever written by a team of people, but most large software systems are not the work of a single individual -- though much of the vision might be, I agree. The problems in large system development are those brought about through the com- munication needed between groups of people, assuming certain levels of compe- tence or experience. (The individual differences between programmers which studies by Curtis, Sheppard, et al, have demonstrated also tend to wash out, according to Belady and Lehman, the larger the project gets.) > Understanding the way to approach a problem and solve it is >much more important that learning the syntax of a particular language. > >Perhaps that is where CSCI course need to be bolstered up. More problem >solving and less 'programming'. > >Of course, you need both, but I wonder where the emphasis should really be? Clearly on the former. I have taught students who were taking a second or third language and who told me they "knew how to program" already. They did some of the more careless and sloppy work as well as having had some of the least ingenious solutions. They're goal was to "get done" with the course be- cause they just "needed another language credit" to graduate. Programming is the easy part. Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (201-699-3910 (w) 201-463-3683 (h))
duncan@dduck.ctt.bellcore.com (Scott Duncan) (05/09/89)
In article <16007@bellcore.bellcore.com> I wrote: > > They're goal was to "get done" with the course be- ^^^^^^^ >cause they just "needed another language credit" to graduate. God help me for that one...well, it was early in the morning after working late at night, etc., etc. Sorry folks... Speaking only against myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (201-699-3910 (w) 201-463-3683 (h))
reggie@dinsdale.nm.paradyne.com (George W. Leach) (05/09/89)
In article <1989May4.225626.657@ziebmef.uucp> stephen@ziebmef.UUCP (Stephen M. Dunn) writes: > We at McMaster University used Oh! Pascal, 2nd ed., for our second- >year course (a second course, the first being in FORTRAN). I found the ^^^^^^^^^^^^^^^^^^^^^^^^^^ >book to be fairly useful, although it is aimed more at a first course, >which is what the original poster had in mind. This is exactly the same sequence of courses that I took as an undergrad back in the mid 70's. Is this still the order in which most CS programs teach introductory level programming? I would have thought by now that FORTRAN would not be the first language taught. I attended an engineering school where everyone learned FORTRAN as a first programming course. Pascal was introduced in the Intro to CS course. George George W. Leach AT&T Paradyne .!uunet!pdn!reggie Mail stop LG-129 reggie@pdn.paradyne.com P.O. Box 2826 Phone: (813) 530-2376 Largo, FL USA 34649-2826
880716a@aucs.UUCP (Dave Astels) (05/11/89)
In article <1085@lafcol.UUCP> ciriello@lafcol.UUCP (Patrick Ciriello II) writes: > >Absolutely. Understanding the way to approach a problem and solve it is >much more important that learning the syntax of a particular language. This is fine for begining 'programmers' but they shouldn't be given the idea that you can't start coding until you understand the problem and its solution. If this was the case no research would ever get done. In some fields (AI in particular) the problem becomes understood better by trying to solve it. Exploritory programming? It definately has its place. Of course only with a good interactive environment (i.e. Smalltalk, Lisp...) -Dave Standard disclaimers about this being my own opinions...
kwan@maui.cs.ucla.edu (Edmund Kwan) (05/12/89)
In article <1866@aucs.UUCP> 880716a@aucs.UUCP (Dave Astels) writes: >In article <1085@lafcol.UUCP> ciriello@lafcol.UUCP (Patrick Ciriello II) writes: >> >>Absolutely. Understanding the way to approach a problem and solve it is >>much more important that learning the syntax of a particular language. > >This is fine for begining 'programmers' but they shouldn't be given the idea >that you can't start coding until you understand the problem and its solution. ^^^^^^ >If this was the case no research would ever get done. In some fields (AI in >particular) the problem becomes understood better by trying to solve it. ^^^^^ Coding without understanding the problem & its solution(s) (Code and Fix Approach) is a no-no according to my Software Engineering class. We should definitely not teach beginning programmers to hack out a program in Pascal rather than to design a solution and then implement it in Pascal. Perhaps you are talking about prototyping? Seems to me that students don't ever need to develop prototypes in their classes (or maybe all they do is develop prototypes).
gviernes@dca-pac.dca.mil (Glenn P. Viernes (BBNCC)) (05/12/89)
I'm a systems analyst and a former full-time college instructor (former because
it didn't pay well enough). So I've worked on both sides of the Education-
to-Industry interface. I saw many students who automatically threw code at the
symptoms of a problem, and unfortunately I continue to see computer scientists
who persist in the same 'freshman' practice. It is these same 'professionals'
whose egos are threatened when asked to describe the problem in 25 words or
less. Colleges are the best place to acquire new tools for solving problems,
however they are the worst place to get a solid foundation in problem analysis
and solution strategy. I'm refering to all disciplines. This is not an
acceptable situation. (I'm now getting off my soapbox.)
The most important lessons I learned in CS-1 are as follows:
Module 1: How a Computer thinks and communicates. Why?
Module 2: The Types of Problems Computers can solve.
Module 3: How to translate a 'human' problem into computer solvable problems.
Module 4: A computer language is just a means of communicating with a
computer.
If you have the freedom to effect a change, change in the direction of problem
analysis.
Glenn Viernes
NOC Analyst
Disclaimer: I am not a spokesman for my employer... They won't let me!manis@faculty.cs.ubc.ca (Vincent Manis) (05/12/89)
In article <23855@shemp.CS.UCLA.EDU> kwan@cs.ucla.edu (Edmund Kwan) writes: >Coding without understanding the problem & its solution(s) (Code and Fix >Approach) is a no-no according to my Software Engineering class. We should >definitely not teach beginning programmers to hack out a program in Pascal >rather than to design a solution and then implement it in Pascal. Having taught both, I'm not entirely sure that Software Engineering and Computer Science are the same thing. In fact, I'm pretty sure that the reverse is true. Software engineering, like all forms of engineering, relies upon the application of fairly well-understood principles to problems. The goal is to produce something which works, with as little uncertainty as possible. Whether it's a bridge or a program, we want a reliable product, as close to budget and deadline as possible. (Incidentally, it has always amazed me how people will hire `programmers' who know nothing about software design, but would rather like to learn. I'd never hire an architect or a lawyer that way...) Introductory computer science is much more of a laboratory science. Students are supposed to learn concepts, primarily by experimentation. The goal is not the program, but the increased understanding of the subject. Naturally, students will be encouraged to program well; but, then, one of the reasons I got out of chemistry was my tendency to break anything made out of glass. There is no claim that `science' is better than `engineering' here. However, I don't think it makes sense to teach engineering prior to teaching sound science. A propos this topic, if you haven't already done so, read the `ACM Task Force on the Core of Computer Science' report in the January CACM. It will change your paradigm of computer science completely. ____________ Vincent Manis | manis@cs.ubc.ca ___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn ____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net ___ /\ ___ University of British Columbia | uunet!ubc-cs!manis __ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394 _ / __ \ _ ____________ "I'm not making this up, you know!" -- Anna Russell
880716a@aucs.UUCP (Dave Astels) (05/13/89)
In article <23855@shemp.CS.UCLA.EDU> kwan@cs.ucla.edu (Edmund Kwan) writes: > >Perhaps you are talking about prototyping? I guess I am. My area of interest (Natural Language) seems to be one of "this sounds like it will work, let's try it!" Also, I am a self-taught hacker. As such I haven't much use for 'by the book' software engineering. If it feels right try it. It's called creativity (as opposed to rote design). Although in a well defined domain like CS-1 level, this approach isn't needed, and a good grounding on methodical problem solving is required (at least for the first year CS students that I've seen). But on the other hand, they shouldn't be limited in their problem solving techniques. Sometimes a shot in the dark pays off.