A Panegyric for the Year

Oscar is a genius. He is kind, caring, and has a depth of knowledge and experience about programming that never fails to astound me. These past few weeks, I've gotten to know him very well, and a couple things have stuck out to me.

The trait immediately apparent was his enthusiasm for new topics and for learning. When I proposed that was try to make a directory of LASA, he told me that it was a great idea, and we started work that day. Oscar's receptiveness to new ideas stuns me. I couldn't ask for a better person to bounce ideas off of; he'll point out any flaws in the plan, and best of all, work towards solutions.

Less easily noticed, but just as important, is his willingness to teach (with considerable skill) those around him. He's helped me learn Objective C, not through traditional lecture, but through demonstrating the basics, then letting me try what I want to. If I have a problem, I can simply roll over a couple feet and ask Oscar for help. He is my Wikipedia, my crutch, my best programming bud. He appreciates something many teachers do not--that the best learning often comes from experience. Through making my first app, Counter, I learned the structure of Objective C, how to link buttons to do things, how View Controllers work, and how to make app icons. Oscar, you are wonderful. The best part of it is that through this, I've also learned the process for programming. I've shared it with you below.

Step 1: Type up what you think you want.
Step 2: Press Run
Step 3: Go through each error, and google it.
(optional) Step 4: Cry.
Step 5: Implement the solutions discovered in Step 3 and/or stumbled upon during Step 4.
Step 6: Repeat until you have a working program.

I am extremely grateful to Oscar. Because of him, I now feel as if I have a proper grounding in Objective C, and could use it to make what I wanted to. Oscar, if you ever read this, just remember: you are brilliant. Even more importantly, you are kind and compassionate. I'm sad to hear that you're not planning to pursue any CS classes next year, but I respect your shrewd decision. Stay fantastic and never forget how outstanding you are.

Oh right. This is a blog post for APCS. Mr. Stephens, I was wonderfully productive. I never took any of my free days, because I enjoyed everything I was doing in class. Here are some things I've learned in the short span of time you gave us.

• Objective C
• Structure
• Syntax
• Layouts
• R
• Vectors
• Matrices
• Graphing and Manipulating Data
• Importing/Exporting Data

I did stuff, and I hope it shows. Mr. Stephens, this class was the best I had this year. I appreciated your teaching style, as well as the atmosphere you fostered inside the classroom. I can't thank you enough for introducing me to harnessing computers to accomplish the minutia of life. Your class has changed the way I approach problems.

A Quick Example
Recently, I took pictures of the textbook for a class, instead of bringing it home. Coming home, I found that all the pictures were rotated to the left. Now, a year ago, I would have opened every one (20 pictures) in preview, and flipped them manually. However, now that I've turned into a lazy student, I decided instead to see if there was a way to get the computer to do it all for me. Googling my question, I found that there was an app called Automator that would accomplish everything I wanted to. So I opened it up. Again, I found that I had changed. Where last year's me would have complained about the complicated layout and closed the program. I jumped into the project with gusto, trying to pick up the language, which I did in five minutes. My final workflow allowed me to paste photos into a folder, have them rotated, and packaged into a combined pdf. I had just invented the world's most cumbersome pirating software.


EDIT: I just realized that I wrote an off topic blog post, so here's another one.

Learning Java has been eye opening. It's a cry different from History or English. There are no tricks you can use to escape being wrong. When you make a mistake in Java, you can't laugh it off or hide it with clever prose*. Instead, you must face up to your mistakes, and find a way to make your mentally handicapped computer understand what you want it to do. It's pleasantly different and challenging.

Another lesson the class has taught me is the importance of flow**. Before the class, I hadn't experienced a state of flow in years. After elementary school, I became less focused, and easily distracted. I hadn't experienced an activity where I found I could work for hours on end. I found that in the Breakout game that I coded for five hours straight. I remember starting on it, then slowly going through each of the error messages in turn. The next memory I have is my father screaming at me for being up at five am. I had worked completely through the night (but hey, at least my program worked). The experience boosted my self esteem greatly--I had started to think I lost all the intelligence I had in elementary school, but being able to churn out a product I was proud of gave me comfort. But right, flow. I just wrote this blog post in one hourlong burst. Although I'm not always able to get into states of flow, I feel amazing when I do enter those states, and I try to achieve that level of immersion in all my work (often to no avail).

Wow this is a long blog post, but I'm not done. Another great part of my year was that I was able to meet amazing people. Arnav, whose knowledge never failed me--he helped me through every single problem I brought to him, Zoli, whose prickly exterior concealed a caring, passionate person excited about sharing his knowledge with others, Oscar (see earlier praise), and Aryaman, my faithful programming partner, who was willing to catch every single misplaced semicolon and test my silly inane Scratch games. A large part of the reason I've been able to meet these people and get to know them is the atmosphere of Mr. Stephens' classroom, which welcomes all stragglers. I've found the computer nerds at LASA to be the kindest, most helpful group of people at the school. You all are amazing, and I believe that this is largely in part to the way Mr. Stephens structures the classes and encourages his students to work together. So here's another shoutout to you, Mr. Stephens, you've made the CS program at our school exceptional. Thank you.

*apart from "try{} catch{}"
**"Flow is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does." 

Should Cargo-no-t be used to teach Recursion?

Recursion is convoluted and difficult to understand -- at least for a student like me. The way that my teacher introduced it was to have us play around with a game called Cargo-not that implemented basic recursion with a  drag and drop programming system. The problem was, the game didn't really give players a realistic view of why recursion was powerful. The power in recursion lies in the fact that a function using recursion can call itself on different parameters. This lets recursion efficiently divide a large problem into smaller chunks, allowing the problem to be solved using dynamic programming.

I feel that while Cargo-not was a great game, it did not show me the true potential of recursion. Go ahead and try the game out, I'll wait. Okay, done? Now let's examine why I feel this game is not appropriate for teaching purposes.

The game makes it too easy to simply hard-code answers to the problems.

The game uses a star system to reward players based on how concise and efficient their code is. Ideally, code that utilizes recursion more efficiently will have less command blocks, because it manages to use recursion instead of repeat the same line of instructions over and over again. The code for moving all the way to the left could be written two ways:

Inefficient, 0/3 stars

Smooth and simple, recursively supreme

The different between these two algorithms would be 3 stars, which might be enough motivation for a completionist, but I found that for most of my classmates, simply completing each problem was enough of a challenge for them. The game did not guide us towards finding the best solution to each problem, rather, it led students towards hard coding the answer.

I am Smarter than a Fifth-Grader!

Recently, I looked at the requirements for the Computer Science AP, and was surprised to discover that I knew most, if not all, of the information that was going to be tested. The only topics that we haven't covered on the AP curriculum relate to Searching and Sorting.

      B. Searching
           1. Sequential
           2. Binary

      C. Sorting
           1. Selection
           2. Insertion
           3. Mergesort

We also have covered Sequential Searching, but we need to look at Binary Search. The  Sorts are still a mystery to me, though, and I hope to learn them quickly. I'm pretty surprised at the ease of the class, and how our teacher has managed to teach us so much information in such little time. I feel well prepared for the AP test, because I recognize all the topics presented in the Course Overview. Even so, I hope to have some review time, simply because some of the methods will be hard to remember without any reference material during the test.

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!