Programming outcomes
From
Robertsurton (Talk | contribs)
(Created page with 'These are my (~~~) notes based on the Fall 2016 discussion of PSU's web of topics. The following outcomes are all existentially quantified over languages and tool sets (compiler...')
Newer edit →
Revision as of 19:17, 22 October 2016
These are my (Robertsurton) notes based on the Fall 2016 discussion of PSU's web of topics.
The following outcomes are all existentially quantified over languages and tool sets (compiler, debugger, editor, etc.); that is, any combination of language and tool set is acceptable for achieving the ASOT-CS, although a school accepting it for transfer may require students to demonstrate the same level of proficiency in a particular language or using a particular tool set.
Some outcomes were seen as better belonging to CS 160, which will reappear and be applied in the programming sequence. They include:
- ethics
- designing algorithms
- problem solving
- requirements and specification of non-programming problems
Some outcomes drew discussion and therefore seem to be the points on which schools differ:
- be able to learn a new language quickly for a particular task (e.g. problem, project, or class)
- unit testing
- OOP
- using
- creating
- tool use
- debugger
- reference documentation
- IDE
- memory
- dynamic memory management
- references
- linked lists
The tool use and memory discussion seem to be challenges because of the desire for language/toolset agnosticism, since the details (and which details seem natural to cover) depend so much on those choices. My impression of the purpose of the memory topics is to prepare a student to take data structures without spending a lot of time learning about references and linked structures.