This is an open invitation to my students to critique my course, CIS 450. I'm a little discouraged with the content of the course and am really interested in talking to Dr. Mizuno and the faculty about revamping it.
I know that the CIS faculty is currently consdering some modifications to the core curriculum overall. The new CIS 450 needs to react to these changes and I would like to make it centered more on actual architecture and less on the relationship between C/C++ and assembly. I don't see this as a rewrite of the course so much as a refactoring. I'm actually considering some research into the topic and perhaps finding or writing some practical software to support it.
Anyway, I'm curious to hear my student's opinions. This seemed like a forum where opinions could be posted anonymously and those opinions could be discussed. I believe the anonymity is mostly unnecessary as I usually take criticism and praise independently of my grading, but that risk does, of course, still exist. Anyone who isn't willing to accept that they might be subjective in ways they don't realize is being subjective without realizing it.
Anyway, opinions. Please.
CIS 450 material
Sterling, et. al.,
While reviewing cis450 please keep a few things in mind. For starters, this class is the first time several of us have ever seen C++. Of course I heard that CIS 208 is being turned into CIS 308 and will be required someday soon, but even then, still keep the "introduction to C++" part in the course.
I also think that the course is just fine the way it is. I have learned more in this course than I have learned in any course so far (except maybe CIS 300). Maybe the instructor should compare the SPARC and Pentium and JVM and acually run through assembly in those architectures. But all in all, I would have to say that my novice opinion does not share Sterling's negative sentiments about the course. I think its fine.
Regards,
Tim Weninger
C++ and such
Well, the CIS curriculum is currently very Java-centric. There's quite a bit of history dating back to around 1997 and 1998 for this change. The department is now revising the curriculum and it looks to me as if Java is going to fall out of importance to be replaced by multiple languages. Most prominently will be C++, C#, Java, and possibly Python from the discussions I am privy to. Anyway, it's probably that all students will be interested to a variety of languages earlier in the curriculum, which is something that graduates have been begging for in their exit interviews since at least 2001, when I got my B.S.
The C++ introduction will be required on some level. First, not all students will have seen it before, even if it's required for our curriculum. EE and CE majors often take CIS 450 and their requirements are, obviously, different. However, I hope to be able to condense it to a focuse just on pointers and classes---i.e., the cool stuff.
Then, perhaps, we can focus more on other architectures. As for more SPARC. Nah, we left SPARC. SPARC is dying. I would be interested in looking into PPC, though. I've not studied PPC much and will probably start doing so this summer as a possible replacement for SPARC. The JVM study could have potential. And then, there's my old (er, actually new) favorite, Parrot.
Thanks for the feedback!
Cheers.
Hmm
I think reducing the importance of Java is a bad thing... unless it was replaced with C++ completely or the like. This nice thing about having 200, 300, 501 and 560 completely java based is that we learn the language inside and out.
If we spread the focus out, we really don't learn deep concepts about the lanaguage and we'll graduate as useless as MIS majors.
Personally, I wouldn't have minded getting pounded by C++ and Java at the same time.
450 was indeed and excellent class; I learned a tremendous amount, but we seemed to run out of steam near the end of the sememster. I'd say, throw out SPARC, and bring in the same things we did for the Intel architecture for the PowerPC. Keep JVM in there (perhaps a bit more in depth since we're losing SPARC), and call it good. You're teaching methods are excellent and you really seem to know the material (that can be a problem in some classes).
CIS 450 Review
Although you aren't very satisfied with the material of the course, I thought you did an excellent job teaching it. One thing that I thought would be interesting, would be to make more difficult homework assignments and instead of us working alone, grouping us up. It is always good to work with other students, because you always come out of the situation with +1 or more perspectives.
One possible solution for this would be instead of having a final, incorperate everything that "we" the students have learned throughout the semester into one program and then for a final project have us draw up memory maps and do pointer arithmetic for the assembly code.
-Seth-
I think that the focus on poi
I think that the focus on pointers and classes is exactly what i needed as a cmpE. If anyone wants to know about the design of architectures then eece 649 is for you. I think that this class was a nice bridge between the hardware world and software world. It was good to see how the high level languages get translated into assembly and also to see how assembly interacts with hardware. I am surprised that the cmpE curriculum doesn't have this class as a requirement. It was much more useful to me than cis 501.
Maybe but...
I hate group projects. When I was a student, I was the one that did all the work and I didn't have +1 perspectives, I just had +1 leeches. The only time this wasn't the case was when I took CIS 540. As such, I have a pretty sour opinion of group projects. Furthermore, I don't know that the content of this course is very good for group work. Mathematics tend to require individual effort (even if it helps to have group study).
On the other hand, group work is one of those things that is an important focus of industry interest right. Thus, I'm not going to just write off the idea, but group projects will need to be carefully constructed.
I'd call it a success.
I came into this class not knowing a thing about C++, assembly, pointer arithmetic, or pretty much anything to do with computer architecture whatsoever. I'm going to come out of the class feeling like I have a pretty good working knowledge of the above subjects, which is monumental to my confidence as I continue with the CS curriculum.
With that in mind, I'd say you did an excellent job at the helm, Sterling. It's obvious that you know your stuff, but you conveyed that knowledge in a way that students like myself who didn't know any of the material beforehand were able to comprehend your lectures and follow your instructions. That, I think, should be the goal of any teacher.
As far as changes to the course material, I haven't the slightest idea what to tell you. Only years later will we be able to determine how much the tools learned in 450 will help us in our professions.
Ryan
General language focus
First, the general language focus is a topic to be brought up with the likes of Dr. Wallentine or Dr. Schmidt. But let me say that I partially agree and disagree. In one sense, I agree. If we go too general, the curriculum will fall apart and be way too general. However, the single language focus is in itself a bit crippling. Without a good exposure to three or four different languages (and at least a couple radically different), you're stuck in a box.
I feel the same way about CIS students being stuck in Microsoft Windows. I far prefer Linux and Mac OS X for myself, but this doesn't mean that my preference is right for everyone. A lot of this is a matter of taste, available applications, etc. Yet, a student who hasn't forced themself to learn Linux or Mac OS or something different is stuck in a box. Anthropologists take this a bit further than I would in stating that a people-group's language determines and limits how they think, but they are essentially correct. If you don't have a word for the difference between blue and violet, then you have a harder time seeing the difference.
The same is true in computing. If students are only exposed to a subset of the variety of ideas out there, they will not be able to see the full spectrum. Therefore, I believe a strong exposure to Java, C++, SML or OCAML, and Perl or Python would provide this kind of variety. We can still pick a language to work with, but we should be careful not to become stuck. Otherwise, we just turn out tech school grads who know the popular language now, but haven't the skills to quickly adapt to a new language when the need arises.
As for the rest of the comment, I think that's the general direction I'm heading.
Software to Hardware mapping
You're correct. This course is in Computer Science. Thus, the focus is on software. We'll leave the hard core machine architecture stuff to the hardware junkies. The really interesting part for this course is, "How does my program use it?" Mostly, I think the course is on the right track, but I think a stronger focus on work that is architecture related versus work that is compiler related is the distinction I wish to make.
For example, how does a switch statement look in assembly? This was an interesting question and I think I'll do something similar in the future, but it begins to delve into the land of compiler design rather than architecture. In a way Computer Architecture forms the bridge between the hardware, compilers, and operating system. I want to find the right combination of connective tissue.
As for pointers, this is the key to this course. I think pointers are the key topic of this course. I will not lessen their importance. I understood what pointers were good for when I took AP Computer Science in high school, but I didn't really understand how they did their magic until I took this course (or CIS 350 as it was numbered then). Anyway, the essence of pointers cannot change for this reason.
Radical ideas
One thing I'm strongly considering is writing a couple programs to help with the course. It would be a fairly simple matter to write a program to automate all the work of the pointer proofs. I'm thinking that I will write a program next semester to automatically work out pointer arithmetic proofs and show the result. This way, a student could enter any random expression into the program and get back input showing the results. Of course, this rules out homework using pointer proofs as every student would get perfect (unless they're dumb enough not to check their work and make it perfect). Instead, I'd have a few extra in-class homeworks/quizzes on the subject to make sure you could do it without the tool.
I'm thinking that the same thing could be done for memory maps. This would be a bit more tricky, but it shouldn't be too difficult to parse a compiled program's object code to retrieve information about the global memory sections and simulate program execution. This would be considerably more involved. It's conceptually simple, but would be tedious to actually implement a simulator of this sort.
I think both would make for interesting research projects, so I might suggest them to the faculty for a student to implement. It'd be nice to publish something again too. I'll have to look around first to make sure no one has done something similar already. :)