Archive for January, 2015
I’ve spent the past two weeks working on a program that stores and manipulates data in a binary search tree. This, of course, means I’ve been up to my ears in recursive functions.
For my non-techie friends, it’s the idea that you write a method (a little program that does something) and it calls itself over and over again. And you just kind of have to trust that it works. Trust that a method calling itself over and over again will get the job done. Because you can’t actually see what it’s doing, that would just be silly.
And my point is this–I don’t like it. I much prefer writing programs iteratively. I like writing out all the steps so that I can see each and every one and know exactly what my program is doing and when. It’s the whole “just trust that it will do what you want it to do” that makes me a little edgy.
Hi, I’m Rachel and I’m Type A.
I like to think of the recursive function as the “trust fall” of the programming world. You remember those? In all office-type tv shows, there’s a company retreat where some overly sentimental counselor makes the employees turn their back on each other, close their eyes, fall back, and trust that a random person will catch them. All in hopes that people will get in touch with their feelings, bond with each other, work better as a team, and make the company more money. Humbug!
My recursive functions CONSTANTLY fail. And I feel just like someone who closed their eyes, fell backwards, and woke up with a concussion about 4 minutes later.
How does that happen? I was 2 feet away from the person. They were directly behind me. The instructions were clear—it’s not like they didn’t know I was going to fall into them. This is not supposed to be complicated! And yet, I somehow ended up on the ground.
Next step in the process: I have to look at the situation and try to figure out why this happened. It’s not as easy as it seems. It’s not immediately clear because I had my eyes closed and couldn’t see anything. Also, nobody can talk to me about what happened—that would just be too easy.
You might find yourself saying “Rachel, clearly a gale force wind came out of the west and pushed you out of the way” or “Naturally, the person who was supposed to catch you was highly allergic to bees and they saw one on your back. So, of course they didn’t catch you.” Both of those scenarios are completely reasonable, I assure you. And so I do some research, try to figure out which of those completely plausible factors is the culprit–and then I have to find a way to make it so it never happens again.
Naturally, I do the only reasonable thing: I move the retreat activity into a hypoallergenic clean room with no windows. And if I do the trust fall here, I can trust that the other person will catch me, right? The answer to that question is a firm “maybe.”
And this is what coding is like (at least when I do it).
Aaaaaaaaaand school is back in session. I already miss vacation.
I’m up late working on the first coding project of the quarter. Sometimes I wish code were more like people. When it throws an error, I want to be able to shake my head disapprovingly and say “you know what I mean” and have it laugh, say “yeah, I know,” and start working.
But, no. Of course not. It does silly things like print out my binary number correctly the first time I call it, but put a “0” at the front of it the second time. Or it throws an error every time I try to delete memory I dynamically allocated. Every. Single. Time.
I can only assume this stems from my love/hate relationship with pointers.
Every time I think about my relationship with pointers, I imagine an actual coffee date with a human-sized arrow. And the arrow always looks sad. One time, it cried and said “The program ended and you just LEFT ME THERE!” Yes—this is what I think about during class. I can only assume Anson had the same daydreams when he was in college. 🙂
So, I am up late trying to delete the memory and make my pointers happy—and thus far I’ve been gloriously unsuccessful. The problem with coding late at night is that bad decisions are made. Bad, bad decisions. For example, deleting every occurrence of the word “const” in your code. Why, you ask? Well, that’s a great question. I honestly have no idea. At the time, it seemed like a great way to make all of my addition and subtraction operator overloads work better. And now my code “smells.” It has “bad code smell.” Which is apparently a real thing (trust me—I learned about it in college).
I’m sure I’ll get it eventually. Still have a couple days left to get this all sorted out. Add back all the consts, get rid of memory leaks, and-well-everything else in the requirements. Should be a fun weekend! 😉