Topic: programming
Leaders: Steve Ramsay and Tom Horton
Steve delivers paper
Response to Steve:
JU: we shouldn't be too frightened of amateurism.
WM: proposes terms "responsible user" as substitute term. Students
should be "responsible users" rather than "non-amateurs."
TH: one goal of program--create graduates who can have a conversation
with computer scientists. to facilitate this, we must have some
common ground. a common language. computer scientists should/must
think our research projects are interesting.
JD: what is the distnictive qualities of this degree as opposed to,
say, an MIS or an MS in computer science.
MIS degrees in McIntire, both undergraduate and graduate. Talk to
these people?
SR: teaching programming so that people can write cgi scripts OR teach
programming primarily so that they can have informed, responsible
engagement with the issues (and the type of conversations mentioned
previously).
GR: how long does this take? two parts here: core concepts and JAVA.
How much time is spent doing each of these?
SR: what would people need to understand to take the Software Design
or
"Humanities Information Systems" course in the second year? that's
what we need to teach. we could achieve that in a semester. could
not achieve that in bootcamp or proficiency requirement.
TH: thought second-year course would be very applied: students
bringing experience and tools from different perspectives to build
something, and that something should be substantial. need significant
preparation to be prepared for this activity.
brought documents that list what students should know before that
second-year course.
JD: why don't we review the proposed curriculum for the entire
program. maybe a course just needs to be added, so maybe this is
mostly an administrative issue.
GR: problem of amateurism, if you design a curriculum that essentially
covers the first two years of a computer science undergradute degree,
how can you call it a graduate degree?
SR: many programs that have similar problems -- cs admits graduate
students who don't have undergraduate degrees in cs -- and they solve
it by requiring students to take articulation classes, undergraduate
courses in cs that aren't taken for credit
GR: how do we distniguish this from cs courses? talk about history of
programming. the historical aspect distinguishes the humanities.
JU: let's switch to the actual topic -- programming in the context of
the kr seminar.
TH: very difficult to find good readings. let's start with chapter
one of _An Introduction to Programming and Object-Oriented Design
using Java_ by Nino and Hosch. read this for next week.
talk today about section 1.2
what we might leave out--discussion of hardware
design patterns, inspired by architecture, might serve as a model for
where our students might go. tom will end with a bit of code to
demonstrate this marriage, to see where we might go.
Tom's talk:
data vs. functionality (algorithms, procedures)
algorithms: often there b/c they work on data and data structures
(slightly more complex organization of data)
-implicitly, an algorithm is a series of steps that can be expressed
precisely, mathematically, easily executable and repeatable
-when studying algorithms, become interested in efficiency,
computability
-when interested in data structures, become interested in models and
operations (that are part of that model)
-example: have a set and a new element. is the element a
member of the set? membership is an operation
-models --> efficient storage
-operations --> algorithms
algorithm + data structure = programming
abstract data type = abstract model of data + set of operations that
manipulate that data
-example of abstract data type = set
-reason it has "abstract" in its name - want to separate this from
implementation; different implementations have different efficiencies
-when building software, start with ADT and don't worry about
implementation. leads to modular software -- can replace the adt or
the implementation without replacing both. reusable code, libraries
abstraction: data abstraction and procedural abstraction
-data abstraction - if we want to represent something, we choose the
most important parts of it to represent; we choose the important
characteristics and omit the others
-procedural abstraction - when thinking about an operation, you can
think about it at different levels of detail
JM: infinite number of data types?
WM: different languages allow different types of ADT's.
SR: what is the minimum number of ADT's? are there primitives here?
WM: each programming language specifies this.
TH: many different levels of abstraction here. computer scientists
often jump from level to level without being explicit about their
"location".
WM: maybe what we want from our "non-amateurs" or "responsible"
students is to know at what level of abstraction they are working and
talking.
composition: dtd -- combination of adt's, a model for combining adt's,
for combining elements, attributes, entities
JU: is composition the act of combining ADT's OR a set of rules or
constraints for how these might be combined?
TH: the first.
WM: at the level of the ADT, it's very difficult to talk about the
characteristics of the deployment; at the level of the composition,
you know something about the deployment
JU: ADT doesn't tell you anything about the dtd
object: encapsulation, bringing things together into one place
-data encapsulation
-procedural encapsulation
set #3
data = Hamlet
284KB
operations = union
member
object couples model and operations
-group together things that are related. supposed to be easier to
maintian.
-at the level of the ADT, talking about operations in an abstract
sense, not considering particular implementations
-object is a way of realizing an ADT
-conceptualizing operations with data types
object model (class): model for what an object is
-class vs. instance of object
-class is same thing as type
set
data = collection of words
size
operations = union
member
domain modeling: designing the object model(s)
WM: could we call domain modelling "knowledge structure design"
SR: yes!
inheritance: classes can inherit characteristics from other classes
-defining something new by referring to something old and modifying it
WM: encapsulation let you decide what to hide. that's how you manage
complexity--decide what you can ignore in these discussions.
information hiding: building components that are accessed on a "need
to know" basis
-characteristic of object-oriented programming, one distinction
between adt and object
SR: this facilitates working in groups. you don't have to know how
all other "parts" of a program work.
TH: why JAVA or other object-oriented language is best for our
purposes. students can work together, building modular systems.
JM: natural language is like object-oriented programming; if you turn
all of this around on language, you learn that this is the hidden
structure and workings of language. downside is that you hide
information, you create amnesia, because you allow things to operate
without complete knowledge of their workings, because of information
hiding.
analogy to literary studies. you can talk with scholars about
_paradise lost_, and ask them to what edition they are refering and
they won't know. but isn't that essential? it is from one point of
view. making explicit things that are hidden.
TH: information hiding -- selective revelation -- a design decision.
designers decide what is known and what isn't.
GR: aren't there times when the black boxes need to be opened?
JD: is there a taxonomy of classes?
TH: JAVA has a built-in taxonomy of clases. other languages don't.
-object: memory address, class value
-when o-o systems run, you can ask an object "what are you" and "what
operations do you have"; the dynamics of runtime
JU: maybe moo programming is a place to start
SR: likes the idea of moo programming. the reward of having understood
the stuff is immediate--you create a space that you can navigate
-you could turn this into a serious meditation
SR: what should we do next week?
JU: check and see if Alderman classroom is open?
JD: when do you talk about history of programming languages from
humanities perspective
-how might we bring in history of formal logic, analytic philosophy,
formal languages, etc.
-boole, frege
JU: don't get Alderman, get projector and single laptop
JM: talk about algorithms
This archive was generated by hypermail 2b30 : Fri Sep 21 2001 - 14:57:41 EDT