The Artima Developer Community
Sponsored Link

Java Community News
Donald Knuth on Multi-Core, Unit Testing, Literate Programming, and XP

38 replies on 3 pages. Most recent reply: Jun 14, 2008 10:09 AM by John Zabroski

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 38 replies on 3 pages [ « | 1 2 3 ]
John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Donald Knuth on Multi-Core, Unit Testing, Literate Programming, and XP Posted: Jun 14, 2008 10:09 AM
Reply to this message Reply
> In my view, literately programmed code
> should be visible for every programmer
> through its evolution, so literate
> programming doesn't cope with OCP well.
> I guess it is why he prefer "re-editable"
> code to reusable black box code.
> But I think benefits of information
> hiding should not be sacrificed.

I prefer to take a more formal view. There are four levels of specification: defined, implementation defined, unspecified and undefined.

You should be able to re-edit implementation defined facts. The problem is the model you choose to write your programs in gets translated into an application binary interface that necessitates encapsulation. However, as Robert Young could probably point out, encapsulation is not nearly an important principle as data independence. In fact, the ability to break encapsulation while mathematically preserving functionality leads to optimizations! Sometimes the abstractions preserved by encapsulation are fundamentally too coarse-grained to be re-usable and shareable in complex systems. Moreover, in many systems today, encapsulation is ill-defined and results in ambiguous copy and transfer semantics: In C++, the compiler needs to know if an object embedded inside another object is owned by the object instance conceptually or merely related to the object instance. However, the proposed constraint solver for C++0x will fix this somewhat. Furthermore, many systems do not define guarantees between the caller and the callee, such as exception safety, so valuing their encapsulation is dubious at best if you don't know what the input and output wires map to.

Finally, anything unspecified complicates understanding of a system. Some systems have formal semantics that are complete, and so it is impossible for the system's configuration space to contain an unknown configuration.

Flat View: This topic has 38 replies on 3 pages [ « | 1  2  3 ]
Topic: David Pollak on Scala's Option Class Previous Topic   Next Topic Topic: Dojo 1.0 Released

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use