As many of you know, one of the goals for my study leave has been to prepare to teach CMPT 383, Comparative Programming Languages. The calendar says this course is:
Various concepts and principles underlying the design and use of modern programming languages are considered in the context of procedural, object-oriented, functional and logic programming languages. Topics include data and control structuring constructs, facilities for modularity and data abstraction, polymorphism, syntax, and formal semantics.
I took a similar course in my undergrad, and I think it was really useful in helping me see the broader picture of what programming is.
I have been thinking about the course off-and-on for more than a year. I had been forming a pretty solid picture of what the course I teach would look like and things were going well, despite never having devoted any specific time to it or really writing anything down.
Then I talked to Ted. Ted has taught the course before, and has thought a lot about it. His thoughts on the course differed from mine. In particular, he opined that “logic programming is dead, so why teach it?” (Okay, maybe that’s not a direct quote, but that’s what I heard.) So that leaves functional programming as the only new paradigm worth talking about.
He also convinced me that covering too many languages in the single course puts students into a situation of too many trees, not enough forest. (That is, they get lost in syntax and don’t appreciate the core differences between languages.)
Basically Ted did the most annoying thing in the world: he disagreed with me and he was right.
But, there is a lot of stuff that I hadn’t considered before, but might be worth talking about:
- Type systems: static/dynamic, strong/weak, built-in data types, OO (or not), type inference, etc.
- Execution/compilation environment: native code generation, JIT compilers, virtual machines, language translation (e.g. Alice → Java → execution), etc.
So, what the hell do I do with all of that? Any ideas how to put all of that together into a coherent course that students can actually enjoy?
July 8th, 2009 at 12:07 pm
You are _SHITTING_ all over SFU’s proud tradition of teaching 2 weeks of Prolog and 12 weeks of Haskell.
July 8th, 2009 at 12:46 pm
Yea, I think this could be one of the more interesting courses at SFU. I’d throw out the current curriculum and not each any specific language at all. I’d cover such topics as:
– OO vs. Functional vs. Procedural programming
– Type Systems, as you mentioned
– interpretative vs. complied language (little bit of cross over with compilers, but not all students take 383 and 379)
– Closures
– program structure: command line vs. web app. vs. desktop app
– Data manipulation languages: SQL, Regexp
– little bit of language history. (knowing why and where C came from as opposed to say Python)
My goal in the course would be to educate the students on why one language *type* might be better than another in any given situation. Given this knowledge the students can go out on their own and find a language that meets the requirements for their current situation.
July 8th, 2009 at 2:03 pm
Let me know when you get it all together, so I can take it.
July 9th, 2009 at 9:39 am
Greg, I couldn’t have said it better if you’d voiced my own thoughts.
But even so, I’d like to add a few more.
1. I just don’t think the notion of “programming paradigm” has much leverage any more. Haskell enthusiasts bill their language as “the world’s best imperative language” (if you find that statement unlikely, perhaps you should drink a pitcher of Monad Kool-Aid and reread), while Perl optimizes tail-recursion (just not in a way that anyone would want to actually use). Java has almost-closed closures and C++ supports generic algorithms.
Enticing as it might be to divvy the world of programming languages into paradigms, it doesn’t seem to usefully differentiate them. There are real differences, but the paradigm notion doesn’t quite capture them.
2. A concept that I see as crucial, and that you didn’t list, is the relationship between binding, static checking, and efficiency. This is central to modern programming. Distributed systems want to bind at runtime, static checkers want to bind at compiletime (so they can check and also to generate efficient code). Many of our students just don’t get the issues involved in static libs vs. DLLs, Java/C++ vs. Web languages, compiletime vs. runtime assertions, reflective languages, debug binaries versus production binaries, and so forth.
3. Static checking probably deserves its own bullet point. Not just type checking, but static checking of memory usage, data invariants, and the use of non Turing-complete languages (i.e., fixed loop bounds) to program specialized applications with stronger static checking. This stuff has already entered industrial practice in specialized cases (phone switches, MS Windows device drivers, network protocols) and will likely increase in range of application in the future.
July 9th, 2009 at 7:09 pm
So Ted… This is what you do instead of reviewing my assignment? 😉
April 19th, 2010 at 6:09 pm
[…] have mentioned here before that I was planning to teach CMPT 383. It ended up being a no-go this semester because of a very productive capstone project team (more […]