Toronto-based reading group that meets weekly to read computer science books and papers.
Currently reading: The Little Typer
Hey everyone, apologies on dropping the ball last week, so we have two recaps in one this week, let’s get caught up!
First off next week Chris will moderate installment 2 of Wilson’s survey paper, “Uniprocessor Garbage Collection Techniques” (http://www.cs.rice.edu/%7Ejavaplt/311/Readings/wilson92uniprocessor.pdf), and we meet as usual Friday Feb 13, 6:30pm at Bento Miso. You can check the reading list for everything else we have covered, https://github.com/CompSciCabal/SMRTYPRTY/wiki/Reading-Schedule .
Jan 27, Ben helped us navigate some intriguing ideas in the realm of language semantics in Strachey’s excellent paper, “Fundamental Concepts in Programming Languages”. As this topic was I think outside many of our comfort zones there were a lot of diversions where Ben helped explain some of the basics of this field. For instance, a new idea for me was the idea that one should try to identify precisely the true meaning of a given program in a mathematical sense. This is a fascinating concept to me, that I will likely keep thinking about for some time to come, as in my mental model, I think I’ve tended to think of a program as instructions to be performed, and the semantics of what the code does would live at a higher level of abstraction, maybe involving some documentation or some helpful comments in the source code.
Feb 6, Leo started us out on our month of garbage collecting by covering the first 2 sections of Wilson’s survey paper, “Uniprocessor Garbage Collection Techniques”. Garbage collection has a long history in computing, and covers quite a broad spectrum of topics, and Leo did a great job of pulling us through in spite of our many attempts to diverge into tangential discussions. From our perspective today, I think it’s clear that the author’s motivating statements that languages with an effective GC make it easier for programmers to reason abstractly about their programs are quite true. Just imagine trying to teach a high school class on programming, and you ask the students to copy an array. In Python you just tell them to set the new array equal to the old one “A=B”, whereas in C you first have to teach them about how memory works, what a pointer to memory means, and then how to free the pointer later. This is not necessarily a problem, but it isn’t at all what you wanted to teach them. The C programmer is never free to reason completely at the higher level of abstraction as there is always some additional cognitive load to deal with the memory. Section 2 covers several different approaches to GC and their pros and cons and I think helped give us a clearer picture of how we will proceed with our own implementations later this month. There are a lot of subtleties to the different approaches and a lot of trade-offs that need to be considered and I think we will all be going over this section again before the end of the month.
Until Next Time, Scott?