CR: Winter 2014

From Soma-notes
Jump to navigation Jump to search

Decided changes (needs paperwork)

  • switch 3rd year courses that require 1805 to require 2804.
  • 3005: have 2406 and 2804 as prereq, not 1805 and 2402
    • implications for non-CS majors/minors?

Questions for others

  • DFW rates for 1805?
  • co-op about Java necessity - which languages are in demand?

To do

  • learning outcomes of BCS honours and major
  • status of COMP 2404, overlap with 2501, where C++ is in curriculum
  • 3004 - 1 credit?
  • systems programming and architecture in curriculum
  • role of 1406
  • writing, presentation skills
  • which courses are required in 3rd year
  • mobile stream integration
  • honours project
  • big data
  • large code bases
  • VMs in instruction
  • game stream
    • prereq for 1501
    • cap on enrollment
  • split/merged courses - mainly 1405/1005, 1406/1006

Writing and presentation skills

  • require students to take English or other humanities that requires reading comprehension and writing.
  • required second year course in writing
    • read technical papers of historic importance
    • write multiple small papers on readings
    • outsourced partially - jointly taught
    • prereq for 3004, 4905
  • Honours project
    • classroom component - half credit or less of material
    • posters for science fair, potentially in different room

Research methods course

  • teach research reading, writing, methods
  • 3rd year
  • divided into multiple modules covering different research areas, each module taught by a different prof
  • write paper for term, graded by prof in research area
  • also have some small grades - responses or critiques of research methods

Learning objectives for 1405/1406

In order to determine whether and how to change 1405 and 1406, here are some thoughts on what the learning objectives for first year should be.

Problem solving:

  • Be able to read and understand a written problem description.
  • be able to break down a program (or object) using single-purpose, reusable functions
  • Have a conceptual understanding of function input and output, not just syntactic understanding
  • be able to break down a program using single-purpose, reusable objects
    • understand the above is necessary for correctly designed programs, and that "programmer convenience" (e.g. let's lump everything into one class because it's easier) is never a valid design choice
  • experience designing objects that promote data abstraction and encapsulation at the simplest level
  • be able to create simple programs from scratch (e.g., on paper)

Programming language features/conventions:

  • Be familiar with the basics of expression evaluation: operators and operands; operator arity, precedence, associativity
  • Be able to program using the basic Java/C/C++ operators (compound assignment +=, -=, etc, prefix and postfix ++ and --)
  • Functions:
    • understand that all functions take input parameters, perform a task, and store the results in output parameters
    • given a function, be able to identify input parameters, output parameters, and input/output parameters
  • identifier names (objects/functions/variables), indenting, code commenting

Application development

  • Text-mode applications
  • Event-driven, asynchronous programming
  • GUI-based applications
  • make use of existing libraries and frameworks

Programming environment/runtime:

  • Understand a very basic memory model:
    • all variables are stored in linear fashion in memory
    • all variables have characteristics: name, value, data type, address in memory, scope
    • be familiar with the above terminology
    • anecdote from Christine: at the start of 2401, if I write "int i = 10;" on the board and ask what are the variable's "name" and "value", they don't understand the terminology
  • Have a conceptual model of how parameters are passed to functions and how values are returned
  • understand the difference between pass-by-value and pass-by-reference

Debugging techniques

  • Understand what deleting any line in a program will do and *why* that behavior occurs.
  • using "print" statements to observe dynamic program state
  • use of a command-line debugger, including understanding how to single step through a program and how to obtain the value of variables at specific points in program execution

Evaluation strategies

  • Grade programming assignments for quality (good design, following conventions) using clear criteria and constructive feedback, rather than whether or not they "work". It is insufficient to be marking assignments based solely on whether they work or not.

Tools

  • basic IDE use
  • version control software (git?)