Hello, Stanford! (Part II)

by Louis Tur

In my previous post, "Hello, Stanford," I mention that I googled around to find answers to the Stanford iTunesU Swift course. Though, I did not come across (at that time) the single best resource for these assignments: m2m's github.

M2M has repos for each of the assignments, along with a very detailed README that links the solutions/steps to each projects required tasks and extra credit solutions. The repo (for this assignment) is very cleanly written, includes tests, and cleverly solves the problems.


I have completed the second assignment's mandatory requirements, though it certainly took longer than expected. I can attribute this to a few things:

  1. Operations on a stack - In the assignment, you're suppose to add operands and operators and evaluate them in a first in, last out (FILO) fashion. The way the stack is evaluated is by starting at the "top" (the last element in an array) and traversing backwards, checking each element to performing an appropriate action. Conceptually, this isn't really difficult to think about. However, I've never used a calculator in this manner and performing functions on a stack almost requires planning the expression to evaluate ahead of time. Performing calculations in this manner isn't all that intuitive and having to constantly remind oneself of how the calculator should work, bogs down process. I've illustrated one example of what I mean: In this case "sequence normally" means the sequence of button presses you would perform on a standard calculator and "sequence for assignment" is how the calculator in the assignment should work. Even in this relatively short example, you can see how operators and operands are almost handled in reverse. And in theory, the sequence: 6 ⏎ 5 ⏎ 4 ⏎ 3 ⏎ 2 ⏎ + + - x should evaluate as 6 x (5 - 4 + 3 + 2).

  2. Recursion - The manner by which you evaluate this stack and later form it's expression statement, is done through recursion. Fortunately, the lectures covered the bulk of this code, but recursion is always going to be trickier than non-recursion.

  3. Swift - Obviously this being a new language that's significantly different from ObjC is going to lend to some additional overhead.

  4. Scaffolded Code - In order to get some consistency in student code, it is necessary to define very rigid requirements of how it needs to be written. Otherwise, you'd likely get many different versions of code (time consuming to grade) or code that doesn't do exactly what it should (not just bugs, but oversights and missing requirements). One problem with this is that you're essentially filling in a Mad Libs blank with the correct word instead of any word. You can't really come up with a workaround solution when there are many guidelines established.

  5. Boredom - Academic challenges are fun, but there comes a certain point when you realize you're an adult and you actually don't have to do everything possible to get something exactly right. In the schooling environment, it's possible to get 100% on a task.. in life, there's no analogous and quantifiable way to judge things. Outside of school you begin to understand there's a necessary trade off between time and quality, and sometimes your attention is more importantly directed elsewhere. So getting the formatting exactly right on a string's output becomes understandably less exciting than "netflix and chill".

Louis Tur

"How" has been the single most used word in my literary arsenal for as long as I can remember. I've never really been satisfied knowing that something works, but only by knowing how it works.

Read more from this author