Length: Program: none; Algorithm: none; Post-Mortem: 2-3+ pages
Due: Wednesday 23 March at 5:00 p.m.; 5% late penalty per hour
Format: email attachments (please put 303 Perl in the subject line of your
email)
Everyone will write a short computer program using the programming language called Perl. We'll be learning the language in class and will spend a few days in the Arts 1-12 computer lab to get some hands-on experience. By Wednesday 23 March at 5:00 p.m., you'll email to me both your Perl program and a short, two to three page "post-mortem" description about your experiences learning how to program. You can simply attach those documents to your email.
I've created a list of interesting Programming Problems and you're free to choose one of those exercises for this assignment. If you'd rather try your hand at a different problem, please check with me to make sure that it's appropriate for the scope of this assignment. Depending on your project, though, it may be helpful to learn how to read data from files or to use a recursive subroutine.
The goal of this project is to enhance your computer literacy. I don't want to turn you into a programming guru who lives in a basement, eats nothing but potato chips and never sees the light of day. But I do want everyone to understand the absolute literalness of computers and how specific and precise our instructions to them must be. Additionally, in the long historical sweep of things, I feel that humanities scholars will continue to use the computer more and more as a research tool but I'm skeptical that traditional companies like Microsoft will provide the kinds of software we need. We'll have to learn how to write our own software. While graduate students in Humanities Computing learn much more about programming than we will, I think the experience is worthwhile at the undergraduate level too.
The idea here is to learn both the syntax (i.e., grammar) and semantics (i.e., meaning) of the Perl programming language by writing a short program to solve a simple problem. Look through the list of programming problems to see if there's a puzzle that appeals to you. Once you decide on a problem, use a pencil and paper to try to figure out how to solve it yourself. Write down the step-by-step process that you yourself need to do in order to solve the problem -- that's called the algorithm -- and then begin translating that algorithm into Perl. As you write your program and try to get the computer to execute (that is, to "run") it, you'll find that you've made some spelling and punctuation errors. Those are normal -- very, very few programmers ever get a program right the first time. You'll go through a debugging stage in which you eliminate those errors (called "bugs") and what you'll be left with will be a complete and correct Perl program. We'll be stepping through this process in class so you can see firsthand how it works.
One of my long-term goals is to write a programming textbook aimed at humanities students, and so I'm very interested in learning about your experiences on this project. The Post-Mortem is designed to help me improve my teaching. Think of the Post-Mortem as a kind of self-inventory or autobiography or journal about what you understood, what confused you, what problems you had, how you solved them, where you turned for help, what frustrated you, what elated you, etc. Why did you select the programming problem that you did? How did you go about devising the algorithm? What problems did you have with Perl itself? Which was harder: the syntax (the punctuation and grammar) or the semantics (understanding the meaning of the Perl statements themselves)? Did your program work perfectly and give the right answer? If not, why not? If you had more time, what additional work would you have done on this project? If your Programming Problem asked any questions, this would be the ideal place to answer them. I'd like at least 2-3 pages, but if you're generous and want to write more, I'll be grateful.
You should send an email to me by 5:00 p.m. on Wednesday 23 March with two attachments. I don't want people procrastinating on this project, so there will be a 5% late penalty per hour. Be sure to work hard on Perl while we're doing the Perl unit. Procrastination will be your undoing. Use the subject line 303 Perl on your email -- that will insure that my email filter puts your message in the right place.
You need to hand in three things: the program, the algorithm, and the post-mortem. So you should attach two documents to your email: 1) the Perl program itself, which will be a plain text document and which I will run on my machine to see if you've cleaned up the syntax and any logic errors. 2) the Algorithm and Post-Mortem description, which can be in the same document and in any format, although I would prefer that you not use Word Perfect (RTF is a great format to use if you're using Word Perfect).
It's not the end of the world. There's partial credit on this assignment. But don't shirk -- do everything you can to get the program to work correctly. If it doesn't work, though, use the Post-Mortem as a way to explain what went wrong and what you were doing (or would have done, given enough time) to fix it.
As with every other assignment in this course, I'm looking for a serious engagement from you with the material at hand. Here, I'm looking to see whether you've made an earnest and energetic attempt to learn some Perl. I'm not looking only for programs that are perfect -- an ambitious program that doesn't work may well score higher than an unambitious program that's perfect. I appreciate students who challenge themselves.
Even if your program doesn't work or doesn't yield the right answer, I will look for these qualities:
Good programming style: clean, nicely indented code that is well
commented.
A Logical Algorithm: algorithms are the equivalent
of a term paper prewriting outline so be clear and concise.
An Honest Post-Mortem: It's not a term paper but
a self-appraisal, so just be honest.
Feel free to visit me during my office hours. You can also check out some of the Perl Tutorial pages I've written (like those on filehandles and recursive subroutines) and there are many other fine tutorials on the web -- just do a Google search. We may also want to do a few out-of-class Perl tutorials too. Contact me and we can put a group together and find a time to meet.