7 ms·
I work at Monash University in Melbourne, Australia. Last year we moved our foundational course in data structures and algorithms from Java to Python, with grea
by candeira 12y ago
I work at Monash University in Melbourne, Australia. Last year we moved our foundational course in data structures and algorithms from Java to Python, with great success. This is a course that used to be taught in C, then moved to Java. I tutored it as a Java course, and was in charge of adapting the tutorial (classroom exercises) and laboratory (programming assignments) materials when we started using Python to teach the unit.
The main content of the course hasn't changed. Complexity, Big O notation, sorting and searching are introduced in the first two or three weeks. Students work through the usual implementations of arrays, linked lists, stacks and queues (both array and linked-list based), trees, heaps, tries, etc. All these data structures are explained first as chunks of data with external functions for the operations; then a second time as objects with methods for operations, once object orientation is introduced in week 5 or 6. Iterators are introduced as an abstract interface to list-, array- and tree- walking. Where relevant, we explain every operation twice, showing the iterative and recursive approaches. The course ends with two weeks of lower level work, where the students hand-compile pseudo-Python to working MIPS assembly.
The move to Python gained us, among other things, the freedom not to have to explain Java's generics and access modifiers. Many of our students have never programmed with a text editor before our unit, and dropping them into the big boilerplate world of Java micro-management was not good for them or for the course. We used to spend too much time on syntax and other details ("native types are like this, reference types are like htat") that we should have been spending on data structures and algorithms.
With Python, we even have time to explain idiomatic Python iterators and generators, and to discuss Python scoping rules (which come up again when we work on local variables in their hand-compilation tasks). So we still teach a bit of language-specifics, but we don't feel we are shackled to have to teach them. Also, teaching them idiomatic Python is a good deed after spending the first three or four weeks in a not very idiomatic subset of Python where we maintain explicit indices, update them by incrementing or decrementing them manually, use while loops the condition checking on the index value, etc. as required by the course content.
I don't have data on the results, because I was only the adjunct adapting the tutorial materials. The only difference I noticed was that students had less support from their IDE, and that some common errors (attempting to access attributes on None is the top one) that used to be picked up statically are now runtime errors, as expected. There didn't seem to be any big problems from Python's lack of lexical typing. Type errors are still caught, again by the runtime instead of the IDE and, if anything, this is a better exercise for students, since fixing them requires better understanding of what the program is doing.
If anyone is interested, I can ask the lecturer about the outcomes, but just from the fact that neither she nor anybody else teaching the unit has raised any issues the second and third times the unit was taught I can tell it's all going smoothly.
- deleted 12y ago[deleted]
- eru 12y agoWhat's lexical typing?
- btilly 12y agoI would assume from context, it is the ability to declare a variable in a lexical scope to have a specific type in that scope. With static typing you would then have the ability to catch use of that variable with the wrong type and make that a compile time error. That said, I believe that pylint could statically catch some of the type errors that are being referred to.
- candeira 12y agoI may have made this term up myself; I am on the go and can't check it. As I use the expression "lexical typing", it means that the type of a variable can be ascertained from examining the text of the program, without needing to run it. Python is strongly typed, but dynamically typed: you can only know for sure the type of a value by checking the value at runtime. This by analogy with "lexical scoping", where you know where a certain name will be bound just by looking at the program's text, while with dynamic scoping, the stack is what determines where a variable is bound, and you can only know about it at runtime. I guess I should have said "static typing". I probably made the mistake because lexical scoping is also called static scoping, and I was writing in a hurry.