Week 9
What did you do this past week?
Took an exam, did some grading, and worked on projects for the rest of the week. I also held some pretty long office hours throughout the week; the topic is virtual memory, one of my favorite subjects in OS, and also definitely a challenging one to understand.
What’s in your way?
I’m currently spending almost all my time on school, so I don’t really have time to buy groceries or cook. I’d like to eat out less, as it can be pretty costly.
What will you do next week?
I’ve been too busy with this week’s work to worry about next week. There will definitely be homework I need to catch up on, but seeing as I have two projects due very soon and midterms are over, it should be a bit of a break.
If you read it, what did you think of Paper #8: Interface Segregation Principle?
In my opinion, the interface segregation principle is just a specific instance of the single responsibility principle. The paper gives some more reasons why this specifically is important though — without enforcing the separation of interfaces, you open up the possibility that your base classes change according to derived classes, which is completely wrong, as well as just having unnecessary dependencies. It showed some pretty cool object-oriented patterns like the adapter pattern, but the usage of multiple inheritance was the most elegant. Of course, the implementation of multiple inheritance can be tricky (e.g. the diamond problem), and languages like Java get around it by allowing multiple inheritance of interfaces but not classes (I believe C++ has a similar policy but more confusing semantics).
What was your experience of functions, closures, and decorators?
I’m a big fan of functions and programming languages built around functions (i.e. functional programming languages). They’re composable and make things very easy to generalize, as shown by some of Python’s functional features like map and reduce.
Closures are a fun consequence of mashing functions and mutability together. In an immutable language, everything would be captured by value (which isn’t even an expensive operation — we can share thing since they never change), but in a language with mutable variables, it introduces more complexity. C++ lambdas simply won’t capture variables unless you specify = or & meaning by value or reference. Python, it seems like, simply makes everything a reference (in the context of closures), allowing functions to hold internal state implicitly, which can definitely be used for some cool tricks.
Decorators are a new concept for me. They seem like a very useful tool for easily modifying existing code, and seem to work by taking advantage of Python’s dynamic nature. The other language I know of that has features that might be similar (metaprogramming) is Lisp, another dynamically typed language.
What made you happy this week?
With the quantum midterm done, I’m done with midterms for now. I’m content with the grade I got on it.
What’s your pick-of-the-week or tip-of-the-week?
Strict typing. Church numerals. When you put these together, you can get some pretty cool things going. For example, if I were to write Haskell code to represent qubits, I could say that a quantum state is represented by some complex amplitude vector data QSTate = QState (Vector C). But this is hard to work with. How do I know how many qubits are in this state? I could inspect the length of the vector, but that’s ugly, not supported by the type system, and doesn’t prevent me from shooting myself in the foot trying to combine mismatched states. If only there was a way to tell the type system how many qubits there were. Enter Church numerals. Let’s define some types like this:
data Zero
data S tdata One = S Zero
data Two = S One
...
Since these are types, the type system knows about them! We can then parameterize our QState type like so: data QState n = QState (Vector C). Even if that type doesn’t influence the internal representation, we can enforce operations between our quantum states with the type system now:
inner :: QState n -> QState n -> C
tensor :: QState n -> QState n -> QState (S n)And this allows us to enforce writing code that is much more safe and structure by taking advantage of typechecking.
