----------------- From: Gordon Cormack To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 09:09:23 -0500 As you know I've been a proponent of Scheme and SICP for many years. I would sooner teach a pair of courses that blend Scheme and Java, rather than a Scheme course followed by a Java course. This is also not a new idea. I believe that this approach emphasizes the fact that abstractions (lists, containers, functions, whatever) exist independent of their implementations. In the bad old days, students were inclined to believe that a "list" was something cobbled together from records and pointers. Now they think that it is some piece of magic from the class library. Scheme has a minimal amount of magic, and can be used to demonstrate the essential abstractions of computer science. At the same time, Java can illustrate both low-level and class-library realizations. I'm also a big proponent of an advanced stream. I hear more and more discontent with our curriculum from our best students. At least two of my acquaintances maintain joint majors in CS (as opposed to Pure Math alone) only to fulfil scholarship requirments. I think this would be a good opportunity to allow students to skip some of the fill courses (especially cs246) and perhaps to introduce some "topics in problem solving" option. I am tired of the perception that the field of CS has nothing to stimulate our neurons. Our current curriculum promotes this perception. ----------------- From: Prabhakar Ragde To: plragde@ds1.cs.uwaterloo.ca Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 14:23:03 -0500 > As you know I've been a proponent of Scheme and SICP for many years. Yeah, you and I go back over a decade on this point. > I would sooner teach a pair of courses that blend Scheme and Java, > rather than a Scheme course followed by a Java course. I think this is more or less what is intended. Certainly in the last three weeks or so of 143 we can foreshadow Java constructs, or even just lay them out -- I can't imagine talking about mutation, for instance, without talking about imperative assignment statements, and as we get more into OO territory, the parallels become easier. And the first few weeks of 144 will have Scheme examples alongside the Java material. Were you imagining more of a mix than that? It would start to look like a comparative programming languages course. > I think this would be a good opportunity to allow students to skip > some of the fill courses (especially cs246) and perhaps to introduce > some "topics in problem solving" option. The trick has always been to get the right students to take such options, and the wrong ones to not take them. --PR ----------------- From: Nancy Day To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 09:25:55 -0500 Hi Prabhakar -- A couple of quick comments on your proposal: - I like the idea of a course sequence that gives the students the opportunity to learn a functional language first, and I would probably be willing to teach such a course - I have not used Scheme, but I am quite familiar with Haskell and ML, and I use them regularly. I have two concerns about the use of Scheme: 1) I believe Scheme is an untyped language, and I worry the students will be missing an important concept in understanding how types work; 2) I believe Scheme's syntax still looks very much like Lisp, which is rather cumbersome. Both Haskell and ML have the additional features of types and better syntax. But I recognize that many universities use Scheme and therefore the availability of good textbooks is a factor in the choice of language. ---------------------- From: Prabhakar Ragde To: nday@cs.uwaterloo.ca Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 14:23:37 -0500 Thanks, Nancy. >1) I believe Scheme is an untyped language, and > I worry the students will be missing an important concept in > understanding how types work; Scheme is weakly-typed, or maybe it's better to say dynamically-typed. You can say (define my-constant 4) and then (boolean? my-constant) would return "false", but (number? my-constant) would return true. Parameters to functions don't have to be of a specific type. The added "struct" function in HtDP also creates a type and provides a type-checking predicate. >2) I believe Scheme's syntax still > looks very much like Lisp, which is rather cumbersome. There are a lot of parentheses, certainly. HtDP cleans up some of the keywords (though "lambda", alas, is left as is). --PR ----------------- From: Jack Rehder To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 10:47:15 -0500 Hi Prabhakar, I have read over your proposal and have some observations. First the positive: - I believe that the advantages of a cs143 course in Scheme, which reduces the effect of diversity in background is particularly relevant here at UW. Even with our three entry points, there is still a diversity of background, particularly in cs133. This causes attendance problems, and participation problems because some people are intimidated by those with more experience in the room. - I agree that the deficiency in algorithm development is a problem in our current curriculum. - the minimal syntax would probably be helpful to some students, although I believe that the current cs13x model of providing templates and focusing on programming patterns has mitigated the effects of Java's complexity to a certain extent. - I am in general in support of providing choice so that we don't force students into a particular mold. students do not all learn the same way; nor do they all have the same goals. Now the negative (mostly logistical, rather than curriculum based): - With the co-op program, I think at UW the 'sell' of a non-mainstream language will be particularly difficult. I think this may be even more true of CS students who want to build up their CV. You may find that the takers are Math students, not CS students. - an additional course offering will kill any possibility of retaining M-sections for 1A students. It is already almost impossible to schedule M-sections with our three entry points; a fourth entry point will be unmanageable. The scheduling is done too far ahead, and the selections will not be known well enough in advance. If this is further complicated by the ability to switch once they arrive, the M-sections cannot be maintained. I think one must determine if this is an acceptable cost of the new proposal. - a once-per-year offering of CS143 and 144 may be the desire, but I'm not sure if it's feasible. We originally planned to offer cs131 once per year and cs132 twice per year. But it has not worked. We are now offering these courses every term of the year. We have found that we have needed to accommodate other entries (are ELAS students not to be given the choice of the new curriculum?) as well as allowing for failures. Can someone who fails cs143 in Fall term take cs133 in Winter or Spring? It seems doubtful to me. -there are too many entry points to choose from for incoming students. Students will not be able to choose, and I'm not convinced we can help them. Nor am I sure that we can convince THEM that they will not be adversely affected by their choice. One suggestion that would come to mind would be to eliminate cs134 as an entry point. If they already have lots of Java, then great: take 143. Having choice is good, but only if we feel that students have the tools to help them make a good choice. I'm not sure that we can give them such tools. -planning for multiple entry points is extremely difficult. Schedules are determined 6-7 months in advance with no knowledge of how many students will be in each stream - we don't even know how many students there will be in total! The more entry points we have, the harder it is. If we guess too small, it is difficult/impossible to add more sections of the course; if we guess too large, there are insufficient resources and students are not distributed properly. Switching a course from one type to another is complicated because of the different teaching patterns of the courses. For example, it is not possible to switch a cs134 section into a cs133 section if we learn that the demand has shifted that way because they are taught on different schedules. The only way that I could see this working well is for all first year courses to be scheduled in a standard 3-hour lecture/1 hour tutorial pattern so that we could more easily shift from one schedule to another. Pedagogy: The cs13x sequence has particular pedagogies associated with it: practicums and pair programming, to name just two techniques. Would these be abandoned in the cs14x sequence? And if so, then I think there should be some question as to why they would be part of one sequence but not another. Endpoint: I have not taught a course at the 2nd year level. However, I would be particularly concerned that students from one stream versus another would have some different backgrounds. Instructors will find it difficult to bring previous experience examples into the course. Some students will be stronger in one area than another. Whether this is a real disadvantage is not necessarily the only consideration - some students may PERCEIVE that by having chosen one particular stream, they are placed at a disadvantage. I should leave comments on this to those who have actually taught 2nd year. ----------------- From: Prabhakar Ragde To: Jack Rehder Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 14:31:27 -0500 Thanks, Jack. I have a couple of small comments on your comments (most of them need more lengthy pondering). >One suggestion that would come to mind >would be to eliminate cs134 as an entry point. If they already have lots of >Java, then great: take 143. Mark suggested this as well. It's worth considering. >The cs13x sequence has particular pedagogies associated with it: >practicums and pair programming, to name just two techniques. Would these >be abandoned in the cs14x sequence? And if so, then I think there should be >some question as to why they would be part of one sequence but not another. I have suggested eliminating practicums in 143. It's not the way I choose to design courses, and since this is an alternative stream, I don't think the pedagogies need mirror each other. The mainstream course, and the one with the more difficult syntax, may be more in need of practicums. I am still undecided about pair programming; I'm talking to people about it. Currently I'm leaning to "try it if you like, here are the rules and regulations". --PR ----------------- From: Gordon Cormack To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 14:43:19 -0500 On Tue, Dec 16, 2003 at 02:15:18PM -0500, Prabhakar Ragde wrote: > Java material. Were you imagining more of a mix than that? It would > start to look like a comparative programming languages course. Yes, I was thinking of having them more closely linked than that. To be honest, when I first conjured this up, I was thinking of Scheme and C in parallel. My idea was to present the standard elementary searching/sorting/counting/graph algorithms and data structures in both. I believe that a bilingual presentation helps to show how particular details vary, while essentials don't. I don't think this bilingual presentation adds much complexity to the course. If it does, we are focussing too much on details. Java has a whole bunch of other stuff that may or may not be germane to this presentation. My initial guess is that I would use a pretty restricted subset. I'm not exactly sure what you mean by 'comparative programming languages' but in most such courses they do a bland overview of several languages in sequence, noting the peculiarities of each. It has been a while since I thought about this in detail, so forgive me if I'm not as lucid as I might be. ----------------- From: To: plragde@uwaterloo.ca Subject: Re: curriculum proposal Date: Tue, 16 Dec 2003 09:53:25 -0500 Dear Prabhakar, I just read your (detailed!) proposal. Wow that's ambitious. I am sympathetic to your ideas. In particular, I agree that students need to spend more time thinking about problems and less time coding. I am also a huge Scheme/LISP fan. I have two comments. The first comment is a possible problem with your proposal and our current co-op program. Even if students want to do 143/144, there my be considerable anxiety how to get their first co-op job without having at least one term of Java (either 133 or 134). I'm talking about students who have 1A in Fall, then their first co-op job in Winter. I think your idea would work much better if we had a "traditional" year, with school terms in Fall/Winter and workterms, co-op or not, in the summers. Everyone would be in sync after their first year, and everyone would be ready for the same jobs after 1A/1B. In addition, co-op causes problems, because it fragments years. It may be difficult for students to make the transition from 143 (functional-first) to 144 (java/objects) if there is a work term in between. The current transition (133 to 134) seems much more manageable. The second comment is about teaching "imperative-first", "objects-first", and "functional first". One practical solution may be a single course in "imperative-first", followed by two parallel courses, one in "object-oriented" and the other in "functional-programming". What I envision is the first course, would be "imperative-first", and would teach all the fundamental stuff in CS134 (algorithms, data structures, proof of correctness), but none of the "software engineering" issues of data abstraction, objects, functional programming, etc. The trick, and I think an ongoing problem, is to completely avoid object oriented stuff in the first course. I really like Pascal for this. Contrary to what you say, I find the syntax is pretty simple, and it is very expressive (as an imperative language). I'm not familiar with CS133. Is this taught without objects? One trick would be to make a version of java that NO OBJECTS WHATSOEVER. Make something like a wrapper that inserts the object declarations. It should look like C, not C++ (but without the pointers). Anyway, these are just first impressions. I'd like to hear what others have to say. ----------------- From: "Craig S. Kaplan" To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Wed, 17 Dec 2003 09:59:06 -0500 (EST) Prabhakar, I read through your proposal. I don't think there's much I need to add apart from my vote of support. I'm a fan of Scheme and I believe that it makes an excellent language for teaching those students interested in computer science rather than computer programming. Scheme's greatest virtue for teaching CS is that it exposes the raw mechanisms of abstraction, offering students a framework for understanding the rich language structures they will learn later. I don't think you'll have problems recruiting a sufficiently large group of incoming students to make the experiment worthwhile. I am enthusiastic about seeing this project through, and would be willing to teach one or both of your proposed courses in the future. ----------------- From: Gordon Cormack To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Wed, 17 Dec 2003 12:27:09 -0500 This message is a followup to Nancy's suggestion that we use ML or Haskell. I have a lot of respect for these languages, but, having taught them for decades (well, Haskell isn't quite decades old, but ML is) I cannot support them as introductory languages. The details of the syntax and of the type system interfere with the essential concepts. These are fine concepts to be taught in a subsequent course - perhaps one that replaces cs246. Scheme's syntax may be annoying, but it is easy to understand. One of the great virtues of Scheme is that, in a 50-minute lecture you can present everything you need in order to send students away with 5 programming assignments ranging from trivial to extremely difficult. Saying "everything must be parenthesized, and instead of (1 + 1) you must say (+ 1 1)" may elicit groans from the class, but they have no comprehension problems. Here's an example script from a first lecture for bright students. You can make up the voice-over: Scheme saved on Sunday November 21, 1993 at 9:15:23 PM Release 7.3.1 Microcode 11.146 Runtime 14.166 1 ]=> 1 ;Value: 1 1 ]=> (+ 1 1) ;Value: 2 1 ]=> (define x 1) ;Value: x 1 ]=> x ;Value: 1 1 ]=> (+ x 1) ;Value: 2 1 ]=> (lambda (x) (+ x x)) ;Value 1: #[compound-procedure 1] 1 ]=> ((lambda (x) (+ x x)) 1) ;Value: 2 1 ]=> (define double (lambda (x) (+ x x))) ;Value: double 1 ]=> (double 1) ;Value: 2 1 ]=> (double 2) ;Value: 4 1 ]=> (define twice (lambda (f x) (f (f x)))) ;Value: twice 1 ]=> (twice double 10) ;Value: 40 ----------------- From: Michael Demko To: "P.L.Ragde" Subject: Curriculum Proposal Date: Thu, 18 Dec 2003 00:30:22 -0500 (EST) Professor Ragde, I'm writing from a hotel room in High Level, so this might not make a tremendous amount of sense, but I found your proposal too interesting to leave alone. Give or take a few months, I am a 4th year CS major. I have tried to avoid restating comments that have already been made. -I am not convinced that expecting students to become competent in ML in time to complete their first assignment is any worse than expecting students to become competent in Java in time to complete their first assignment. Compiling code without solidly understanding type inferencing would be difficult, but trying to correct a NULL pointer exception is difficult even if you know what a pointer is. Earlier assignments could require that types be explicitly specified in code to reduce confusion. - I like the idea of teaching Scheme and C (or 'simple Java') in parallel. Any student having to learn Java or C++ in cut-time with no previous background will be at a disadvantage unless they are familiar with (in particular) arrays, pointers and type casting. These are the concepts I find myself explaining to many of my younger friends taking courses in OOP. - I think many people without a programming background have a difficult time learning OO design and the syntax of a new language concurrently. In addition, OO practices are difficult to justify to someone with no experience writing reasonably large or complex programs. - It might be worthwhile to consider how many students secure co-op postings that require knowledge of Java in their first year. Most students I knew who were placed as programmers were asked to code in VB or had considerable high school experience with C++. But then I was 4-stream... ----------------- From: Prabhakar Ragde To: Michael Demko Subject: Curriculum Proposal Date: Thu, 18 Dec 2003 11:00:56 -0500 Thanks, Michael. We are not doing a wholesale review of first year in which everything is up for grabs; the suggestions for ML, Haskell, or parallel Scheme/C are interesting to think about, but will not go anywhere unless those individuals wish to actively pursue them. I am looking for comment on a specific proposal. If there is overwhelming opposition, I will withdraw it; if there are reservations, I will try to address them; and I need to hear from people like Jack (who was a great help with 134 a decade ago) about logistics. I like the idea of the parallel Scheme/C approach in that it demonstrates the universality of the concepts even as it shows how they can be expressed quite differently, and having more than one semantic model is valuable. But I can't see it in a first course; you'd have to severely wrench both languages towards each other. Recursion without mutation is a lot easier in Scheme, but you can't talk about recursion in C or Java without introducing some notion of frames. You can't do anything much in C without mutation, but introducing it in Scheme complicates the semantic model considerably. There's also no textbook support I know of, and I am not a great fan of homebrewed course notes as the primary resource for a course. I'll try to find out how much Java coding there is in a first work term. It's complicated in that some companies may use "Java experience" as a filter, rather than as a genuine requirement. --PR ----------------- From: rmgolbeck@uwaterloo.ca (Ryan M. Golbeck) To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Thu, 18 Dec 2003 09:53:47 -0500 Mornin', I can't really speak to its effectiveness as a teaching tool, but other than that I think it's a great idea to offer the additional entry point. There are a lot of cool programming concepts that you can experience in scheme that you just don't get out of using other languages. I remember when I read SICP, I was pretty amazed at some of the things introduced, even in the beginning chapters, as things I have never thought about before. I realise that the course wouldn't be taught with SICP (and I haven't read HtDP myself, but I have heard a lot of good things about it), but teaching in scheme should open some eyes. In the posted responses, people have commented about scheme's syntax. And, like you pointed out, there are historical artifacts (the lambda keyword, etc), the parenthesis should not be a big problem. With the proper editor, one that will do the indenting of code for you, it is very easy to nearly ignore the parenthesis and read the code based on indentation. I'm fairly sure anyone who codes a lot of scheme will read it this way (since counting parenthesis and guessing where you are is horrible), the editor is very important. Fortunately, DrScheme is one of the editors that will do this for you. I wish this option was available when I started. -Ryan ----------------- From: Lisa Joy Rubini To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Thu, 18 Dec 2003 14:03:46 -0500 (EST) I really do appreciate the mentality behind the model you suggested. There are some major issues with the first year courses in regards to the development of algorithmic skills. Often when I experienced a student with difficulty in first/second year courses in regards to programming, the underlying cause is a lack in skill in designing the solution or in the transition to implementation. Now, as you might suspect, there are some downfalls and as downfalls are easier to talk about, they are much longer than my praise. Please don't take this to mean I do not agree with your proposal. I don't like the idea of this alternative being more 'challenging' than the normal 13x version of the first year. While your proposal tries to emphasis that this course is not meant to be more challenging, you do admit that "the audience is likely to be mostly stronger students", and in the long run this will attract students "might enjoy the challenges and extensions". This may give the course the perceived notion of being more challenging and if terms pass with bright students taking the course, this perception could be saturated into the course material and teaching style. The fact that CS144 transitions from Scheme to Java, and converges with CS134 material could also give the perception of CS144 as more challenging, since students may see CS144 as "two courses in one". Some of us average students would be interested in this course sequence and I agree that this course will be beneficial for non-cs students who don't feel a strong coding background is necessary for their careers. Since many of these students tend to worry about their ability in computer science gearing this course to brighter students will discourage these students and thus not be of benefit for them. Secondly, there is the issue of gender here. To have this alternative perceived as more 'challenging' one would probably discourage women from taking it. Technology and computer science is masculine culture and in that culture an expert is a male figure. This behavior can be exhibited as early as the junior years of elementary school and continues into university and beyond. If the image of the average student taking the course is that of a "brighter than most" student, then you will probably scare off many bright young women since many of them will be unable to associate themselves with the type of student that would take this course. Considering that women's enrollment in CS is still decreasing - is this something that would increase women's involvement or decrease it? In all curriculum issues dealing with Computer Science, I personally feel this is of great importance to consider. We must ensure our curriculum is not flawed to discourage women from participating to their fullest ability. Please feel free to contact me further about this issue. Sincerely, Lisa Rubini 4A Computer Science ----------------- From: dan brown To: plragde@math.uwaterloo.ca Subject: Scheme proposal Date: Fri, 19 Dec 2003 11:16:59 -0500 (EST) Hi Prabhakar, I don't know if I'm the only CS faculty member whose first university CS course was in Scheme, but I suspect I may be. (And yes, I realize that, with C$1, that will buy me a bad cup of coffee...) However, here are some reminisces from Spring, 1992, when I took 6.001 at MIT: 1) I don't believe that the claim that different backgrounds were mostly smoothed out is correct. I remember several of my friends (mostly women) who were not experienced coders getting very lost by how to think like Scheme, while those of us who were already fluent in multiple languages did well. This is true even though I don't recall anyone who knew a functional language before taking 6.001. I remember lots of tears, honestly, and I remember 6.001 being the point where many of my friends started to live in tutors' office hours, and in the dedicated lab. While I understand that you don't want to use the Struggle and Intimidation of Computer Programs book for this course, I still think that this may repeat. 2) There was an incredible joy in using an interpreted language again when I took 6.001; I'd been using Pascal/C since I was in high school, and Basic always felt dumb. I remember how an early 6.001 problem set made fractal images (2-D Serpinski gaskets, the fractal snowflake, etc.), and then basically said "go play." A later problem set, about objects, involved building an adventure game, and I remember how easy it was to change the game's world, by just executing a few set! commands. To this day, I'm much worse at debugging compiled code than interpreted code. Not having to wait, but just seeing the results, was incredibly seductive. I think this is one of the huge advantages over languages like C++ or Java. 3) I actually think that the course you've described is a good fit for students from other departments in the Math Faculty, and that it should be targeted at them as well as at our own students. 4) I wonder about resource limitations for this new course. Can we teach a good course within our means? The MIT EECS core courses have enormous resources: Faculty teach recitations (Abelson taught my 6.004 recitation) and the courses have extremely well-staffed labs. One other difference is that roughly 2/3 of MIT students take 6.001, so everyone knows piles of people who have done essentially the same problem sets and can help them. (There's no honor code at MIT, but explicit cheating in 6.001 was rare.) 5) One consequence of the 6.001 experience was that students often had a terrible time getting used to the imperative (C/Pascal) mode (which comes much later at MIT). I don't know what things would be like for OO. I do worry that CS 144 may also cause lots of tears, and may be the course that is a bigger pain than 143. 6) I think that the soggy typing of Scheme is actually a plus, not a minus. 7) I am not aware that 6.001 being in Scheme reduced access to internships for MIT students. On the other hand, the fraction of MIT students needing internships was smaller than the fraction of UW students needing co-op placements. But I have to assume that quickly, co-op employers will get used to it, as long as 143 stays small. In general, then, I think it's a good idea. I think the idea that it will smooth out differences in background is wrong, but I think that we've got to do something to make it clear that CS isn't all about syntax, right from day 1. I do worry, though, that it may require more resources than we easily can expend on it. Happy holidays, -dan brown ----------------- From: Prabhakar Ragde To: dan brown Subject: Scheme proposal Date: Fri, 19 Dec 2003 11:35:06 -0500 Thanks, Dan. I can certainly believe that SICP, as a required course, would cause tears and living in the lab; that was my impression upon reading it recently, which caused me to turn to the gentler approach of HtDP, and to suggest that this approach be optional. If you have half an hour sometime, perhaps you can take a look at the online version of HtDP and give me your first impressions. We have pretty good instructional support in first and second year here; full-time undergraduate tutors, ISG coordinators, dedicated labs. My plan for 143 calls for leaning on them less than 133 does; if it proves necessary, we can increase dependence on such resources. I admit that I have less of a sense of how 144 will work out; again, I am convinced by the fact that this has been the required stream (not an option) at several institutions for several years. The students in 144 will already have seen some of the CS2 material (lists, trees) in a Scheme context, so we can contrast functional and imperative approaches, as well as recursive and non-recursive approaches. (I always felt that nonrecursive deletion from a binary search tree was a terrific argument for recursion.) I am a little more worried about Java being the imperative language, but I don't think it's realistic to do anything about that currently. --PR ----------------- From: Troy Vasiga To: plragde@uwaterloo.ca Subject: Schemes and counter-schemes Date: Fri, 19 Dec 2003 16:58:07 -0500 Prabahakar, My response is in three parts: Pedagogical, Administrative, Political. Pedagogical: To begin, I love Scheme, and I love teaching Scheme. It is a 2 week topic in CS241, the goal being to compare an interpreter against a compiler, and (typically) interpreted languages against (typically) compiled languages. Further, a lot of students really love it. Here is a typical email (received this term: names are hidden to protect the enthusiastic) "Scheme is the best programming language...ever. That's all I have to say. I love it." So, I think students who take it will really enjoy it, and learn a lot from these courses. To hit on a point mentioned by Jack, I will briefly comment as a 2nd year instructor. CS241: Since Scheme is taught in CS241, students coming from two different perspectives may feel either bored or slightly disadvantaged: however, this is a solvable problem for CS241 (e.g., we can just teach Scheme to those that need it, and when discussing writing and designing an interpreter, we can pull both sets of students together). CS240: Having taught this course a few times, I don't think this will be a problem, so long as there is some "fundamental" data structures (trees, queues, arrays, stacks) discussed in CS143/144. As well, to reiterate Prabhakar's point, student do pick up Scheme very quickly: we actually do provide the "voice-over" for a 90-minute lecture, which gives them enough to do interesting things. This ease is due to the fact that Scheme is so lightweight, and has such a gentle-learning curve: you don't have to worry (at least, very minimally) about telling students to "use this thing, but don't ask what it does, since you will learn about that later." Administrative: To reiterate Jack's point, this could be a nightmare administratively: students already make bad choices, and more choice compounds the problems even more. Actually, it will be a nightmare. I am less worried about M-sections failing, since maybe they actually need to fail (i.e., I am not convinced they are working to any great measure), but that is a discussion beyond this forum. Waterloo being Waterloo means that the administrative problems will most likely overshadow the other two. Clearly stated plans for fallback/failing procedures need to be hammered out in a reasonable way, both for the students and for advisors. Political: I will just make statements without much elaboration. 1) I think the timetable for Fall 2004 is a little ambitious, though possible. 2) I am weary of hoping that a new course will wipe out all aversion of teaching first year courses. I would be interested to know what research faculty who have taught CS133 (in its current manifestation) think of this: are there smaller tweaks that can be made for CS133 to make it more palatable (if that is the problem)? 3) Part of me is not opposed to a flat-out replacement of OO first with functional first. It seems like a cleaner approach, though it might be a bit too much sink-or-swim. I am not sure if that part of me is strong enough to warrant this though. 4) If we believe this will be an attractive force for women to consider CS, we should state this more formally. The current "decision helping document" makes CS 143/144 seem a bit elitist: rather, I think we should stress this course for the populous. Overall: I would be in favour of giving this a whirl in F04. Troy (t.v.) ----------------- From: Prabhakar Ragde To: Troy Vasiga Subject: Schemes and counter-schemes Date: Fri, 19 Dec 2003 20:06:48 -0500 Thanks, Troy. I believe Mark Giesbrecht and Arne Storjohann were the last two research faculty to teach CS 133; perhaps one of them can comment on whether small tweaks might make it more palatable. (Mark has made some suggestions for changes, but I don't think they will improve its reputation among research faculty.) Speaking personally, I do not see how to do it, which does not make it any less laudable a goal; it's just that I can't help. I would only advocate a flat-out replacement of objects-first with functional-first if the functional-first approach turns out to be extremely popular when offered as an alternative. I don't think it will ever be; in the Waterloo context, there are always going to be extremely industry-oriented people who will disdain it. I think functional-first is an approach for the populace, but perceptions have a way of twisting out of our control. I need to do more readings on women and CS (Margolis and Fisher have a book out, and I have the library's copy) before claiming with more conviction that functional-first will be attractive to women, and selling it to them is another matter entirely. Certainly we don't have a lot of time to prepare the materials that help students decide; my attempt is a very preliminary first crack, and if you would care to attempt a redraft, even a hasty one, I think it would help a great deal. I suggested replacing Scheme in 241 with ML, but I don't know how this meshes with the compiler-versus-interpreter theme. I need to look at this more. --PR ----------------- From: Michael Demko To: Prabhakar Ragde Subject: Re: Curriculum Proposal Date: Sun, 21 Dec 2003 15:41:52 -0500 (EST) Thank you for considering my comments. If I had understood the implications and the option had been available, I would probably have chosen to enter your proposed alternate stream. ----------------- From: Sandy Graham To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Tue, 23 Dec 2003 18:26:33 -0500 Prabhakar: I am certainly in favour of any discussion which looks to improve the students' experience in their first year computer science courses. However I would like to consider the intended audience for this alternate stream in more detail. I would argue that the students in CS133 are the most diverse group in comparison to any CS course in our faculty. I believe their diversity comes in two major forms: their language background, and more importantly their "algorithm writing" background. If we are considering offering an alternate stream of first year courses, I would like to see it help reduce this diversity in CS133 which means theoretically we could provide students in CS133 a course which is more suited to the audience. I do not believe that teaching Scheme would be a "leveller" in the way you hope it would. I believe students who struggle do so because they have less practice writing algorithms than some of their peers. There are two groups of students that I think we should consider when looking for alternative streams, the non-majors and the advanced CS students. I know that traditionally the faculty has argued that all math students should take the same core. One argument is that all CS students have to take calculus and algebra, so all math students should have to take CS. However I would argue that all incoming students must have taken very similar high school mathematics; this is not true when looking at their CS background from high school. I agree with Gord Cormack that we should be looking for a way to challenge our advanced CS students. I think that it is very disappointing that our program, which is so well known, does not offer these elite students an option in the way that we do offer advanced math courses. I realize that we do not have the same tools to identify the "strongest" CS students, but I think that if we are considering developing a new course for first year students, then this group should be given some consideration. I am looking forward to a very interesting debate on the proposal. Sandy ----------------- From: Prabhakar Ragde To: Jack Rehder Subject: Re: curriculum proposal Date: Thu, 25 Dec 2003 14:34:41 -0500 Jack: I have thought about your logistical points regarding the 143/144 proposal, and have some comments and questions. On the issue of M-sections, I guess I need to know what you think the strengths and weaknesses of the current approach are. Troy has suggested in his comments that M-sections are not working well, but I don't know enough about them to draw any conclusions. With respect to advising students, I think that there is a difference between offering students a choice for which they have the responsibility, and creating several entry points for which we set the criteria in order to deal with diversity. We have, since the introduction of 130 and 134 (and later 131/132), attempted to do the latter, but I don't know how successful it has been. I don't think we should do the latter for 143, and even if we wanted to, I don't know what criteria will work. I can't think of a concise way to describe the kind of student who should take 143. Many of these students have just made a far more momentous choice (UW over other schools) with less useful information than what we can provide in this context. I don't believe the choice between 143 and 13x is as fraught with danger; it will make some difference, but not a huge amount. With respect to number of offerings and failure options, I think that if 143 is the non-mainstream alternative, we have less responsibility to offer it repeatedly (for example, to ELAS or transfer students). I don't have a good sense yet of why someone would fail 143 and what should be done with them. There is always 131, but that puts them quite far back. I would not suggest that they take 133 as it is now, but perhaps with the changes that Mark has suggested, and the fact that there tend to be more weak winter 133 students, some could manage it. I know that scheduling is going to be complicated; I guess that is another effect of choice. I would not want to insist that all courses be forced into a 3L/1T pattern. It would be a shame if logistical considerations were to dominate both curriculum and delivery (though of course they can't be neglected entirely). --PR ----------------- From: Prabhakar Ragde To: Sandy Graham Subject: Re: curriculum proposal Date: Thu, 25 Dec 2003 14:35:34 -0500 Sandy: You raise good points. Historically, the use of computers was circumscribed enough that there didn't need to be a conflict between the needs of Math CS and non-CS students (whether or not two CS courses should have always been in the Math core is another issue). But now, with computing becoming a part of many disciplines, this may no longer be true. In an earlier draft of my proposal, I had mentioned the possibility of a followup course to 143 for nonmajors, perhaps using scripting languages, or discipline-specific ones (e.g. GPSS, Matlab, Maple). However, I took it out to improve focus. I would argue that the conceptual approach of 143 offers more scope for this than 133 does. While I started exploring the use of Scheme for an advanced section, I am more interested now in a broader audience. Again, historically, we have done very little for advanced students in CS; it is only in the last decade that they have even been allowed to skip 133, and those who are strong intellectually but lack experience cannot do this. I believe that 143 has something to offer these students, even though it is not designed solely for them. Lisa Rubini has made the point that women are less likely to opt for an advanced CS section (or one perceived as advanced), both because they tend to underestimate themselves and because they dislike peacock displays. Perhaps, informed by your experience with the Imperial Oil Seminar in Computer Science for Young Women, you could comment on this point. I agree that in the current system, those who have had prior experience with designing algorithms have an advantage. The way in which Scheme can work to reduce that advantage is by it being so different in terms of how algorithms are expressed. If one has learned to add up a list of numbers in Visual Basic, it is not much of a stretch to do it in Java, because both have the same sort of imperative constructs. But how to do it in Scheme, where there are no built-in loop mechanisms and no variables (until week 11 or so)? Both the VB student and one with no computing experience will be forced to think in a new way. Of course, those who are better at thinking conceptually will have an advantage, but that is not one we wish to remove. --PR ----------------- From: "J.P. Pretti" To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Mon, 29 Dec 2003 16:06:13 -0500 (EST) Prabhakar: I still intend on sending you a more general response to the proposal. However, this message is in response to your December 25 response to Jack. I share Jack's concerns. I can easily believe that CS 143/144 would kill M-sections. Now, like Troy, I can't say if this is a good or bad thing. Nonetheless, it should be made clear that this is a faculty level issue. CS may indeed choose to introduce these courses thereby potentially killing M-sections but it needs to know this is a potential effect and must be prepared to address concern from the rest of the faculty. Can you expand on your statement that the choice between 143 and 13x will make some difference but not a huge amount? I agree and it is largely for this reason that I am not particularly supportive of the proposal (given the costs). If we don't feel we are as responsible to students in a non-mainstream alternative as other students (even if only in addressing failures) then we need to make this abundantly clear in documents they use to select between alternatives. Students will fail CS 143 as students fail every course we offer. We need to have a firm and fair handle on how we are going to advise them before starting a pilot section. You note that "it would be a shame if logistical considerations were to dominate both curriculum and delivery (though of course they can't be neglected entirely)." Although this sounds right, warm and fuzzy, I'm not sure what it means. In particular, what do you mean by "dominate" here? An outright ridiculous proposal would be to cut our class sizes to 10 in first-year CS courses. It seems to me that it would have incredible curriculum and delivery upsides but simply can't be made to work for logistical (is $ logistical?) reasons. I am guessing that your comment was made more in passing bit I think these logistical considerations need to be more than not neglected entirely. As I read back through this message I worry that it sounds combative. Please know that this certainly isn't my intent. ----------------- From: Prabhakar Ragde To: "J.P. Pretti" Subject: Re: curriculum proposal Date: Mon, 29 Dec 2003 17:44:28 -0500 JP: Pretty clearly 143/44 is a faculty issue, if Math non-CS people are to be permitted to take it. If Mark has not already done so, I intend to contact other Associate Chairs early in the New Year. I know there is concern emanating from the Dean's Office over 13x, but I don't know whether or not it is coming from the other departments. >Can you expand on your statement that the choice between 143 and 13x >will make some difference but not a huge amount? I think, actually, that the functional approach will make a considerable difference to a number of students, but in the absence of empirical evidence from a UW implementation, I am not prepared to argue this point strongly. I don't yet know, without trying it, whether I can do the approach justice. I think that non-CS students will be less confused and more appraised of the fundamentals -- that is, they will be better able to see the forest instead of the trees. I think that CS students will be more inspired, those that have the potential to be inspired and are not in it because their parents wouldn't let them do music, and I hope that the early exposure to algorithmic thought will make them better able to handle upper-year courses, both theoretical and practical. But I can't guarantee this. My point on logistics was simply that not being able to offer students a given level of service (advising, M-sections) should not be a show-stopper, especially given that it is not clear how effective these measures are currently. I know it is easy for me to say this, as an instructor who does not have to deal with a lot of the fallout. It is customary to present proposals like this by listing all of the benefits and none of the drawbacks. I am trying to take a more balanced and honest view: everything I have said in the proposal and my responses I genuinely believe. It seems to me that this proposal is not more disruptive, and offers potentially more benefit, than the move we made several years ago from Pascal to Java. Have things gotten so much more difficult that we cannot innovate? --PR ----------------- From: "J.P. Pretti" To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Mon, 29 Dec 2003 18:43:14 -0500 (EST) Prabhakar, > >Can you expand on your statement that the choice between 143 and 13x > >will make some difference but not a huge amount? > > I think, actually, that the functional approach will make a > considerable difference to a number of students, but in the absence of > empirical evidence from a UW implementation, I am not prepared to > argue this point strongly. I don't yet know, without trying it, > whether I can do the approach justice. I think that non-CS students > will be less confused and more appraised of the fundamentals -- that > is, they will be better able to see the forest instead of the trees. I > think that CS students will be more inspired, those that have the > potential to be inspired and are not in it because their parents > wouldn't let them do music, and I hope that the early exposure to > algorithmic thought will make them better able to handle upper-year > courses, both theoretical and practical. But I can't guarantee this. Fair enough. Do you think one pilot section will help us determine this? It may help give us more of a gut feeling but it seems that real benefits or drawbacks may not be determinable until after a few years when these students hit courses like CS 341 and meaningful attrition statistics can be computed. Admittedly, even then, we might not be able to rely on much more than gut feelings and personal experiences (which is fine). > My point on logistics was simply that not being able to offer students > a given level of service (advising, M-sections) should not be a > show-stopper, especially given that it is not clear how effective > these measures are currently. I know it is easy for me to say this, as > an instructor who does not have to deal with a lot of the fallout. It And it is easy for me to lean to heavily on issues like this as one who deals with the fallout everyday. I agree with your point as long as (and I think this is very important) we make it clear to students that this is part of the package. > is customary to present proposals like this by listing all of the > benefits and none of the drawbacks. I am trying to take a more > balanced and honest view: everything I have said in the proposal and > my responses I genuinely believe. It seems to me that this proposal is > not more disruptive, and offers potentially more benefit, than the > move we made several years ago from Pascal to Java. Have things gotten > so much more difficult that we cannot innovate? --PR No. I certainly haven't suggested nor am suggesting we can't innovate. It is hard for me to comment on comparisons with the move to Java not having been involved. In the end, to me (and I think you) it will naturally come down to balancing the disruption with the potential benefit. I still need to give this more thought but as I'm sure you know, I'm just not seeing a big potential benefit with this as an *alternative* sequence. On the other hand, lots of potential problems are staring me in the face. Regardless, I truly will keep an open mind and think carefully about how this alternate sequence might benefit CS. ----------------- From: Prabhakar Ragde To: "J.P. Pretti" Subject: Re: curriculum proposal Date: Mon, 29 Dec 2003 19:05:42 -0500 >Fair enough. Do you think one pilot section will help us determine this? >It may help give us more of a gut feeling but it seems that real >benefits or drawbacks may not be determinable until after a few years >when these students hit courses like CS 341 and meaningful attrition >statistics can be computed. Admittedly, even then, we might not be able to >rely on much more than gut feelings and personal experiences (which is >fine). No, one pilot section will not do it. Unless I totally screw up (which is possible), the pilot section will get good reviews from those involved -- instructors and students alike tend to validate their own experiences, and doing "something different" makes one willing to overlook all sorts of things. Historically I don't think we've even tried to measure effects of curricular changes, and given that 143 students will be self-selecting, I don't know if we ever can. I did suggest that an independent observer or team assess the pilot section, to give a little more critical distance. But I think you are right, we are going to be short on quantitative measures of success. I don't mean to give the impression that I think 13x is solely responsible for algorithmic and foundational weakness in our students -- I am peering with suspicion at the entire first two years, including 251, which I designed (and which may give the impression of being "fact-based" without a "skills" component). We need to look at everything we do to make sure the rote/memorization component is balanced by more intellectual/active components. Re letting students know what they are in for: absolutely. I worry that they are inundated with information in their admissions packet and their first couple of weeks here, and can easily miss things. --PR ----------------- From: Sandy Graham To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Mon, 5 Jan 2004 10:31:50 -0500 >While I started exploring the use of Scheme for an advanced section, I >am more interested now in a broader audience. Again, historically, we >have done very little for advanced students in CS; it is only in the >last decade that they have even been allowed to skip 133, and those >who are strong intellectually but lack experience cannot do this. I >believe that 143 has something to offer these students, even though it >is not designed solely for them. Lisa Rubini has made the point that >women are less likely to opt for an advanced CS section (or one >perceived as advanced), both because they tend to underestimate >themselves and because they dislike peacock displays. Perhaps, >informed by your experience with the Imperial Oil Seminar in Computer >Science for Young Women, you could comment on this point. I agree with Lisa that we are unlikely to get a good percentage of female students in an "advanced" section of CS. In particular, the problem of female students underestimating their abilities will deter them from taking such a course. However, my instincts say that female students would tend to shy away from this alternate course for the same reason. However, if we did remove some of the students who display "peacock" behaviour from CS133, this might allow a more comfortable classroom environment in which the less confident students may participate more. ----------------- From: Jack Rehder To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Mon, 05 Jan 2004 13:28:47 -0500 Hi Prabhakar, I'm attempting to answer the questions you've asked, in order: At 02:34 PM 12/25/2003 -0500, you wrote: >Jack: I have thought about your logistical points regarding the >143/144 proposal, and have some comments and questions. On the issue >of M-sections, I guess I need to know what you think the strengths and >weaknesses of the current approach are. Troy has suggested in his >comments that M-sections are not working well, but I don't know enough >about them to draw any conclusions. M-sections are intended to build relationships among the students. I think there can be some benefits from such a system for the student. From a teaching point of view, it certainly does simplify things like doing group work in a course (because students have many opportunities to contact each other). That being said, I personally am not in love with M-sections. I think we can live without them, but I point it out only because the Dean is very strongly in favour of M-sections. >With respect to advising students, I think that there is a difference >between offering students a choice for which they have the >responsibility, and creating several entry points for which we set the >criteria in order to deal with diversity. We have, since the >introduction of 130 and 134 (and later 131/132), attempted to do the >latter, but I don't know how successful it has been. I don't think we >should do the latter for 143, and even if we wanted to, I don't know >what criteria will work. I can't think of a concise way to describe >the kind of student who should take 143. Many of these students have >just made a far more momentous choice (UW over other schools) with >less useful information than what we can provide in this context. I >don't believe the choice between 143 and 13x is as fraught with >danger; it will make some difference, but not a huge amount. I understand that you don't see a huge disadvantage between choosing 143 and 13x. But I'm not sure that we can convince the students that it doesn't matter. They will ask for advice, and will worry about the choice they have made. At some point, they may also ask to transfer from one to the other once they arrive. All of this will be a time sink for us, and in some cases may seem that we are not offering services that the students want - for example, if we deny them the opportunity to change their mind once they get here. You may wish to talk to the advisors and to Sandy Graham who currently deal with the students in choosing among the three 13x courses; I think they will say that there is a lot of concern on the part of the student to choose the right thing. I have often dealt with students wishing to make changes once they arrive - logistically, this is difficult, but if we don't provide the opportunity, our image may be worse. >With respect to number of offerings and failure options, I think that >if 143 is the non-mainstream alternative, we have less responsibility >to offer it repeatedly (for example, to ELAS or transfer students). I >don't have a good sense yet of why someone would fail 143 and what >should be done with them. There is always 131, but that puts them >quite far back. I would not suggest that they take 133 as it is now, >but perhaps with the changes that Mark has suggested, and the fact >that there tend to be more weak winter 133 students, some could manage >it. We can't assume that we won't have any cs143 failures. We certainly have plenty of people who fail cs133, so I can't see why that would be different for 143. There are many reasons for failure - one main reason being these are first year students, and they have adjustment problems which cause them to fail courses, regardless of the curriculum. I know of first year Math students who fail PSYCH 101. So believe me - it's possible!! I would like failure plans/paths to be considered as part of the implementation because at some point, we will have to deal with it. With respect to ELAS students, I think you may find that the Dean feels quite strongly that the same opportunities be available to them as for our regular admits. It is for ELAS students that we are now offering CS131 year round (we don't really need to for non-ELAS students, but the Dean insisted that we offer it for that group in Spring 2003), so I wouldn't be surprised if he felt that we need to offer them the same opportunities with access to cs143. >I know that scheduling is going to be complicated; I guess that is >another effect of choice. I would not want to insist that all courses >be forced into a 3L/1T pattern. It would be a shame if logistical >considerations were to dominate both curriculum and delivery (though >of course they can't be neglected entirely). --PR No, we would not want curriculum to be dominated by logistical considerations. It's not 100% clear to me however that changing the teaching pattern (to simplify the logistics) would harm the course. And if that's true, it might be worth considering. ----------------- From: Prabhakar Ragde To: Jack Rehder Subject: Re: curriculum proposal Date: Tue, 6 Jan 2004 14:25:17 -0500 Thanks, Jack. I certainly did not mean to imply that students would not fail 143, or that they would not fail for the wrong reasons (ie transition woes -- on the other hand, are there ever any right reasons to fail?). We will have to consider fallback paths for these students. I will attempt to sound the Dean out on M-sections and ELAS students. --PR ----------------- From: Karen Yeats To: Prabhakar Ragde Date: Mon, 12 Jan 2004 14:50:42 -0500 (EST) Hi, I'm Pure Math alumna so you can take what I say with how ever much salt you like, but I have a few comments on your proposal and on the comments which you have already posted from others. First of all I am in favor of the proposal. I do fear that defining the audience and hence tailoring to it will be difficult, primarily in balancing between "advanced" and the other interested parties. Initially I didn't think that could be possible and that the sequence would turn into an advanced sequence whether you wanted it to or not. However after a good look at your proposal it does seem possible, though still difficult. What I surmize that you have realized and what perhaps could be made more explicit is that a strong student can appreciate, enjoy, and lean from certain sorts of courses which are easy for them, while other sorts of courses, if at the wrong level, will only be frustrating and tedious. Furthermore this distinction can be independent of how successful either sort of course is for typical students. I think, as many others have commented, that you need to think more carefully about how students can move around between the sequences. However I have a novel argument for this view. I think that not being able to move around with relative freedom will strongly influence less confident students away from the new sequence, which will hinder the possibility of having the most appropriate audience select it. You can read "less confident" as "in higher proportion female", though the above argument holds no matter who is less confident. ----------------- From: Prabhakar Ragde To: Karen Yeats Date: Mon, 12 Jan 2004 19:07:00 -0500 Those are excellent points -- that good students can get something out of courses which are not difficult but which are designed to offer them something, and that a lack of flexibility or fallbacks may discourage the less confident. Do 1A students plan for failure, though? I have a more serious question -- do we need to distinguish between "CS confidence" and "math confidence"? I think the Scheme approach, being functional, connects more to students' experience with math, even though it is not really mathematical (in the way that some of our upper-year theory courses are). --PR ----------------- From: Karen Yeats To: Prabhakar Ragde Subject: Re: your mail Date: Mon, 12 Jan 2004 19:24:01 -0500 (EST) > Do 1A students plan for failure, though? Well I did (where I take failure to mean doing substantially worse than one wants to, not necessarily technically failing the course) but I can't claim typicality. ----------------- From: "J.P. Pretti" To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Thu, 15 Jan 2004 16:29:47 -0500 (EST) Prabhakar, I don't think we should try this. I have really struggled with your proposal. I don't have anything against it in principle. I would have liked it as a student and may even have opted for it. I would like to teach CS 143 and CS 144 if the proposal is approved. However, in the end, I just don't think the advantages outweigh the disadvantages. I would much prefer to discuss this in person and really do plan on visiting you in your office sometime before the next UAPC meeting. However, most of the public comment on the proposal has been positive and I don't think it would be responsible of me to keep this private. Many of the comments to date have been along the lines of "yes, I would like to teach this course" and "I wish I had this option when I was in 1A". This is valuable and worthwhile feedback but I don't think enough emphasis has been placed on determining if the benefits of this as an *alternative* first-year CS course sequence are worth the costs to the School. Many of the possible benefits and drawbacks you cite in conclusion are more arguments in favour of replacing our current sequence or reasons why the alternative sequence may be the right choice for a particular student. As an alternative, the real benefit of this proposal would be our ability to offer a course more appropriate for a select group of students than what we currently offer. As you indicate, there are several reasons why the alternative sequence may be more appropriate and hence this select group of students consists of several subgroups. The claim is that the School is now large enough to support an alternate course sequence for these subgroups. As proposed, CS 143 and CS 144 won't be available or as likely a choice for: - students in 4-stream co-op (e.g. PMATH co-op and likely soon CM co-op) - students in programs with limited scheduling flexibility (e.g. students in advanced sections, Accounting students, double degree students, Bioinformatics students, new BCS/BBA students, new BAFM students, St. Jerome's students) - SE students - ELAS students - students admitted in winter terms This means the pool of students able to make the choice between our current sequence and the alternate sequence will be considerably smaller than the size of our first-year Math cohort. My gut feeling, discussion with others and an unofficial, unscientific and possibly biased poll of my two CS 134 classes suggests approximately 5-10% of the students in this pool will choose the alternative. (It would be interesting to poll a few local high school classes.) Put together, I therefore predict that CS 143 and CS 144 will each consist of absolutely no more than one section of 90 students, probably considerably fewer. As has already been mentioned a number of times, a fraction of these students will make the wrong choice in selecting the alternative sequence. So for arguments sake, let's assume 75 students a year will truly benefit from this proposal. Some students in the alternate sequence will stay in CS when they might otherwise have been turned off of and leave CS. Others may be so motivated that they choose CS when it never before had been an option in their mind. Either outcome is fantastic. I think both scenarios will occur. I also want to note that if I am perfectly honest, in some ways I would "weight" the benefit to these students highly because on average they will likely be the students keen on learning, less inclined to cheat and less worried about their resume. No matter how you cut it, I like the idea of using resources to encourage these types of students. The above, in my mind, is the only real argument in favour of the proposal and it is a good one. Most of the drawbacks have been noted. Let me summarize (and in some cases expand on) them here: - Scheduling of CS 143 and CS 144 will be a disaster. - Students that make the wrong choice either way will be more easily disillusioned and disgruntled. - Extra choice will be a further cause of stress for incoming students. - Increased diversity in CS 241 and CS 246 will make them harder to teach. I have no doubt that this can be resolved but it will consume resources and in the end, CS 241 and CS 246 will suffer albeit not all that much. I don't think it has been pointed out that CS 241 and CS246 will be affected even if only for a failed pilot section. - The proposed time frame is very tight and prone to error. - A lightweight course may not offer the same technical support that students simply need in terms of development environments and debugging skills. - Tutors will be harder to find. - The alternative stream may well be viewed as or end up as an advanced section of sorts. This has the drawbacks (and also most certainly the benefits) of an advanced stream. - Computing support will be necessary. This will consume extra resources. What concerns me most about this is that CS 13x is not well supported at the moment and that's an understatement. It seems to me that we should first think about getting the computing environment and support for current courses in order. - Students that fail either course will be in quite a pickle. - Weak students and students with no programming experience may be worse of in the alternate sequence because they won't handle language transition well. - It will be logistically difficult to accommodate switching in and out of the alternate sequence in September when most students have their first opportunity to ask for advice from us in person. - CS applications and enrollment is dropping so we are shrinking and therefore possibly moving to a size that can't or shouldn't support an alternate sequence. Each of these concerns can be debated individually. However, in balance, I think they outweigh the benefit. Please allow me to be utterly unscientific and oversimplify a complex issue for a moment. 75 students a year. Ask yourself if each of the 13 disadvantages listed above is worth the benefit to approximately 5.8 students a year? I understand that this is a ridiculous argument but I make it more to give others a sense of why I see the scale tipping in favour of not accepting the proposal. Now let me be more constructive. If we do go ahead with the proposal, I suggest we: - Schedule CS 143 and CS 144 at a time that causes as few conflicts as possible paying special attention to courses such as the advanced MATH 14x courses. Late afternoon or even evening offerings should be at least considered. - Consider dropping 134 as an entry point. - Include mandatory labs as part of CS 143. - Spend a *lot* of time very carefully crafting how we present the choice to incoming students. - Don't go ahead with a pilot section in Fall 2003 if the labs aren't set up with Dr. Scheme and any other necessary support by June 1, 2004. - Require programming experience or high 90s in high school Math courses for at least the first pilot sections. And as an alternative to the proposal, off the top of my head, let me put the following ideas on the table: - Offer one or two sections a year of CS 134 as is with ML (or some choice other than Java, C++ or Scheme) as the language of instruction. - Pour resources and energy that would otherwise go into the alternate sequence into developing challenge and bonus thinking and programming exercises for current CS 13x courses. ----------------- From: Prabhakar Ragde To: "J.P. Pretti" Subject: Re: curriculum proposal Date: Thu, 15 Jan 2004 21:56:56 -0500 J.P: I'm sorry to part company with you on this issue. Your position as student advisor and popular instructor of many of our first and second year courses makes you quite qualified to comment. But I am more worried about what your arguments say about the operational state of our program than with what they say about my proposal. You list a number of groups with constrained programs who would be unlikely to opt for or get into 143, and that 143 will complicate scheduling. Quite apart from the fact that some of these programs may recommend 143 instead of 133 (it would make a lot of sense for SE and CM), the argument here would apply equally well to the 131/132 alternate sequence, which has a much more deleterious effect on sequencing. It's a good thing the Math advanced sections are 30+ years old, or we would never agree to them. We created the BCS to offer the flexibility of both "roll-your-own" degrees and highly constrained degrees such as the BCS/BBA; it would be counterproductive to then argue that the existence of the latter should limit flexibility in other areas. 90 students a year? Perhaps in the pilot section. I find it hard to believe that students, having just made the most significant academic free choice of their lives, are going to immediately retreat into a state of complete conventionality. Much will depend on the "street buzz" from students in early sections. Diversity in 241 and 246? We already have diversity -- we have students who can think computationally, and students who can't. This proposal is supposed to address that. A lightweight course not offering sufficient support to students? It's funny how students managed to learn before programmed labs, and continue to do so at many other institutions. I suggest that it is the complexities of Java syntax and industrial development environments that necessitate such support, and not the inherent frailty of first-year students. (By the way, I have installed DrScheme on Windows and Mac OS X, and it is basically a one-click process. Since it is designed specifically for instruction and not for production code, it is going to be much easier to deal with both for students at home and in a lab environment.) Tutors hard to find? One doesn't have to have taken 143 in order to tutor it, but I believe that those likely to want to become tutors are also those more likely to take 143. Many of your suggestions for what we should do if we go ahead with 143 will unnecessarily hobble the course: by scheduling evening classes, force it into a timeslot undesirable to students and faculty, as though it were an afterthought; by removing the 134 entry point, force students with Java experience to learn what they may well consider an irrelevant language; by putting high barriers on the pilot section, send the immediate message that it is for the elite. You've said before that my arguments sound like I want to replace 13x with 14x, and I really don't know how I can deny it any more clearly. Obviously, if I felt that 13x were perfect and appropriate for all students, I wouldn't be making a proposal; but in doing so, I am not suggesting that 14x will be perfect and appropriate for all students. I will also state yet again that 14x is not intended to be an advanced section. You end by suggesting that we should instead seek to make CS 131/2/3 more challenging. I don't believe it is the lack of challenge in this sequence that is the reason for proposing an alternative, but in any case, "we" in this sentence will mean lecturers and ISG staff. Mark informs us that not a single one of the 40-plus research faculty have listed any of these courses on their course preference forms. If 143 is turned down on logistical grounds (too hard to schedule, too hard to advise), that divide will become permanent; faculty will conclude that the first CS course is out of their hands until a time when they can propose a complete and universal replacement. I ended an earlier message to you by saying, "Have things gotten so much more difficult that we cannot innovate?"; your implicit answer to my rhetorical question is not reassuring. --PR ----------------- From: "J.P. Pretti" To: Prabhakar Ragde Subject: Re: curriculum proposal Date: Thu, 15 Jan 2004 22:43:16 -0500 (EST) > J.P: I'm sorry to part company with you on this issue. Your position as > student advisor and popular instructor of many of our first and second > year courses makes you quite qualified to comment. But I am more We don't have to agree on everything. And do know that I will happily do my best to support 143 and 144 if they come to be. I would teach it. I'll happily advise students about it. I'll happily still teach CS 13x courses. I'll happily teach CS 241 to students from both sequences. We're only parting company temporarily :) > You list a number of groups with constrained programs who would be > unlikely to opt for or get into 143, and that 143 will complicate > scheduling. Quite apart from the fact that some of these programs may > recommend 143 instead of 133 (it would make a lot of sense for SE and > CM), the argument here would apply equally well to the 131/132 > alternate sequence, which has a much more deleterious effect on > sequencing. It's a good thing the Math advanced sections are 30+ years I have never liked the idea of 131/132 and dislike it more every day. > old, or we would never agree to them. We created the BCS to offer the > flexibility of both "roll-your-own" degrees and highly constrained > degrees such as the BCS/BBA; it would be counterproductive to then > argue that the existence of the latter should limit flexibility in > other areas. The existence of the latter does not in itself have anything directly to do with it. It is more of a fact than an argument. I was simply suggesting that if we only have one section then it will be almost outright impossible to schedule things so that all these groups of students can take 143 and 144. > 90 students a year? Perhaps in the pilot section. I find it hard to > believe that students, having just made the most significant academic > free choice of their lives, are going to immediately retreat into a > state of complete conventionality. Much will depend on the "street > buzz" from students in early sections. You are absolutely right. And this is where my argument (and opinion!) may fall apart. I must admit that I didn't actually know you had a vision of much more than one permanent section of each. I'm sure I simply misunderstood. If other programs (e.g. SE or CM) do in fact require 143 and 144 and if it becomes more popular among students than I am guessing then my estimate of 90 will be way off. AND this changes things. It changes things *a lot*. The whole gist of my argument and why I feel the way I do is that I just don't think it is worth it for what I am guessing will be a small group of students. If there is a large audience then I think the benefits may indeed outweigh the drawbacks. Don't forget that I really like the 143/144 curriculum. > Diversity in 241 and 246? We already have diversity -- we have > students who can think computationally, and students who can't. This > proposal is supposed to address that. As an alternative, how? > Many of your suggestions for what we should do if we go ahead with 143 > will unnecessarily hobble the course: by scheduling evening classes, > force it into a timeslot undesirable to students and faculty, as > though it were an afterthought; by removing the 134 entry point, force > students with Java experience to learn what they may well consider an > irrelevant language; by putting high barriers on the pilot section, > send the immediate message that it is for the elite. I know you don't want this Prabhakar. I know. It's just that your wish may not come true. I have the same gut feeling as I think Karen Yeats has. > You've said before that my arguments sound like I want to replace 13x > with 14x, and I really don't know how I can deny it any more > clearly. Obviously, if I felt that 13x were perfect and appropriate > for all students, I wouldn't be making a proposal; but in doing so, I > am not suggesting that 14x will be perfect and appropriate for all > students. I will also state yet again that 14x is not intended to be > an advanced section. I don't think I said that. I think I said your arguments sound more like arguments in favour of replacing 13x with 14x. I've never thought you actually were proposing this. The proposal clearly says otherwise. You've said it clearly again and again. I believe you. I did the first time. Read this: "The possible benefits include increased student choice, motivation of OO concepts without syntax overload, a suitable balance between analytic and developmental skills, mitigation of diversity due to prior computing experience, appeal to a wider audience, and increased involvement of faculty in first-year courses." Aside from student choice, doesn't that sound like one heck of an argument in favour of replacing 13x with 14x? > You end by suggesting that we should instead seek to make CS 131/2/3 > more challenging. I don't believe it is the lack of challenge in this > sequence that is the reason for proposing an alternative, but in any > case, "we" in this sentence will mean lecturers and ISG staff. Mark > informs us that not a single one of the 40-plus research faculty have > listed any of these courses on their course preference forms. If 143 > is turned down on logistical grounds (too hard to schedule, too hard > to advise), that divide will become permanent; faculty will conclude > that the first CS course is out of their hands until a time when they > can propose a complete and universal replacement. I ended an earlier > message to you by saying, "Have things gotten so much more difficult > that we cannot innovate?"; your implicit answer to my rhetorical > question is not reassuring. --PR I think everything you say here is true if we were all to agree that several sections of CS 14x are expected and realistic. On the other hand, I don't think any of this is fair if my prediction is true. ----------------- From: Prabhakar Ragde To: "J.P. Pretti" Subject: Re: curriculum proposal Date: Fri, 16 Jan 2004 12:10:17 -0500 >I must admit that I didn't actually know you had a vision of >much more than one permanent section of each. I'm hoping for a third to a half of incoming Math students. That may be ambitious, and it depends not only on my effectiveness, but how well other instructors take to the course. >> Diversity in 241 and 246? We already have diversity -- we have >> students who can think computationally, and students who can't. This >> proposal is supposed to address that. >As an alternative, how? By first of all being effective with some students who are currently not getting the skills they need (and I confess that these students will be less likely to take 143) and second of all by allowing 13x to evolve, as it need no longer be all things to all students. >I know you don't want this Prabhakar. I know. It's just that your wish may >not come true. I have the same gut feeling as I think Karen Yeats has. I know that the incoming average of 143 students will be higher, maybe always. I just don't see any reason to build this in as an institutional bias. If it's already going to happen, why mandate it right at the beginning? >Aside from student choice, doesn't that sound like one heck of an >argument in favour of replacing 13x with 14x? Yes, it does. But note that I also offer counterarguments why 13x should continue to exist (though I support the changes Mark proposes). I simply don't want to force all students through 14x. >On the other hand, I don't think any of this is fair if my prediction >is true. I'm sorry if I was unfair; what seemed like a measured response in the seventeenth hour of my yesterday seems a bit harsh in morning light. ELAS students and the originally postulated audience for 131/132 are also small groups for which we seem to be ready to turn things upside down. Math advanced sections are also small. And, as I said above, I don't see why the audience is inherently limited to 75. You're rightly thinking of the work and headaches if 143 is approved. Give a moment to pondering the consequences if 143 is not approved. --PR ----------------- From: Paul Schreiber To: Prabhakar Ragde Subject: first-year CS: Python :) Date: Sun, 18 Jan 2004 21:08:10 -0800 Prabhakar, [I know you were collecting suggestions a while ago...] I think it'd be great if UW adopted Python for first-year CS courses. It's object-oriented, has many built-in types (complex numbers, ints, reals, hashes, lists, etc.), functional programming, modules, exceptions and dynamic typing, among other things. Python's syntax forces you to adopt a clean programming style. The Python web site has a section called "computer programming for everybody," aimed at beginning programmers: http://www.python.org/cp4e/ ----------------- From: Prabhakar Ragde To: Paul Schreiber Subject: first-year CS: Python :) Date: Mon, 19 Jan 2004 09:23:11 -0500 I'm keeping an eye on Python. The main problem seems to be that there is no textbook out yet. (One is not enough, of course; we need alternatives.) I thought of it as a possibility for a second course for nonmajors following my proposed CS 143, but it is a bit premature to make such plans. --PR ----------------- Thanks for posting your proposal. I have some administrative concerns that I think need to be considered. We already offer four first year courses for honours Math and CS students, as well as first year service courses, and I fear that additional first year courses will unnecessarily tax the resources of the School of Computer Science. The effort needed to create new courses is substantial, as is the effort to maintain, revise and coordinate the courses over their lifespan. I must confess that I am pessimistic about additional resources coming to the university system in the next few years, and about the depth of the CS admission pool as well. The provincial budget is very tight - in fact, I would not be at all surprised to see cuts in the upcoming budget. Weaker students mean additional academic support and advising effort. My real question: In a period of steady state to declining resources, does the School have the long term resources in teaching personnel, in competent coordination, and in course support (markers, servers, licenses, ...) to take on more first year courses? Thanks for listening, Steve ----------------- From: Prabhakar Ragde To: Steven Furino Subject: First Year CS Proposal Date: Mon, 26 Jan 2004 22:17:55 -0500 As you know, Steve (from having taught 131 and 134 with me, years ago) I have had some experience in designing and maintaining first-year courses. The current 131/2/3 courses are expensive to maintain; that is the result partly of conscious choices made in the design and partly due to the nature of the task they are attempting. My contention is that 143/4 will consume fewer resources, especially in maintenance, because of the nature of the task it is attempting, and because of my design choices. There is never a good time to innovate. CS curriculum is in a continual state of ferment, and has been since I can remember. When enrollments are rising, we haven't the breathing space; when enrollments are falling, we haven't the resources. It is not my job to make proposals like this; my proposal is a response to problems that I and others perceive. They are not so chronic that everyone sees the urgent need for change. I would prefer not to wait until they become chronic, which I believe will happen if we maintain the status quo. The cost of fixing things at that point, added to the human cost of having let them become chronic, may well be more than the cost of innovation now. --PR ----------------- From: Jack Rehder To: Prabhakar Ragde Subject: Re: curriculum proposal; some costs Date: Mon, 26 Jan 2004 11:42:39 -0500 Perhaps it is my Business background showing through, but I'd like to ensure that when a decision is being made that the costs are considered and acknowledged. Here are a few costs that I've thought of that will be/should be incurred should the proposal pass. Some of these have already been stated, I'm just reorganizing these into a different format for consideration: 1) Computing support. Are we willing to commit more dollars to CSCF teaching support? There is a LONG lead time on getting software installed and set up. We have been waiting in some cases for over a year for software to be installed on Nexus and/or Unix systems. There can be no guarantees that the software will be installed on such a tight timeframe (If such guarantees *can* be made, then I'd like to know why those same resources have not already been deployed to support us better with our current course set!) I'm not trying to slam CSCF here; I just want you to know that they have acknowledged that this is a problem. CSCF resources are already too tight; dividing the resources suggests with another platform suggests that we will be less happy than before. Should we make a curriculum-based decision on such a logistical issue? Absolutely not. Common sense suggests that we should simply fix whatever is wrong so that we can be more responsive in this and other desired curriculum changes. But HOW is that change going to happen? If we don't do anything differently in terms of computer support, we would be foolish to expect different results. We clearly need more resources within CSCF to support a more diverse curriculum. Either that, or the existing resources need to be deployed differently. That is not really for me to say; only that someone must commit to change. 2) Higher instructional costs. The costs will be somewhat higher for a few reasons; quite obviously, some of the 'economies of scale' will be lost, so cost of TAs may be a bit higher. But in addition to this, we will not be able to accurately predict in advance how many students will choose each course. This is already a problem, and it will worsen with the addition of another choice thrown into the mix. We tend to offer more sections than we absolutely need, meaning that overall there may be more instructors used. Scheduling is done 6 months in advance; once students are enrolled, we cannot move them around to eliminate half-full sections. If we err on the other side (scheduling too few sections of any particular course) we are much worse off; adding a section of a course almost always means it will be in the evening once the initial schedule has been decided. This may be not as bad in the proposed pilot offering (since the space will be limited to one section) but in the long run, we cannot get information as far in advance as we need to optimize course timetables. Is this a cost we are willing to absorb? 3) Student environment costs. The cost of adding a CS entry point will mean the elimination of M-sections. There is no real way to maintain the continuity of M-sections with so many different entry points in CS. M-sections only work well with sufficient numbers of students taking similar courses. The blocking will be broken down to the point where M-sections will not be viable. (As one example, if the accounting students split between CS133 and CS143, the accounting M-section is not viable) This problem may be mitigated in the future, if certain programs dictate one course or another, but if there is actually choice, it will not work. Personal opinion from an instructor's point of view: not a huge loss. But students and other admin people may feel differently about that. Is this a cost we are willing to bear? 4) Student satisfaction. This is a repeat of what JP has already stated - Students that make the wrong choice either way will be more easily disillusioned and disgruntled. Students who cannot make the choice (due to program/streaming constraints) may also be dissatisfied. We will not be able to accommodate switching in and out of the alternate sequence in September when most students have their first opportunity to ask for advice from us in person. This is not a true dollar-cost, but it is a cost just the same. Are we willing to accept this cost? 5) Advising costs. There will be many additional questions from incoming students. Who is equipped to deal with them? How much time will this take from the already over-worked advisors? Will they be compensated in some way? 6) Support costs. I won't really say too much about this, only that it may or may not exist. A 'lightweight' course such as Prabhakar is proposing may not require staffing support from ISG. If not, then there is no cost issue here. The above does not imply that these cannot be overcome; I only ask that there be an acknowledgement of these costs, and a willingness to accept them as a result of accepting the proposal (should it be accepted). Thanks, Jack ----------------- From: Prabhakar Ragde To: Jack Rehder Subject: Re: curriculum proposal; some costs Date: Mon, 26 Jan 2004 22:23:38 -0500 Thanks for the summary, Jack. Since I have already commented on many of these points, I have only one additional response. I find it surprising that people are arguing that because students who feel they have made the wrong choice or who cannot access a choice may be dissatisfied, we should not offer anyone a choice. Isn't this akin to saying that, because knowledge brings misery, we should keep people ignorant and happy? I don't think any student will be happy with being denied a choice on this basis. --PR ----------------- From: dan brown To: plragde@math.uwaterloo.ca Subject: CS 143 proposal Date: Mon, 26 Jan 2004 17:45:24 -0500 (EST) Hi Prabhakar, I've spent a brief period of time with your copy of the How to Design Programs book and have some comments I'd like to make more publicly than in the private discussion we've had. I'm still supportive of the 143 proposal. In particular, I believe that the functional approach to teaching introductory programming has a tremendous user-friendliness that may help a lot of our students get used to thinking about programming and ideas first, before they start to think about their void public static ick. That said, I also think that there needs be a body of add-on stuff developed to go along with the HtDP book, if in fact it's to be the textbook. I mean this in a few ways: First, I think it's too slow for where many of our best students will be, which will result in boredom, despite the fact that CS 1 is a great time to teach students how exciting our field really is. Also, I think it misses and screws up some basic principles in ways that are reparable, but unfortunate. We've talked a little about this over private email, but I think that in several places, most notably when it talks about bindings, recursive data structures, and abstraction, the text is either really awkward, or goes 85% of the way in saying what should be said. I don't think this is fatal; I think after re-examining my copy of SICP last week that it, too, is flawed. Yet with the course I took out of SICP at MIT (and presumably with our own courses), the limitations of the book were not all that much of a big deal; in any group of MIT students and alums, half of them had at one time or another taken 6.001. Everyone knew which sections were badly written, and they'd stop at parties (yes, really) and talk about the limitations of the dispatch model, or how much they wished that SICP had explained some concept better. While this is perhaps distressing (embarrassing?) in retrospect, it also meant that there was an enormous resource available. (And as to enrichment-type material, that was also available: I remember friends who suggested fun Scheme projects, or problems that they remembered from when they had previously taken .001.) This isn't going to be available for our students soon, and yet I think will be necessary. I don't even think it's resolved well by one enthusiastic instructor preparing good augmentary material for a particular incarnation of the course. Does this sort of concern worry you? I guess to me, it feels that an incarnation of this course with the wrong instructors would be much more unfortunate than an incarnation of CS 134 with the wrong instructors would be. I'm curious how we maintain quality under these circumstances. ----------------- From: Prabhakar Ragde To: dan brown Subject: CS 143 proposal Date: Mon, 26 Jan 2004 22:42:56 -0500 I must say that, having spent a fair amount of time and text fending off suggestions that my course is for advanced students only (or should be), it is refreshing to hear that you think they will find the text too slow in places. I agree with this. It is a text designed for the masses. I hope to be able to develop enrichment material that can be passed from instructor to instructor (there is some already available at the places where the text is in use). 143 is better for advanced students than the current alternative, but I'm not claiming it's the best we can do. Perhaps someone else can think of something better for them. As for flaws in the text -- I can't think of a single text, even ones I have considerable respect for, which don't do some things I consider ill-advised, boneheaded, quirky, or just plain wrong. I will discover parts of HtDP that affect me the same way, when I use it to teach. Suggestions on workarounds go into the instructor notes. (I'm sure you have some already; let me know the details, please.) I think an incarnation of any course with the wrong instructors is unfortunate. There is simply no way to make a course immune to how it is taught. Even as robust a course as data structures can, in the hands of the wrong instructor, become just a memorized and regurgitated cookbook of methods. I think that people who care about teaching will want to teach 143. That will help. It also helps that it is not my personal vision -- I am not creating this course out of thin air. It has been implemented elsewhere; others are in charge of the text and supporting environment. The same things that inspired me to propose this approach for UW can inspire others. --PR ----------------- From: Steven Furino To: Prabhakar Ragde Subject: Re: First Year CS Proposal Date: Tue, 27 Jan 2004 05:33:26 -0500 Well said and many thanks. ----------------- From: "Yaacov Iland" To: "Prabhakar Ragde" Date: Mon, 26 Jan 2004 23:53:10 -0500 Hmmm, that's a very interesting proposal. On the weekend, one of my housemates, a science grad, was asking me about learning to program and I was trying to explain the three classes of languages. I realised that I didn't have the foggiest clue why anyone would want to use functional languages, other than for the mathematical beauty of it. Quite a shame, really, especially since algorithms and data structures were the part of my CS degree that I most enjoyed. I started in 134 and did 246 in 1B. At the end of first year, I decided that I would give CS one more course to convince me that it was interesting, before switching majors. Luckily, I hadn't started in 130, or else the third course would have ended up being 246 instead of 241. A progression such as you are advocating would have made my first year much happier and more interesting. I wish you the best of luck with it. ----------------- From: "Eric Lippert" To: "Prabhakar Ragde" Date: Thu, 29 Jan 2004 13:53:02 -0800 Your proposal is quite interesting. I have often wondered why schools concentrate upon teaching principles of object oriented programming. The most obvious alleged benefit is that OOP languages such as C++, Java, C# are in widespread use in industry. But I don't really buy that argument. Yes, UW is a highly practical school, but still surely the purpose of a UW CS degree is to study theoretical computer science. And really, most people in industry do not have a good grasp of OO principles. More: they do not NEED a good grasp of OO principles except insofar as those principles serve their needs. Heck, I design and implement programming languages for a living and it's not like we're in code reviews saying "Well, Bob, this code works, but doesn't it violate the Liskov Substitution Principle?" Which brings me to my second point -- why do we have OO principles in the first place? Not because they are cool, I hope. Rather, because OOP is a style of programming which emphasizes encapsulation, abstraction, contracts, information hiding, extension through inheritance, etc, etc, etc. These are things which help in the design and implementation of large scale software. Super. That's goodness for me -- I work on systems like that. But in an introductory course in computer science, typically the students are working on small, simple programs by themselves. OO languages are not necessarily good pedagogically at the introductory level. Case in point: what I sometimes see when I interview people and review code is symptoms of a disease I call "object happiness". Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists. Hopefully the co-op program shocks them out of it, but better to not get Happy in the first place. So I agree with you that earlier exposure to functional programming is a good idea. Not just from a theoretical standpoint, but also from a practical standpoint. I strongly believe that as programming languages evolve we are going to see an increasing number of _functional_ language and _declarative_ language features in mainstream industry production languages. (In the latest version of C#, for example, there is improved support for delegates, moving towards a first-class-function model, and also some support for declarative attributes. But both could be greatly improved further.) Of course, I might be somewhat biased. I spent five of the last eight years working on JScript, which can be used as an imperative, object-oriented AND functional language, and is usually found embedded inside declarative languages such as HTML, XML. (My colleague at Netscape, Waldemar Horwat, once told me that Javascript was just another syntax for Common Lisp -- he was a pretty hard-core functional programmer.) Come to think of it, JScript might make a very interesting pedagogic language. It's very easy to get productive right away by writing little imperative scripts, it implements functional language features such as closures and anonymous functions, and it has an interestingly non-standard approach to OOP (prototype inheritance). ----------------- From: Rob Ewaschuk To: Prabhakar Ragde Subject: Scheme Date: Mon, 2 Feb 2004 04:32:57 -0500 (EST) Prabhakar, J.P., Josh, cc: Jesse, uw.cs.ugrad, http://rob.infinitepigeons.org/blog/thoughts/pedagogy/ I'm told that today is most likely D-Day for PR's Scheme proposal. I spoke to Josh at length (where "length" is constrained by expensive phone bills) about his concerns with Prabhakar's Scheme proposal. I understand the problems that he has raised, and agree that they are, indeed, problems. But one thing strikes me as very important here, overriding pretty much any objections: Doing something bold with CS at UW is, I think, quite badly needed. It would excite me to see this happen, and I think it would excite many other people, too. Thus, despite many practical, administrative and pedagogical issues raise concerning this plan, I am still firmly in support of it, or something like it. And, in particular, I think if this particular plan gets rejected today or in the future, something similar in spirit should be put back in its place. If nothing similar in the spirit of excitement and change can be found that has fewer objections, then this plan should be adopted. Essentially, what I think is this: the cost of changing nothing is high. Not necessarily because what's there is really bad (I don't think it is), but simply because change is good, and trying new and different and neat things is what UW CS should be doing. That is my distant, but considered opinion. ----------------- From: Prabhakar Ragde To: Rob Ewaschuk Subject: Scheme Date: Mon, 2 Feb 2004 07:53:52 -0500 I am not a fan of change for change's sake, any more than I am a fan of preservation for the sake of preservation. But I do believe in evolution, and I think I have presented an adequate rationale for it in this case. While change comes with costs, we have to also consider the costs of not changing, and I don't think some of those who are objecting to my proposal have considered those costs seriously enough. Without doing so, innovation is slowed, and it ceases entirely when our fear of the mistakes we might make overwhelms our concern over the mistakes we are already making. --PR ----------------- From: "Antonio Michaelangelo D'souza" To: Prabhakar L Ragde Subject: Scheme in 1st year Date: Mon, 2 Feb 2004 10:23:25 -0500 Hi Prabhakar, I just finished reading the comments on your proposal to introduce Scheme as an alternative to Java in 1st year at The various issues have already been beaten to death and I'm probably too late to make any sort of difference anyway but I'd like to say that I believe it is a good idea and I'm very happy with the amount of thought that has been put into it so far. The M-section concern took me by surprise because I never really understood the point; however, I could be in the minority as I lived in one of the church colleges and did not have to rely upon the faculty to supply me with "study-buddies", which is what I have been lead to believe is the justification for M-sections. Had I known in 1st year what I know now, I would have loved to expose myself to some functional programming. The caveat of Java as a filter used by co-op employers does stick in my mind, however; I believe I was able to sell myself as a programmer (rather than the QA or tech support that I've seen many fall into like quicksand) because of having taken 2 Java-based CS courses prior to my 1st work term. While there are employers who do value knowledge of functional languages, they are generally also looking for 3rd & 4th year students. It seems to be a case of preparing for the future with the risk of neglecting to handle the present. However, doing the mix of Scheme & C/Java as a few have suggested could alleviate this problem. Yes, I realize that this mindset is very industry-focused. However, unless we wish primarily to woo students in regular, rather than co-op, this will be a real concern, especially since co-op is one of the biggest selling points UW has. Since Python was mentioned, I'd like to say that I strongly prefer it over Scheme, having used both in different 4th-year CS courses, mostly for syntactic reasons though. One advantage is that tt would allow for teaching OO principles later on without having to switch languages entirely. I'm not convinced that a textbook is required, since there are a few excellent tutorials and references to this language on the web. In the end, of course, the fact that it is optional will assuage some of these fears anyway, although in the interests of seeing it succeed they ought probably to be dealt with anyway. ----------------- From: Prabhakar Ragde To: "Antonio Michaelangelo D'souza" Subject: Scheme in 1st year Date: Mon, 2 Feb 2004 11:15:57 -0500 I think you may be underestimating the importance of a solid textbook for a course, particularly a course that is going to be taken by people who aren't going to be CS majors. One of the supporting pillars of the objects-first philosophy is that students won't use objects correctly if you first teach non-OO parts of the language, and Python is vulnerable to this criticism (plus its OO features are open to criticism). It has proved its worth as a scripting language for those who know how to program; I remain to be convinced that it can work as a first language for both CS and non-CS majors. --PR ----------------- From: "Antonio Michaelangelo D'souza" To: Prabhakar Ragde Subject: Re: Scheme in 1st year Date: Mon, 2 Feb 2004 11:28:02 -0500 That is a reasonable criticism of Python as a 1st-year course. I do recall, however, being taught about iteration and selection (the building blocks of procedural programming, I would think) in CS 130 before we learned about class hierarchies and such. The problem with learning about objects and nothing else is that they seem quite useless if you can't do anything with them. Perhaps I'm showing my procedural thinking rut here though. Are there OO languages (with full inheritance) that aren't procedural? ----------------- From: Prabhakar Ragde Date: February 2, 2004 11:45:48 AM EST To: "Antonio Michaelangelo D'souza" Subject: Re: Scheme in 1st year > I do recall, however, being taught about iteration and selection (the > building blocks of procedural programming, I would think) in CS 130 > before we learned about class hierarchies and such. Take a look at http://www.student.cs.uwaterloo.ca/~cs131 . In week 1, they make a simple GUI. In week 2, they extend classes. In week 3, they write helper methods. In week 4, they practice using conditionals and loops. CS 133, which is taken by those who get their high-school teacher to sign that they had a real course in computer science, spends very little time on iteration and selection. > Perhaps I'm showing my procedural thinking rut here though. Are there > OO languages (with full inheritance) that aren't procedural? PLT Scheme comes with a complete object class system, though it is not used in the textbook -- that is, it is not in the language definition, but is a tool built for use that is accessible to students who wish to move past what the proposed course offers. There are various research languages which are object-oriented functional and declarative languages, but none of these are really suited for education. --PR ----------------- From: Matthias Felleisen To: Prabhakar Ragde Subject: CS1 @ Waterloo Date: Sat, 14 Feb 2004 10:10:40 -0500 Hello again -- I accidentally ran across the public responses to your proposal at Waterloo's web site. It looks like your colleagues are quite supportive (at least in public) but are also not well-informed about what it takes to run a first-year course. ------------------------------------------------------------------------ Here are a couple of reactions that you may share w/ your colleagues if it matters: 1. HtDP is gentler than SICP in many ways. The speed very much depends on the instructor and the audience. I used to cover Part I (100 pages) in two lectures at Rice and I now use four or five at Northeastern. While I admit that some students are bored at this pace, they suddenly wake up in lectures 5 through 10 or so when we continue with the simple looking recipe yet tackle disk space usage of directory structures, forest of family trees, and even graphs. In the end HtDP can offer as much challenge as SICP -- but HtDP's design recipes carry over to OOP and other languages, which is what matters. 2. HtDP isn't perfect. No text book is. We (the instructors) constantly invents supplementary materials, and others who use the book do, too. Matthew for example switched the introduction to use a graphics approach. Instead of + and * on numbers, he introduces add-beard, add-glasses, and pictures, which as you know are values inside of DrScheme. 3. Mixing languages. We have conducted experiments with mixing languages (Utah, Northeastern, Brown). The experiments suggest that students w/o experience have trouble switching syntax. We therefore recommend a stratified approach. The key issue is to teach with a design-recipe approach when you switch to Java. Using this approach, you will be using inheritance in the second week and template-and-hook in the third. If there is a desire to switch in one semester, I strongly recommend covering parts I through IV before switching. Indeed, that's almost the ideal point. ------------------------------------------------------------------------ If you and/or some of your TAs wish to attend the HtDP workshops we organize next summer you're welcome to come and to send people. Georgia did this a couple of years ago, and the teachers loved seeing the book in action. ----------------- From: Matthias Felleisen To: Prabhakar Ragde Subject: p.s. Date: Sat, 14 Feb 2004 10:17:01 -0500 On lambda: 1. If you really don't like the word lambda, add function as follows to your intermediate with lambda language: (define-syntax function (syntax-rules () [(function parameters body) (lambda parameters body)])) Then your students are free to write loops like this: > (map (function (x) (+ x 1)) (list 1 2 3)) (2 3 4) 2. Looping constructs apply "actions" to each "node" in a (recursive) data structure (such as integers, lists, trees). Scheme has 1023 looping constructs -- defined to suite the need. Java and C have three each, because loops must produce the void value. That's their fatal flaw. 3. We also have a TeachScheme! 2 workshop for people who understand HtDP. You may want to consider that for yourself and/or your instructors. ----------------- From: Prabhakar Ragde To: Matthias Felleisen Subject: CS1 @ Waterloo Date: Fri, 5 Mar 2004 15:02:21 -0500 >If you and/or some of your TAs wish to attend the HtDP workshops we >organize next summer you're welcome to come and to send >people. Georgia did this a couple of years ago, and the teachers >loved seeing the book in action. Thanks, Matthias, I will keep the workshops in mind. >Matthew for example switched the introduction to use a graphics >approach. I'm inclined not to emphasize graphics, in part because I'm not convinced that we need to do this in order to retain interest (only to bore them in later courses?) and in part because, since drawing functions have side effects, things like order of evaluation become important, and in the subsets approach, we have to rely on tricks like using AND with shortcuts to draw two things before the introduction of "begin". But I agree that it would be very simple to do if I were so inclined. >If there is a desire to switch in one semester, I strongly recommend >covering parts I through IV before switching. Our current plans are to do a full semester in Scheme, getting at least to part VII (and further if possible), before starting Java the following semester. >1. If you really don't like the word lambda, add function as follows to >your intermediate with lambda language: Oh, I like it fine, and it has more historical resonance than "car" and "cdr", which you did replace. Some students might have preferred "function". It's easy enough to add that alias in DrScheme, but not so easy to do it in the textbook, so I will stick with "lambda". ----------------- From: Matthias Felleisen To: Prabhakar Ragde Subject: Re: CS1 @ Waterloo Date: Fri, 5 Mar 2004 15:10:58 -0500 On Mar 5, 2004, at 3:02 PM, Prabhakar Ragde wrote: >> If you and/or some of your TAs wish to attend the HtDP workshops we >> organize next summer you're welcome to come and to send >> people. Georgia did this a couple of years ago, and the teachers >> loved seeing the book in action. > > Thanks, Matthias, I will keep the workshops in mind. Another possibility is for some of us to come out and train. After the dean at GA saw the enthusiasm of the TAs we trained for them, they brought Matthew Flatt and two of my TAs in and had the whole faculty trained so that they'd know what was going on. >> Matthew for example switched the introduction to use a graphics >> approach. > > I'm inclined not to emphasize graphics, in part because I'm not > convinced that we need to do this in order to retain interest (only to > bore them in later courses?) and in part because, since drawing > functions have side effects, things like order of evaluation become > important, and in the subsets approach, we have to rely on tricks like > using AND with shortcuts to draw two things before the introduction of > "begin". But I agree that it would be very simple to do if I were so > inclined. Matthew's graphics is completely functional. You say things like > (add-glasses picture) picture-w-glasses > (add-glasses (add-beard picture)) picture-w-glasses-and-beard And you can step through them, just like in algebra. No effects. ----------------- From: Matthias Felleisen To: Prabhakar Ragde Subject: P.S. CS1 @ Waterloo Date: Fri, 5 Mar 2004 15:27:27 -0500 P.S. If your department accepts the proposal, I'd be happy to visit and give an overview talk. I have done so at several places, incl Harvard most recently. I can also give a technical research talk. -----------------