CS 105: Introduction to Computer Science

Brief description: Introduction to the intellectual and software tools used to create and study algorithms: formal and informal problem specification; problem solving and algorithm design techniques; understanding the process of computation; impacts of computing systems on society; software reliability, formal verification, testing, and peer code review techniques; program clarity, complexity and efficiency; functional and imperative paradigms; associated programming skills.

Includes a required weekly one-hour lab meeting. Note that completion of the lab assignments and homework typically takes an additional 6-10 hours of work per week outside of the scheduled lab.

Prerequisite: None (students with prior programming experience may wish to take the placement test to start with a more advanced course).

Note that CMSC 231 Discrete Math is often taken in the same semester as either CMSC 105 or CMSC 106.

Haverford CMSC 105 is equivalent to Bryn Mawr's CMSC 113 - students may not receive credit for both.

CMSC 105/113 is often followed by CMSC 106: Introduction to Data Structures or Bryn Mawr's equivalent, CMSC 151.

Current-semester details such as instructor, schedule, syllabus, etc., are specific to each section.

Normally this course (and B113) is offered every semester, often with two offerings in the fall. (This search of the Haverford College Catalog may lead to useful information).

Labs

Labs make up a major and important portion of the work for this course. For due dates, please see information about the current semester. If lab assignments are visible in advance, note that modifications (including changing, cutting, or adding other labs) are sometimes made before they are officially assigned (a week or two before they are due), so any work done in advance is at your own risk.

Labwork should be done on the computers in the computer science "QuaCS" teaching lab, by going to the lab rooms (KINSC H110 or H204) or, one remote access has been discussed in class, by logging in remotely.

WARNING: some labs only run on the QuaCS computers, and copying the files has often led to students losing work, so please don't make copies unless the instructor has described how to do so properly via the "git" version-control system.

Details of Content and Structure

Though some specifics may vary by semester, this course normally includes content related to

• Computer Programming, i.e., the expression of computer software in a specialized language, i.e., Python. CMSC 105 focuses on algorithms, the verbs of programming, applied to a limited set of data structures (nouns) that are built into the language, such as numbers, "strings" of text, and lists or dictionaries that can be used to organize other data.
  
  CMSC 105 emphasizes two paradigms, i.e., ways of understanding what software is. In our study of the pure-functional paradigm, we think of software primarily in terms of the relationship of an algorithm's result to input, focusing on what the answer is. In our study of the imperative paradigm, we view software as a sequence of steps the computer must execute in a specific order, focusing on how the computer can be created.
  
  Computer programming is explored in the lab exercises and, in most semesters, via homework and in-class exercises that emphasize the ability to write software without assistance from the computer.
  
  The creation of data structures takes center stage in CMSC 106, which is often taken after CMSC 105. CMSC 106 emphasizes the object-oriented paradigm, typically introducing both pure-functional and imperative variants thereof.
  
  
• The Process of Computation is introduced at a foundational level, and considered in two frameworks (known as notional machines in the CS education field).
  
  Computation can be understood as a process in which an unchanging program updates a collection of potentially-changing relationships, e.g., between a variable name and the data "object" it names, and between a given data object and the value it currently has. This approach can be readily visualized, for either imperative or pure-functional software, via the debugger component of most standard software development environments, or a special-purpose visualizer such as Python Tutor.
  
  Alternatvely, the progress of computation can be understood as generalization of the idea of software refactoring, in which the software and its inputs are, together, repeatedly rearranged and simplified until a final answer is achieved. This approach pairs naturally with pure-functional code, though its application to imperative code is not usually explored in the undergraduate curriculum. Many individual refactoring steps are readily available in software development environments, but visualizers to illustrate the full refactoring/substitution-based approach to execution are rare (see The DrRacket Stepper or our N-Dolphin for examples).
  
  This material is primarily explored in homework and in-class exercises, which may include "by-hand" activities and/or the use of some of the aforelinked tools.
  
  The process of computation is explored in depth, through both a mathematial study of its theoretical properties, in CMSC 345 Theory of Computing, and courses that discuss concrete aspects of specific computing systems, beginning with CMSC 251 Principles of Computing Systems,
  
  
• The Impact of Computing Systems on Society can be hard to predict. In addition to the potential to cause deliberate harm, or to cause harm through failure to operate properly, computing systems can also cause harm in more subtle ways. Systems designed for one purpose can be adapted for other uses, and the intended use can have unforseen side effects. While it is impossible to fully prevent all such risks, we hope that an awareness of these issues will help programmers do what they can to manage them.
  
  This topic is normally discussed in lecture and explored via a lab project in which students learn to read data files and perform statistical analysis of the impact of a computing system.
  
  
• Problem Specification, i.e., appropriate ways of describing a problem that is solved, or which we wish to solve, via computation. Having a clear description is an important, though often overlooked, element of both individual and team programming.
  
  Specifications can be informal, e.g., natural-language (English) descriptions, or as precise as other elements of our computer programs, when they are expressed via test suites (see below) or other checkable properties such as preconditions and postconditions.
  
  This material is explored in lab exercises and other activities.
  
  
• Problem Solving Approaches, also knows as algorithm design techniques, are introduced at the introductory level. This study continues through CMSC 106 and into CMSC 340 Analysis of Algorithms.
  
  Early lab exercises typically require a specific approach to design and programming, whereas later labs give the students more freedom (and responsibility) to choose whatever approach works best for them.
  
  
• Reliability/Correctness of computing systems is explored in three ways.
  
  Most lab exercises require the development/enhancement of a test suite, which ensures that software must produce the correct answer for some specific set of test cases.
  
  Some lab exercises require the development of paired pre- and post-conditions. These can provide a foundation for precise reasoning about whether the software produces the correct answer for all legal cases, though the exploration of these reasoning techniques varies greatly by semester.
  
  Peer code reviews are important tools for understanding the correctness, efficiency, and clarity of software. Unlike test suites and pre-/post-conditions, this approach can reveal cases in which a programmer has misunderstood some aspect of the problem as well as how the programmer solved it. In some semesters, students engage a peer code review with other members of their lab section, in a setting that is designed to introduce this process gently, i.e., minimizing the potential for social discomfort or embarrassment.
  
  
• Efficiency, i.e., measuring or controlling the need for time, energy, carbon footprint, computer memory, etc.. This topic is briefly introduced in an informal way, to provide a foundation that will be enhanced in CMSC 106.
  
  Normally this is explored in a variety of in-class/homework activities and a single lab exercise.
  
  
• Clarity is important for both team software development, where other programmers will need to understand the software someone has written, and solo programming, where often one feels that software one wrote weeks ago looks like it might have been written by a stranger or alien being from another dimension.
  
  Students may receive feedback about clarity on their lab assignments from faculty or teaching assistants, and, in some semesters, provide such feedback during a peer code review session.
  
  

Course Calendar