Small surprises while grading programming languages exams | Hacker News Reader

Small surprises while grading programming languages exams

cs.uni.edu

21 pointslincolnq7 comments

Bound and free variables: when I was taking a programming languages course, these concepts popped out at me as being incredibly important. But I had been programming for years without understanding that there was a distinction. Are they important for programming, or just for understanding how programming languages are implemented?

Regarding bound and free variables, I was reverse engineering Python's scoping semantics and discovered this little gem:

  def a(x):
    def b():
      print x
      x = 5

    b()

  a(3)

What do you expect? Prints 3, right? Nope. UnboundLocalError, because 'x' is referenced before it was assigned. It turns out that variable bindings in Python are all lifted to the enclosing 'scope' (usually a function block). So x is not a free variable in the 'print x' line... even though the interpreter claims it's not bound, either.

(This behavior is a royal pain to implement in an interpreter. You can't just recursively execute expressions; you have to scan the scope you're about to execute for free variables which are later bound in that scope.)

Python 3k adds a new keyword, nonlocal, which actually lets you print out x that way (you'd declare nonlocal x before printing). Check out PEP 3104: http://www.python.org/dev/peps/pep-3104/

> "I can't do much to ensure that students will care enough to hit the books to overcome their disappointments, but I can change what I do."

> "there were far more 0s in the final grid of grades. I even had a couple of 0s on quizzes, where students simply failed to show up."

If this was happening to my class (I am not a teacher!) I would feel it was reflecting badly on me, not the students. Poor grades are one thing but I would feel that zero results (due to increasing numbers of students not showing up) says I need to change my teaching style. A bunch not showing up means they have no faith in your ability to help them fill the gaps in their knowledge to the point they might be able to scrape through with a pass.

I skipped a lot (okay, most) classes during my time in college. It didn't really have much to do with the teacher -- I was just lazy and would rather sleep / write code. It's not necessarily a lack of faith as much as it is a lack of ambition, in some (many?) cases. Sometimes I would take courses where they were teaching topics where there effectively were no gaps in my knowledge. That didn't make them poor professors, either, it just meant I shouldn't have been made to take the course.

If anything, I would think consistently low grades would be worse. This means that people are attending the class, but not "getting it". I think it's trickier with programming; I met many people in my programming courses who just flat out couldn't understand the basic concepts, despite paying attention, taking copious notes, and spending hours studying.

What's wrong with accumulators? They are useful for transforming head-recursive code into tail-recursive code.

Granted, accumulators can't really improve code that traverses trees. But for code that traverses lists, like zip... accumulators can be useful. Also, the added complexity isn't too bad.

In Okasaki's _Purely Functional Data Structures_, he adds an accumulator variable to the binary (and RB, etc.) tree membership test as an optimization, because it turns the test from up to 2*depth time to constant depth+1 time. (It's exercise 2.2.)

I suspect what the post meant was that while accumulators certainly have their benefits, reflexively using them everywhere is probably a sign that you don't really understand them.

This is an awesome blog - read some of the other posts.

Reply on news.ycombinator.com