cs101snapsummary.md

As I mentioned at the start of our time with Snap, there were two primary goals in working through these first few labs, and that is to get acquainted with repetition statements (repeat, forever...) and to learn about defining your own custom blocks and parameters. This ability to group and name pieces of code is the foundation of computer science, and starts to get at the idea of what it truly means to build abstractions.

If I had to summarize computer science in one sentence it would be "To notice and exploit structure to solve problems". I think this will sound familiar to a math educator - this is how we solve problems in any field, after all. Even so, I think it is useful to consider how this idea relates to this particular context.

1. Modularity (or, orthogonality). Programmers seek to separate problems into small, independent pieces. In a large system, you want to be able to modify an individual piece of code without having to grasp the entire system. This is the only way to solve complicated problems without having the complexity of the solution make it cave in on itself.

2. Clarity. Poorly considered code often reads like a story written by a 5 year old - this happens, then this, then that, and so on. Things are certainly being done, but there seems to be no rhyme or reason as to what, when and how. Noticing structure allows programmers to write concise, clear and intentional code. It allows us to communicate about how the different aspects of our solution relate to each other. That makes it possible for others to understand how everything fits together, and how to modify or extend the code we write.

3. Correctness. You wrote some code and it gave you the right output (at least for every input you've tried). But, have you truly solved the problem? While programmers are writing code they often evaluate its correctness by doing "mini-proofs". Let's take a look at an algorithm for finding the largest element in a list,

define function max(list):
  if list has one element, return that element
  otherwise
    let el be the first element of the list
    let r be the rest of the list
    let m be max(r)
    if el > m then return el
    otherwise return m

We noticed that the problem can be solved by reducing to a smaller problem. After providing a base case (single element list), we can then construct a proof by induction and be sure that our algorithm works for all possible inputs. This is a bit of a contrived example, but while building larger systems such insights are key.

In summary...

I hope that your experiences of playing around with Snap will allow you to take a new perspective on how you work with the calculator and the Computation Layer. In order to accomplish a particular goal within your activities, you will sometimes need to create very elaborate constructions. A major concern while doing this is to manage complexity. Programmers do this by identifying structure, splitting it out into independent code blocks, and taking care when naming and composing those blocks.