← Back to the Introduction to Computer Science outline The Course Maker
← Introduction to Computer Science outline
Week 10 · Discussion: Traditional alternative (no AI)

Week 10 Discussion — Open Code, Kept Data? — Traditional alternative (no AI)

Introduction to Computer Science Free sample edition
Traditional alternative (no AI), unpublished. In the course this is a separate discussion that ships unpublished beside the adaptive discussion: same objective, no AI. An instructor who prefers it publishes it and unpublishes or deletes the adaptive one, as the note at its top says.

Instructors: publish this instead of the adaptive version if you prefer, and unpublish or delete the adaptive one.

Hook

A club fair sign-in sheet can be a plain list of names, a set that keeps each visitor once, or a dictionary that remembers how often each person came. This week you learned that a dictionary finds a value by its key, that a set keeps one copy of each value, and that a missing key raises KeyError, so print(log["comics"]) stops before it prints anything.

Your discussion question — choose Option A or Option B; they carry the same weight and the same rubric, and you say which you picked.

Option A: Picture a campus club that needs a sign-in program built on this week's tools: a dictionary that maps each member's name to a visit count, kept up to date with the counting idiom. Open-source software publishes its source code so anyone can read, change, and share it; proprietary software keeps its code private and is usually sold. Take a position on whether the club should build on an open-source tool it can read and change or a proprietary product it pays for, and say what each choice trades: openness against pay for the people who build the software, and control against outside support. Use this week's ideas (dictionary, key, counting idiom, set) and say what someone who weighs that trade differently would argue.

Option B: The same sign-in program could keep only a set of the names that came, which answers who came and nothing more, or a dictionary that maps each name to every time that person signed in. Take a position on how much the program should keep about each person, and say what the club gains and what it risks with each choice. Use this week's ideas (set, dictionary, key, key-value pair, insertion order) and say what someone who weighs usefulness and privacy differently from you would argue.

There is no single right answer. People who agree on every fact about how a dictionary and a set behave still disagree about whose code to trust and how much to keep about people, because those questions rest on values and judgment as well as on facts. Pick the option you actually care about, and make your case.

Expectations

Activity format: one initial post followed by two substantive peer replies. Plan on about 45 minutes across the two deadlines; your instructor sets both due dates in Canvas.

Your initial post — by the first due date (early in the module week):

  • Say which option you chose.
  • For Option A, describe the sign-in program's dictionary (its keys and its values), say whether the club should build on an open-source tool or a proprietary product, and name what that choice trades; for Option B, say whether the program should keep a set of names or a dictionary of each person's visits, write out one key and its value, and explain what the club gains and risks.
  • Use at least two of this week's terms (dictionary, key, key-value pair, set, counting idiom, insertion order) correctly.
  • State the strongest case for a view you do not hold, in one or two sentences.
  • Length: roughly 150–250 words if written. You may instead record your post as audio or video (about two minutes) and attach a transcript; both forms are scored by the same rubric.

Your replies — by the second due date (the end of the module week):

  • Reply substantively to at least two classmates.
  • A substantive reply does more than agree: run their counting idiom on a short list of names and report what it prints, point out a key that a lookup would miss, or make the strongest fair case for the side they did not take. "Nice point!" on its own does not count.

What a strong post looks like:

I chose Option B. A study group's sign-in program needs to know who came, so I would keep a set built from the day's names, which drops the repeats; a dictionary that maps each name to every sign-in time keeps more about each person than the group needs. If the group later asks who stopped coming, a set of each week's names still answers that. Someone could argue that a dictionary of visit counts helps a group notice who is drifting away, and that is a fair point, but I would ask members before keeping it.

Notice how it names the collection, says what the program keeps, takes a position, and states a fair case for the other side. That is the bar.

Participation rubric

This discussion is worth 10 points. The three criteria below look at your initial post and your peer replies.

How the 10 points of this discussion are earned
Criterion Full credit Partial credit No credit
Quality of the initial post (4 pts) A specific program and its collection described, with keys and values or set members named, a clear position with a reason, and a fair statement of another view A program is present, but the collection stays vague, or the position is asserted without a reason Missing, off-topic, or no reasoning about the code or the data it keeps
Use of course concepts (3 pts) Uses dictionary, key, value, set, and the counting idiom precisely, with every claim about what a lookup or a set prints matching a run Uses a term loosely, or treats a key and a value as the same thing No course terms, or used incorrectly
Engagement with peers (3 pts) Two or more substantive replies that extend or challenge a classmate's reasoning One substantive reply, or replies that only agree No replies, or "I agree" with nothing added

Post early if you can — the best threads happen when people have time to reply before the second due date.

Built with The Course Maker · samples.thecoursemaker.com