-A A +A

CS2013-Strawman-PL-Programming Languages (DEPRECATED)

Primary tabs

15 posts / 0 new
Last post
CS2013-Strawman-PL-Programming Languages (DEPRECATED)

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on "PL-Programming Languages" Knowledge Area in the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page.

psosera's picture
UPenn PLClub draft comments
Your rating: None

The following comments are from the University of Pennsylvania Programming Languages group (Benjamin Pierce, Stephanie Weirich, Steve Zdancewic, Arthur de Amorim Azevedo, Aaron Bohannon, Chris Casinghino, Richard Eisenberg, Marco Gaboardi, Michael Greenberg, Cătălin Hriţcu, Justin Hsu, Karl Mazurak, Benoit Montagu, Peter-Michael Osera, Vilhelm Sjöberg. Benoit Valiron, Daniel Wagner, Brent Yorgey, Bob Zhang, and Jianzhou Zhao). We discussed the strawman document at a group meeting, collected impressions, and jointly edited them to produce the following:

High-Level Impressions
+ Overall, we are extremely impressed with this document -- the strawman proposal overall, and the PL material in particular. The latter seems well thought out, well articulated, intellectually coherent, and richly connected to other topics.

+ We are very pleased to see OO and FP represented as complementary approaches in the core curriculum! Indeed, the breakdown of OO, FP, and Event-based programming closely mirrors what we do with our intro courses now (CIS 120, http://www.cis.upenn.edu/~cis120). In it, we discuss all three paradigms in the context of OCaml and Java. When the time comes, we’d like to offer this course as an exemplar for the final document.

+ We could not find a specific topic regarding programming with explicit memory management anywhere in the document. We found discussion of its implementation (PL/Runtime systems, PL/Language Translation and Execution) but nothing about techniques for programming with explicit memory management. Much as we love garbage collection, we believe understanding how to program without it is a necessity and should be called out somewhere, e.g., as a core-1 topic in Systems Fundamentals.

+ The word “invariant” seems to appear just once in the whole strawman document (in the PL section, but even there en passant rather than as a fundamental concept). This seems a shame: ideas like loop invariants, recursive invariants, data structure invariants, critical sections (where invariants are broken), etc. are (in our experience) extremely powerful and useful tools for thinking about programming. Probably this belongs with material on data structures and algorithms, though, or perhaps software engineering -- these are not PL ideas per se.

Programming Languages (PL) Section
[p. 130, Line 39] We were unsure what was intended behind the topic of “Behavioral replacement”. Is the intention simply method overriding and its uses, or the (more complex and somewhat controversial) Liskov substitution principle? Whichever is intended, the wording here should be more precise, e.g., simply saying “Method Overriding”.

[p. 130, Line 42] The “Private fields” topic should be generalized to “Privacy and visibility of class members”, not just fields of a class.

[p. 130, Line 51] The topic “Benefits of effect-free programming” is worded in a non-neutral manner which is contrary to the rest of the topics in the text. For consistency sake, it should be renamed appropriately, e.g., “Effect-free programming”.

[p. 130, Line 55] “Processing structured data” ought to be “Processing recursively-defined data” or similar instead. The interesting cases of data types in functional programs are those that have recursive structure which is an essential distinction from handling data that is in a (non-recursive) discriminated union.

[p. 130 Line 56] Related to the previous comment, “Discriminated unions” here may not be the optimal term (though we’re sure it was chosen after long discussion!). Really what is important to highlight with functional programming that is distinct from other paradigms is its treatment of recursive data with algebraic data types. So there’s an argument that “Algebraic Data Type” should be used instead. (This was not a unanimous view in our discussion: “discriminated union” does sound less intimidating.)

[p. 130, Line 58] Related to the topic of first-class functions that should be mentioned in the parenthetical are currying and partially applied first-class functions. Currying and partial application are two of the “ah-ha” moments that distinguishes people that “get” functional programming and those that don’t. Currying and partial application could also be learning outcomes (which we discuss later in the comments).

[p. 131, Line 90] “Reference types” doesn’t seem like it belongs here for two reasons. (1) When we talk about type systems, we typically only distinguish between primitive/base and compound types. Reference types fall into the second of these buckets. (2) “Reference type” as we believe it to be intended seems to be a Java-centric notion especially when contrasted against primitive types. Other languages, e.g., C#, share this idea, but not all do. For example, O’Caml reference types are an actual type whereas with Java it is an implicit categorization of all non-primitive types. Perhaps instead there should be a topic concerning call-by-value and call-by-reference semantics where this distinction actually occurs. Such a topic should be added here to the Core-Tier1 topic list for type systems.

[p. 131, Line 104] The topics here don’t seem to seem to address exactly the set of ideas that we think should be teased apart when addressing static vs. dynamic typing:

+ When type errors are checked (compilation vs. execution).
+ Inability of static types to (directly) express certain patterns of code that dynamic types allow (e.g., if-expressions that return different types, heterogeneous collections).
+ The burden (according to one point of view) of adding type annotations, especially when prototyping programs.
+ The distinction between statically inferred types vs. dynamic types.
+ The distinction isn’t binary: it is a spectrum characterized by the precision of the type system which introduces engineering trade-offs between flexibility and total correctness.

In particular, the first topic (Line 105) aligns with our “When” topic. The second topic (Line 106) seems to address our “Burden” topic. But the last two (Lines 107-108) are vague and also do not seem essential to the discussion.

[p. 132, Line 130] It is not entirely clear if the intention here is simply knowing the distinctions and trade-offs between automated vs. manual memory management. Or if students should understand specific programming techniques (e.g., finalization/dispose patterns with automated memory management, raii with manual memory management) within these paradigms.

[p. 132, Line 133] (We have a separate sections for comments about the PL core topic learning outcomes below).

[p. 135, Line 246] “Control abstractions: exception handling”: exception handling should be removed. This gives an impression that exception handling is an elective when it is clearly not (as it is mentioned in SDF), and that it is an esoteric technique, which again it is not.

[p. 135, Line 250] We aren’t sure what is intended by “String manipulation via pattern-matching”. Is the intention here regexes specifically? This topic should be expanded with concrete examples (perhaps in a parenthetical).
Separating the “PL / Type Systems” topic (p. 136, lines 283-297) from “PL / Formal Semantics” (p. 137, lines 300-313) is a bit awkward; for example, it doesn’t make a lot of sense to talk about “type safety as preservation plus progress” (line 289) without first talking about “Formal definitions and proofs for type systems” (line 307). But this is a minor point, as these topics are electives anyway; instructors are going to mix and match according to their own taste.

[Line 305] If you’re going to mention axiomatic semantics, you should really also mention Hoare logic The “PL / Language Pragmatics” topic (p. 137, lines 315-327) seems a bit minor and miscellaneous. We would propose just dropping it.

PL Core Learning Outcomes [p. 132-133, Lines 133-159]
We think the list of learning outcomes could be organized better. Some of the outcomes are specific to a particular topic and others cross topic boundaries. It would make this section easier to read if it only contained learning outcomes that included multiple core topics and place the remainder alongside their associated topics. In particular:

[Line 134] 1. should be in the cross-topic section (and we think is a very important one!)
[Line 138] 2. should be under the Object-oriented Programming topic.
[Line 140] 3. should be in the cross-topic section.
[Line 142] 4. should be in the cross-topic section.
[Line 144] 5. really ought to be broken up into “writing algorithms that avoids assigning to mutable state” and “writing algorithms that avoid considering object identity” and place them in the Functional Programming and Object-oriented Programming topics, respectively. Several of the other learning outcomes could also be broken up like this in order to increase clarity, e.g., a similar argument could be made for learning outcome 4.
[Line 145] 6. should be in the Event-driven and Reactive Programming section.
[Line 146] 7. should be in the Object-oriented Programming topic.
[Line 148] 8. should be in the Basic Type Systems topic.
[Line 149] 9. should also be in the Basic type Systems topic.
[Line 151] 10. should be in the Program Representation topic.
[Line 153] 11. should also be in the Program Representation topic.
[Line 156] 12. should be in the Language Translation and Execution topic.
[Line 158] 13. should also be in the Language Translation and Execution topic.

So there are only a few cross-topic learning outcomes that should be highlighted although they are very important.

Reply to UPenn
Your rating: None

Thanks for such a large group effort. Let me jump right to detailed replies to your specific suggestions:

> [omission of programming with explicit memory management]

Indeed. The steering committee discussed this and we plan to try to add something relevant to the Systems Fundamentals KA. I have made a note to myself to follow up on this.

> [omission of invariants from the entire Body of Knowledge]

Ooh, I agree with all of your comment about this. I hope something can fit in SDF or SE. I will ask and repeat the general comment to the full steering committee.

> [behavioral replacement]

We did basically mean the Liskov substitution principle but were not sure such jargon would be known by this name (though another comment mentioned it as well). For now, I am trying the longer, "Notion of behavioral replacement: subtypes acting like supertypes". I like this because "acting like" is a bit less formal than Liskov, which seems appropriate here. I don't like it because it may still not be clear.

> [private fields should be "Privacy and visibility of class members"]

I like this suggestion and took it as is.

> ["Benefits of effect-free programming" is not neutral]

Per your suggestion, I removed "Benefits"

> ["Processing structured data ought to be "Processing recursive-defined data" or similar]

I didn't change this since one needs cases for even non-recursive datatypes and the ("(e.g., trees)") felt like a strong enough nudge.

> ["Discriminated unions" vs. "Algebraic Data Type"]

Yes, this is a close call on which jargon to use, and I ended up leaving it as is.

> [currying and partial application]

I didn't want to add this in tier-1 as it's less universal in languages without convenient syntax for it (Scheme, C#, ...), so I added it as its own topic under tier-2, albeit without a specific learning outcome attached.

> [reference types]

I agree and massaged the situation by deleting "Reference Types" and adding references to the parenthetical list in the following topic.

> [topics for static vs. dynamic typing]

I struggled with this feedback more than any of your other suggestions and ended up, so far, making fewer changes than I would have liked. Maybe you or the subcommittee will have better ideas. In more detail:

* left "Errors early vs. errors late/avoided" as is since it seems to capture when errors are detected and the 'avoided' is a benefit of dynamic that errors irrelevant to how code is actually used are never brought to a programmer's attention.

* for the next bullet, I made a change to try to hit your second and third points, producing this mouthful, "Enforce invariants during code development and code maintenance vs. postpone typing decisions while prototyping and conveniently allow flexible coding patterns such as heterogeneous collections"

* I left the next two bullets since I think they are relevant, e.g., code reuse/misuse is related to arguments over "duck typing". And dynamic partisans often complain about having to fill out all cases before running a program whereas static case-exhaustion analysis is invaluable to others.

* You propose including statically-inferred vs. dynamic. Indeed, I always thought that would fit here, but it ended up being awkward, so I left it to the elective topic of "Type inference". In particular, I'm persuaded not to include it because unless you're using a language with substantial type inference, it's probably not a compelling topic. I personally love such languages, but many curricula won't use them.

* You point out the distinction isn't binary. I couldn't agree more and yet this is probably too subtle a point to get across in the body of knowledge. In fact, in my opinion there's a second axis here that is also a continuum, namely the "when". In addition to "compile" and "execute" there is "link" and "load". And some errors can even be delayed dynamically. Indeed, decades of experience have led to languages where 3/0 raises an exception but 3.0/0.0 propagates NaN.

> [intention w.r.t. programming with memory management]

hopefully having learning outcomes right here makes the intention clearer. And once SF adds material related to this, I'll need to revisit this, add a cross-reference, etc.

> [remove exception handling from control abstractions]

I see your point, but left it for a couple semi-defensible reasons. First, it helps the casual reader know what we mean by "control abstractions" even if he/she has never heard of continuations or monads. Second, the SDF treatment may be quite minimal, basically when and how to /throw/ an exception as opposed to language constructs for catching them, re-throwing them, etc.

> [what is meant by string manipulation via pattern matching]

I added a parenthetical about "regular expressions"

> [if mentioning axiomatic semantics, should mention Hoare logic]

Is this important to mention /explicitly/ rather than as a natural thing that would be presented if doing this topic? Analogously, there is nothing under denotational semantics about any particular domains.

> [pragmatics seems droppable]

I also do not cover this elective material in my curriculum, but since it's emphasized in many courses and textbooks, I wanted to have a place for it in the Body of Knowledge.

> [core learning outcomes should be organized better]

This feedback was near-universal and heeded it. Your feedback was the most specific in this regard and was very helpful in distributing the learning outcomes to the Knowledge Units. Rather than a "cross-cutting" one, I decided to /duplicate/ some learning outcomes in FP and OOP, with comments indicating that this was happening. I think this will be clearer.

Inbalance in proposed requirements on PL
Your rating: None

I am referring to the table in Page 129.

1. A total of 8 hours of instruction required by Core-Tier-1 is simply not enough. A curriculum satisfying the minimum requirement could produce computer science graduates who have not been exposed to syntax and semantic analyses, who know only of object oriented programming and functional program only.

2. The report is heavily biased towards object-oriented and functional programming. Other programming paradigms are elective, meaning that they need not be covered.

Inbalance in proposed requirements on PL
Your rating: None

I am referring to the table in Page 129.

1. A total of 8 hours of instruction required by Core-Tier-1 is simply not enough. A curriculum satisfying the minimum requirement could produce computer science graduates who have not been exposed to syntax and semantic analyses, who know only of object oriented programming and functional program only.

2. The report is heavily biased towards object-oriented and functional programming. Other programming paradigms are elective, meaning that they need not be covered.

reply to lunjin
Your rating: None

Thanks. Please see the chapter of the document explaining "tier-1 vs. tier-2". It would be almost impossible for a curriculum to drop all the tier-2 PL material, and I hope they don't. They should include all or almost all of it. That said, syntax and semantic analyses are typically taught in optional compilers courses, so it does not seem plausible to put much material there in the core. It is for this reason we have the Program Representation and Language Translation and Execution KUs.

As for emphasizing OOP and FP (and to a lesser extent, event-driven), that is how things ended up being divided -- there is a lot of that material here, but plenty of more general software concepts in SDF and SE. All of that material will have to be taught in /some/ programming context and hopefully other paradigms will be part of many curricula. Are there specific other paradigms that should be mentioned, even as electives? Notice we included logic programming, but as an elective.

Claremont Colleges draft colleges
Your rating: None

The following comments are from the Programming Languages faculty at the Claremont Colleges (Kim Bruce -- Pomona College and Melissa O’Neill, Chris Stone, & Ben Wiedermann -- Harvey Mudd College):

High-Level Comments

Overall we are very pleased with the content of this area. Below we include some specific suggestions for improving the presentation that should have little or no impact on the hours.

(1) Introduction: We think the introduction could provide more motivation for and detail about the study of Programming Languages. In addition to the reasons given, we believe that PL is worthy of study because computer scientists and programmers are not passive observers of programming language design and implementation but engage in these activities every time they design, e.g., the API for a library. There are still other good reasons to study PL. Might it be possible to draw from the many excellent contributions to the SIGPLAN programming language curriculum workshop (http://dl.acm.org/citation.cfm?id=1480828)? Other Knowledge Areas in the draft proposal contain more detailed introductions -- surely PL can contribute the same!

(2) Learning outcomes: We think that the learning outcomes could benefit from a different organization, from a tighter coupling to the topics of study, and from more precision. We give more detailed suggestions below, but overall we think the draft could be improved if (a) learning outcomes were moved closer to their topics, (b) each topic had at least one learning outcome. We also think it would be preferable if the average level of mastery for the learning outcomes were a bit higher. (There are several subsections where most or all of the outcomes are knowledge-based -- the lowest level of mastery.)

(3) Topics vs. Depth: (This may be a comment on the draft in general, not only the PL Knowledge Area.) In a few places, a topic is mentioned multiple times in different tiers. It is not always clear what the draft intends students to learn about a particular topic, in a particular tier. We think that clearer, more specific learning outcomes could help.

(4) Cross-referencing: (This may be a comment on the draft in general, not only the PL Knowledge Area.) It's not clear what "cross reference" means. Is a cross-reference a dependence on another topic or an overlap with another topic?

Detailed Comments

[page 130, line 34]: We weren't sure what precisely was meant by "Dynamic dispatch: definition of method-call". Is it, roughly, "the control-flow of polymorphic calls"? The learning outcomes don't mention dynamic dispatch, so a specific outcome related to this topic could help clear things up. (For example, "Given a set of method definitions and a set of method calls, predict which definition corresponds to which call.")

[page 130, line 39]: What is meant by "behavioral replacement"? (Is this another term for the Liskov substitution principle? Again, the intent might be clearer with more specific learning objectives.)

[page 130, lines 51-54]: The Tier1 section of Functional Programming lists many benefits of effect-free programming, but such a section does not appear in either the Object-Oriented Programming or Event-Driven and Reactive Programming sections. In general, it might be nice if the structure of these sections resembled one another. For example, the OO section could contain topics related to the benefits of OO, and the functional section could contain a topic for decomposing a problem into functional units (i.e., the functional analogue of line 30).

[page 130, lines 51-54]: These lines implicitly hint at the benefits of functional programming for concurrency; perhaps the draft should state the benefit explicitly?

[page 130, lines 55-57]: We think that the draft could be clearer about the basic concept in these lines, especially in line 57.

[page 130, lines 58 and 65]: These lines are an instance of a possible duplication between two tiers of the core. We believe that a specific learning objective could help clear things up, especially for line 65. For example, is the intent that students be able to recognize when to use map, etc., or be able to write map, etc. from scratch, or...?

[page 131, line 96]: (This may be a comment on the draft in general, not just the PL section) As best we can tell, this is the only explicit mention of undecidability in the entire draft! This seems like a key concept that should be tied into another portion of the draft.

[page 132, lines 119-131]: Should this section include mention of JITs, e.g., to give a sense that the real world is not strictly divided into compilers and interpreters? Alternatively, perhaps change the word "vs." to "and" in line 122?

[page 132, line 130]: Perhaps change the word "notion" to "heuristic", to convey a sense of the undecidability of perfect garbage collection? (i.e., reachability is a heuristic for liveness)

[page 132-133, lines 134-159]: We believe that these learning objectives should be moved closer to their corresponding topics, to clarify both the topics and the objectives themselves. For example, Objective 10 (lines 151-152) mentions language definitions, which don’t seem to appear as a topic.


Might parameter passing mechanisms (e.g., by-value, by reference, and by-name) be a topic to include in Tier1 or Tier2?

Might name resolution / scope be a topic to include in Tier1 or Tier2? There's a hint of these ideas as they relate to memory layout on page 132, line 128; but this topic might be worthy of mention in and of itself. Even statically scoped languages have a variety of name resolution rules.

Might the concept of undecidability be appropriate for the Static Analysis and Type System sections?

repy to Claremont
Your rating: None

Thanks for the thorough read and coordinated response. Onto the details...

> [add more motivation and detail to preamble, e.g., usefulness for API design]

I'm torn on this. On the one hand, I agree with you there are plenty more reasons and motivation we could give. On the other hand, there are advantages to "under-selling" a bit. In particular, non-PL people have read this paragraph and agreed with everything in it, which is great since it motivates and justifies the material that follows. So I'm tempted "not to push it."

> [learning outcome organization]

Done, though -- and I may get in trouble for this :) -- I can't claim with a straight face that /every/ topic has a corresponding learning outcome at this point. It's close now.

> [low level of mastery]

I tried to follow the descriptions of what the "levels of mastery" are supposed to mean and this is what I came up with. I was surprised when finished that only one learning outcome was at the highest level, but many were at the middle level and it will just depend on where courses are in a curriculum (lower level vs. upper level) how "deep they go" on many of the topics.

> [topics vs. depth]

Hopefully the reorganization of learning outcomes, including labeling outcomes as tier-1 or tier-2 unless the entire KU is one or the other, helps in this regard.

> [cross-referencing]

This means overlap, not (necessarily?) dependence. I'll make a note to suggest that be explained somewhere.

> [unclear meaning of dynamic dispatch]

Good suggestion, I added a new learning outcome of, "Correctly reason about control flow in a program using dynamic dispatch."

> [behavior replacement]

I did mean Liskov substitution but didn't think that jargon would be any better known. I edited it to, "Notion of behavioral replacement: subtypes acting like supertypes" but I worry this isn't better enough.

> [suggestion to make OOP and FP more uniform in structure]

I didn't do this mostly because I feel the learning outcomes already pushed the dual nature of OOP and procedural decomposition pretty far (farther than some may want) and most people wanted the FP section to emphasize the effect-free aspects.

> [benefits of FP for concurrency]

An earlier draft had this, but we decided to take it out for the more general issue of "other code" not having side effects that affect "your code". In this sense, concurrency is just one example of a more general issue.

> [lines 55-57 should be clearer]

I agree line 57 needs to be rewritten. I'm going to throw it back to the full subcommittee since I'm not sure what to say. Suggestions welcome.

> [differences between lines 58 and 65]

I added and revised learning outcomes to deal with this. So now tier-1 is to write useful functions that take and return other functions whereas tier-2 is focused on iterator-like functions. That means you can do both tiers by teaching map/reduce/filter, but for tier-1 you could do something else instead.

> [only mention of undecidability]

It /is/ surprising how much "PL people" seem to care more about decidability what is an /absolutely/ fundamental and universal concept. But fear not, it is elsewhere in the document, just under its synonym "computability". See the elective KU AL/Advanced Automata Theory and Computability and the core KU AL/Basic Automata Computability and Complexity (which discussed the halting problem).

> [mention JITs?]

hmm, I couldn't figure out a natural way to mention them, though I certainly don't mind including the idea. There is already the notion of "dynamic code generation", which at this level may be close enough to a synonym.

> [change notion to heuristic?]

I didn't do this because to me (and I could be wrong) "heuristic" has a connotation of being neither sound nor complete, where of course reachability is a sound approximation. So on a technical level, I'd be happiest with "approximation" but this may confuse non-PL people.

> [move learning outcomes to KUs; what does (10) correspond to]

Done. I put (10) under Language Translation and Execution, as a general point for the KU.

> [omission of parameter-passing mechanisms]

Maybe this is a personal preference of mine, but I don't see the need for this even though it seems common in PL courses. Certainly call-by-value and the notion of references and even C++-style by-reference comes up in many intro courses, and there's nothing wrong with that.

> [omission of name resolution / scope in tier-1 or tier-2]

It's certainly in the elective "PL/Compiler Semantic Analysis". And I like teaching it in lower-level required courses, but don't think the Body of Knowledge needs to require doing so as an explicit topic.

> [omission of undecidability in Static Analysis and Type Systems]

Even though it's not mentioned explicitly, I don't see how one would teach this advanced material without it coming up, at least informally. I'll see if the subcommittee has ideas for how to tweak the learning outcomes to make this "more obviously true".

Memory management
Your rating: None

The only place manual memory management is really mentioned in the whole document appears to be in PL/Language Translation and Execution, line 130; and even here, it is more about comparing manual memory management to garbage collection. So I'd suggest its inclusion over in SDF or someplace similar (this might tie into my comment about "intermediate programming concepts" actually), but learning outcome #12 (p 133, line 156) suggests it might belong somewhere in the PL core instead.

In any case, manual memory management certainly belongs somewhere in the body of knowledge, and probably in the core (maybe in tier 2).

reply to blahedo
Your rating: None

The steering committee discussed this and decided that SF was the best place (although there was no perfect place). I'll follow up to make sure this doesn't get forgotten.

Feedback on KA: PL- Programming Languages
Your rating: None

I have posted some comments that I believe apply to all KAs within the CS2013 Strawman Report-Chapters 1-5 thread. I would like to make reference to those comments here since they apply to all KAs.

The comments are posted under the following subjects:
First of All: Thank You.
Matching of Topics and Learning Outcomes for Core-Tier-1 and 2.
Unique Labeling or Numbering of all Topics and Learning Outcomes.
Improved Correspondence between Learning Outcomes and Topics.
Consistent Labeling for Levels of Understanding.
On the Importance of the Learning Outcomes in Core-Tier1 and 2.

Comments for this KA:

Page 130, Lines 29-34 and 39-45: We should move the corresponding Learning Outcomes closer to their respective topics. If necessary we could add a 'PL/Integrative and Comparative' KU.

Page 130, Line 33-34: The concepts of sub-classes and inheritance are quickly grasped by most students. The concepts of overriding, overloading, and dynamic dispatch are much harder to grasp and should be moved to Core-Tier2.

Page 130, Line 42-43: The concepts of encapsulation is usually quickly grasped by most students and can be moved to Core-Tier1.

Page 130, Line 51: Should it say 'side-effect-free programming'?

Page 132, Lines 114-117: I think that the topics listed in this KU cannot realistically be covered in 1 hour. This KU may need to be moved into the Elective category.

Page 132, Lines 123-127: These two topics should be reclassified as Elective within the KU.

Page 135, Lines 229: The term model-checking here makes me believe that this topic is misplaced. This I believe should be included within the PD/Formal Model and Semantics KU.

reply to dcdl
Your rating: None


* move learning outcomes closer to topics: done for next draft. (And all learning outcomes are clearly tier-1 or tier-2.)

* I agree overriding and dynamic dispatch are harder for students than inheritance, but as they're the essence of OOP, I think they need to stay in tier-1.

* Encapsulation is quickly grasped and can be moved to tier-1: Over in SDF, topics like "interface vs. implementation" are tier-1 and rightfully so. Here, I mean that teaching how to do encapsulation with objects or how to do encapsulation with closures can be tier-2, though I certainly wouldn't want my curriculum to omit it.

* "side-effect-free" vs. "effect-free" -- I think it's the same, and "effect-free" might emphasize a bit that we don't even allow updating the state of arguments (as opposed to global/static variables).

* lines 114-117 can't be covered in 1 hour: It's a really close call and I totally see your point, but the intention here is really to emphasize just the bare basics -- that we can represent code as a data structure such as an AST and then do something with that data structure. I think that's doable with one lecture in an appropriate course. Naturally, elective courses like compilers can spend weeks on such ideas.

* lines 123-127 should be elective: This is one of those topics where any of the details can be fairly called elective, but it seems core that students should graduate knowing how to "connect" the bits and bytes over in SF with the programming constructs in SDF and SE and PL. That's the intention here.

* model-checking is for PD: in recent years, model checking has become a very effective technique for software analysis, even of single-threaded programs. It is also still, of course, very valuable in concurrent systems, where it originated.

Feedback from ACM Education Council meeting
Your rating: None

[Comments below are from ACM Education Council meeting discussion of CS2013]

Intro description is great.

Line 43: Interfaces revealing only method signatures – this idea seems to be becoming less common in widely used programming languages. Objection was mainly just at “revealing only method signatures”. Interfaces are fine.

PL/Functional Programming
Should be able to teach some of these concepts in a non-functional language. Requiring teaching a functional language to capture this will require many more hours.

Line 51-57: Most instructors wouldn’t know what this section was talking about. Needs to be written for a lay audience, but topic is worthwhile.

Move Line 65 to Tier1.

Move line 55-57 to Tier2.

Line 58: Most people think of first-class functions as including closures. Tier1 topic would really be something more like “Functions as data (e.g., function pointers, taking, returning, and storing functions)”. As stated, the Tier1 requirement forces institutions to teach a language that supports first-class functions (Java and C++ don't). But "functions as data" sees to be a reasonable compromise across almost all languages.

Perhaps there should be a module that explains the overarching concept of different programming paradigms.

PL/Event-Driven and Reactive Programming – this doesn’t seem like a Programming Language issue. This really seems like a Software Development Fundamental. This is really more of a programming structuring issue.

Line 91: Are “unions” fundamental? (Sentiment was that they are not.)

Line 94-96: Needs to be rewritten to be understandable for a layperson

Line 100: Generic types really need to be Tier1

Notion of “abstract data type” needs to be in SDF/Fundamental Data Structures somewhere

Organization of learning outcomes makes it difficult to understand. Really need to have consistent structure of learning outcomes as other KAs. (e.g., line 140-141 convolves Tier1 and Tier2 outcomes). (Several people reiterated and emphasized this point.)

Lines 140-141: Be clear that phrase "such as" does not mean that all these methods have to be covered as that would require teaching languages that implement all these paradigms, which is a large hidden cost.

Line 156-157: is there a cross-reference having to do with memory addresses or architecture that should be mentioned here.

reply to ACM Ed Council breakout section
Your rating: None

[This is a little more difficult to reply to as it is really scribed notes from a group discussion that I wasn't present at, but I'll give it a go...]

* "interfaces revealing only method signatures": The intention here was just to clarify what we mean by "interface", which can mean a lot of things in computer science. We didn't want to say "Java-style interfaces" since we assiduously avoided ever mentioning a language by name. The point is the idea of using an object in terms of its interface, not its class, or the fields that it has, etc. I can't think of something more general than method signatures that won't be more confusing. Suggestions welcome.

* "should be able to teach FP concepts in a non-FP language": Absolutely! Nowhere does the BoK require using a particular language or even paradigm. If you want to teach OOP using C (not C++), go for it! I don't personally recommend it, but it's more than doable even though C does not have /built in/ support for OOP.

* "move line 65 to tier-1": Tempting indeed, but in both OOP and FP we left iterator-like concepts in tier-2. I certainly hope most/all curricula include them.

* "move lines 55-57 to tier-2": as other comments made clear, we need to reword this, especially line 57. The basic topic corresponds to a tier-1 learning outcome, so we need to get our point across better.

* "line 58 think of first-class functions as including closures" -- the distinction in jargon is technical and may be impossible to make exactly clear to everyone, but certainly, as I noted above, I disagree that anything here requires using a language with particular features. Teaching the /tier-2/ learning outcomes without built-in support for closures might be difficult, plus Java will have them soon, Python has half of what you need and you can survive with that, etc.

* "event-driven doesn't feel like PL" -- indeed it's a close call, but it seemed best to keep FP, OOP, and EventDriven together.

* "are unions fundamental" -- they are from the perspective of being the logical dual of records (instead of having a foo /and/ a bar, you have a foo /or/ a bar). In OOP, the natural way to /represent/ a union is with subclasses of a common superclass, while other paradigms have more direct representations.

* "lines 94-96 not understandable to a layman" -- can someone elaborate? Maybe line 96 would be clearer if we started with undecidability rather than making it the last word? Or used "computability" as a synonym?

* "generic types in tier-1": I wouldn't mind, but then again there isn't much in tier-2 of PL that I wouldn't personally put in tier-1, especially compared to many other things in tier-1 in the Body of Knowledge. Moreover, I consider generic types as described here a "really useful thing" but static vs. dynamic typing to be a "core concept of computer science", so I'm not sure I'd promote one before the other.

* organization of learning outcomes difficult to understand: almost all replies indicated this and I've fixed it for the next draft.

* "such as" does not mean many different languages have to be taught: that seems clear enough, although across a curriculum one /should/ use multiple languages and indeed this doesn't show up in hour-counts (much as students at some point need to learn a build system and that doesn't show up either).

* cross-reference to memory management: we need to add memory management to SF and then add a cross-reference.

responses as of September 2
Your rating: None

As the chair of the subcommittee working on the PL Knowledge Area, I've just done my first batch of edits since the Strawman. In doing so, I read all the comments available as of today quite carefully and will now respond to each of them in appropriate detail. But I wanted to give a general THANK YOU to everyone who replied -- the feedback was very useful. Even in the cases where I have chosen, for now, not to incorporate a suggestion, it helped clarify our thinking and in every case it's just a judgment call as we work to create a concise document for many constituencies.

Let me also add that I'm posting all these "replies" somewhat prematurely -- before even sharing my edits with the rest of the subcommittee, much less publicly. So further changes are likely. I'm replying now because there are so many great comments that if I don't do so, then I'll forget the details of the edits I just made and it will be much more work for me later. Given the level of detail, please excuse any conciseness -- I assure you I am being specific not dismissive.

There are still a couple more weeks to comment on the Strawman Draft, so I encourage any follow-up conversation that would be productive.

--Dan Grossman

Log in or register to post comments