Talk:Imperative Programming I

Comments from 2011

Likes

• Examples in the lecture are prefect.
• Proving by invariant.
• I liked how the course used a beginner language and introduced many of computer science structures that are key to programming. The lecturer clearly knew how to structure the course well.
• I loved learning about the use of procedures within modules and I have had much fun playing with the Oberon language. Specifically, I am very grateful to have learnt about pointers and the ability they have to improve list structures.
• The course was well structured and the lecturer made valuable points about all the material studied.

Dislikes

• Much too slow.
• As the online lecture notes were only partial account of lectures, I sometimes found that it was hard to understand and review some of the material when out of the lecture theater. However, the Wiki Corner was very useful and this issue is only minor.
• Oberon.
• Capitalising every END! Nothing seriously.
• IF Oberon THEN True ELSE False
• Too much time spent at the beginning and not enough in the end - hash tables and binary trees could certainly be explained in more detail.

Missing topics

• I would have liked to learn a bit more from scratch how to use the "in", "out", "arg" "err" etc. modules imported. I think we learned very well how to write the main body in a module: the procedures using many different algoritms and types etc, but I found it difficult in the practicals to write the stuff in the module which was "all around the procedures": reading different kinds of input, making proper error messages etc.
• Perhaps, more algorithms?
• I would have liked more information as to how to use Oberon to create a user interface, but I think this outside of the lecture course...

Other comments

• I would say longer, problem sheets with problems that ease you in to the topics would have been helpful. Sometimes, having the first question be really hard is discouraging.
• Can't wait for IP2!

Did you attend most of the lectures?

• No, because everything that happened was extreamly trivial. but most of time i felt sleepy so couldnt be really concentrated.

Practicals

What was the most interesting aspect of the practical?

• The material was clearly written by a very motivated writer. There was a lot of background information. The best part was the use of unix tools. Would have been nice if the entire practical/course had been about taco-bell programming with sed, xargs, etc.
• I liked the topics of the practicals: especially the codebreaking practical. That gave motivation to immerse in the problems.
• The practicals had extremely helpful and cheerful demostrators who made the practical times very exciting but also meaningful.
• I found learning about how to encrypt files and how they could be decrypted very interesting, as I could envisage how this might apply in reality.

What, if anything, do you think should be changed?

• Less text in the practical, or at least more easily marked questions. Couldn't find them.
• The Lab Manual referred to an algorithm from a question on an old problem sheet; this algorithm should be described in the lab manual instead.
• Ideally the language used would be kept completely to Oberon for the sake of learning, so that I could have had more complete control of the program I was writing (and thus be responsible for any and all errors).
• The first practical had enough work load. However, the second one could have included additional work and there was plenty of time to do some additional practice.
• It would be helpful to have some example of what the final lab report should look like
• I think that everybody had time to do 3 laboratory exercises. It would certainly help the understanding of the subject material.

Comments from 2010

Pace

Loop loops should have been shown in more detail.

The start was probably a bit slow ~ first 1-6 lectures.

Likes

Most of the material was new to me, and I found it very interesting.

Overall style of lecturer was good (comments on unix, python, hash tables, low level memory/call-stack architecture). The four practical projects were also nicely "real-world".

It felt relevant and useful.

Implementation of Dijkstra's algorithm, as I have previously attempted to code this algorithm myself.

I liked the practical part of the course. Enjoyed constructing clear, logical statements.

The lectures often included material that linked into other courses in interesting and diverting ways.

Cool practical!

Lecturing about pointers has given an interesting tool to add to my repertoire. The very comprehensive lab manual made the practicals a lot more understandable.

Pointers – they're fun!

Spivey's general presentation techniques.

Almost everything about this course is right; stimulating ideas to think about were abundant; real-world applications are underlying all of it; and analytical skills were taught.

Dislikes

Oberon is a nightmare.

Oberon is an obsolete and hideous language. Python would serve the purpose much more effectively.

I still have no love for Oberon. If looking for a language with explicit pointers, expose Computer Scientists to C like the Physics dept. does. If looking for a minimal garbage collected language with implicit pointers, use Lua. Using an ancient language like Oberon does admittedly have advantages with regard to teaching, but languages which still see real-world usage must have some advantages too. [For Oxford Physics computing, see here and here – Mike.]

Doing Dijkstra's algorithm before actually studying it.

Missing topics

GUI.

Although I agree with the reasons given for not choosing C or Java, Oberon is a very poorly supported language and maybe others should be reconsidered.

I cannot say so: many of the things I had either never heard of before, or never thought of in that way.

Other comments

Great lectures. Perfect course synopsis. Materials easily accessible on wiki. Lecturer open to questions and willing to help even out of lectures. I do not like the choice of programming language (Oberon), especially because we have not been able to build programs from scratch – in practicals, we were just editing code.

The lectures were engaging and well presented. I very much liked the 'easter eggs' of references to great literary works and pop culture.

Windows > Mac >> Linux.

Dr. Spivey is brilliant; and completely mad. I expect very few lecture courses to surpass this one in insights. The books are old-fashioned and out of print, but definitely worthwhile, informative and helpful. Annoyingly, Dr. Spivey does not produce elaborate notes or use Powerpoint, so the lectures 'die' and/or are not reproducible in case you miss them; I trust his wisdom and talent in that the "art of lecturin'" has died since Powerpoint. Also, his general knowledge off-topic educational comments are very informative and brilliant. May he live long and prosper.

From a customer's blog

Googling "Oberon quine" leads here: http://www.dow2db.com/content/quine-oberon. I quote:

One of the courses I took this term was the imaginatively titled "Imperative Programming I" (aka. Programming II as "Functional Programming" - Haskell - was last term). The lecturer for this course is very good, but the language used for this course is one that most people won't have heard of: Oberon 2. The rationale for choosing this language is given here and here - in short saying that "modern" languages (Lua, Python, Ruby, etc.) are too high-level, and languages like C are too hard. After using Oberon for a term, I still have no love for the language (unlike using Haskell for a term, which resulted in some affection for it), and could argue for using C / Lua instead of Oberon for a long time (the Physics dept. teaches their 1st year undergrads C, so it can't be too hard for the 1st year Comp Sci undergrads, and so on...), but doing so wouldn't benefit anyone (as the choice of language is at the lecturer's discretion, and he likes Oberon - as I like Lua).

As previously said, the lecturer for this course is very good. One of the reasons for this is the interesting practical exercises and problem sheets which he set. For example, the last question on the last problem sheet was to "Write an Oberon program that, when you run it, prints out its own source text". [Spoiler omitted]

Footnote: I suspect that at least some of the recent updates to the rationale for Oberon were due to some of my comments on the course feedback form. This is great, as it shows that the lecturer is reading and responding to feedback. I'm slightly confused by the statement on that page "I can't stand the 'used to be the bees knees, but is deprecated in version 5.1' business" - I suspect that he is referencing Lua 5.1 as neither Python nor Ruby are anywhere near a version 5.1, yet the list of things changed / made deprecated in Lua 5.1 contains nothing that I would class as "the bee's knees". One could also the discuss the general point of whether languages changing (or, if you prefer, evolving) is a good thing or a bad thing, but again, this is not the place to do so.

Thanks for expanding upon your comments. I left this note:

Oh, the 'deprecated in 5.1' business was really a reference to Python, modulo the fact that I can't be bothered to keep track of what version number they've reached, any more than I care what language features are deprecated this month.

The physics guys hardly write any non-trivial programs, so they don't have chance to encounter the full horror of C. Besides, I am reliably informed that next year they will be learning either Python or Java – which it will be has yet to be decided.

How did I get here? By googling "Oberon quine" of course.

Comments from 2009

Likes

Really nice that we are studying "real things" instead of purely learning syntax and constructs on their own.

Examples of complex real world applications.

Seemed not so hard as functional programming – same style as A level.

The information provided to help with the practicals.

Mike really hates Windows. Keep up the abuse!

The whole course was insteresting, and the extra problem classes were interesting.

It overlapped well with the Algorithms course, so was a good application of things learned in the course. The practicals were interesting and challenging.

Microsoft bashing, lecturer's unique style, analysis involving women drivers.

All the topics were well explained, good examples and notes. Although I had seen a lot of the material before, going to lectures was still worthwhile and helped increase my understanding of the ideas covered.

Loop invariants, etc. – formal way to look at program correctness.

Lecturer explained everything in a way that could be easily understood. Even though I already knew almost everything we covered, I learned and realised many things I didn't think about before.

Dislikes

Find better books on reading list that introduce properties of the imperative programming paradigm as opposed to programming language specs / too advanced books.

The course was slightly slow-moving, especially for the first few weeks. Invariants were used heavily for very simple ideas, but less and less towards the end.

Missing topics

Makefiles.

Other comments

Very enthusiastic – makes the material interesting.

Good topic, good to assume no previous knowledge, a lot of clear examples, material easy to digest, excellent handouts – contain core material but omit extra stuff to give an incentive to attend lectures. Good sense of humour / anecdotes really help memory and recall of material. The BEST lecture course so far.

Would be better if problem sheets were split into smaller ones (i.e., 8 overall, not 4). This would make it clearer which problem sheets corresponded to which lectures. (I ended up doing most of the material in the problem sheets before it was covered in lectures because of this.)