So we’re done, well, almost done. There’s only a little bit left and some grading to be done but, essentially, we’re done here. I’ve gotten some decent feedback already but the actual teaching evaluations have yet to come in. As I may have said on this blog before, I’ve actually been asked to teach this class again in the fall which I think will probably be easier and more organized than this last term.
So things that I think have worked:
- Getting the big picture across
- Speeding through the simple bits well enough that people are still learning from it but we had time to get to The Good Stuff
- Keeping the pace of the class at a reasonable level
- Making the homeworks have challenging bits without being overwhelming or too often
Things that I think could be improved next term:
- Getting solutions out ASAP.
- Having some mixture of programming and proving so that students can make use of skills they’re already building
- Give take home exams/projects instead of in-class midterm and final
- Streamline the presentation better. I’ve had trouble getting the timing of classes right, so we’ve ended a few minutes early a number of days. That’s not inherently bad, but it does mean that I don’t have a good sense for the exact time lectures will cover.
- Polishing up lecture notes and maybe distributing them in PDF form as well.
I think all of these improvements can work if I put some time over the summer into them. I’ll have roughly a month break from when I’m done with my summer teaching job til I’m teaching the theory course again.
Really, I’d like to spend even less time on simple automata next term, but I don’t know how much more I can cut about DFAs/NFAs/PDAs without meaning that I eliminate the first half of the course, effectively. A decent percentage of the students have already seen things like context-free grammars before so, hey, maybe that introduction can get cut down a little. The background for students here is more varied than most schools, but I think we can hit a decent compromise without just totally talking down to them like what happens in a lot of terms.
I’m also still debating a lot about whether to include more programmatic elements in doing the basic automata. What I’m envisioning is a simple language where we have the ability to define DFAs/NFAs etc. as tuples and also have the ability to define operations on the automata by having some kind of case statement that deconstructs the data. For example, maybe something where you could define the complement as an operation that takes a DFA, which you can then deconstruct into a tuple, and then you’re allowed to use that data when defining the new DFA. Then we can actually make these constructions more obviously constructive. I’m probably going to hack a bit on writing these languages over the summer.