Author

Martine

Browsing

The weight of Stereotypes in CS: 

Learning Computer Science, just like about anything I would guess, is not easy. In the case of Computer Science, a lot of “folk tales” are going around: “CS is not for women”; “CS is heavy in math”; “CS is hard”; “Wow, you must be super smart if you are in CS”, and I could go on and on and on… These statements are all false and unfounded. However, hearing (or having heard) these does not help when you are a student who might be second-guessing his or her choice of major, his or her fitness to the studying this field.

The weight of Expectations in CS2: 

Over the last semesters, I have taught CS2, which is the second course in the 3-course CS introductory sequence. Coming to CS2, CS students have already taken an Introduction to Computer Science course (or equivalent). We usually expect them to have been acquainted to programming in Java (in our case; possibly other languages for other institutions), to the notion of algorithm, to solving problems, and to the details of control structures that implement conditionals, repetitions, etc. This is a heavy expectation: some students may have taken the intro course several semesters or years ago, or even just a summer ago, and have forgotten a lot of it; they may have barely passed the intro course; etc. All sorts of reason that make them not fit exactly the profile we expect. And sometimes, it is just about perceptions and fears: students may know all they should know, but undermine themselves by thinking they are not good enough. This brings us back to the power of negative statements like those that I outlined earlier.

Regardless: Whatever the reason, whatever how confident or not my students feel about their skills coming to my class, I believe that we can work this out and support all students to succeed.

So how do we achieve this?

First: my disclaimer. Let’s be clear, I do not do magic… a.k.a., nothing I am going to suggest will work for a student who cannot commit. And to be sure I am not misunderstood, I understand that students may not be able to commit. A lot of our students work outside of campus, some are essential financial support for their families, some support their parents, others their children, some both, some are homeless, and I am sure that there are other circumstances I did not list that are as trying if not worse. So, I am very thankful to have my students in class every day of class and I understand that they might not have a lot of time outside of class to do what ideally they would.

However, in order for me to help a student (all students) be successful, I need their cooperation, that is, commitment. And commitment is not all consuming either, rather reasonable.

This being said, here we go. I have a few observations / recommendations on what to focus on.

Committing to what?

Computer Science is like running. I could teach you all I want about running: how to pace your effort, how to develop your endurance, etc. If you did not run, it would be useless, and by the end of the semester, you would not be able to finish the race.

I expect the same in Computer Science. Practice is required. The beauty of CS is that you can answer most of your questions by programming them: does the java instruction System.out.println(myArray) print the content of myArray or something else? Go code it and see it for yourself. This is a great power you have! I said something in class that you are not sure about: go and code it to check it for yourself. You do not need to stay confused: you now see it for yourself. Etc. Etc.

So the commitment I am expecting of my students is simply this: PRACTICE, CHECK things for yourself (yes, of course you can do it!), and PRACTICE some more… regularly, not just before a deadline or at the end of the semester.

Unless you exercise your CS muscle, I cannot promise you can be successful. Just like a running coach would not tell you that you could win or even finish the race if you did not (or only seldom) practice.

Now that we agree on the need for regular practice, let’s see how you need to practice, what exactly you need to do.

Give yourself credit:

However unfit, unprepared, or lost you may feel as you come to my class, I need you to agree to give yourself credit. You bring to the class and to your study of CS a lot more than you think you do. Most if not all of what we study in CS2 has a direct equivalent in real life. As a person, you have a lot to bring to what we are going to do: you know how to sort playing cards, you know how to look for stuff in your house, you know how to go from point A to point B without hitting walls or people, etc. You know a lot more than that. You may be working already, be taking care of your parents, your children. You may speak another language, another culture. You have time management skills that you often underplay. Bring them to class and use them. Be confident, know that your experiences are valued and useful in my class.

This belief is broadly shared in the UTEP community. The UTEP EDGE philosophy is spreading on campus. Check out the Bienvenidos campaign!

Focus on the real problem to be solved and give yourself credit (you can do it):

There are multiple questions that need to be addressed when approaching a programming question/lab. The obvious two that are usually at the center of our students’ work are What? and How? The “ultimate How?” will lead to a Java program that addresses the problem at hand. However, it is the last step, possibly the most “terrifying” to my students, but in fact, the easiest one if the earlier steps are taken properly.

So what are these earlier steps. They are the steps that consist in answering the following questions: 1/ “What?” and 2/ “How does that work in real life?” questions.

The “What?” question:

Before to rush into writing code that solves a problem, the most important thing to do is to make sure that you know “WHAT” needs to be done. Strategies that help at this stage of solving your problem include:

  • Asking questions (to your instructor, members of your instructional team); and
  • Rephrasing the problem in your own words (and checking with your instructor, members of your instructional team that you have it right).
The “How does that work in real life?” question:

At this stage in the CS curriculum, most problems can be illustrated by a real-life activity (sorting algorithms can be tried on playing cards, linked lists can be worked out with physical props like beads on a necklace or little-people toys). I have observed that 1/ recognizing how what is asked in a lab is similar to real-life situations, and then 2/ figuring out how we would approach this problem in real life are essential steps that contribute to developing problem solving skills.

As a result, any problem posed as a programming lab assignment should first be addressed as a real-life one. We should be able to come up with a no-jargon solution / solving strategy that can then be translated into Java (or any other language).

This step requires honesty: do not lay out a strategy to solving a problem that you would not use in real life. Ask yourself if that makes sense, if you could explain it to someone (a living one, not a computer). Until you can clearly explain how to proceed, in clear human terms, you are not ready to write any code.

Tip:as soon as you find yourself speaking in “create this loop”, and then “you have a nested loop”, and “call this method”, etc., you have strayed away from the path to solution.

Please take a look at the IDEAL problem-solving framework (resource 1 and resource 2), where:

  • I means Identify
  • D means Define
  • E means Explore
  • A means take Action
  • L means Look back

Persist:

Okay, let’s fast-forward a little. You are now done with the previous step and you are ready to code your algorithm / solution. What could go wrong, right? Well, although you are ready to code, many things could still go wrong: you do not remember the name of a given Java method, you tend to leave typos in your code, you forget semi-columns, etc. This is your last challenge before success. You cannot give up!

That’s the point: persist! Do not give up! The last muscle that needs to be exercised is the “debugging muscle”. This can be daunting if you get a lot of errors, but by exercising this muscle, you will soon develop an eye for errors: you will see them and know where they are coming from, making fixing them much easier. But to get there, you need not to give up and practice.  To help here, use an IDE that you are comfortable with. It makes coding and debugging much easier.

Finally, this phase is also one in which testing will come in handy (not just because it is a part of your lab requirements, but just because it is useful to making sure your code does what it is supposed to do: important, no?). Practice your Unit Testing skills: you will soon appreciate how useful and easy they will have become to you. It is well worth the learning curve.

In a nutshell:

It all comes down to: Practice, Practice, Practice… and focus your time and efforts where they need to be: the two fundamental questions as well as debugging/testing.

 

 

Some context.

I have taught the intro to computer science course at UTEP every regular semester since spring 2015. A lot of what I aim to teach the students in this course is how much computer science is about problem solving. In this respect, when I get to meet them, I believe that students are already pretty skilled in solving problems. They have solved and continue to solve problems daily (without realizing it: that’s the catch). By the time I get to meet them in their first CS semester at UTEP, most of my students have already been juggling jobs and school and commute for several semesters. This is serious problem solving! Nevertheless, they do not realize that and the main challenge I face in “teaching” my students problem solving is to get them to up their self-confidence in this area.

So, early on, as I started to teach the intro to CS course, I informally put together a so-called problem solving and programming club, meeting once a week. It had very limited success, although growing over the semesters when I held it (until fall 2016). The goal of this club was to bring students together around riddles and other problems that we would solve together during one hour a week. Sometimes, we would implement (program) solutions to problems, program ideas to test them, bend problems definitions while programming to push further and explore other ways of programming, etc. The ultimate goal was to create a fun environment in which students would regain confidence in their problem solving abilities. I did not conduct any study to formally assess the impact of this initiative. However, I noticed that students were developing a knack for riddles and other problems. The fear was vanishing. That was worth the effort, even if for few students only.

I then decided to try it as a full 3-credit-hour course. In summer 2016, over a month (4 weeks, a little over 2 hours daily), I taught a special topic on Problem Solving and Algorithms, to a class of about 15 students (a mix of junior/senior undergrads and graduate students). Since, all of a sudden, I could take advantage of 45 hours of meeting time with students on this topic, I was able to do even more, to structure my teaching around different elements of problem solving, different types of problems, even have graduate students do some research of specific problems. I used two books: first, a pretty friendly book of riddles and problems: Problem Solving Through Recreational Mathematics, by Averbach & Chein, Dover; and then The Power of Algorithms: Inspiration and Examples in Everyday Life, by Giorgio Ausiello and Rossella Petreschi, Springer. The first one provided a range of activities organized by topics, types of problems. The second one allowed us (and the graduate students mostly) to dive into specific problems, which they then researched further into and presented. Although there was again no formal assessment of the impact of this course, I collected anecdotal testimonies from students who took this course in regards to the impact of taking this course on their performance in other CS courses. I only received positive feedback. The main positive change was the newly found ability to pause before to dive into solving a problem: that is, to take the time to understand, rephrase, and model a problem before to start solving it. This sounds trivial, but it is crucial and often overlooked. A common tendency when approaching a problem is to slide through the understanding stage and to start to work… which often results in solving the wrong problem or in getting stuck at some point and unable to get out of such a deadlock.

In Summer 2017, as our CS department, led by Dr. Ann Gates, had just been awarded an NSF RED grant, among other things, the faculty revisited the UG curriculum and we proposed to add 1-credit hour courses to the curriculum to scaffold the early semesters of our CS UG students with complementing courses. Among the proposed courses was a course on problem solving, which turned into a series of three 1-credit-hour courses on problem solving: they are currently being developed, in consultation with Google, by UTEP (#1 in the series), California State at Dominguez Hill (#2 in the series), and NMSU (#3 in the series), which are CAHSI institutions. I developed the first course in the series, which is a variation of what I did before in my club and in my summer course, and I taught it twice during Fall 2017. The whole course was recorded and analyzed in the context of our NSF RED project. Findings have not been shared yet. However, after teaching this course twice, in addition to my prior experience, I wanted to share some of the elements of this course and why I think it is working.

Essential Elements for Problem Solving.

No Programming. It is important to mention that there was no programming/implementation involved in this course. It focused solely on developing the students’ ability to lie out a plan of action for solving a problem. So the emphasis throughout the semester was that “the solution does not matter; the journey towards it does”.

A Problem-Solving Framework. The biggest change (improvement?) from my previous experiences to the last two times I taught problem solving was that I had my students study and use a given problem-solving framework, namely the IDEAL framework: Identify, Define, Explore, take Action, Look back. There exist many problem-solving frameworks out there. Sharing one with my students did not mean to limit them to one way. However, I felt that they could use the comfort of one consistent approach (at mid-semester though, I shared another framework with them so that they could compare, contrast, and reflect on them). My goal was that, strong of this new tool (the framework), my students would feel empowered to take on any problem, even outside of their domain of expertise. This did work, at least as far as I could tell on the problems we covered in class. Each of the two times I taught this course, we had an invited speaker, from a domain outside CS, who came and presented a problem of his/her area, for my students to tackle. The two engineers at Google, who advised us on the creation of this course, also contributed a problem, which turned into a final presentation of the students’ work. Their problems were never CS problems per se.

Rephrasing and Pointing Out the Challenge. “I” and “D” are usually rushed or even merged, skipped when one is not skilled enough at problem solving. The risk is to end up solving a problem that is different from the presented one. A large part of the semester was spent practicing the rephrasing and defining stages of problem solving. An essential element of doing it right lay in the students’ ability to ask questions. They were expected to ask questions of all problems that were presented to them, even of the simplest riddles, for practice. Once students were gaining confidence in “I” and “D”, they had to practice clearly identifying the Challenge in the proposed problems. Indeed, there is no problem solving strategy if there is no challenge, if the problem has a trivial solution. And pointing out a challenge or challenges helps set the Exploration (“E”) phase of the problem-solving approach.

No Action, but a lot of Assessment and Long-term Monitoring. As mentioned earlier, this course was not concerned with implementing solutions, but rather with laying out an action plan. As a result, the “A” part of I.D.E.A.L. – taking Action, was fairly limited. This did not prevent us from discussing what should follow “A”, namely “L” – Looking back. Students learned how to plan assessment metrics and devise plans for adjustment, sustainability, once an action would have been tested or even deployed.

Concretely, how did this work? I believe that this course should be fun, rewarding, and gradually build a sense a confidence in one’s problem-solving abilities. Students should be challenged but gradually, and be on the edge of their sense of mastery. To achieve this, throughout the semester, we had a mix of riddles and larger problems, leading to much larger and complex and out-of-their-domain-of-expertise problems. But to get there, the mix consisted of riddles only at the start of the semester and larger (and much larger) problems were added little by little. Students enjoyed riddles and kept asking for them at times when we were doing less of them, later in the semester. Why riddles? Although I always emphasized that solution to problems are not important, in order to build a sense of confidence and mastery in my students and to maintain the fun aspect of the class, I felt that students had to get a sense of reward and in this respect, the more riddles proved to be the better. Here is why I like riddles: Riddles are understood very quick, so we can go through many: this allows for more practice. Although usually not representative of clear real-life situations, riddles can be very representative of common pitfalls in problem solving. I would often give riddles intended to trap my students, so that we can then have a conversation about why this happened, how to avoid the trap next time it presents itself, what such a similar trap would look like in a real-life scenario, and expand the riddle trick to an actual real-life meaningful problem. Although short, riddles lend themselves well to retrospection and analysis of the problem-solving approach: this allows, on small bites, to have students wording out their approaches and understand them better. It also allows them to practice on the IDEAL framework.

Attitude. I found essential to (1) encourage students to be creative, to word their ideas uncensored, to (2) validate their contributions and to explain how their ideas fit in the IDEAL framework, how their different viewpoints would nicely contribute to innovation in a diverse team, and to (3) gently push them to question the problems posed to them, as well as to challenge their own and their classmate’s ideas.

In closing, I am a strong believer that our students are strong problem solvers. However, until they have observed themselves often enough performing well in non-daily problem solving, they tend to fret, panic, and underperform in problem solving. A course like the one put together as a concerted effort with CAHSI institutions and Google has a tremendously positive effect on the students who took it. From the start of the 15-hour course to its end, students appeared transformed and they all delivered excellent work as their final presentation. I cannot wait to hear about and observe the longer-term effects.

 

 

 

In fall 2014, as two colleagues and I were readying ourselves to teach CS1 (in spring 2015), we decided to revamp the course, in the aim to reduce attrition (a long-standing problem in this intro course). Since then, I have revisited it several times: once funded by Google, and since spring 2017, funded by UTEP’s STEM Accelerator initiative. Often, I am asked what I did in this course. In this document, I leave out the details of all changes (I may address this in another document) to focus on the major changes I put in place.

VERY IMPORTANT:

Course Description: The purpose of this course is to present the student with the mathematical techniques used for analyzing the time and space performance of computer algorithms.  The focus will be on the practical application of these techniques to designing efficient algorithms.  The following topics will be covered: asymptotic notation, recurrences, lower bounds for worst case and average case, dynamic programming, searching algorithms, sorting algorithms, graph algorithms, and if time allows, parallel algorithms, string matching algorithms.

Textbooks:

It is very important that ALL students have their books from Day 1.

  • “Introduction to Algorithms”, by Cormen, Leiserson, Rivest, and Stein, Third Edition, McGraw Hill
  • “Algorithms in a nutshell”, by Heineman, Police, and Selkow, by O’Reilly, 2008.

Exams: There will be two examinations, some written assignments, homework assignments, quizzes (announced and unannounced — but roughly one quiz every week), two projects, and a presentation.  On of the projects will involve testing an existing library for performance purposes. The other project will involve programming some algorithms and carrying out an analysis on their performance.  For the presentation, students will present an algorithm research paper from a journal or conference, preferably recent.

For more information about the course, please download the syllabus here.

SUMMARY OF IMPORTANT DATES:

  • Information to be posted soon, as the semester starts

ANNOUNCEMENTS:

  • Week 2: No class on Monday: Labor Day / Quiz on Wednesday!
  • Week 1: Quiz on Wednesday

WHAT TO EXPECT — some of this semester’s milestones:

MATERIAL:

ASSIGNMENTS:

  • Week 16: (december 12)
    • FINAL EXAM on Wednesday December 12 from 4pm to 6:45pm.
  • Week 15: (december 3 and 5)
    • Presentations of projects 2
  • Week 14: (november 26 and 28)
  • Week 13: (november 19 and 21)
  • Week 12: (november 12 and 14)
    • Reading assignment: Chapter 26
  • Week 11: (november 5 and 7)
    • Reading assignment: Chapters 22, 23, 24, 25
  • Week 10: (october 29 and 31)
    • Midterm exam on Monday
    • Greedy algorithms on Wednesday (Read Chapter 16)
  • Week 9: (october 22 and 24)
    • Work on dynamic programming problems in teams
    • Review for midterm on Monday October 29
    • Project 1 due on October 25!
  • Week 8: (october 15 and 17)
    • Read Chapter 16 of Introduction to Algorithms
  • Week 7: (october 8 and 10)
    • Read Chapter 15 of Introduction to Algorithms
  • Week 6: (october 1 and 3)
    • Keep reading chapters 4, 5, and 6 from Algorithms in a Nutshell: you need to have it done by the end of Week 6
  • Week 5: (september 24 and 26)
    • Read Chapter 4 of Introduction to Algorithms
    • Homework assignment: Problem 4.1, Problem 4.6
    • Keep reading chapters 4, 5, and 6 from Algorithms in a Nutshell: you need to have it done by the end of Week 6
  • Week 4:
    • Read Chapters 1 and 2 of Algorithms in a Nutshell
    • Read Chapters 2 and 3 of Introduction to Algorithms
    • Homework assignment: Problem 2.1, Problem 3.1, Problem 3.4, Problem 3.6: homework will be randomly checked on Wednesday September 19th in class: have it ready in a file named: LastName.doc, LastName.docx, or LastName.pdf + your file must be readable without any problem of formatting using open office and word if it is an office document; if your name is called, you will have to send it right after that class.
    • Start reading chapters 4, 5, and 6 from Algorithms in a Nutshell: you need to have it done by the end of Week 6
    • Partial quiz solutions for loop invariants
  • Week 3:
    • Problem 2.3 (p.41) due on Thursday September, 13 at 11:59pm via email with email subject: “[CS5350] FirsName LastName: Homework: Problem 2.3”
  • Week 2:
    • Chapter 2 with special attention to the loop invariant
    • Problem 2.3 (p.41) due on Thursday September, 13 at 11:59pm via email with email subject: “[CS5350] FirsName LastName: Homework: Problem 2.3”
  • Week 1:

Additional material:

Note: More information (such as assignments, reminders for due dates, quizzes, exams) will be posted on this page as the semester goes.

Students: Please register at http://www.piazza.com/utep/fall2012/cs3360 using your utep.edu email address only.

Course Description: In this course we will study concepts and examples of programming languages with the goal of acquiring the tools necessary for critical evaluation and rapid mastery of programming languages and constructs.

TA. Angel Garcia, afgarciacontreras/miners…

His office hours are: Tuesdays and Fridays from 11 to 12:30.

Textbook: It is very important that ALL students have their textbook from Day1 of the semester.

  • Robert W. Sebesta, “Concepts of Programming Languages”, 9th edition, Addison Wesley

Exams: 2 mid-term examinations and one comprehensive final exam; unannounced quizzes.

For more information, please download the  syllabus here.

SUMMARY OF IMPORTANT DATES:

  • First examination: October 15
  • Second examination: TBA
  • Final examination (comprehensive): Wednesday December 12 from 1pm to 3:45pm.

ANNOUNCEMENTS:

  • Week 1: August 27th is our 1st day of classes!
    • COURI program for UnderGraduate Research:

WHAT TO EXPECT — some of this semester’s milestones:

  • Programming projects: 4 of them
    • First programming project on OOP in Java, due September 11th: description and report template.
    • Second programming project on AOP (AspectJ): description
    • Third programming project on functional programming: description, EXTENDED DEADLINE: October 24 at 11:59pm!
    • Fourth programming project on prolog: description, deadline: November 16 at 11:59pm.
    • Fifth programming project on PHP: description, deadline: December 4 at 11:59pm; special rule for extra points: see piazza!
  • First midterm exam on: October 15
  • Second midterm exam: on December 3
  • Final exam on December 12

MATERIAL:

ASSIGNMENTS:

  • Week 15: (december 3 and 5)
    • Second examination on Monday
  • Week 14: (november 26 and 28)
    • Reading assignment on Sections 6.5, 6.6, 6.10, and 6.11 of textbook: quiz on reading on Monday
    • Reading assignment: Chapter 9
  • Week 13: (november 19 and 21)
    • Homework due on Wednesday November 21 (via email to your TA): exercises 6, 8, 10 pp 241–244 Chapter 5 of textbook
    • Quiz on Wednesday!
    • Reading assignment: Chapter 9
  • Week 12: (november 12 and 14)
    • Prolog programming project due on Friday!
    • Make-up quiz on Wednesday
    • Intro to PHP on Wednesday
  • Week 11: (november 5 and 7)
  • Week 10: (october 29 and 31)
    • Do the prolog exercises distributed in class
    • Variables, type binding, storage binding
    • Read Chapters 5, 6, and 16
  • Week 9: (october 22 and 24)
    • Introduction to variables
    • Introduction to Prolog
    • Reminder: Project 4 is due on October 24. Exceptionally, projects turned in either Thursday or Friday by 11:59pm will only incur a penalty of 5 points. After that, the penalty will be back to usual: -10 points per extra day (starting Saturday morning)
  • Week 8: (october 15 and 17)
    • 1st examination on Monday
    • Axiomatic semantics
  • Week 7: (october 8 and 10)
    • Review on Friday for the 1st examination
  • Week 6: (october 1 and 3)
    • Semantics
  • Week 5:
    • Read Chapter 15 on Functional Programming
    • Monday: lab (bring your own laptop) and exercises on Haskell
    • Wednesday: lecture about functional programming
  • Week 4:
    • Read Chapters 3 and 4
    • Homework on AspectJ due Monday night (see piazza)
  • Week 3:
  • Week 2:
    • Read Chapters 2 and 12 of the textbook for Monday.
    • Read Chapter 3 of the textbook for Wednesday.
  • Week 1:
    • Read Chapters 1, 2, and 3 of textbook (quiz on chapters 1 and 2 soon)
    • For those of you who did not attend Monday’s session: Read, print, sign, and turn in the course syllabus

Note: More information (such as assignments, reminders for due dates, quizzes, exams) will be posted on this page as the semester goes.

Course Description: In this course we will study the foundations of constraint programming and solving, of numerical and combinatorial optimization, and we will review some of their applications in Software Engineering (e.g., testing, verifying).

Meeting times: Summer I (from June 11 to July 5), MTWRF from 11:40am to 1:50pm in CCSB room 1.0204.

Textbook: It is very important that ALL students have their textbook from Day1 of the semester.

  • K. Apt, Principles of Contraint ProgrammingCambridge University Press (December 17, 2009)

Exams: 1 mid-term examination and one comprehensive final exam; unannounced quizzes.

Homework: there will be reading assignments and quizzes to assess the reading and understanding of concepts covered in class. There will be some homework given, rarely to be turned in.

Project: the bulk of the work to do outside of the classroom will be about the 4-week long project. The project will involve a literature survey on the topic of your project, proposing a relevant timeline and deliverables, delivering on time, and presenting your work towards the end of the summer I period.

Grades: (see syllabus)

________________________________________________________________________________

SUMMARY OF IMPORTANT DATES:

  • First examination: Friday June 22th.
  • Project: due Tuesday July 3rd. Projects have been assigned on June 12th so by now, all students know their own teams and project topics. More detail to come about the requirements of the projects and deliverables.
  • Final examination: Friday July 6th

ANNOUNCEMENTS:

MATERIAL:

  • CS4365-5354 Syllabus
  • Copy of the daily grading form
  • Outline of the semester lecture and activities: each week will focus on one specific software engineering problem (more details to be posted)
  • Logic programming project: we recommend you use SWI-Prolog

ASSIGNMENTS:

  • Graduate students only:
    • summarize one article per week, to be chosen among the following articles
      • summaries are due on Friday June 22, Friday June 29, Wednesday July 3 (at 11:59pm) via email
  • Week 1:
    • for June 12: read Chapters 1 and 2
    • for June 13: read Chapter 3
    • for June 14: read Chapters 1 and 3 + Chapter 4 for graduate students
    • for June 15: read Chapters 5
  • Week 2:
    • for June 19:
      • read Chapter 5 and 7
      • Assignment to be turned-in on Code-Covering Test Cases: either program a small prototype or review the literature and summarize ideas (possibly your own) about how to proceed
    • for June 20: read Chapters 5 and 7
    • for June 21: re-read all chapters assigned so far, focusing on the topics covered in class
    • for June 22: review all that was covered in class so far for the first MIDTERM on June 22
  • Week 3:
    • No quiz on Monday! (but expect one on every other day of the week)
    • For June 26:
      • Reading assignment: re-read chapter 2 on optimization and chapter 3 (looking at the solving algorithm) + read Chapter 8
    • For June 27:
      • Reading assignment same as of June 26
    • For June 28:
      • Same reading assignment but with a special focus on Chapter 8 (in preparation of class group work on June 28)
    • For June 29:
      • Same as this whole week + chapter 9
  • Week 4:
    • For July 2: reading assignment: review of all chapters and material presented in this course
    • For July 3: all projects are due!
    • July 5: general review
    • July 6: FINAL EXAM!

OFFICE HOURS:

  • June 12: 2pm to 2:50pm
  • June 13: 3pm to 4pm (tentatively)
  • June 14: 10:00am to 10:30am
  • June 15: no office hour
  • June 18: no office hour
  • June 19: 2pm to 3pm
  • June 20: 3pm to 4pm
  • June 21: 2pm to 3pm
  • June 22: no office hour
  • June 25: 3pm to 4pm
  • June 26: 2pm to 3pm
  • June 27: 3pm to 4pm
  • June 28: 2pm to 3pm
  • June 29: no office hour
  • July 2: 3pm to 4pm
  • July 3: 2pm to 3pm
  • July 4: NO CLASS
  • July 5: 2pm to 3pm

Important message: all Tuesday due dates are moved to Thursdays!

Course Description: In this course we will study concepts and examples of programming languages with the goal of acquiring the tools necessary for critical evaluation and rapid mastery of programming languages and constructs.

TAs. Aditi Barua, abarua/miners… and Angel Garcia, afgarciacontreras/miners…
Their office hours are: Friday morning from 11am to 1pm for Angel in the research lab of the second floor, and Wednesday from 9am to 11am for Aditi, in room 3.1202F.

Textbook: It is very important that ALL students have their textbook from Day1 of the semester.

  • Robert W. Sebesta, “Concepts of Programming Languages”, 9th edition, Addison Wesley

Exams: 2 mid-term examinations and one comprehensive final exam; unannounced quizzes.

Grades:
Midterms                                         15% each
Final exam                                        20%
Quizzes and homework                  22%
Projects                                       23%
Class participation                      5%

SUMMARY OF IMPORTANT DATES:

  • First examination: Tuesday February 28th.
  • Second examination: Thursday April 11th
  • Final examination (comprehensive): Thursday May, 10th from 1pm to 3:45pm.

ANNOUNCEMENTS:

  • Week 13:
    • The deadline for programming project 4 has been extended!
    • Extra-credit programming project will be available this week (due May 3rd)
    • Look at the homework assignment for week 14!
  • Week 3:
    • First programming assignment will be given in class on Tuesday and will be due by February 21!
  • Week 1: January 17th is our 1st day of classes!
    • COURI program for UnderGraduate Research:

WHAT TO EXPECT — some of this semester’s milestones:

MATERIAL:

ASSIGNMENTS:

  • Note: unless otherwise specified, homework will be due via email on Thursdays before the class starts
  • Week 15:
    • Reading assignment: Chapters 3 and 4
    • Homework assignment: Chapter 3 Problem set # 22.c, 23, 24, and 25.
  • Week 14:
    • Reading assignment: Chapter 3, Section 3.5 and Chapter 4.
    • Homework assignment (due Thursday): Chapter 3, problem set #6, 11, 15, 17, 19.
  • Week 13:
    • 2nd Exams back on Tuesday!
    • Please note that the deadline for PP4 has been extended (one more week to complete it!)
    • Extra-credit programming project given on Tuesday, due on May 3rd
    • Reading assignment: Chapter 16 (on logic programming); Section 3.5 of Chapter 3 (on semantics)
  • Week 12:
    • Review on Tuesday
    • SECOND EXAMINATION on Thursday: list of topics now available (see in your emails)
    • Homework assignment: Programming exercises 4, 5, and 6 of Chapter 5, due Thursday
  • Week 11:
    • Topic of the week: data types
    • Reading assignment: Chapter 6
    • Advice: start working now on the homework for next week!
  • Week 10:
    • Topic of the week: variables and binding
    • Reading assignment: Chapters 5 and 6
    • Assignment will be given in class and due Thursday March, 29th
    • QUIZ on Thursday!
  • Week 8:
    • DO NOT FORGET THAT YOU HAVE A PROJECT DUE THURSDAY!
    • Reading assignment: Chapter 15 on functional programming
  • Week 7:
    • FIRST EXAMINATION ON TUESDAY!!!
    • Topics include: syntax (BNF, EBNF) and semantics (attribute grammars only), OOP, AOP
  • Week 6:
    • First programming project due on Tuesday Thursday February 21 23 (description)
    • Reading assignment: review all class notes, all chapters assigned so far. The first examination is around the corner: scheduled for February 28th!
  • Week 5:
  • Week 4:
  • Week 3:
  • Week 2:
    • Presentation about COURI, by Lourdes Echegoyen, on Tuesday, followed by a quiz
    • Read Chapters 1, 2, and 3 of textbook
  • Week 1:
    • Read Chapters 1, 2, and 3 of textbook (quiz on chapters 1 and 2 on Jan. 19)
    • For those of you who did not attend Monday’s session: Read, print, sign, and turn in the course syllabus

Note: More information (such as assignments, reminders for due dates, quizzes, exams) will be posted on this page as the semester goes.