You may complete this assignment in teams of two provided both team members read the chapter
and work together to answer the questions. (In other words, don't "divide and conquer".)
Successful completion of this assignment fulfills the "Background and Context" learning objective.
- Why might it be detrimental to a language to have too many constructs / ways
of doing things? Can't programmers simply ignore the constructs they don't need?
(Discuss effects on both readability and writability).
- What do the authors mean when they say in Section 1.3.2 that "writability must be considered in the
context of the target problem domain of a language"? Give an specific example
of an evaluation that does not apply this principle.
- In your own words, explain what it means for a programming language to be
"reliable". (Don't just quote the book's definition.)
- According to the "Cost" section (Section 1.3.4), what is the main cost / consequence
of a language having poor readability?
- Why is the cost of poor readability potentially much higher than the cost of
poor writability or poor reliability?
- According to the section on "Programming Design Methodologies" (Section 1.4.2),
- What major cost shift took place beginning in the late 1960's?
- What major shift in program design resulted?
Updated Saturday, 14 January 2023, 4:19 PM
