Reflections on a First Semester

I'm sorry I haven't been posting for a while; its because no blog posts have been due recently (blame my computer science teacher). To be honest though, I don't know if I could have found time to post amid the finals and the loads of fun I was having trying to finish computer science labs. But now I'm just complaining. This semester in CompSci has been really enriching, and I appreciate the structure and the curriculum of the course.

My teacher taught the course mainly through labs. We would get a lesson taught to us through a powerpoint, then have to apply it through a lab. These labs were essentially cookbooks for programs, and were made so that each successive lab would have less hand-holding.

Here's an excerpt from an early lab.

"There is a folk rule stating you should only date someone who is at least seven years older than than half your age. For example, an 18 year old needs to date somebody at least 16 years old ( 7 + ( 18 / 2 ) ).

Produce a program that first prompts and reads an integer for a variable named age. The program then computes and displays the age of the youngest person for whom dating meets the folk rule."

Now, for contrast, here are some instructions from a later lab.

"You will complete the PlayList.java file which contains some method stubs for you. When you are finished you will need the following completed:

• Instance Variable
• Song[] list
• Two Constructors
• default constructor used to set the instance variables to default values
• initialization constructor used to set the instance variables

• Accessor and Modifier Methods for Instance Variable

• addSong(int x, Song s)
• method to add a song to the playlist
• getSong()
• method to get a song from the playlist
• public int numSongs()
• method to get the number of songs in the playlist
• totalLength()
• method to get the total length of the playlist specified in seconds
• removeArtist()
• method to remove any songs from the specified artist
• removeLength()
• method to remove any songs longer than the length specified
• shuffle()
• method to shuffle the order of the playlist - use the card shuffling example from the arrays presentation to help
• equals()
• I am providing you the equals method
• toString()

When you have completed PlayList.java, you can use PlayListRunner.java to test your program. This is a completed file to help you test your program."

We can see that the later lab not only provides less guidance, but also is more complex, asking the student to program multiple methods that can interacts with each other. I think my teacher did a great job of choosing labs that built on each other and giving us challenging opportunities (in the labs) to use our knowledge. Another thing I think my teacher excelled at was communicating with his students. He sent out emails all the time to remind us of due dates and was very accessible during school and before. If we had a problem, we could always ask him for help.

The parts that were most frustrating to me about the class were the quizzes and worksheets. I wish we would go over commonly missed questions on them in class. I realize that students can come in during lunch or before school starts to discuss the quizzes or worksheets in class, but I feel as if many of the people who need to do not. Going over just the most frequently missed question on the quiz or a couple questions on the worksheets would be really help students understand the concepts in the class.

What I can do to learn more in the class? I probably need to stop talking to our resident techno-genius, Zolie (pseudonym). That shouldn't be hard though, because I think by now he's moved to California, working for a company there. I should try to stop socializing, and knuckle down to do my work. Not quite sure if I'll be able to though....

Arrays Are Dope-Swaq

Arrays are arguably the most useful thing I have learned in CompSci so far. They have allowed me to store enough data within a structure to make Java be actually practical and useful in everyday applications. The example that most readily comes to mind would be the Sound Lab. I learned a lot from that about how to manipulate arrays, and about the usefulness of arrays.That program was the first one in which I actually felt the program would have utility to a consumer. I thought it was a well designed lab that taught me how to edit values of an array to accomplish what I wanted to do.

Here is an acrostic I made about arrays:

A - Arrays
R - R
R - Rays of Sunshine
A - And
Y - YOLO-
S - swag

I feel as if this acrostic accurately describes how I feel about arrays, because they seemed like a ray of sunshine in an otherwise dark language. Before, I had thought that java wasn't applicable to anything in the real world, but this lab helped me reconsider my position on the entire language.

While For Loops Run

While loops and for loops confuse me, because I don't really see any merit in using for loops. Here's what my teacher, Mr. Stephen (pseudonym), says about the for and while loops. "You use a for loop when you know how many times your program will run ahead of time, and you use the while loop when you have no idea how many times your program needs to run" [citation needed]. Of course, this is also the teacher who encouraged me to "talk to Zolie (pseudonym)" [citation needed], so his advice might not be the most trustworthy. At first, Mr. Stephen's explanation seemed simple, but the more I thought about it, the less useful it seemed. Why not just establish a while loop with a condition that counted the number of times the loop had run? Mr. Stephen's rule now seemed unnecessary. I guess I'll just disobey him, always use while loops, and that'll be fine.

Since I need to fill up half a page, I'll just fill in this space by showing that I know what a for loop is. The syntax for a for loop goes something like this:

for(establish variable; create condition; increment variable)
{
      <insert what the loop does here>
}

This contrasts with a while loop, for which the syntax is:

while(condition)
{
       <insert what the loop does here>
}

The while loop is much cleaner and simpler, and for those reasons, I prefer it over the unwieldy and unnecessarily verbose "for" loop.

Programming Lingo

It's tough to keep all these terms straight in my head. Apparently, a modifier statement is different from a constructor, which in turn is completely different from initialization constructor. Each one of these terms makes my head spin, and I can't tell them apart. I didn't think it was going to be much of a problem at first, but when the quiz rolled around, I realized how little I actually knew. For me, the largest problem was keeping everything straight in my head, and matching up the right terms to what I knew needed to be in each class. I finally figured out that the system works like this.

public class ClassName{
  <define instance variables>
  public ClassName(){ //default constructor
     <assign some default values to your instance variables>
  }
  public void setInstanceVariable(variable){ //modifier method
     instancevariable = variable;
  }
  public <instancevariable datatype> getInstanceVariable(){ //accessor method
     return variable;
  }
  public toString toString(){ //toString method
    return ""+ variable;
  }
}

Sorry if the post was dry, but i needed to make sure I could write out the concepts for my own use, and so that I could map out what every class should look like. I think the way I learned to identify each component was to think about what each part did in the structure of the class, and to learn the function of each method. For example, the accessor method is a "get______" because it accesses and grabs that variable's value for the user. That helped me spatially place each method in it's place and associate the name with the method. Thanks for reading!

Thirty Two into Sixty Four?

This unit in class, we learned about bits. How certain variables require certain amounts of space, and how bits quantify that amount of space. To most people in the classroom, those concepts seemed intuitive. Everyone nodded their head along with the presentation, and no one asked any clarifying questions. I however, was clueless. I had no idea how why mod existed. So I stumbled through the first problems of the worksheet, trying to sort things out in my head, and to make some sense out of the conflicting rules in my head. "Why could a int fit into double, but not double into int." I knew what the answers were, but it was only through a knowledge of other examples. I didn't have a rule that would help me actually understand why concepts were the way they were. I ended up scribbling some answers down (I know no one else does this), and praying that some of them were correct. If someone had asked me why I had answered what I did, I honestly would not have been able to defend my answers.

When I got the paper back, I was relieved to see that only three or four problems were marked incorrect. Mostly, I had missed the questions that had required casting. When Mr. Stephen (fake named used for anonymity) walked past with our worksheets, I asked him questions (these questions were relevant). He reexplained the box analogy, how a variable could store something, akin to a box, and how each variable was sized differently. That was why the data stored in a double (64 bit) variable couldn't fit into a int (32 bit) variable. The box example really made sense the second time around, and I appreciated the time time my teacher took to reexplain it.

To be honest, I think the best thing a student can do is to ask questions. It's a powerful tool to keep a student engaged with the lecture, and it often snatches extra knowledge for the student. All it takes is the courage to ask. That's programming with panache.