Stanford University
Computer Science 349: Winter 2005 - 2006
Here's my attempt to summarize the basic answers I was after for each question. Given their mushy nature, lots more could be written in each case.
Answer: a key aspect I was after is recognition that the cost (and value) of a feature is better evaluated in terms of feature interaction, than as an isolated unit. Moreover, the worst-case in this view is rather frigthening. If a company adds k features each release, and they have kN feature interactions. With this base analysis, you would expect a software system to evolve into something completely unsupportable fairly quickly. Howover, every software system is pushed to add features to keep customers happy and maintain a competitive advantage. Plus, the situation is not really that bad because a feature does not generally interact with all other features, types and objects.
Industry currently does informatlly try to eval. the impact of a feature in terms of modules that need changing, costs, etc. There are simply low-cost features that only affect one or a small number of modules in a simple way. However, ideally we should have more concise models and tools to evaluate interactions and cost of feature. Moreover, the real issue is often impact over time. I.e. what is the future cost of this feature together with all the others we have and will add going forward. One concern here is the scalability impact of a feature, both at present and in the future. This relates back to feature interaction because a given feature may cause non-lineary growth in memory or processing because of feature interaction. E.g. if you have a feature that need state per port-vlan, the cost grows multiplicatively in ports and VLANs.
In sum, there is growing awareness of cost of features, feature interactions but we need to get better theory, and better understanding of the impacts over the lifetime of software.
Answer: DL is basically right. However, the key aspects I am after are:
One can identify other dimensions on which one might compare audit vs. assert, but that is not what the questions was really asking.
Answer: What I was after was the recognition that there are often invariants that are related to whether an object is in a collection or not. For example, if an app. have a snapshot view of a process ready queue, as an app. iterates thru the queue, it get a pointer to a process that have been since been deleted from the queue, so the process object itself may indicate blocked even though the iterator suggests it is ready. Similarly, an object may be encountered in a directory iteration that has been deleted from the directory so the iterator suggests it is in the directory but a lookup on the key of the object does not find it in the directory. In general, a snapshot of a collection is too small a unit of state to ensure that many invariants hold.
Some answers mentioned that the app might now want the snapshot semantics, in effect. However, I really wanted to see any example of this case to make that compelling. Morever, presumably a class can easily providing the non-snapshot version too. The real focus of the question was to what degree the snapshoting really solved the semantics issues.
Answer: One aspect is just the overhead to create and manage snapshots. Many answers mentioned the timestamp based approach mentioned in the notes. However, as I mentioned in the notes, it is challenging to figure out when to really delete objects in a collection. As I see it, you need to maintain lists of all the iterators on the collection and either periodically run thru the collection deleting objects whose delete time is older than all existing iterators or do this each time an iterator is deleted. The alternative approach is to make a copy of the collection when the iterator is instantiated. Either approach involves extra passes over the collection.
In terms of comparison, when a snapshot is not needed so no redo is required with the version-approach, clearly that version approach is far cheaper.
When greater consistency is called for, you can use the version-based approach to either redo the iteration when the version has changed or make a copy of the collection (and redoing if it changes during the copy creation) and then perform the iteration on the collection copy (i.e. snapshot). The former means that a re-iteration may be required for the collection, so is comparable when there is contention, and in fact can be more expensive if contention causes more than two passes over the collection. The latter requires a pass over the collection so is comparable to a snapshot implementation (the timestamped version presumably requires a pass after iteration to delete). Overall, e version approach makes it feasible to be more efficient when snapshot semantics are not required and comparable when they are.
Answer: Considering Kerry first, there is an element of "digital divide" at least in the sense that far fewer programmers really understand templates and generic programming. However, given the benefits of templates for collections and smart pointers, it is infeasible to abandon them altogether. However, you can recognize a significant difference between the skill required to use a class template from that required to design/program the class template. You can have a few highly skilled senior programmers that can deal with class template design, if in fact you need any new ones beyond those provided by a good framework. Other programmers just need to use them, and it seems questionable to employ someone on an OOP project that cannot even use templates.
On the other hand, generic/template programming appears to be more difficult to develop, debug and maintain in the current state of the art. The big payoff comes in KLOC from a small number of class templates that are widely used. Also, a template version tends to be far more code than a single class instance, e.g. 70 lines of unique_copy as a class template vs. less than 7 as real code. Thus, a class template has to be used roughly 10 times to even achieve parity with non-templated code. Thus, limited selective use of templates provides benefit but extensive (and certainly exclusive) use tends to increase all the software engineering costs, so would be a competitive disadvantage.
In summary, judicious use of a small number of well-designed class templates such as provided by a good framework has compelling benefits, but additional use of templates, especially design of application-specific templates should be approached with caution given the costs and complexities of templates.