Blog #7

Your blog entry must explicitly answer the following questions about the class (mark the questions in bold in your post):

• What are you most proud of doing last week?

I received 3/3 on exercise 4 (“Array”) on Monday. I believe I was the first to finish it in the 11 am section.

• What ability or skill did you use to make that moment the most proud of?

I used my skill at C++ programming to finish the assignment quickly. I also guessed that array would be the subject of an exercise, because while discussing it in the day’s lecture, Prof. Downing seemed to be carefully skirting its implementation details.

• What impact did what you do have on other people?

I helped some other students understand the requirements of the exercise, fix compilation errors, and debug their attempts.

• What did you think of Paper #7. Liskov Substitution Principle.

Of the three Robert Martin articles we’ve reviewed so far, I find this one the least objectionable. As in the prior articles, the terminology and the principle itself are given somewhat fuzzily, but Dr. Liskov did continue to develop the principle and make it more rigorous in later publications than the one this article cites.

The article is beneficial to the extent that it leads us to think about preconditions, postconditions, and type invariants.

• What did you think of Exercise #4. Array.

It was surprised at the difficulty much of the class had on Monday. I finished the exercise pretty quickly. Possibly I just got lucky because I happened to write il.begin() and il.end() instead of begin(il) and end(il), and only the former syntax works, even though it seems like both should work. I know at least some people got hung up on this on Monday.

As for the std::array type itself: wrapping a native C array in a safer type is a great idea. It adds a huge amount of convenience thanks to its support for copying and equality, it hides the pitfalls of C’s array-to-pointer decay, and it allows implementations to offer bounds-checking as a debug or safety feature.

The array type is also our first demonstration of non-type template parameters: the length of the array is an integer template parameter. I would love it if this led to a discussion of dependent type systems, in which the return type of a function can depend on the value (and not just the type) of the function’s arguments. But I don’t expect this class to have that discussion.

• What did you think of stack<T, C>?

I’m not sure the cognitive and compile-time burdens of that C parameter are justified.

• What made you happy this week?

I always enjoy talking about functors and monads. I also liked getting out of class early on Wednesday. On the other hand, I saw the dentist for a semi-annual teeth cleaning and that’s never a fun time. (If you’re planning a career as a dental hygienist, I’m sorry. And why are you even reading this?)

• What’s your pick-of-the-week or tip-of-the-week?

My tip of the week is this advice from Brian Kernighan, one of the creators of Unix and the C programming language:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

See you next week!