tag:blogger.com,1999:blog-32575062946748196412024-03-08T01:30:17.675-05:00Natural SoftwareMorgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-3257506294674819641.post-62821001318598543862010-12-10T14:42:00.000-05:002010-12-10T14:42:18.082-05:00Klingon ScalaEnglish is a "<a href="http://en.wikipedia.org/wiki/Subject_Verb_Object">subject-verb-object</a>" language. This denotes the ordinary order of words in an English sentence. For example, "He loves her," reveals his feelings, but not hers. When we write code in an object oriented language, we tend to choose words that reflect this practice.<br />
<br />
In <a href="http://www.scala-lang.org/">Scala</a>, given a Set <b><i>ns</i></b> of Integers, we can use the Set's <b><i>contains</i></b> method to ask whether a given number is in the Set.<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> val ns = Set(8, 15, 17)</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> println(ns contains 42) //false</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> println(ns contains 17) //true</span><br />
<br />
In a sense, <i><b>contains</b></i> is a binary operator that carries ordered pairs to Booleans. We emphasize that, unlike other binary operators such as `+`, this one is not commutative. A snippet like "42 contains ns" would mean something else entirely, and doesn't even compile.<br />
<br />
<span class="Apple-style-span" style="color: purple;"><span class="Apple-style-span" style="font-size: large;"><span class="Apple-style-span" style="color: black;">A </span><a href="http://c2.com/cgi/wiki?EmbeddedDomainSpecificLanguage">DSL</a><span class="Apple-style-span" style="color: black;"> with ∈</span></span></span><br />
<br />
Klingon (<a href="http://en.wikipedia.org/wiki/Klingon_language">Tlingan</a>) is an "<a href="http://en.wikipedia.org/wiki/Object_Verb_Subject">object-verb-subject</a>" language. Translating word-by-word from such a language, "Her loves He", or more properly, "She is-loved-by him" again tells us about his feelings, but not hers. Sometimes when writing code, it would be easier on the reader to shuffle the order of our operands.<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> println(42 `∈` ns)</span><br />
<br />
This of course does not compile because there is no such <b><i>`∈`</i></b> method of integers. However, when the gain in readability is worth the effort, Scala offers a way to write such expressive code.<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> class MyElement[X](x :X) {</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> def `∈`(xs :Set[X]) = xs contains x</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> implicit toMyElement[X](x :X) = new MyElement(x)</span><br />
<br />
This approach contrasts a bit with <a href="http://en.wikipedia.org/wiki/Monkey_patch">monkey patching</a> found in other languages. On one hand, the Scala approach tends to be a bit more verbose, since a new class is defined. On the other hand, Scala allows careful control over the modification's scope. Instead of globally altering the integer type as monkey patching would do, Scala affects the code only where the <b><i>implicit</i></b> function is imported.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-90524600215970985962010-12-03T10:25:00.019-05:002010-12-03T11:34:19.245-05:00Scala Duck Typing, AlmostThere are a couple of different approaches to type systems, and I'm not talking about the whole static vs. dynamic thing. The <a href="http://en.wikipedia.org/wiki/Nominative_type_system">nominative</a> approach requires subtypes to extend base types explicitly. The <a href="http://en.wikipedia.org/wiki/Structural_type_system">structural</a> approach allows types to be equivalent if they merely have the same methods. Scala supports both.<div><br /></div><div><div><span class="Apple-style-span" style="color:#3333FF;"><b>Nominative Example</b></span></div><div><br /></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>trait Printable { </span><span class="Apple-style-span" style="font-family: 'courier new'; ">def print :Unit </span><span class="Apple-style-span" style="font-family: 'courier new'; ">}</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><br /></span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>class Nominative extends Printable {</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>def print { println("Nominative") }</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div></div><div><br /></div><div>If we define a function that accepts <i>Printable</i> instances, then it will happily accept <i>Nominative</i> instances, too.</div><div><br /></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>def nominative(p :Printable) = {</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>p.print</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>nominative(new Nominative)</span></div><div><br /></div><div><div><span class="Apple-style-span" style="color:#3333FF;"><b>Structural Example</b></span></div><div><div><br /></div><div>Because our <i>Structural</i> class below does not explicitly extend <i>Printable</i>, the compiler does not let us pass its instances into the <i>nominative</i> function, even though it has a suitable <i>print </i>method. And sometimes, that's exactly the kind of type safety we want.</div><div><br /></div></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>class Structural {</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>def print { println("Structural") }</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><br /></span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>nominative(new Structural) // does NOT compile</span></div><div><br /></div><div>But, other times it isn't. Scala is powerful enough to support structural types, whose definitions look like traits but without names. We can use the <i>type</i> keyword to give our structural type an alias.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-style-span" style="font-family:'courier new';"> </span></span><span class="Apple-style-span" style="font-family:'courier new';">type CanPrint = { def print :Unit }</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>def structural(p :CanPrint) = {</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>p.print</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>structural(new Nominative)</span></div><div><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-tab-span" style="white-space:pre"> </span>structural(new Structural) // compiles!</span></div><div><br /></div><div>A nice feature here is that our <i>Structural</i> class was defined before <i>CanPrint</i>, so structural typing is useful when we must adapt old code to a new purpose.</div><div><br /></div><div><span class="Apple-style-span" style="color:#3333FF;"><b>An Interesting Idiom</b></span></div><div><br /></div><div>Finally, let's consider an interesting non-legacy case. Suppose we want structural typing, and we also have full control over our class definitions. It sure would be nice to be able to have the compiler check that our signatures match up.</div><div><br /></div><div>Unfortunately (or perhaps fortunately, since it's not completely clear what it should mean), the following does not compile.</div><div><br /></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space: pre; "> </span>class DoesNotCompile extends CanPrint {</span></div><div><br /></div><div>So instead, let's use the <i>Predef.identity</i> generic function to ensure that our class does indeed have the correct structure.</div><div><br /></div><div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space: pre; "> </span>class AnotherStructural {</span></div></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-style-span" style="color:#CC0000;"><b>identity[CanPrint](this)</b></span></span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><br /></span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>def print :Unit = {</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>println("AnotherStructural")</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div><span class="Apple-style-span" style="font-family: 'courier new'; "><br /></span></div><div>If we had misspelled or forgotten the <i>print</i> method, our class would not have compiled.</div><div><span class="Apple-style-span" style="font-family: 'courier new'; "></span></div><div><div><br /></div><div><span class="Apple-style-span" style="color:#3333FF;"><b><br /></b></span></div></div>Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-21579329643984232442009-11-23T08:36:00.006-05:002009-11-23T09:27:20.954-05:00AspectJ and Scala<div><div>What is the "atom" of software? If you consider an atom to be the smallest thing with which you can work, while continuing to do chemistry, then what's the software analogue?</div><div><br /></div><div>My first thought was that an atom is a file. I can jar them up to make molecules, and string peptides of them together to make <a href="http://www.osgi.org">OSGi</a> bundles. At some point the inorganic chemistry of programming becomes the protein-rich biochemistry of software engineering.</div><div><br /></div><div>Or maybe an atom is the largest thing that, in isolation, can't possibly have a bug in it. Something like an instruction. Or maybe even a fully unit-tested class or method.</div><div><br /></div><div>But, the history of the atom allows our analogy to grow richer, and weirder. Originally, atoms were a computational aid. They were discovered as a way to predict the outcomes of macroscopic chemical reactions. Even up until around <a href="http://wien.cs.jhu.edu/AnnusMirabilis/AeReserveArticles/eins_brownian.pdf">1905</a>, there were still a handful of practicing chemists who didn't believe in atoms, except as a calculational tool.</div><div><br /></div><div>But real they are, regardless of the intended meanings of the symbols chemists use to denote them. So, atoms feel more like <a href="http://en.wikipedia.org/wiki/Aspect_(computer_science)">aspects</a> to me. Always there lurking in a program’s behavior, even if not represented using aspect syntax in the source code.</div><div><br /></div><div>If I have a class implementing the public <a href="http://en.wikipedia.org/wiki/Application_programming_interface">API</a> of some library, then I log all the incoming calls. That logging is an aspect, even though I might have duplicated those <a href="http://www.slf4j.org/">slf4j</a> calls in a dozen places. If I have code that takes care to release resources after I've acquired and used them, then that's another aspect. And if I've forgotten the finally clause somewhere, then that bug is a contaminant in the reactants, which makes my program behave differently than my chemistry equations would predict.</div><div><br /></div><div>The trouble with hand-implemented aspects like repetitive logging calls or finally clauses -- even when you remember all of them -- goes beyond the biz logic pollution that they impose. All that duplicated code permits inconsistencies. For example, the log message in this method here looks a little different than the one over there.</div><div><br /></div><div>And that's a bug escape. Because the log scraper that customer support is using, which you didn't even know about, is going to malfunction on that logging call that's only half a bubble off plumb.</div><div><br /></div><div>It's a bit like isotopes of atoms. Not all carbon atoms are alike. You used a carbon-12 here, but whoops you used carbon-14 over there. And we know that one can decay on you. You used mostly <a href="http://en.wikipedia.org/wiki/Hydrogen-1">protium</a>, but here's a deuterium, so the heavy water that you made from it has measurably different physical properties (like boiling point), even though the chemical properties are the same.</div><div><br /></div><div>Keeping with the analogy, hand-implemented aspects take you out of ordinary chemistry and force you to worry about nuclear and physical effects. It would be better to elevate aspects in the code to natively supported compiler constructs, like classes, so everybody is using the same isotopes.</div><div><br /></div><div>That's why using <a href="http://www.eclipse.org/aspectj/">AspectJ</a> and Scala together tops my list of exciting things to do. I think of AspectJ as an external <a href="http://www.martinfowler.com/bliki/DomainSpecificLanguage.html">DSL</a> that allows me to define <a href="http://www.martinfowler.com/bliki/DomainSpecificLanguage.html">pointcuts</a> into my Scala code. Pretty much all my code, including the <a href="http://en.wikipedia.org/wiki/Advice_(computer_science)">advice</a>, continues to be written in Scala itself. The real virtue of AspectJ lies in the <a href="http://en.wikipedia.org/wiki/Aspect-oriented_programming">weaving</a>.</div><div><br /></div><div>And for some elegant work on internal DSL alternatives, refer to the <a href="http://www.jot.fm/issues/issue_2009_11/article5/index.html">paper</a> by <a href="http://www.codecommit.com">Daniel Spiewak</a> and Tian Zhao about an AOP implementation in Scala.</div><div><br /></div><div>So, rather than worrying about polluting my biz logic with code that better belongs in aspects, I'm now on guard against letting my biz logic leak into my aspects. And this is a much happier place to be.</div><div><br /></div><div>Come to think of it, the false promise of object oriented programming was to offer reuse. This never really happened because classes are the wrong size to be reusable. Too small to be independently deployable, and too large to exclude application-specific implementation details. Instead, <a href="http://en.wikipedia.org/wiki/Object-oriented_programming">OO</a> 's importance comes from the organizing principles it champions. But I wonder if aspects, devoid of custom biz logic, might take us closer to reusable software. Components and libraries are reusable in the large. But might some group (or <a href="http://www.webelements.com/">period</a>) of little aspect atoms be reusable in the small?</div><div><br /></div></div>Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-61806541477897556752009-10-29T22:44:00.002-04:002009-10-29T22:51:04.971-04:00Principled ConcordionThere are a couple of ways to look at a hiatus from blogging. Either you are so successful that you rationalize you're too busy or important to reflect on all the wonderful things happening, or you've grown too slothful to find something exciting enough to share. I recently went to the No Fluff Just Stuff conference, and it has recharged my batteries, much as it did the last time I attended. Life offers only the palest excuses to avoid thoughtful introspection, or to fail to discover shareworthy things.<br /><span style="font-weight: bold;"><br />Analogies, Analogies</span><br /><br />Lewis Carroll famously asked, why is a raven like writing desk? The question remains the archetypal example of a riddle deliberately concocted to have no solution. Nevertheless, I love contrived analogies for a couple of reasons. First, they are useful because they can communicate profound ideas economically. Second, they are whimsical and can warp the mind into discovering new ideas.<br /><br />Which brings me to why developing software is like modeling a pendulum. To predict the future behavior of a simple harmonic oscillator, I need to know both the current position and the current velocity. Without two pieces of information, I can't solve the differential equation, and chart the pendulum bob's trajectory. Sorry, but there's just no getting around needing two values. Blame mathematics itself.<br /><br />We often attack software projects like this. We figure out our current state and use it to predict where we need to go. This is a bit like taking a snapshot of the customer's expectations or requirements, and marching in the correct direction. The problem is, taking these measurements is really hard. And just a small error in requirements can lead to unsatisfied customers.<br /><br />But, there's another way to solve differential equations. I still need two pieces of information, but they don't both have to be "initial" conditions. In a Dirichlet problem, I'm given an initial and a final position. From these, I can figure out the intermediate positions and the velocities.<br /><br />We should (and the better among us do) develop software like this. By capturing requirements as stories, and expressing them as executable tests, we reduce our measurement errors. Moreover, our trajectory is anchored by the end condition, not mearly by initial guesses, so we're less likely to march off into the weeds.<br /><br /><span style="font-weight: bold;">Concordion</span><br /><br />Consequently, I'm becoming increasingly enamored with Concordion. There are many descriptions of the tool available on the web, so I won't parrot them. Instead, I'd like to offer a different perspective, which I hope will not offend the Concordion community.<br /><br />Concordion is an organizing principle, which helps one design acceptance tests and other tests of software. To be pedantic, it's actually an instantiation of such a principle, much as Smalltalk is an example of object oriented programming. My take on it is this: a family of automated tests deserves human-readable views into them, with appropriate encapsulation or elision of distracting details, such as execution order.<br /><br />Concordion is often compared with FitNesse, but infrequently contrasted with it. FitNesse drives tests. I can go to a web page, push a button, and see my test run. Concordion, however, is a view into tests. I go to a web page to see results, which probably came from a continuous integration server. This difference is profound.<br /><br />You can find a dozen books on object oriented programming, particularly the older ones, that sing the praises of OO because it permits code reuse. In the real world, reuse turns out to be the least compelling reason to embrace object oriented programming. The real value of OO principles lie in the improved organization of the resulting code. We mean "improved" here for human readability, not necessarily performance or computer efficiency.<br /><br />Analogously, you can find many books about automated testing and the virtues it brings to software development. But a neglected advantage of good automation is that it offers ways to organize tests. Well presented tests are superior expressions of requirements.<br /><br />With Concordion, I can design web page views into my tests. I leave many details, such as the order in which tests run, to my continuous integration server. For example, tests with similar setup requirements can be grouped together. But I can organize the presentation of the results any way that I want. For example, tests can be organized by sprint, or by module, or by cross-cutting feature.<br /><br />Concordion makes software development look more like a Dirichlet problem, where I can keep the end in mind from the very beginning. Thinking of Concordion not as a tool, but as a principle, will shape how I program. And I still have much to learn about how one does that well.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-30608263562008905782009-06-24T12:01:00.001-04:002009-06-24T12:01:02.872-04:00More Scala Using RAISINLast time, we offered a minimally functional emulation of C#'s using syntax, to manage resources elegantly in Scala. We defined a curried function, whose second argument was a simple block of code. We'll refine that approach and try to bring about the remaining goals we set for ourselves for this feature.<br /><blockquote style="font-family: courier new;"><pre><br /> def using[T <% Disposable]<br /> (resource: T)(block: => Unit) = {<br /> try {<br /> block<br /> }<br /> finally {<br /> resource.dispose<br /> }<br /> }<br /></pre></blockquote><br />One problem with our first cut was that the object encapsulating the managed resource had a larger scope than we wanted. Since we constructed our FileHandle instance outside of the block that used it, one could accidentally access it after it had been disposed.<br /><blockquote style="font-family: courier new;"><pre><br /> val handle = new FileHandle("trouble")<br /> using(handle) {<br /> handle.read<br /> handle.write(42)<br /> }<br /> // big trouble below!<br /> handle.read<br /></pre></blockquote><br />What we really need is not to pass a Unit into the using function, but a function that accepts the resource as its argument. In other words, we'd like to be able to make a useful function and pass that as an argument into the using method<br /><blockquote style="font-family: courier new;"><pre><br /> def useful_function(handle: FileHandle): Unit = {<br /> handle.read<br /> handle.write(42)<br /> }<br /><br /> // pseudo-code to capture the idea<br /> //<br /> using(new FileHAndle("good"), useful_function)<br /></pre></blockquote><br />That's the gist of what we want to do, but we don't want all the cruft of declaring the useful function separately. Happily, Scala allows us to use function literals to write the above very economically.<br /><blockquote style="font-family: courier new;"><pre><br /> using(new FileHandle("good")) { handle =><br /> handle.read<br /> handle.write(42)<br /> }<br /> //<br /> // handle is not visible down here and<br /> // can't be abused, Yay<br /></pre></blockquote><br />For this to work, we have to refine our using method. All we have to do is change the second argument from type Unit to the function T => Unit, and make sure to call the block with the expected T resource.<br /><blockquote style="font-family: courier new;"><pre><br /> def using[T <% Disposable]<br /> (resource: T)(block: T => Unit) {<br /> try {<br /> block(resource)<br /> }<br /> finally {<br /> resource.dispose<br /> }<br /> }<br /></pre></blockquote><br />Our using function is pretty powerful now. Without any modifications, it works with closures as well as function literals. Let's alter the client code a bit to demonstrate. The following is a closure and not a function literal because i is not defined inside the curly braces demarking the code passed into using.<br /><blockquote style="font-family: courier new;"><pre><br /> def demonstrate_closure(i: Int) = {<br /> using (new FileHandle("simple")) { handle =><br /> handle.read<br /> handle.write(i)<br /> }<br /> }<br /></pre></blockquote><br />Still, there are additional things we can do in the body of our using method. For example, we could take special action if the resource passed in were null. Alternatively, we could wrap the dispose calls inside a try-catch block to prevent them from emitting exceptions.<br /><br />C++ uses compile-time overloading to choose different behaviors for some functions. For example, the new operator comes in different overloaded flavors. One takes a throwaway argument of type nothrow_t to indicate that the desired version of new will return NULL when it fails, instead of throwing an exception.<br /><br />In Scala, a tried and true way to choose different behaviors at compile time is by the import statements. For example, if you want a mutable Set in Scala, you<br /><blockquote style="font-family: courier new;"><pre><br /> import scala.collection.mutable.Set<br /></pre></blockquote><br />This inherits from the same Set trait as the immutable version, so the logic where the class is used is clean. Although the C++ nothrow_t concept is interesting, Scala's approach appears to have a better separation of concerns, and results in uncluttered code.<br /><br />If we are so inclined, we can do something analogous with our using method. We could choose to import from one package where the implementation swallows Throwables emitted by dispose. Or, we could import from another where they are allowed to propagate. In other words, we can handle exceptions quite intelligently, and customize our behavior depending on context.<br /><br />Finally, let's consider whether we can avoid needing to nest using clauses, and manage the disposal of multiple resources more elegantly. This is possible, but there's one important subtlety that we have to worry about.<br /><blockquote style="font-family: courier new;"><pre><br />def using[T <% Disposable, U <% Disposable]<br />(resource: T, _resource2: => U)(block: (T,U) => Unit) {<br /> try {<br /> val resource2 = _resource2<br /> try {<br /> block(resource, resource2)<br /> }<br /> finally {<br /> resource2.dispose<br /> }<br /> }<br /> finally {<br /> resource.dispose<br /> }<br />}<br /></pre></blockquote><br />Note that the _resource2 argument is passed by name, and not by value. We don't actually access it until declaring the val resource2 inside the outer try block. This means that if the construction of resource2 fails, we will still call dispose on the other resource.<br /><br />Let's demonstrate this. Suppose our first resource object constructs okay, but the second one throws an exception in its constructor. This is standard behavior for a RAISIN class, which disallows partially constructed instances.<br /><blockquote style="font-family: courier new;"><pre><br /> def two_resources() = {<br /> using (new FileHandle("okay"), new FileHandle("bad")) {<br /> (first, second) =><br /> second.write(first.read)<br /> }<br /> }<br /></pre></blockquote><br />If that second FileHandle constructor fires before entering the using method, then we have a resource leak! The first FileHandle is never disposed. But, because we pass the second argument by name, the second constructor does not fire before entering the using method. We're essentially passing a pointer to the constructor into the using function, who calls it.<br /><br />Why pass just the second one by name and not the first one? Did we just get lucky? No. Scala evaluates its arguments from left to right.<br /><br />A consequence of this choice is that we cannot access the _resource2 argument more than once inside the using method. Note that it's accessed exactly once when defining the val resource2. Otherwise, the constructor would be called again and again inside the using method. That would be an even worse resource leak, and would probably malfunction.<br /><br />We've now shown that our C# emulation meets all but one of our goals. This is impressive because the Scala behavior is superior even to C# itself, for example with regard to limiting the scope of variables. The remaining goal is to demonstrate how our using construct can work with legacy classes such as java.io.File that do not extend Disposable. We'll take up this cause in the near future, after a detour into some decidedly non-standard C++. But the punchline is, we had the foresight to use view bounds and not upper bounds, so we're well prepared.<br /><br />In summary, we've shown how to emulate the C# using syntax in Scala, to enable RAISIN style programming. We were remarkably successful at bullet-proofing our resource management with surprisingly few lines of code. We handling many edge cases, offered flexibility, and achieved ambitious goals. Along the way, we encountered function literals, closures, pass by name, generics, view bounds, import statements, and (presently) implicits.<br /><br />This was a lovely exercise because so many different aspects of Scala had to come together in harmony. It's clear that API designers must master these features to produce high quality code, but even casual programmers would do well to learn them.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com2tag:blogger.com,1999:blog-3257506294674819641.post-91649728054439340302009-06-17T12:01:00.007-04:002009-06-17T12:01:00.876-04:00Scala Using RAISINlast time, we touched on RAISIN, and considered Java's inability to support this programming style to be an important deficiency of the language. We also promised to explore whether Scala could emulate the C# approach to deterministic destructors. We take up that challenge presently, and we're going to find that a wide variety of Scala features all come together to make this happen.<div><br /></div><div>Implementing RAISIN is a little tougher than our Ruby "unless" modifier, where the task was pretty narrow and well understood. So before we begin, let's capture the goals we should set for emulating -- and surpassing -- the C# "using" syntax inside Scala.</div><div><ul><li>Beautiful, readable code</li><li>Obliging the user to do very little</li><li>Handling multiple resources at once</li><li>Preventing stale objects from being accessed</li><li>Prefer immutable & avoid nulls</li><li>Intelligent exception handling</li><li>Flexible enough for arbitrary resources</li></ul></div><div><span class="Apple-style-span" style="color: rgb(51, 102, 255);"><span class="Apple-style-span" style="font-style: italic;">Beautiful, readable code</span></span></div><div><br /></div><div>This is always the prime directive. Suppose we had our <span class="Apple-style-span" style="font-style: italic;">FileHandle </span>class, and we have to ge rid of its associated reource after we use it. We should tolerate nothing uglier than what we'd see in C#.<br /><blockquote style="font-family: courier new;"><pre><br /> // Scala wishful thinking<br /> //<br /> val handle = new FileHandle("myfile")<br /> using(handle) {<br /> // Either of the following methods might<br /> // throw, but that's okay.<br /> //<br /> handle.read<br /> handle.write(42)<br /> }<br /></pre></blockquote><br /><span class="Apple-style-span" style="color: rgb(51, 102, 255); "><span class="Apple-style-span" style="font-style: italic; ">Obliging the user to do very little</span></span></div><div><span class="Apple-style-span" style="color: rgb(51, 102, 255); font-style: italic;"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-style: normal; "><div><br /></div><div>We really want to avoid having to repeast all the try-finally scaffolding in the user's code, which Java would require. We also don't wan tht use to have to understand the details of how to free up the resources. Maybe something as simple as...</div><div><blockquote>import csharp._</div></blockquote></div><div>...should be sufficient to make the using syntax available to the programmer's code.<br /></div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(51, 102, 255); font-style: italic; ">Handling multiple resources at once</span><br /></div><div><div><br /></div><div>Rather than nesting one using clause inside another, it would be nice to follow C#'s practice of allowing multiple resources inside one using statement. This also aligns with th functionality afforded by C++, in which we can put multiple objects on the stack inside the same block, illustrated below.<br /><blockquote style="font-family: courier new;"><pre><br />// C++<br />{<br /> FileHandle const h1 = // details omitted<br /> FileHandle const h2 = // details omitted<br /><br /> // Use h1 and h2 freely here. Even if the<br /> // construction of h2 failed, h1 still<br /> // gets released. That's important<br /> //<br />}<br /></pre></blockquote><br /><span class="Apple-style-span" style="color: rgb(51, 102, 255); "><span class="Apple-style-span" style="font-style: italic; ">Preventing stale objecgts from being accessed</span></span></div><div><br /></div><div>This is an opportunity for our Scala solution to shine. Reconsidering our first example above, We'd like the handle to have the smallest possible scope.<br /><blockquote style="font-family: courier new;"><pre><br /> val handle = new FileHandle("myfile")<br /> using(handle) {<br /> // Either of the following methods might<br /> // throw, but that's okay.<br /> //<br /> handle.read<br /> handle.write(42)<br /> }<br /><br />// It would be nice if we could somehow make the<br />// compiler prevent spurious accesses of the handle<br />// down here. We want to deny access to disposed<br />// objects.<br /></pre></blockquote><br /><span class="Apple-style-span" style="color: rgb(51, 102, 255); "><span class="Apple-style-span" style="font-style: italic; ">Prefer immutable & avoid nulls</span></span></div><div><br /></div><div>We'd like to use val rather than var wherever we can. This is analogous to using Java final when declaring variables. We'd also like to be assured that the resource is constructed correctly, and not null.</div><div><br /></div><div>These desires may may compel us to put the initialization, meaning the resource acquisition, somehow inside the using clause where it can be managed well.</div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(51, 102, 255); "><span class="Apple-style-span" style="font-style: italic; ">Intelligent exception handling</span></span></div><div><br /></div><div>It's a well known coding practice in C++ to code destructors so that they do not emit exceptions. However, no such convention exists for common Java classes. For example, the <span class="Apple-style-span" style="font-style: italic;">java.io.File.close</span> method throws <span class="Apple-style-span" style="font-style: italic;">java.io.IOExceptio</span>n. We need a way to handle such exceptions intelligently.</div><div><br /></div><div><span class="Apple-style-span" style="color: rgb(51, 102, 255); "><span class="Apple-style-span" style="font-style: italic; ">Flexible enough for arbitrary resources</span></span></div><div><br /></div><div>In C++, any class can have a meaningful destructor, so previously designed classes can be used in the RAISIN style. In C#, we're constrained to use only classes that inherit from the <span class="Apple-style-span" style="font-style: italic;">IDisposable </span>interface, and the cleanup has to be done in the dispose method.</div><div><br /></div><div>This means that ordinary classes like <span class="Apple-style-span" style="font-style: italic;">java.io.File</span>, which has a close method instead of a dispose method, will pose some difficulties when trying to wrap it in a C#-like "using" clause. Yet, Scala is powerful, and it's a reasonable goal to overcome these limitations.</div><div><br /></div><div>Will all these goals in mind, let's not try to bite off too much at once. Last time, our zeroth cut defined a <span class="Apple-style-span" style="font-style: italic;">Disposable </span>trait and a FileHandle that extends it. This time, we'll also want a using function that accepts a <span class="Apple-style-span" style="font-style: italic;">Disposable </span>object and a block of code to be executed.<br /><blockquote style="font-family: courier new;"><pre><br />// First cut...<br />package csharp<br /><br />object Using {<br /> def using[T <% Disposable](resource: T)(block: => Unit) {<br /> try {<br /> block<br /> }<br /> finally {<br /> resource.dispose<br /> }<br /> }<br />}<br /></pre></blockquote><br />There's a lot going on in that method, so let's tease it apart carefully. First, it's a parameterized function, where the resource argument must be of type <span class="Apple-style-span" style="font-style: italic;">T</span>. The <% notation is a view bound. It means that type <span class="Apple-style-span" style="font-style: italic;">T</span> must inherit from <span class="Apple-style-span" style="font-style: italic;">Disposable</span> or be transformable into <span class="Apple-style-span" style="font-style: italic;">Disposable</span> by an implicit.</div><div><br /></div><div>(It's not obvious yet why we need view bounds, or even an upper bound. This is just a little adumbration for how we're going to achieve some of our trickier goals, such as "preventing stale objects from being accessed," and "flexible enough for arbitrary resources." We won't get there in this post, but have patience.)</div><div><br /></div><div>Second, the using method has two argument lists, rather than a single list of comma delimited arguments. Put another way, using is a curried function, as evidenced by two sets of parentheses instead of just one. This syntax allows the second argument to be a block of code in curly braces, rather than something inside using's parentheses.</div><div><br /></div><div>Third, note that the arrow notation implies that the block is passed by name, not by value. This means that the code won't actually execute until block is called inside the try clause of the using method. It does not execute before using is entered.</div></div><div><div><br /></div><div>Since our toy <span class="Apple-style-span" style="font-style: italic;">FileHandle</span> class (defined in a previous post) inherits from <span class="Apple-style-span" style="font-style: italic;">Disposable</span>, then we can write the following.</div><br /><blockquote style="font-family: courier new;"><pre><br />import csharp.Using._<br /><br />object Main {<br /><br /> def simple_usage = {<br /> val handle = new FileHandle("simple")<br /> using(handle) {<br /> handle.read<br /> handle.write(42)<br /> }<br /> }<br /><br /> // details omitted<br /></pre></blockquote><br />That's not bad for a first cut. We've achieved our first two goals, but we still have a long way to go in future posts to make progress on the others.</div><div><br /></div><div>In summary, we've taken some steps towards implementing RAISIN in Scala, taking the C# using syntax as a model. Along the way, we've seen view bounds, curried functions, and pass-by-name. The latter two language features allow the user's code to be beautiful.</div>Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-69463258588574740302009-06-10T12:01:00.004-04:002009-06-10T12:01:00.609-04:00Software Development ProcessA process is the collection of practices followed in an organization. it identifies the hats worn by people, and the artifacts they produce and consume. It names the responsibilities that the workers fulfill, and the workflows through which their artifacts pass. Also, a process likely includes at least some of the tools used, because automation is a big part of getting things done.<div><br /></div><div>Examples of software development processes include RUP (Rational Unified Process), Scrum, and Waterfall. To make a coding analogy, one might argue that a certain project instantiates a development process just as an object instantiates a class.</div><div><br /></div><div>A process not only reflects the activities of the participants, it also guides their efforts. however, keeping with the coding analogy, the humans are the virtual machine in which the process instance runs. Therefore, people are the heart of any process, and processes are always malleable. Even if a process purports to be rigid, it will not likely be followed for very long.</div><div><br /></div><div>Processes can be documented, but a process description is no more a real process than a virus is a living cell.</div><div><br /></div><div>The metaphor is apt. Practices are captured in memes. For example, champions of test driven development self identify as "test infected." Very few developers who have not actually tried TDD and seen that it changes the way code gets designed could have gleaned this effect just from reading a book.</div><div><br /></div><div>A good process will reproduce, evolve, and spread its success far and wide. But just as some organisms can't live in some environments, the ecosystem has to be receptive to the practices embraced in a process for them to take root. There are no "best practices." Context is everything.</div><div><br /></div><div>Successful processes arm decision makers with timely information, and offer guidance for resolving problems. As a corollary, the more empowered the workers are, the more freely available such information must be, because there are more decision makers shaping progress. The contrapositive also follows. Without transparency, success rests on the talents of just a few privileged individuals.</div><div><br /></div><div>Useful processes permit the measurement of and influence over:</div><div><ul><li>Quality</li><li>Costs</li><li>Progress</li><li>Growth</li></ul></div><div>By Quality, of course we mean customer satisfaction. What's not quite so obvious is that many people in the organization wear the customer hat for various artifacts and services during development.</div><div><br /></div><div>By Costs, we mean the fiduciary expenditures for salary, tools, training, hardware, and so on. (This is sometimes more difficult than it would appear, beause a single software effort could have multiple funders, each interested in different features being developed.)</div><div><br /></div><div>By Progress, we mean the maturing of the artifacts, such as code, documentation, and models, into a consumable or sellable state. Often, the careful monitoring of progress is especially important to certain stakeholders.</div><div><br /></div><div>By Growth, we mean the professional growth of the human beings who are developing goods. This includes skills improvement, job satisfaction, value to the organization, and contributions to the profession and the art.</div><div><br /></div>Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-43294595735618395812009-06-03T12:01:00.005-04:002009-06-03T12:01:00.842-04:00Hey Scala, Finalize ThisYears ago, when I moved from C++ to Java, I expected to miss a few things. My daily workhorses like templates & the STL were not available in the new environment. When it came to API design, which is really mini-language design, I could no longer rely on operator overloading. Even little efficiencies like inline functions were denied me.<br /><br />But, it turns out, I didn't really long for any of those things as much as I anticipated. What I really missed, I mean what I felt no programmer could live without, was the deterministic destructor.<br /><br />Bjarne Stroustrup champions RAISIN, Resource Acquisition IS INitialization. The idea is to represent acquired resources as class instances on the stack. So when those objects fall out of scope, a destructor fires and frees the associated resource.<br /><br />A nice advantage of RAISIN is that it doesn't matter how you leave the scope. The code could simply return, or it could emit and exception. The burden falls on the class designer to remember to free up the resources. This is vastly superior to obliging every user of the class to remember to free the resources, in every place where it's used.<br /><br />Note that we're not talking about manual memory management here. Resources include file handles and mutexes and database connections and whatnot. Acquisition occurs when the instance is initialized. Let's see an example.<br /><blockquote style="font-family: courier new;"><pre><br />//C++<br />void raisin_example(std::string name)<br />{<br /> FileHandle const handle = FileHandle(name);<br /><br /> // use handle here, maybe some code throws<br /> // an exception, but that's okay<br /> //<br />}<br /></pre></blockquote><br />All the cleanup work is done once and for all in <span style="font-style: italic;">FileHandle::~FileHandle()</span>, and that always fires when the handle object falls out of scope. The simplicity and safety of he above contrasts sharply with Java.<br /><blockquote style="font-family: courier new;"><pre><br />// Java<br />void hardly_raisin(String name)<br />{<br /> FileHandle handle = null;<br /> try<br /> {<br /> handle = new FileHandle(name);<br /><br /> // use handle here, maybe some code throws<br /> // an exception, but that's okay<br /> //<br /> }<br /> finally<br /> {<br /> if (null != handle) handle.close();<br /> }<br /></pre></blockquote><br />Wow. That's a lot of scaffolding for something that every user has to remember to get right every single time. There's a lot of opportunity for things to go wrong here. We can't even make the handle const (or final), because it would then be out of scope of the finally clause. Java even gets worse if here are several resources, and we have to release them in the reverse order of which they were acquired.<br /><br />Coming to Java required a profound shift in programming style. The lack of support for a good coding practice like RAISIN is one of the serious deficiencies of the language. I used to marvel at how much Java code I had written since leaving C+, as if hat was some kind of proof that RAISIN really wasn't so important. But now that I program in Scala, I shudder to think about how many lines of that Java code were just scaffolding.<br /><br />Java's success despite this weakness says something about how important Java's strengths are. In other words, in the marketplace, garbage collection apparently trumps RAISIN. Thinking like a scientist, it's fun to speculate about what language features are more valuable than others, using trial by market as a grand laboratory.<br /><br />The C# designers addressed this Java deficiency, after a fashion, by creating <span style="font-style: italic;">Disposable </span>objects, and a convenient language syntax for cleaning them up.<br /><blockquote style="font-family: courier new;"><pre><br />// C#<br />void raisin_example(String name)<br />{<br /> FileHandle handle = new FileHandle(name);<br /> using(handle)<br /> {<br /><br /> // use handle here, maybe some code throws<br /> // an exception, but that's okay<br /> //<br /> }<br />}<br /></pre></blockquote><br />That's not too shabby. All we have to do is oblige the <span style="font-style: italic;">FileHandle</span> class to inherit from the <span style="font-style: italic;">IDisposable</span> interface and implement a dispose method, which executes at the end of the using clause. The clean up code that the C++ programmer would have to put into a destructor goes into the <span style="font-style: italic;">dispose</span> method instead.<br /><br />Like Java, Scala also lacks deterministic destructors. However, Scala is powerful enough to emulate the C# "using" syntax. Let's make a zeroth cut at this in Scala. We'll define a <span style="font-style: italic;">Disposable</span> trait, which we'll use in subsequent posts.<br /><blockquote style="font-family: courier new;"><pre><br />// Disposable.scala<br />package csharp<br /><br />trait Disposable {<br /> def dispose(): Unit<br />}<br /></pre></blockquote><br />Finally, let's contrive a <span style="font-style: italic;">FileHandle</span> class that extends <span style="font-style: italic;">csharp.Disposable</span>. We'll use this in subsequent posts, too.<br /><blockquote style="font-family: courier new;"><pre><br />// FileHandle.scala<br />package raisin<br /><br />class FileHandle(name: String) extends csharp.Disposable {<br /><br /> // constructor acquires resource here<br /> //<br /><br /> override def dispose: Unit = {<br /> // release resource here<br /> //<br /> }<br /><br /> // Nice things you can do with a FileHandle<br /> //<br /> def read(): Int = { /* details omitted */ }<br /> def write(i: Int): Unit = { /* details omitted */ }<br />}<br /></pre></blockquote><br />Last time, we showed how the Ruby unless modifier could be implemented in Scala. Next time, we'll take some steps towards bringing RAISIN to Scala.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-52020219557053132192009-05-27T12:01:00.008-04:002009-05-27T12:01:00.202-04:00Ruby Unless ScalaNow that I'm programming primarily in Scala, I find myself missing a couple of cool tricks that Ruby offers. For example, it's neat to be able to put "unless" <a href="http://beust.com/weblog/archives/000387.html">modifiers</a> at the end of a line. Even if you've never seen Ruby (or Perl) before, it's easy to guess what the following code does.<br /><br /><span style="font-family:courier new;"></span><blockquote><span style="font-family:courier new;"># Ruby</span><br /><span style="font-family:courier new;">print total unless total.zero?</span></blockquote><br />It should be no surprise that if the <span style="font-style: italic;">total </span>is zero, then nothing happens. But if the <span style="font-style: italic;">total </span>is not zero, then it's printed.<br /><br />To my knowledge, Scala has no such concept. However, with all the power Scala offers for creating internal <a href="http://en.wikipedia.org/wiki/Domain-specific_language">DSLs</a>, it might be fun to try to emulate this syntax. This post is more about demonstrating what can be done with Scala than it is about championing the use of unless modifiers in one's code.<br /><br />My first attempt failed. I thought I would create a <span style="font-style: italic;">RichBoolean</span>, analogous to a <span style="font-style: italic;">RichInt</span>, so that I could effectively add some methods onto the <span style="font-style: italic;">Boolean </span>class. My new class needed an "unless" method, but it had to be right associative. So, borrowing the trick use in the <span style="font-style: italic;">cons </span>operator, it would have to end in a colon.<br /><blockquote style="font-family: courier new;"><pre><br />class RichBoolean(b: Boolean) {<br /> def unless_:(block: => Unit) {<br /> if (!b) block<br /> }<br />}<br /><br />implicit def booleanToRichBoolean(b: Boolean) = {<br /> new RichBoolean(b)<br />}<br /></pre></blockquote><br />There's a lot going on up there, so let's try to tease it apart and explain it. The <span style="font-style: italic;">RichBoolean </span>class is basically a wrapper around the <span style="font-style: italic;">Boolean </span>class. We've effectively added an "<span style="font-style: italic;">unless_:</span>" method to that class. The implicit function tells the compiler to convert a <span style="font-style: italic;">Boolean </span>into a <span style="font-style: italic;">RichBoolean</span> whenever it appears that someone is trying to call an "<span style="font-style: italic;">unless_:</span>" method on it.<br /><br />This is the standard Scala way to add methods to a class. Some languages are more open, and allow the addition of methods directly after the class is defined. Scala offers the same freedom, but with better control. Unless you're importing the <span style="font-style: italic;">booleanToRichBoolean </span>function, you don't get the automatic conversion. I know that some folks are nervous about implicits. But because of this control, I find them safer than open classes.<br /><br />Another noteworthy feature of the above is the arrow symbol. This implies that the block is being passed into the "<span style="font-style: italic;">unless_:</span>" method by name, and not by value. In other words, we hope that the block doesn't get evaluated before "<span style="font-style: italic;">unless_:</span>" executes, but only inside of that method when <span style="font-style: italic;">b</span> is false.<br /><br />Passing by name is a remarkably powerful language feature. To the imperative programmer, it might seem like passing by reference in C++ or Fortran, but it's actually more subtle. We're not passing the address of the result of some calculation. We're actually passing a pointer to the code that computes the result. Methods that accept pass-by-name have the option to skip the calculation entirely, when that makes sense. Consider how efficient that can make a logging API!<br /><br />Finally, Scala forces us to include the underscore in the "<span style="font-style: italic;">unless_:</span>" method name, so that there's no ambiguity about whether the colon symbol is part of the lexeme. There's an important lesson here that's more widely applicable than this example. Never end lexemes with underscores. If they happen to wind up next to a colon, they may run into trouble.<br /><br />I tried to test out this code with a little function. I could pass either true or false into it and see what happened. It compiled fine. It just didn't do what I expected.<br /><blockquote style="font-family: courier new;"><pre><br />def demonstrate_ruby_syntax(flag: Boolean) = {<br /> println("flag is " + flag) unless_: flag<br />}<br /></pre></blockquote><br />Sure enough, <span style="font-style: italic;">flag </span>gets promoted to a <span style="font-style: italic;">RichBoolean</span>, and the infix "<span style="font-style: italic;">unless_:</span>" fires. But no matter whether I pass in true or false, the <span style="font-style: italic;">println </span>always executes. This is a little surprising because we passed block by name and not by value.<br /><br />I'm at a bit of a loss to explain this. A little instrumenting showed that the block containing the <span style="font-style: italic;">println </span>statement is executing outside the "<span style="font-style: italic;">unless_:</span>" method, and not inside it.<br /><br />By way of comparison, suppose we used the cons operator (::) to construct a <span style="font-style: italic;">List[Int]</span> as follows...<br /><blockquote style="font-family: courier new;"><pre><br /> val list = 1 / 0 :: Nil<br /></pre></blockquote><br />This blows up because of the divide by zero, but the stack trace reveals that the exception occurs before getting into the cons method. However, the cons method scaladocs say that the argument is passed by value, not by name, so we'd expect exactly that here.<br /><br />So, unable to make my <span style="font-style: italic;">RichBoolean </span>idea work, I next tried to put a wrapper class around the block itself. This had the advantage of letting me get rid of the colon cruft on the unless method name. I also don't think it's any more dangerous, despite the implicit, because the <span style="font-style: italic;">unless </span>method signature admits only a <span style="font-style: italic;">Boolean</span>.<br /><blockquote style="font-family: courier new;"><pre><br />package ruby<br /><br />object Unless {<br /><br /> class UnlessClass(block: => Unit) {<br /> def unless(b: Boolean) = {<br /> if (!b) block<br /> }<br /> }<br /><br /> implicit def<br /> unitToUnlessClass(block: => Unit): UnlessClass = {<br /> new UnlessClass(block)<br /> }<br />}<br /></pre></blockquote><br />Happily, this approach worked. It also demonstrates a neat fact. The implicit function accepts block by name, and the <span style="font-style: italic;">UnlessClass </span>constructor does too. Yet, block doesn't execute until the unless method is called with a false argument. This means that the Scala compiler is smart enough to let the by-name cascade through (at least) two calls.<br /><br />All I have to do now is...<br /><blockquote style="font-family: courier new;"><pre><br />import ruby.Unless._<br /><br />// details omitted...<br /><br /> def demonstrate_ruby_syntax(flag: Boolean) = {<br /> println("flag is " + flag) unless flag<br /> }<br /></pre></blockquote><br />... and my Ruby-esque unless modifier syntax works as expected. The printing only occurs when the flag is false.<br /><br />There's one more enhancement we can consider. Our code only compiled because <span style="font-style: italic;">println </span>returns <span style="font-style: italic;">Unit</span>. But what if we had some other routine that returned some other type? In such a case, we're relying on the side effects, and not the computational result of the function. This is an imperative rather than functional style, but since Scala lives in both worlds, it would still be nice to be able to use the unless modifier syntax. Consider the following contrived example.<br /><blockquote style="font-family: courier new;"><pre><br />def myfunc(flag: Boolean): Int = {<br /> println("myfunc flag is " + flag)<br /> 42<br />}<br /></pre></blockquote><br />Happily, generics can come to our rescue. By parameterizing our <span style="font-style: italic;">UnlessClass</span>, we can implicitly convert to it from arbitrary types.<br /><blockquote style="font-family: courier new;"><pre><br />class UnlessClass[T](block: => T) {<br /> def unless(b: Boolean): Unit = {<br /> if (!b) block<br /> }<br />}<br /><br />implicit def<br />toUnlessClass[T](block: => T): UnlessClass[T] = {<br /> new UnlessClass[T](block)<br />}<br /></pre></blockquote><br />Note that our new unless method still returns <span style="font-style: italic;">Unit </span>because we only use this construct where the return value of methods like <span style="font-style: italic;">myfunc </span>are deliberately discarded.<br /><blockquote style="font-family: courier new;"><pre><br /> def demonstrate_ruby_syntax(flag: Boolean) = {<br /> myfunc(flag) unless flag<br /> }<br /></pre></blockquote><br />In summary, by emulating the Ruby unless modifier, we've demonstrated a few of the Scala language features that allow rich DSLs to be created. Along the way we learned about right associativity, implicits, passing by name, and generics.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-37944604271357077322009-05-20T12:01:00.003-04:002009-05-20T12:01:00.842-04:00Overriding Scala def With valLast time, we created a little toy class hierarchy to demonstrate Scala injection. We also illustrated how Scala's powerful type system can keep us out of trouble. This time, we're going to explore some design tradeoffs that emerge from choosing Scala <span style="font-style: italic;">def </span>or Scala <span style="font-style: italic;">val</span>.<br /><br />To review, we created an abstract base class that stores masses, and always reports their values in kilograms. We extended that with immutable classes that are initialized with values in various units.<br /><blockquote style="font-family: courier new;"><pre><br />abstract class Mass {<br /> def kilograms: double<br />}<br /><br />class Kilograms(kg: Double) extends Mass {<br /> def kilograms = kg<br />}<br /><br />class Grams(grams: Double) extends Mass {<br /> def kilograms = grams / 1000.0<br />}<br /></pre></blockquote><br />Suppose that the calculation to convert grams into kilograms was difficult and lengthy. Then the <span style="font-style: italic;">Grams </span>implementation of the <span style="font-style: italic;">kilograms </span>method might get us into trouble, because we'd be repeating that work needlessly every time it was called.<br /><blockquote style="font-family: courier new;"><pre><br />class Grams(grams: Double) extends Mass {<br /> def kilograms: Double = {<br /> Thread.sleep(5000) // pretend to think hard<br /> grams / 1000.0<br /> }<br />}<br /></pre></blockquote><br />The above class constructs instantly, but every time somebody calls the <span style="font-style: italic;">kilograms </span>method on an instance, it takes a long time. This is sad because <span style="font-style: italic;">Grams </span>is immutable. We'd like some way to save the output of the calculation instead of the input.<br /><br />Let's use the <span style="font-style: italic;">javap</span> tool to peer into what Scala is doing under the hood. The constructor argument grams is called a class parameter in Scala-ese. Class parameters used outside of constructors, as <span style="font-style: italic;">grams </span>is used in the <span style="font-style: italic;">kilograms </span>method, become full fledged private fields of the class. Consider the following (edited) snippet.<br /><blockquote style="font-family: courier new;"><pre><br />$ javap -private Grams<br />Compiled from "Grams.scala"<br />public class Grams extends Mass<br /> private final double grams;<br /> public Grams(double);<br /> public double kilograms();<br /></pre></blockquote><br />Amazingly, Scala allows us to override the abstract "<span style="font-style: italic;">def kilograms</span>" in mass with a "<span style="font-style: italic;">val kilograms</span>" in <span style="font-style: italic;">Grams</span>. This is a lovely language feature, but it's worth spending a little energy to understand what's going on under the hood.<br /><br />Let's change our kilograms <span style="font-style: italic;">def</span> into a <span style="font-style: italic;">val</span> in our derived classes. The following class is slow to construct, but each call to <span style="font-style: italic;">kilograms</span> completes instantly.<br /><blockquote style="font-family: courier new;"><pre><br />class Grams(grams: Double) extends Mass {<br /> val kilograms: double = {<br /> Thread.sleep(5000) // pretend to think hard<br /> grams / 1000.0<br /> }<br />}<br /></pre></blockquote><br />Take a moment to digest the tradeoff. The first version is small in memory, containing only one double field, the <span style="font-style: italic;">grams </span>class parameter. It constructs quickly, but each call to <span style="font-style: italic;">kilograms </span>takes a long time. The second version constructs slowly, but all calls to <span style="font-style: italic;">kilograms </span>are quick. We would prefer the first design if we expect the users of the class to call <span style="font-style: italic;">kilograms </span>no more than once, and the second design if we expect the users to call <span style="font-style: italic;">kilograms </span>multiple times on each <span style="font-style: italic;">Grams</span> instance.<br /><br />In the second design, the grams class parameter appears to be used nowhere but in the constructor itself when the "<span style="font-style: italic;">val kilograms</span>" is defined. So, one might expect that it will not become a real field in the <span style="font-style: italic;">Grams </span>class. Trusty <span style="font-style: italic;">javap</span> confirms this suspicion. Consider the following (again edited) snippet.<br /><blockquote style="font-family: courier new;"><pre><br />$ javap -private Grams<br />Compiled from "Grams.scala"<br />public class Grams extends Mass<br /> private final double kilograms;<br /> public Grams(double);<br /> public double kilograms();<br /></pre></blockquote><br />Note that under the hood, despite being declared a <span style="font-style: italic;">val </span>in the Scala source code, <span style="font-style: italic;">kilograms </span>is also a method. A moment's reflection(no pun intended) will tell us that it has to be a method. <span style="font-style: italic;"> Grams </span>is a concrete class that extends an abstract class with a pure virtual <span style="font-style: italic;">kilograms </span>method. So even thought the Scala source hides it, <span style="font-style: italic;">kilograms </span>is still a method of <span style="font-style: italic;">Grams</span>.<br /><br />What is that public <span style="font-style: italic;">kilograms </span>method up to? Again we appeal to <span style="font-style: italic;">javap</span>, and learn that it's doing nothing except returning the double stored in the private <span style="font-style: italic;">kilograms </span>field. Just as we might have expected.<br /><blockquote style="font-family: courier new;"><pre><br />public double kilograms();<br /> Code:<br /> Stack=2, Locals=1, Args_size=1<br /> 0: aload_0<br /> 1: getfield #30; // Field kilograms:D<br /> 4: dreturn<br /></pre></blockquote><br />The above is much shorter than the previous version, which performed the expensive calculation. Again, we conclude that the criteria to prefer one design over the other rests on the expected usage patterns of our class, as explored above.<br /><br />We should also ask ourselves whether it's possible to delay the expensive calculation, possibly indefinitely, in case it's never needed. This third design would represent the classic programming tradeoff between space and time, and we'll take it up in a later post.<br /><br />In summary, we've seen that it's possible to override a Scala <span style="font-style: italic;">def </span>with a Scala <span style="font-style: italic;">val</span>. Under the hood, the override is still implemented by a method. The <span style="font-style: italic;">javap</span> tool is very useful to help us figure out what's going on, and one would do well to understand the design tradeoffs of each approach. Scala's marriage of object oriented programming with functional programming is made in heaven. We can use inheritance and exploit immutability, enjoying the flexibility to make considered design choices.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com1tag:blogger.com,1999:blog-3257506294674819641.post-38854981581925279222009-05-13T12:01:00.003-04:002009-05-13T12:01:01.318-04:00Sweet Scala InjectionBefore getting back to non-final finals, let's consider a fun diversion. The second most famous equation in Physics is Newton's second law of motion, F = ma. When you apply a force F to an object of mass m, it accelerates at rate a.<br /><br />Of course, your arithmetic only gives you the right answer if you're consistent in the measurement system you pick. There are two major systems of units in use. One is the metric system or SI (System International), formerly called the mks system. The letters stand for meter, kilogram, and second, which are the principal units used to measure length, mass, and time.<br /><br />The other main system in use is also the metric system. (Gotcha.) It's called the cgs system, whose letters stand for centimeter, gram, and second. You have to take care to keep your units straight to use formulas like F = ma. The units for force are named newtons in the mks system and dynes in the cgs system. But if you multiply a gram times an acceleration recorded in meters per second per second, you'll get neither a newton nor a dyne.<br /><br />The recent loss of the <a href="http://mars.jpl.nasa.gov/msp98/news/mco990930.html">Mars Polar Lander</a> is a painful demonstration that units really matter.<br /><br />Since I like to blog about how thinking like a scientist makes me a better coder, I'll mention that it's unnatural to think, "oh, this book weighs two." Such a sentence might be grammatically correct, but without specifying the units, it's meaningless.<br /><br />Scala has an especially thoughtful type system, and we can press it into service to keep our units straight when we do calculations. In this (and the next) post, we'll create a toy program, in illustrate one or two Scala goodies.<br /><br />Kilograms and grams both measure mass. It's not too much of a stretch to use the "is-a" relationship in an object oriented language to capture this notion. In what follows, <font style="font-style: italic;">Kilograms </font>and <font style="font-style: italic;">Grams </font>inherit from <font style="font-style: italic;">Mass</font>.<br /><blockquote style="font-family: courier new;"><pre><br />absract class Mass {<br /> def kilograms: Double<br />}<br /><br />class Kilograms(kg: Double) extends Mass {<br /> def kilograms = kg<br />}<br /><br />class Grams(grams: Double) extends Mass {<br /> def kilograms = grams / 1000.0<br />}<br /></pre></blockquote><br />Our base class has a kilograms method that returns the amount of mass in the mks units. All our calculations will be done in mks units, but the programmer is free to initialize a mass variable with either kilograms or grams.<br /><br />Now let's construct a <font style="font-style: italic;">Force</font> class. In a full-fledged example, we'd probably make it an abstract class extended by Newtons and Dynes. But we don't need such a complete solution here to demonstrate the ideas. Give the class an <font style="font-style: italic;">accelerates </font>method, which tells how much the given force in newtons will accelerate a specified mass.<br /><blockquote style="font-family: courier new;"><pre><br />class Force(newtons: double) {<br /> def accelerates(mass: Mass) =<br /> (newtons / mass.kilograms) + " meters per sec^2"<br />}<br /></pre></blockquote><br />Note that the <font style="font-style: italic;">accelerates </font>method doesn't care whether it's passed a value in kilograms or in grams. All it's demanding is a mass, and since that offers a method to take us into mks-land, we can assuredly report our acceleration in meters per second per second.<br /><br />Now, let's define a force of half a newton, and run a little program to see how much this force will accelerate a couple of masses. In each case below, there's no ambiguity about whether each mass is expressed in kilograms or grams, because the units are explicitly specified.<br /><blockquote style="font-family: courier new;"><pre><br />object MyApp extends Application {<br /> val force = new Force(0.5)<br /> println(force accelerates (new Kilograms(4.0)))<br /> println(force accelerates (new Grams(100)))<br /> //<br /> // "0.125 meters per sec^2"<br /> // "5.0 meters per sec^2"<br />}<br /></pre></blockquote><br />The parentheses around the "new Kilograms(4.0)" are actually redundant, but that might surprise a Java programmer. Scala also lets us omit the dot between force and accelerates, which arguably improves readability.<br /><br />So, the above works, but specifying "new Kilograms" everywhere I need to define a mass is a hassle. More importantly, it hurts readability, because there is no "new" anywhere in my mental model of the F = ma equation.<br /><br />Fortunately, Scala offers <font style="font-weight: bold;">injections</font>, which can pretty up the source code. In C++, I can construct an instance on the stack without calling new. Although all instances in Scala live on the heap, I find the syntax reminiscent of C++ constructors.<br /><br />We want to be able to write "Kilograms(4.0)" instead of "new Kilograms(4.0)" when we use our concrete Mass classes. To do this, create a Scala companion object of the same name as the class, and give it an <font style="font-style: italic;">apply</font> method.<br /><blockquote style="font-family: courier new;"><pre><br />object Kilograms {<br /> def apply(kg: Double) = new Kilograms(kg)<br />}<br /><br />object Grams {<br /> def apply(grams: Double) = new Grams(grams)<br />}<br /></pre></blockquote><br />These functions are called injections. Basically, they are factory methods on the companion objects, but we don't need to call apply explicitly. This is the same syntactic sugar that allows us to write "List(1, 2, 3)" instead of "new List(1, 2, 3)". It pretties up our code nicely.<br /><blockquote style="font-family: courier new;"><pre><br /> println(force accelerates Kilograms(4.0))<br /> println(force accelerates Grams(100))<br /></pre></blockquote><br />Note that we have made a tradeoff for this sweetness. We had to write more code (the injections) when defining our classes, so we could make life easier on the users of the classes. However, this is almost always the way to go. Readability is important.<br /><br />Readability is also the reason that the accelerates method takes a Mass instance and not a plain Double. The extra word "Kilograms" or "Grams" doesn't help the computer, but it does help the human.<br /><br />(However, the astute reader will have noticed that the kilograms method of the <font style="font-style: italic;">Grams </font>class is inefficient. It performs a double precision floating point calculation every time it is called, even though the instance itself is immutable. If only there were a way to save the result of the calculation instead of the inputs, then we could run faster without worsening our memory footprint. Contemplating this is a topic for another day.)<br /><br />In conclusion, tastefully applied Scala injections enhance readability. And they're more digestible than Martian soil coming towards you at a rate of, uhm, really fast.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-41779502784627246952009-05-06T21:30:00.004-04:002009-05-10T07:53:52.559-04:00And That's Final, Not!This post is about C++ and Java, but it really offers some necessary background material to explore an interesting issue facing Scala. What follows is hopefully widely known by C++ and Java veterans, but it's still worth reviewing here so that we're all on the same page when we talk about Scala in the near future.<br /><br />C++ fans are often encouraged not to use <i>#define</i>s for their constants, in part because the preprocessor has no notion of types. For example, <a href="http://en.wikipedia.org/wiki/Scott_Meyers">Scott Meyers</a> champions this idea. Instead of writing...<br /><blockquote style="font-family: courier new;"><pre>#define PI 3.14159</pre></blockquote><br />...which performs a simple textual substitution everywhere in the source file, the following is usually preferred:<br /><blockquote style="font-family: courier new;"><pre>const double PI = 3.14159;</pre></blockquote><br />The latter alternative helps the compiler supply more meaningful error messages. If the preprocessor were used instead, then the compiler has never heard of the lexeme "PI", and can't include it in any error messages.<br /><br />We don't have a preprocessor in Java. We also lack a usable const keyword. Instead we use <i>final</i> to describe variables whose values will not change. Unfortunately, just as <i>static</i> has multiple meanings in C++, <i>final</i> has multiple meanings in Java.<br /><br />In C++, methods are non-virtual by default, and must be given a special keyword, <i>virtual</i>, to denote that they are polymorphic. The Java philosophy is different. In Java, methods are virtual by default, and must be given a special keyword, <i>final</i>, to denote that they can not be overridden. So this keyword pulls double duty in Java: for methods <i>final</i> means non-virtual, and for fields it implies constant.<br /><br />Another difference with C++ is that we don't have standalone variables in Java. We put them inside a class as below. In order to explore the issue at the heart of this blog entry, we deliberately do not make the field below <i>static</i>.<br /><blockquote style="font-family: courier new;"><pre><br />public class MyClass extends YourClass<br />{<br /> public final double PI = 3.14159;<br /> //<br /> //... details omitted<br />}<br /></pre></blockquote><br />A nearly equivalent way to define PI would be in a constructor. It's noteworthy that the final fields of a class can only be defined where they are declared, or in a constructor. A "set" method to change a final field would not compile.<br /><blockquote style="font-family: courier new;"><pre><br />public class MyClass extends YourClass{<br /> public final double PI;public MyClass()<br /> {<br /> PI = 3.14159;<br /> }<br /> //<br /> //... details omitted<br />}</pre></blockquote><br />At first glance, the two ways of defining the final PI in Java appear equivalent. But they are not. In fact, they are different in a crucial way that we'll explore in a subsequent post. Programmers that don't understand when final doesn't really mean final risk writing programs with undesired behavior.<br /><br /><h4>In case you're on an interview...</h4><br />A standard interview question is to ask a candidate to contrast inheritance in C++ and Java. The expected answer includes something like, "Well, C++ has multiple inheritance and Java doesn't."<br /><br />But there's another difference, and folks who make the following observation display a valuable insight into the differences between the languages. "Well, I can truly call a virtual function from a Java constructor, but I can only appear to call a virtual function from a C++ constructor."<br /><br />Let's digest this statement. If I try to call a virtual function in a C++ base class, I'm only going to get the base class's version, not the derived class's version. In other words, it's forbidden for a base class constructor to peer down into the code of a class that inherits from it.<br /><blockquote style="font-family: courier new;"><pre><br />// C++<br />class Base<br />{<br />public:<br /> virtual void f();<br /> Base();<br />};<br />void Base::f() { cout << "Base" << endl; }</pre></blockquote><br />The rules of C++ deny the implementation <i>Derived::f</i> from being executed within <i>Base::Base</i>. In other words, <i>f</i> does not behave as a virtual function when called within a constructor.<br /><br /><h4>But in Java...</h4><br />Such behavior contrasts sharply with Java. In Java, the derived class's implementation does get executed. Consider the ostensibly equivalent program below.<br /><blockquote style="font-family: courier new;"><pre><br />// Java<br />public class Base<br />{<br /> public void f() { System.out.println("Base"); }<br /> public Base() { f(); }<br />}<br /><br />public class Derived extends Base<br />{<br /> @Override public void f()<br /> {<br /> System.out.println("Derived");<br /> }<br />}<br /><br />public static void main(String[] args)<br />{<br /> new Derived();<br /> //<br /> // "Derived" gets printed, not "Base"<br />}</pre></blockquote><br />Java's approach might seem to be an advantage, but it comes with a hefty price. If the <i>Derived</i> class has a constructor, it fires after the base class constructor. That means that the <i>f</i> method of the derived class executes before the derived class constructor.<br /><br />Reread that and let it sink in. It implies that if the derived class constructor has any initializations to perform or invariants to enforce before <i>Derived::f</i> fires, then we're in trouble. Let's demonstrate this with an example.<br /><blockquote style="font-family: courier new;"><pre><br />public abstract class Abstract<br />{<br /> public Abstract() { showPi(); }<br /> public abstract void showPi();<br />}<br /><br />public class Concrete extends Abstract<br />{<br /> final double PI;<br /> public Concrete() { this.PI = 3.14159; }<br /> @Override public void showPi()<br /> {<br /> System.out.println(PI);<br /> }<br />}<br /><br />public class Main<br />{<br /> public static main(String[] args)<br /> {<br /> new Concrete();<br /> //<br /> // "0.0" gets printed, not "3.14159"<br /> }<br />}</pre></blockquote><br />How can this be? It's as if the <i>final</i> PI value has changed. In fact, that's exactly what has happened. When a new Java object is allocated from the heap, all its fields are zeroed out. So when the constructor of <i>Abstract</i> fires, the memory location where PI lives contains zero. Later on, when the constructor for <i>Concrete</i> fires, that memory location is overwritten by 3.14159. Any subsequent attempts to call <i>showPi</i> will print "3.14159".<br /><br />How serious is this problem in Java? I argue that it's not too serious, as long as developers are trained in this behavior, and they know what to expect. The greater dangers come from language quirks that surprise the coder, or from the clever coder who tries to exploit the poorly lit street corners of the language.<br /><br />There are a few reasons why this problem is not too awful. First, the behavior is still deterministic. The fields of the object are all zeroed out when it's allocated from the heap, so there is no surprising cruft left in those memory addresses. No matter how many times I run my program above, I'm always going to print "0.0" and not some random bits.<br /><br />Second, it's prudent for constructors only to call methods that are themselves final (meaning non-virtual). This is a common coding convention, and embracing it leads to code that's easier to understand and maintain. Tools like the <a href="http://fb-contrib.sourceforge.net/">fb-contrib</a> plugin for <a href="http://findbugs.sourceforge.net/">Findbugs</a> can enforce this convention.<br /><br />Finally, classes that extend base classes know what their superclass is. It's a bit difficult to sneak dodgy behavior into a base class without being seen by the designer of the derived class, particularly when your tools will detect it. Consider that the source code of the child class itself will specify the particular base class it extends.<br /><br />How serious these non-final finals are in Scala, however, may be another matter. We'll investigate this in the near future.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-52535316602910527492009-04-29T14:31:00.011-04:002009-05-01T08:06:10.633-04:00Scala Dependency InjectionFirst in a series... This post flows from my attempts to understand and apply the lessons from the "Modular Programming Using Objects" chapter of the <span style="font-style: italic;">Programming in Scala</span> book by Odersky, Spoon, and Venners. As much as I love that book, I felt that the chapter was a bit too terse for my poor brain, and there's a lot of exploration possible for the ideas found there. In other words, maybe all this is obvious to everybody but me, but here goes...<br /><br />I'm a <a href="http://docs.codehaus.org/display/PICO/Constructor+Injection">constructor injection</a> chauvinist. I don't hate setter injection, but I avoid it if I'm able. I do appreciate that how one does <a href="http://www.martinfowler.com/articles/injection.html">inversion of control</a> is somewhat a matter of taste. But a couple of defenses of my preference come to mind.<br /><br />First, I like my finals. In Java, member fields assigned in a constructor can be final, and that prevents me from accidentally changing things I shouldn't change. <a href="http://en.wikipedia.org/wiki/Poka-yoke">Poka-yoke</a> has saved many a developer many a time. I think it was noted software developer <a href="http://www.imdb.com/title/tt0070355/quotes">Harry Callahan</a>, who advised us to know our limitations. On second thought, I think he might have been speaking in a different context, but I'm well aware of the kinds of programming mistakes I'm prone to make.<br /><br />Second, a once-used <span style="font-style: italic;">set</span> method looks like dangling cruft. It's usually public so as to be callable by frameworks, so it lessens the signal to noise ratio of the class's source code. How? Well, the users of the class must be educated not to call the special set method. I'm troubled by a method with a standard name that suggests a particular usage, but then behaves unpredictably if that usage is attempted.<br /><br />Additionally, the instantiators of the class must be educated to call the special set method, and not to use the class before doing so. It's never a good idea to surprise the coder, and constructors that don't finish constructing will enable partially built objects to exist. Maybe this is just a violation of Poka-yoke again.<br /><br />In Scala, instead of finals, we have vals. And in addition to dependency injection frameworks like Guice or Spring, we have a lovely way within the language to assemble object graphs. It could well be argued that such frameworks are merely clunky compensators for weaknesses in the Java language itself, such as the lack of mixins.<br /><br />Imagine an <span style="font-style: italic;">AutoPilot</span> object that needs to ask questions of a <span style="font-style: italic;">FuelSensor</span> object. The fuel sensor has a <span style="font-style: italic;">remaining_liters</span> method that the auto pilot might need to call from time to time. So our object graph comprises an auto pilot object with a pointer to a fuel sensor. This graph has to be instantiated when the program starts.<br /><br /><blockquote style="font-family: courier new;"><pre><br />class FuelSensor {<br /> def remaining_liters: Int = { //blah blah<br /><br />class AutoPilot(<br /> private[this] val fuel_sensor: FuelSensor) {<br /> // blah blah<br /></pre></blockquote><br /><br />A typical Scala approach to dependency injection will encapsulate the initialization of the object graph inside a trait that can be "with"ed into the application.<br /><br /><blockquote style="font-family: courier new;"><pre><br />trait ProductionEnvironment {<br /> val the_fuel_sensor = new FuelSensor()<br /> val the_auto_pilot = new AutoPilot(the_fuel_sensor)<br />}<br /><br />object MyApp extends Application<br /> with ProductionEnvironment { // blah blah<br /></pre></blockquote><br /><br />Of course, one can initialize Scala object graphs using Spring XML files or Guice annotations, but the trait approach has a nice advantage: if you make a spelling mistake, it's a compilation error, not a runtime problem. Eventually, we're going to see that it enjoys other niceties, too.<br /><br />In real life, I'll have many environments. For example, when I want to unit test my auto pilot class, I might do something like the following.<br /><br /><blockquote style="font-family: courier new;"><pre><br />trait AutoPilotTestEnvironment {<br /> val the_fuel_sensor = new FuelSensor {<br /> override def remaining_liters: Int = {<br /> // mock implementation here<br /> }<br /> }<br /> val the_auto_pilot = new AutoPilot(the_fuel_Sensor)<br />}<br /></pre></blockquote><br /><br />In the above example, I'm free to use TestNG or ScalaTest if I prefer. Moreover, I can opt for a separate <span style="font-style: italic;">MockFuelSensor</span> class instead of an anonymous one inside the trait. Don't let such details be distracting. The real point is that instead of being in XML-heck with Spring, I can create specific environment traits to assemble meaningful object graphs. And the compiler helps me.<br /><br />There's a second concrete advantage of the Scala "in-language" approach to dependency injection (DI). I can use Object Oriented (OO) principles -- that is, the separation of the general from the specific -- to organize different configurations thoughtfully.<br /><br />Suppose for example, that there were two flavors of fuel sensors. Let's emend our code example a bit. A couple of concrete fuel sensor implementations would inherit from the abstract fuel sensor type.<br /><br /><blockquote style="font-family: courier new;"><pre><br />abstract class FuelSensor {<br /> def remaining_liters: Int<br /> // blah blah<br /><br />class JetFuelSensor extends FuelSensor {<br /> def remaining_liters: Int = { // blah blah<br /><br />class PropellorFuelSensor extends FuelSensor {<br /> def remaining_liters: Int = { // blah blah<br /></pre></blockquote><br /><br />The beauty here is that I can create mixins to mirror the inheritance heirachy of the objects being initialized. Our production environment trait becomes abstract, leaving configuration-specific mixins to handle the varying construction details.<br /><br /><blockquote style="font-family: courier new;"><pre><br />trait ProductionEnvironment {<br /> val the_fuel_sensor: FuelSensor<br /> val the_auto_pilot = new AutoPilot(the_fuel_sensor)<br />}<br /><br />trait JetFuelEnvironment {<br /> val the_fuel_sensor = new JetFuelSensor<br />}<br /><br />trait PropellorFuelEnvironment {<br /> val the_fuel_sensor = new PropellorFuelSensor<br />}<br /><br />object JetApplication extends Application<br /> with JetFuelEnvironment<br /> with ProductionEnvironment { // blah blah<br /></pre></blockquote><br /><br />This feels right. Knowledge about how to construct concrete objects can be collocated with their class definitions, if so desired. I can (no pun intended) mix and match my mixin environments to assemble the exact configuration I want for a given application. Spelling errors are detected early (at compile time).<br /><br />Now for sure, I could do much of this in Spring by including XML fragments inside master configuration files, but I think it's much nicer on the human to use genuine, language-supported OO features. IDE (Interactive Development Environment) support is natural, and that's a big win here.<br /><br />Stay tuned for more thoughts about Scala dependency injection, and for more refinements of our example. We still have to deal with a handful of "real world" considerations as we transform our toy system into an industrial strength solution. The goal of this post was just to throw up a straw man, whom we can clothe in armor as we go along.<br /><br />In summary, Scala's support for mixins offers a nice, in-language way to initialize object graphs. Though perfectly compatible with dependency injection frameworks, Scala offers an approach that enjoys a couple of advantages. First, because configurations are code, certain errors are detected early. Second, configuration details can be partitioned meaningfully in traits, and then assembled in a more user-friendly fashion than XML files or annotations.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-78226677029157650122008-12-26T21:35:00.005-05:002008-12-26T22:01:12.739-05:00Software Velocity as a Physical Observable<span style="color: rgb(51, 102, 255);">The Math Professor</span><br /><br />I had a Mathematics professor who once said, “You’ve been using numbers for quite a while, so it’s about time you learned what they really are.” This was in an analysis class where we were learning about real numbers. There are a couple of ways to define real numbers: an axiomatic approach and a construction-based approach. In the former, you write down the fourteen or fifteen properties of real numbers and presume that a set containing such elements exists. In the latter, you build real numbers out of rational numbers.<br /><br />It’s almost true that real numbers are merely sequences of rational numbers. It’s well known that <span style="font-style: italic;">pi</span> or the square root of two are not rational, but there are sequences of rational numbers that converge to these real numbers. However, the sequences are not unique. There are lots and lots of sequences whose limit is <span style="font-style: italic;">pi</span>.<br /><br />For example, just take any sequence that converges to <span style="font-style: italic;">pi</span> and prepend any integer to the beginning of it. Since you have an infinite number of integers to choose from, you have at least an infinite number of sequences that all converge to the same real number. If that strikes you as too much of a cheat, consider that different algorithms exist for approximating <span style="font-style: italic;">pi</span>. Some converge faster than others, but if you could run them forever, they’d all produce <span style="font-style: italic;">pi</span>.<br /><br />So, an individual sequence doesn’t correspond to a real number, but the set of all sequences with the same limit does. In other words, real numbers are equivalence classes of sequences of rationals. On the one hand, we could have a totally abstract definition of real numbers, based on axioms. (Multiplicative commutativity, the distributive law, and so on.) But on the other hand we could have a more pragmatic definition rooted in equivalence classes of simpler, more mundane objects.<br /><br />There’s something magical about equivalence classes. Consider again that two different algorithms can generate sequences of digits that both converge to <span style="font-style: italic;">pi</span>. If you’ll pardon the pun, <span style="font-style: italic;">pi</span> must be, well, real, if you can arrive at it in different ways. Equivalence classes of concrete things agree with the abstract real number concept, which is otherwise described by axioms alone.<br /><br /><span style="color: rgb(51, 51, 255);">The Physics Professor</span><br /><br />I had a Physics professor who advanced a compelling definition of mass. “Mass,” he said, “is that property of a substance that makes the law of conservation of momentum true.” We all found this delightful. It was a rigorous step up from the circular pseudo-definitions we had seen before. (Mass is quantity of matter. What is matter? Matter is anything that occupies space and has mass. What then is mass, again? Ugh.)<br /><br />As curious Physics majors, the professor’s axiomatic approach to mass appealed to our inner Euclid. First, demand that the something like the law of conservation of momentum works, and then see what follows from that. But, in time, I came to feel that it was dangerously abstract. Sure there’s this elegant concept, but why should the real universe obey it? Yes, it was the apparent utility of mass and momentum that made them worth studying, but were we doing Physics (where we’re never sure that we’re right) or doing Mathematics (where we’re right but we don’t know what we’re talking about).<br /><br />Anyway, there are a number of operational definitions of mass. By “operational,” we mean measurements that rely directly on experiments, even if those experiments are only <a href="http://en.wikipedia.org/wiki/Thought_experiment">gedankens</a>. For example, if you pull on an isolated body with a rubber band stretched to a fixed length, then the object’s mass can be operationally defined as the reciprocal of the resulting acceleration.<br /><br />Other operational definitions are possible. Imagine tying a body to a test mass and spinning them about each other in zero-g. The location of the axis on the rope can be used to measure the ratio of the two masses. You could also imagine a mass-measurer made out of an asymmetrical tilt-a-whirl, where the units surprisingly turn out to be seconds-squared.<br /><br />You could repeat many experiments, and the results would -- if you’ll pardon the term -- converge on the true mass as operationally defined. Moreover, different methods of measurement will agree. The different operational definitions produce consistent measures. You know where I'm going with this. I'm about to suggest that they form an informal equivalence class.<br /><br />The abstract definition of mass is real, and it’s complemented by the equivalence class of all operational definitions of mass. This same line of reasoning sheds insight into other physical observables, such as charge, temperature, and so on. I’m struck by the analogy to the two complementary ways to define real numbers. Equivalence classes of operational definitions marry real world phenomena to abstract models, where we can flex our mathematical muscles and do interesting work.<br /><br /><span style="color: rgb(51, 102, 255);">Software Velocity</span><br /><br />When tracking progress on a <a href="http://alistair.cockburn.us/Earned-value+and+burn+charts">burn-up chart</a>, agilists concede that the units of velocity are not important. They could be person-days, story-points, or whatever. Nevertheless, the velocity concept has meaning. I imagine that each team is like its own custom experimental apparatus, providing its own operational definition of velocity.<br /><br />But is software velocity real? Yes. It’s an abstract concept whose complement is the equivalence class of all operational definitions of software velocity. The difference between physical mass and software velocity is that the experimental equipment needed to operationally define physical mass is very simple, at least in principle. But the analogous equipment for a software development project lives in the deep structures of the developers’ brains, drawing upon whatever arcane magic causes them to choose which <a href="http://www.agile-software-development.com/2007/12/whats-point-in-estimating.html">Fibonacci</a> number corresponds to the heft of any given feature.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-60576401821985258502008-09-20T12:00:00.000-04:002008-09-20T12:04:16.984-04:00Normative Theorems, Narrative PrinciplesWe need a better word than "spec" to name the documents we write. A specification well-describes things that are specifiable, such as a language grammar or a communication protocol or a reusable library. So, if you need to write an <a href="http://en.wikipedia.org/wiki/Ada_%28programming_language%29">Ada</a> compiler, or implement an HTTP client, or use the <a href="http://en.wikipedia.org/wiki/Standard_Template_Library">STL</a>, then the specs for these sorts of things are probably sufficient for you to get your work done.<br /><br />But, that's because you already knew a thing or two about compilers, or <a href="http://en.wikipedia.org/wiki/Inter-process_communication">IPC</a>, or generic programming. If that's the kind of thing that you do in your day job, then I'm happy for you, and a little jealous. A lot of software has to do with modeling poorly understood domains, where there is little agreed-upon common vocabulary or precedent. Some days I get confused about exactly what my job is, because I've strayed into something quite new.<br /><br />If that describes you too, then a normative-only spec doesn't reveal the gist of the problem to be solved. Many of the so-called specs that we write concern "wicked" problems, that is, problems that are so intractable that they can only be stated by solving them. I've often seen requirements documents go on for pages and pages with the guise of rigor, but which fail to convey enough context for why their enumerated and cross-referenced <a href="http://en.wikipedia.org/wiki/Requirement#Documenting_requirements"><span style="font-style: italic;">shall</span></a>s are good ideas.<br /><br />During the actual process of composing such a document, a good writer will actually discover and answer these "why" questions. Options are weighed and decisions are made. But if the reasoning isn't recorded, then the spec degenerates into solipsist snippets of conversations between the author and himself. That's hardly communication.<br /><br />At work, I try to champion putting more non-normative context into our documents. Unfortunately, I'm really good at losing arguments. So, I've started to wonder if any lessons from Mathematics or Physics can shore up my reasoning. I can think of three reasons why normative-only specifications are like Mathematical proofs.<br /><ul><li>They hide the many wrong turns and false starts that their authors suffered while working.</li><li>They are themselves the <span style="font-style: italic;">end </span>product of the effort, not necessarily a <span style="font-style: italic;">means </span>to an end. (Implementing the spec, or applying the theorem, is often left to others.)</li><li>Specs and proofs are both terse, but they convey enough information for their consumers, as long as their consumers have the expertise and context to read them.</li></ul>Somehow, I'm reminded here of <a href="http://nobelprize.org/nobel_prizes/physics/laureates/1965/feynman-bio.html">Richard Feynman</a>'s "Lost Lecture" on the Motion of Planets Around the Sun. He wished to prove that orbits are ellipses without using calculus, and said,<br /><blockquote>I am going to give what I will call an elementary demonstration. [But] elementary does not mean easy to understand. Elementary means that nothing, very little, is required to know ahead of time in order to understand it, except to have an infinite amount of intelligence. It is not necessary to have <span style="font-style: italic;">knowledge</span>, but to have <span style="font-style: italic;">intelligence </span>in order to understand an elementary demonstration.<br /></blockquote>In this sense, our normative software specs need to be <span style="font-style: italic;">elementary</span>. Unfortunately, I have never met a software spec writer as gifted as Feynman. Neither have you.<br /><br />A while back, a pretentious document crossed my desk. It dotted every "i" and crossed every "t." Yet, after several readings, I still had no idea what the point was. There was a whole bunch of language that felt like it was adding fault tolerance features to an existing distributed product, but at the same time there was no redundant hardware to make changes worthwhile. So, naturally, I started to inject myself into hallway conversations to get the gist of the project.<br /><br />It turns out that the existing product relied on some third-party software that came with some pretty onerous licensing fees. The whole point of the project was to rework how the system was deployed to save money. If you could revisit a few architectural decisions, then the expensive software could be localized in fewer places, thus saving a few bucks. Knowing that one little gem would have made the spec comprehensible, but it was nowhere to be found in the text because it was "non-normative."<br /><br />Of course, you already know the punchline of the story. After spending a bunch of cash on the new project, somebody finally had the idea to call up the third-party software vendor and try to negotiate a more reasonable price. They agreed, and the re-architecture effort turned out to be a very expensive way to save money. By every criterion, whether dollars spent or risk incurred or opportunities lost, the phone call was the better option. But since not enough people were trusted with the real objective of the project, the optimal solution was discovered too late.<br /><br />In hindsight, calling up the vendor seems obvious, but it wasn't. For those developers, who seldom interacted non-technically, it actually tipified out-of-the-box thinking. Creativity can't be scheduled into the spec-writer's block of time, because nobody can think of everything. The deliberate decision to exclude non-normative information from the original spec enabled this mistake<br /><br />The best solution to a wicked problem is not commanded; it often emerges as it is solved. Had enough people understood what they were being asked to do, somebody would have made that phone call sooner. Consider <a href="http://en.wikipedia.org/wiki/Eric_S._Raymond">Eric Raymond</a>'s assertion that "given enough eyeballs, all bugs are shallow." It's interesting to speculate whether there exists some parallel to <a href="http://en.wikipedia.org/wiki/Linus%27s_Law">Linus's Law</a>. Perhaps enough eyeballs tame all wicked problems.<br /><br />I suppose rationale doesn't matter when the spec itself is the work product. A compiler writer doesn't really have to know why Ada has two different functions for mod and remainder. One would just have to know the rules for each, and implement them correctly. But many of our software documents are not work products themselves; they are just the means why which communities build work products.<br /><br />Much of what we do is <a href="http://www.poppendieck.com/wicked.htm">wicked</a>.<br /><br />The analogy to nature came to mind as I thought about this software development question. I can hone my mathematical skills by reading and doing mathematics. Terse proofs are suitable in Mathematics, because anything you need to know is already out there for the taking. (Can you tell whether I'm a <a href="http://en.wikipedia.org/wiki/Philosophy_of_mathematics#Platonism">Platonist</a>?) But Physics doesn't work that way. Or, at least, it doesn't work that way in my brain. One can't do new physics without doing experiments, and the most exciting experiments are done in unfamiliar domains.<br /><br />So, mathematical proofs are like normative specifications, but physical principles are like domain expertise. That surely can't be guessed a priori. Now, suspend your objections for a minute. Yes, Physics has proofs. Yes, Mathematics is at least a quasi-empirical science. Yes, the analogy is bad. But all analogies are bad. I'm not really trying to make a point about Mathematics and Physics here; I'm trying to explore how to write better software documents.<br /><br />For example, I think one can reason their way towards the notion that there are more real numbers than there are rationals. (I'm not saying everyone is <a href="http://en.wikipedia.org/wiki/Georg_Cantor">Cantor</a>, but I am saying that bright people can follow his conclusions, and that he didn't need to build a machine to discover them.) This contrast with Physics. I don't think anybody thought up the <a href="http://en.wikipedia.org/wiki/Quantum_Hall_effect">quantum Hall effect</a> before it was discovered experimentally, even though both quantum mechanics and the <a href="http://en.wikipedia.org/wiki/Hall_effect">Hall effect</a> were already laying around. Physics is wicked.<br /><br />The second most famous equation in Physics is due to Newton, F = ma. With calculus, we economically write the more general form F = dp/dt, where p represents the momentum of the object. In all our ordinary experience, momentum is the product of the object's mass and velocity, p = mv. Newton's second law tells us that forces impart changes to an object's momentum.<br /><br />Embracing the analogy, we can say that F = dp/dt is a normative specification for how the universe works. Strictly speaking, you don't need to convey much else. You don't need an appendix containing the history of Leibniz and Newton. As long as you already know calculus and the definition of p, you're off to the races.<br /><br />Knowing calculus is a technical skill. If you <a href="http://en.wikipedia.org/wiki/Grok">grok</a> <a href="http://en.wikipedia.org/wiki/Method_of_Fluxions">fluxions</a>, then you understand what F = dp/dt really means. Given some measurements, you can make some meaningful, quantitative remarks about an object's behavior.<br /><br />Maybe it's technical skill like being able to read <a href="http://www.uml.org/">UML</a>. If you look at the arrows on a class diagram (whether inheritance or composition), then you can tell what depends on what in the picture. If there are cycles, then you might be able to say something intelligent about the quality of the design.<br /><br />Einstein realized that some pretty weird things happen when objects move at speeds that are non-trivial fractions of the speed of light. Our humdrum definition of momentum grows some wrinkles. Our familiar p = mv turns out to be the low velocity approximation of the more general p = mv/sqrt(1-v^2/c^2).<br /><br />The normative formula, F = dp/dt is still quite correct! Even with Einstein's discovery, I wouldn't need to rewrite my normative spec. But it's going to be misunderstood by anybody who only knows the low velocity definition of p. When you start to pull people out of the domain in which they are most comfortable, normative isn't enough.<br /><br />So, if "spec" is too pretentious for what we do, what's the alternative? Our documents need to be more humble. It's a happy coincidence of English that humble and human are such similar words, because when trying to evolve solutions to wicked problems, it's all about people communicating.<br /><br />Specs are perfectly good work products that describe what something has to do, and they have a crucial role in software development. But not every document is an end unto itself. Many are living documents. What could we call those documents, which people use as tools to build a work product?<br /><br />Narratives.<br /><br />Specs are <span style="font-style: italic;">ends </span>of well-defined efforts. Narratives are <span style="font-style: italic;">means </span>of attacking wicked problems. In literature, the best narratives uncover profound truths about the human condition. In software development, the best narratives collect the relevant principles needed to attack the problem at hand.<br /><br />Einstein elucidated the principle that the speed of light is constant, regardless of the speed of the observer. This principle drove a rethinking of the definition of momentum, but it only matters for objects outside of our familiar experiences. However, when attacking problems where the principle is relevant, we'd better make it clear. I'm going to start calling what I do in my day job narrative-writing instead of spec-writing, and see where that leads.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-28555049790670301282008-01-06T13:00:00.000-05:002008-01-06T14:07:37.660-05:00Methods Of ProofOver the past couple of weeks or so, I've been playing with some recreational math. It was pointed out to me that the sum of the first <span style="font-style: italic;">n</span> cubes always seemed to be a square. For example, 1^3 + 2^3 + 3^3 = 36 = 6^2. This is probably obvious to the highly <a href="http://en.wikipedia.org/wiki/Numeracy">numerate</a>, but it blew my mind to learn it. After struggling a bit, I could show that the sum of the first <span style="font-style: italic;">n</span> cubes is always the square of the sum of the first <span style="font-style: italic;">n</span> integers. Wow!<br /><br />I came up with a couple of different proofs that were full of tedious algebra, and didn't seem to offer any insights into <span style="font-style: italic;">why </span>such a relation should hold. I became convinced that something so easy to state should have a brief demonstration, possibly geometric, and definitely more intuitive. For quite a while, I couldn't find such a thing.<br /><br />Then it hit me. <a href="http://mathworld.wolfram.com/Induction.html">Induction</a>! There are so many methods of proof: reductio ad absurdam, proof by construction, even proof by computer. Once I remembered the technique, I quickly banged out a proof by induction that the sum of the first <span style="font-style: italic;">n</span> cubes is the square of the sum of the first <span style="font-style: italic;">n</span> integers in just a handful of lines.<br /><br />Mathematical proofs to me are a lot like tests in software development. Just as there are varied methods of proof, there are varied mechanisms for testing the deliverables in the software development process. For example, I might test that the requirements are met with formal acceptance testing. In other words, the acceptance test proves the functional spec (or some other document).<br /><br />As another example, someone might say that the unit tests prove the code. As a fan of <a href="http://c2.com/cgi/wiki?TestDrivenDevelopment">test driven development</a>, I would say exactly the reverse. But the point is that different testing mechanisms are suitable for different parts of the development process. Just as a mathematician must be well versed in different methods of proof, we software folks must be well versed in different testing mechanisms.<br /><br />But what tests the <span style="font-style: italic;">design</span>?<br /><br />Sure, a formal inspection can uncover lots of problems in a document, but is that really sufficient to demonstrate that a design is any good? Multithreading issues, resource leaks, inadequate error handling, and bottlenecks are difficult to uncover in a review, except in the most obvious cases. Formal review chauvinists are sure to challenge me on that opinion. But I believe that if humans really could anticipate how complex systems behaved, then there wouldn't be any such phrase as <a href="http://en.wikipedia.org/wiki/Emergence">emergent behavior</a>.<br /><br />So, I feel that we need another "method of proof" suitable for evaluating design fitness. Ideally, it would be inexpensive and repeatable, giving it another leg up on formal inspections. It should also be available as early in the development process as possible. I suggest that designs are testable by <span style="font-style: italic;">simulation</span>.<br /><br />The project I've been working on most recently has lots of algorithms with tunable parameters, and one of the open questions is how much hardware firepower do we really need to handle realistic customer loads. Although I can imagine that somebody much smarter than I could figure this out from first principles, I wouldn't have much confidence in any design that wasn't vetted by simulations.<br /><br />Happily, with simulation, we don't have to be done before we find out that our design is broken. With languages like Ruby, we can develop margin eaters and simulators rapidly. Design trouble spots can be identified early, maybe even before any production code is written. Of course, this is only possible if the architecture is amenable to simulation.<br /><br />One figure of merit for a good architecture is how early it can support simulations. For example, a recent effort I've shepherded used text over sockets for interprocess communication. There were a lot of fans of <a href="http://java.sun.com/javase/6/docs/platform/serialization/spec/serialTOC.html">Java Object Serialization</a>, but that would have required Java on both sides of the connection. Sticking with text over sockets allowed rapid development of Ruby simulators and placeholders.<br /><br />Testing designs by simulation is not an earth-shattering suggestion. Mature software companies have been using simulation forever, replacing margin eaters with production code as development proceeds. But as an architect, I have profited from the notion that simulation is a kind of test, a method of proof, for designs themselves.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-4412212427305677302007-11-23T15:02:00.001-05:002007-11-23T16:30:28.411-05:00NMI MineThere's an old story about a computer science professor that tried to give his son a middle name of the empty string. Whether true or not, such efforts would surely fail. How could one fill out the birth certificate? The social security forms? There really is no way to indicate that a middle name exists but has no letters in it.<br /><br />I used to work at a big company, complete with photo id badges. Full names were printed on them. If someone lacked a middle name, their badge displayed "NMI" for "No Middle Initial." Naturally, I wondered what would happen if we ever hired someone with a middle name of "NMI." Of course, this never happened. But if I were responsible for the id badge software, you can bet that a person with such a name would be a test case.<br /><br />Programming 101 teaches us to keep data and control separate. But in reality, this lesson is violated all the time. Consider Unix system programming. If you want to open a file descriptor, the <span style="font-style: italic;">open()</span> function returns it, or it returns an error code on failure. Since all the error codes are negative and all file descriptors are positive, this doesn't seem to get us into too much trouble.<br /><br />But, before you fancy yourself as wise as the designers of Unix, it's worth keeping data and control separate whenever possible. I'm familiar with a software system that schedules tasks on distributed embedded hardware. For reporting, the system writes a <a href="http://en.wikipedia.org/wiki/Comma-separated_values">CSV</a> file that can be imported into Excel for friendly display.<br /><br />To schedule a task, a <a href="http://www.w3.org/TR/soap/">SOAP</a> message is sent into the system. This is interpreted, log messages are written, and an appropriate embedded device is chosen. Then the system sends a message of its own to the device, passing along the scheduling information.<br /><br />Scheduled tasks can be edited. But if the start time has already arrived, then the start time can't be changed. Only other details can be changed. In such cases, the update message contains a "zero" as the start time, since null start times were not allowed by the <a href="http://www.w3.org/XML/Schema">XML schema</a>.<br /><br />This use of a magic value, where data masquerades as control, seemed harmless enough at the time. I let it slip by. There were bigger battles to wage, and I felt that I had been saying "no" too frequently anyway. Certainly the designers on the team felt that I had. Unfortunately, this was a mistake.<br /><br />You see, the embedded systems ran Linux. So their "zero" time was the 1970 epoch. However, the outside world was using 1900 as zero time, because that's what Excel uses. I'm embarrassed to say that it took us many days to figure this out.<br /><br />I wish I could blame the delay in fixing this bug on the fact that we have a geographically distributed team. I wish that human language barriers were a suitable excuse. I wish that I could offer something to deflect the cause away from my own bad judgment.<br /><br />But I cannot. The real root cause of this bug was that I allowed an architectural flaw to creep into the system. Thou shalt not conflate data and control.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-68017978662854757422007-11-14T10:00:00.000-05:002007-11-14T09:32:20.317-05:00Aspect VariationsIn a <a href="http://naturalsoftware.blogspot.com/2007/11/oo-is-to-vector-as-aspect-is-to.html">prior post</a>, I suggested an analogy between different ways of formulating Physics and the contrast between thinking about objects and aspects. If <a href="http://en.wikipedia.org/wiki/Object-oriented_programming">OO</a> is like vectors and matrices, then aspects are like variational principles. There's a cute little follow-up that I'd like to explore presently.<br /><br />I'm very fond of <a href="http://logging.apache.org/log4j/">Log4J</a> and diagnostic contexts. In a word, diagnostic contexts conveniently allow the code to store arbitrary strings in <a href="http://en.wikipedia.org/wiki/Thread-local_storage">thread local storage</a>. So suppose I have a jar that offers functionality to persist to a database or a file. The application level code can set a diagnostic context, and then the log messages written by the jar's code will contain that useful information.<br /><br />In pseudo-code, we might do something like this...<br /><pre><br />import org.apache.log4j.NDC;<br />import mypersistpackage.Persister;<br />//...<br /> NDC.push("current cseq=" + cseq);<br /> Persister.save(foo);<br /></pre><br /><br />Then any Log4J messages written by the <span style="font-style: italic;">Persister.save</span> method will contain the specified cseq number. This is incredibly useful, and we didn't have to modify the <span style="font-style: italic;">Persister</span> source code at all.<br /><br />However, a subtle problem arises when we're using thread pools. Whenever the application code makes an <a href="http://en.wikipedia.org/wiki/Remote_procedure_call">RPC</a>, there's a chance that the thread will get returned to the pool during the call. This means that when the remote procedure returns, we might pick up where we left off in a different thread. This means that any context held in thread local storage will be stale.<br /><br />In our example, we'd risk printing out the wrong cseq number after making a remote procedure call. The risks of this would increase when the system is under load, which is exactly when log messages are most important.<br /><br />In a prior post, it was suggested that an aspect could advise all RPCs, so that timing information could be gathered. This is an example of a global principle that can be applied across the entire application. We can press that aspect into service to make sure our diagnostic contexts are not mangled when coming back from a remote call.<br /><br />Even though we <span style="font-style: italic;">could </span>do this with our OO helper class described in the prior post, this solution just plain didn't occur to us until we started thinking in aspects. (In fact, we abandoned using diagnostic contexts altogether.) And sure, I <span style="font-style: italic;">could </span>solve the <a href="http://mathworld.wolfram.com/BrachistochroneProblem.html">brachistochrone</a> problem numerically using vectors, but I'm sure that a computed solution wouldn't give me the same insight I'd get by using the calculus of variations.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-50763953276845841132007-11-13T09:00:00.000-05:002007-11-14T08:55:55.490-05:00OO is to Vector as Aspect is to ...When beginning to study of Physics, one typically learns about forces, just as Newton framed the subject. Forces are vectors, so you have to learn some trigonometry and linear algebra. Trajectories have a <span style="font-style: italic;">locally</span> computable flavor about them, in that they are determined by summing up the forces imparting accelerations to particles. For example, the deflection of a ray of light through a prism is given by <a href="http://scienceworld.wolfram.com/physics/SnellsLaw.html">Snell's Law</a>, which concerns itself only with the place where the light ray hits the glass, not original source or final destination of the beam.<br /><br />And just when you are comfortable with forces being central to everything, the rug gets pulled out from underneath you.<br /><br />Physicists after Newton reformulated Physics with energy and action as central players. This requires a bit more mathematical sophistication. So as you get farther in the subject, you have to learn variational calculus. Trajectories are now the solutions to a boundary value problems, and have a more <span style="font-style: italic;">global </span>nature to them. For example, the deflection of a ray of light through a prism is governed by <a href="http://scienceworld.wolfram.com/physics/FermatsPrinciple.html">Fermat's Principle of Least Time.</a> Out of a family of admissible trajectories, the one nature chooses is determined by a variational principle.<br /><br />That's a very different way of thinking about natural phenomena. I wonder whether there's an analogy here to object oriented and aspect oriented programming.<br /><br />Becoming comfortable with object oriented programming is like learning about vectors and matrices. Objects interact with each other by sending messages changing each other's state. This reminds me of forces imparting accelerations to particles. Direct method calls are like fricative forces, and <a href="http://java.sun.com/products/jms/">JMS</a> calls to mind magnetism or electrostatics.<br /><br />The shift in thinking that's required to embrace aspect oriented programming is like learning about the principle of least action. For want of a better phrase, cross cutting concerns have a more, well, <span style="font-style: italic;">globally principled </span>feel to them.<br /><br />Consider a problem drawn from my real experiences with a system that makes a number of remote procedure calls. Sometimes, things get bogged down, and it's important to know where the time is getting consumed. The original OO approach was to design a little helper class that callers could use to keep track of how long each <a href="http://en.wikipedia.org/wiki/Remote_procedure_call">RPC</a> took.<br /><pre><br />MyHelper helper = new MyHelper("rpcMethodA");<br />rpcMethodA();<br />helper.done();<br /></pre><br />The constructor took note of the current time and method name, and then the <i>done</i> method wrote an informative log message recording how long the method took.<br /><br />But, rather than polluting the biz logic with all this bookkeeping, this problem calls out for an aspect oriented solution. A better approach would be to make an aspect that did the timekeeping and logging, and then advise whatever methods you wanted. In my imagination, this feels like imposing a variational principle on the software.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com1tag:blogger.com,1999:blog-3257506294674819641.post-78014641413964877342007-11-12T22:26:00.000-05:002007-11-12T22:43:10.368-05:00Four A's and a ZedA couple of years ago, in an attempt to combat myopia, I tried to collect some thoughts on a software system I had a hand in developing. I came up with a few principles that applied to that code, but there might be something more general in them that’s worth capturing. So with apologies to <a href="http://www.imdb.com/title/tt0109831/">Hugh Grant</a>, here are Four A’s and a Zed.<br /><br /><h4>Availability is Scalability</h4><br />An important lesson learned is never try to bolt on fault tolerance or fault resiliency at the end. One has to design it in from the beginning. The twin of this idea is that scalability isn’t accidental either. By scalability, I mean the capability of the architecture to improve some figure of merit (throughput, for example) by throwing more hardware at it.<br /><br />All right, those points are obvious. But what wasn’t obvious (and what might not even be true generally) is the idea that availability and scalability are the same thing.<br /><br /><h4>Architecture By Contract</h4><br />ABC is a term I made up to denote an amalgam of <a href="http://archive.eiffel.com/doc/manuals/technology/contract/">Design By Contract</a> (DBC) and <a href="http://www.pragprog.com/titles/kpiod/index.html">Interface Oriented Programming</a> (IOP).<br /><br /><h4>Adaptors for Protocols, Plug-ins for Logic</h4><br />Our product had to integrate into a number of environments. One mistake we made was to mix business logic into the same code that was handling the communication. A better approach would have been to create adaptors that only handled the protocols, and contained no biz logic. Instead, separate plug-ins would contain customizable logic that could be varied independently.<br /><br /><h4>Asynchronicity Considered Harmful</h4><br />Event-driven systems can allow design decisions to be deferred. Usually, it's better not to defer such decisions, but make the hard choices up front.<br /><br /><h4>Zero Bugs in Zero Slocs</h4><br />Code that you don't have to write can't have bugs in it. Our prowess at the keyboard should not be measured by how many lines of code we write, but how few.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-36964565381224889032007-11-09T20:02:00.000-05:002007-11-09T20:11:08.626-05:00Translating OrcsI've been reading Seamus Heaney's translation of <span style="font-style: italic;">Beowulf</span>. It's fantastic. In both senses of the word. I've always liked this kind of stuff, and it's only a coincidence that the movie has just come out. I mean, I would have been reading it anyway.<br /><br />Something early on in the verses has caught my eye. Mr. Heaney translated "orcs" (actually <span style="font-style: italic;">orcneas</span>) as "evil phantoms." I wonder if he was tempted to translate it as simply "orcs." I bet that a lot of Beowulf readers wouldn't be thrown by the word <span style="font-style: italic;">orcs</span>. And those that were would probably be curious enough to look it up.<br /><br />The <a href="http://pragdave.pragprog.com/pragdave/2004/04/end_of_the_know.html">Pragmantic Programmers</a> give a presentation about the Dreyfus Model of communication. Workers (whether in nursing, cooking, or programming) can be divided into five categories ranging from beginner to expert. The less skilled require detailed rules. <span style="font-style: italic;">Bake in the oven at 450 for 30 minutes, then remove the pan using insulated potholders</span>. The more skilled don't require such rules, and embrace intuition. <span style="font-style: italic;">Whip up some fritters</span>.<br /><br />It's suggested that communication across too many levels is difficult. A novice cook would have trouble following the latter directive. An expert would chafe at having to issue the former one. One of the catch phrases when considering the Dreyfus Model is "legalize intuition." In other words, good organizations tend to defer to experts' intuition.<br /><br />I have to quibble with that, though.<br /><br />In our profession, one of the phrases we hear too much is: "I have <span style="font-style: italic;">n</span> years experience, so you have to just trust me." Well, first of all, there's a difference between having twenty years experience and having one year of experience twenty times in a row. Most of us overestimate our expertise.<br /><br />But even when the person making that argument really is an expert, I feel that it's still a cop out not to articulate the logic behind one's point of view. If you really are such an expert, you should be able to convey <span style="font-style: italic;">why </span>the solution you advocate is best. I just don't buy that the expert can't make himself understood to the novice.<br /><br />Of course, that doesn't mean that the novice will believe him. Or embrace the direction given. But that's different from being unable to communicate.<br /><br />I've been blessed with a number of very talented professors over the years. A great many were brilliant. None of them met the stereotype of solipsist genius that couldn't teach worth a darn. In fact, the most gifted were exactly the ones who communicated best.<br /><br />Nobel laureate <a href="http://en.wikipedia.org/wiki/Richard_Feynman">Richard Feynman</a> remarked that if a Physics topic could not be explained to freshmen, then physicists really didn't understand the topic.<br /><br />So, to my fellow architects out there, the next time you are charged with putting a little extra effort into defending your point of view, resist the temptation to take it as a challenge to your role in the group. Instead, welcome the opportunity to reify your intuition into a coherent explanation. And trust your audience to be bright enough, or at least curious enough, to know what <span style="font-style: italic;">orcs </span>are.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-734410159575403462007-11-08T19:26:00.000-05:002007-11-08T19:29:25.992-05:00Unscientific MethodsEvery once in a while, you need to <rant><br /><br />Some years back, I was a novice programmer on an important software effort. <a href="http://www.netlingo.com/lookup.cfm?term=IIRC">IIRC</a>, it was something like a couple or three dozen coders for six calendar months. There were six milestones, one scheduled at the end of each month. For some ironclad non-technical reasons whose details don't matter here, the project's final deadline absolutely positively could not budge.<br /><br />Well, you know how software development goes, and we completed our first milestone after two months elapsed. The project manager called a meeting. "Don't worry," he reassured us. "We're only a month behind schedule." I sure didn't see it that way, so I had a discreet conversation with my technical lead.<br /><br />"Our estimate for how long it would take to complete the first milestone was off by 100%," I said." If our other estimates are similarly off, we're <span style="font-style: italic;">not </span>a month behind schedule. We're <span style="font-style: italic;">six</span> months behind!" My tech lead endured my naivete. He reminded me that we had a talented and hardworking group. The first milestone was just a fluke.<br /><br />"Well, sure," I pressed on. "But, <span style="font-style: italic;">think like a scientist</span>. We've performed one experiment. It tells us that our estimating process is off by a factor of two. I really think we need more people." It was a big company. So throwing more bodies at the problem didn't seem unreasonable to me. But it was not to be.<br /><br />We worked hard, put in lots of overtime, and completed our second milestone after two more months elapsed. The project manager was replaced. The new manager gave us the <a href="http://www.phrases.org.uk/meanings/win-one-for-the-gipper.html">Gipper</a> speech, which pretty much alienated everybody who had been slaving away for the past four months. I now had two experiments supporting my view of the schedule.<br /><br />As I saw it, the team was now effectively tasked with completing eight months work in two months. I voiced this opinion, a little less discreetly this time. But on paper management's unrevised schedule looked like four months work in two months. Somehow that was more palatable. By being the only one who understood the scientific method, I just couldn't make myself believed.<br /><br />Now, I know what you're thinking. You're thinking that they really believed me, but they were wearing their special <a href="http://en.wikipedia.org/wiki/Emerald_%28color%29">emerald colored glasses</a> that get bolted on when they enter the <a href="http://en.wikipedia.org/wiki/L._Frank_Baum">Oz</a> of management. The deadline couldn't move, so they had to keep up the front that we can get the job done in time. After all, <a href="http://memory-alpha.org/en/wiki/Khitomer_Massacre">everyone died at Khitomer</a>, because the alternative would be unthinkable.<br /><br />I might buy that, if it weren't for what happened next.<br /><br />To make up for lost ground, all the programmers were divided into three shifts, and we were each scheduled to come in for our assigned hours. Being young and single, it was little hardship for me to take 3rd shift. We were all working so many hours, there was quite a bit of overlap anyway.<br /><br />That approach might have made sense if we all didn't have workstations of our own on our desks. It might have made sense if programming wasn't such a human activity, which thrived on good interpersonal <a href="http://naturalsoftware.blogspot.com/2007/11/why-team-dynamics-matters.html">communication</a> among team members. It might have made sense if we were geographically distributed across time zones, and worked non-standard hours to maximize overlap. But none of those things were true.<br /><br />Dividing us into shifts was like a shiny pocket watch that a hypnotist takes out of his pocket to distract someone, in this case, upper management. I'm pretty sure I expressed this simile to my tech lead, but we were both so bleary-eyed at the time I can't really be sure. If the decision makers could be duped by the illogic of such a bizarre work tactic, they probably didn't really understand why someone who thought like an experimental scientist would call for revising the milestone effort estimates.<br /><br />At least, that's my hypothesis.<br /><br /></rant>Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-9351732114041449842007-11-07T15:55:00.000-05:002007-11-07T16:42:12.041-05:00Passivating ThoughtsBefore a friend of mine became a brilliant linguist, he was a brilliant Linguistics student. I recall the two of us mulling over some thoughts about active and passive voice then. In English, the subject of an active voice sentence is the actor doing the action. <span style="font-weight: bold;">Geoff studies languages.</span> In passive voice, the subject and direct object get swapped. <span style="font-weight: bold;">Languages are studied by Geoff.</span> It turns out that most active voice sentences can be rewritten in passive voice and vice versa.<br /><br />However, there is an interesting class of active voice sentences that cannot be “passivated,” if I may coin that term. <span style="font-weight: bold;">He sank the boat to become a hero.</span> If we try to flip that around, it no longer makes any real sense. <span style="font-weight: bold;">The boat was sunk to become a hero.</span> It’s no longer correct. Surely the sinker and not the boat itself is the hero.<br /><br />There are similarly structured sentences that do admit passivation. <span style="font-weight: bold;">He sank the boat to collect the insurance.</span> This is nearly identical to the previous example. <span style="font-weight: bold;">The boat was sunk to collect the insurance.</span> That works! It’s clear that the boat is not the collector of the insurance. A million other examples flow off the tongue. <span style="font-weight: bold;">He drank the Jolt to postpone sleep.</span> We were in college after all. <span style="font-weight: bold;">The Jolt was drunk to postpone sleep.</span><br /><br />So, what’s so special about the hero example? Why does the passivation transformation sometimes fail?<br /><br />After kicking this around some, one of us noticed a difference in the sentences. The verb “collect” can be used in passive voice. <span style="font-weight: bold;">Insurance was collected.</span> But “become” is special. Without taking poetic license with the language, one cannot passivate become. <span style="font-weight: bold;">Hero was become</span>, is not correct. We then conjectured that sentences of the form above could be passivated if and only if their infinitival clause had a valid passive voice form.<br /><br />Armed with a conjecture, we thought we’d run a few more experiments and see how it bears up. There’s no way to say “was remain”, so we predicted that the following sentence could not be passivated. <span style="font-weight: bold;">He shredded the contract to remain a free agent.</span> And sure enough: <span style="font-weight: bold;">The contract was shredded to remain a free agent.</span> This sentence would imply that the contract itself was a free agent, but the active voice form does not. The attempt to passivate the verb “to shred” in this example fails because “to remain” admits no passive voice form.<br /><br />Other experiments also shore up the conjecture. <span style="font-weight: bold;">To dance all night, she chose comfortable shoes.</span> That has a clear meaning. She, and not the shoes, is doing the dancing. But attempting to passivate the sentence fails. <span style="font-weight: bold;">Comfortable shoes were chosen to dance all night.</span> Even if that might be a grammatically correct sentence, the meaning is warped. The shoes were not selected to dance (among other dancing candidates). It’s the dancer that dances. Our conjecture correctly predicts this because the construction “were danced” doesn’t make sense. (Although I could dance a jig, which is transitive, and a jig could “be danced,” the flavor of dance used above is intransitive, admitting no direct object, and no passive voice form.)<br /><br />We both celebrated with a <a href="http://www.joltenergy.com/default.aspx">Jolt</a>, but here is where the differences in the way Physics students and Linguistics students look at the world came into play. “We’re done,” I exclaimed. “We looked at the data, formed a conjecture, and tested it with more data. Write it up!” That our conjecture was interesting and useful was enough for me.<br /><br />My friend said something like, “No, we’re not done at all. Now we have to figure out why English obeys the conjecture. What forces could have driven the evolution of the language (or our minds, really) to behave this way? We can‘t just offer the conjecture without justifying it.”<br /><br />This notion floored me. It would never occur to me to ask <span style="font-style: italic;">why </span>F = GMm/r^2. That’s just a useful <a href="http://en.wikipedia.org/wiki/Newton%27s_law_of_universal_gravitation">law</a> that Newton discovered. That it works is enough. <a href="http://en.wikipedia.org/wiki/Hypotheses_non_fingo">Hypotheses non fingo</a>. So, it seemed incredibly ambitious and speculative to try to explain why the linguistics conjecture worked. I was of no further use.<br /><br />In summary, most English active voice sentences can be passivated without changing their meaning or rendering the new sentence ungrammatical. Putting on our Physics hat, we might say that they are invariant under the passivation transformation. However, there are a few sentences that are not, namely the ones with infinitival clauses that admit no passive form. This represents an interesting <a href="http://mathworld.wolfram.com/Symmetry.html">broken symmetry</a>.<br /><br />When <a href="http://www.refactoring.com/">refactoring</a> software, one improves the internal structure without breaking the desired external behavior. In the literature, I perceive a couple of approaches to this. Both are compatible, but have different emphases. <a href="http://www.martinfowler.com/">Martin Fowler</a> and others emphasize the importance of comprehensive unit tests that pass before and after modifications are made. <a href="http://csc.noctrl.edu/f/opdyke/">Bill Opdyke</a> and others champion the idea that source code can be transformed in specific, discrete ways that leave behavior unchanged.<br /><br />I feel that both approaches are important. The first approach admits the possibility that the unit test suite is not complete enough. A client somewhere might rely on some behavior that’s not checked by a unit test. So the refactoring attempt could fail. The second approach <span style="font-style: italic;">should </span>always work, but it limits the refactoring repertoire to those actions that your tool can do. (Unless you are incredibly meticulous and can confidently edit the code by hand yourself.).<br /><br />However, I wonder what subtle <a href="http://en.wikipedia.org/wiki/Broken_symmetry">broken symmetries</a>, analogous to the linguistics example above, might still exist when transforming source code according to our profession's ever growing catalog of refactorings.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com2tag:blogger.com,1999:blog-3257506294674819641.post-291368371733075062007-11-06T08:59:00.000-05:002007-11-06T11:14:23.609-05:00On Being ImitatedA while back, I noticed that my son (who's nearly two) would hold out his arm and stare intently at the back of his wrist whenever someone asked "what time is it?" No one taught him this, he just picked it up because he observed adults doing it. This struck me with the one-two punch of (1) "Wow he's so observant! That's wonderful!" followed by (2) "Oh-oh, what else is he learning by osmosis? I need to be more careful."<br /><br />I'm familiar with a piece of Java code that fires callbacks in response to receiving certain raw events. The idea is that the raw events themselves don't have enough information to be useful to the ultimate consumers. So this piece of code transforms the data, and then fires a more meaningful callback.<br /><br />Here's how it goes. The <span style="font-style: italic;">Transformer </span>class implements a pair of interfaces. One allows clients to register themselves as callbacks, so they can listen to meaningful events. The class maintains a collection of callbacks into which it fires the transformed messages. The other interface allows <span style="font-style: italic;">Transformer </span>to listen to the raw events. Here's some pseudo-code.<br /><span style="font-family: courier new;"><pre><br />public interface Callback<br />{<br /> void onEvent(String s);<br />}<br /><br />public interface Publisher<br />{<br /> void registerCallback(Callback c);<br />}<br /><br />public interface RawListener<br />{<br /> void onRawEvent(String s);<br />}<br /><br />class Transformer implements Publisher, RawListener<br />{<br /> private List<callback> allCallbacks;<br /><br /> public void registerCallback(Callback c)<br /> {<br /> this.allCallbacks.add(c);<br /> }<br /><br /> public void onRawEvent(String s)<br /> {<br /> String transformedString = this.transform(s);<br /> foreach (Callback c : this.allCallbacks)<br /> {<br /> c.onEvent(transformedString);<br /> }<br /> }<br /><br /> private String transform(String s)<br /> // details omitted<br /></pre></span><br />So, clients of the <span style="font-style: italic;">Publisher </span>interface that are interested in receiving events implement the <span style="font-style: italic;">Callback </span>interface, then add themselves into the <span style="font-style: italic;">Transformer</span>'s collection. Some other class fires events into the <span style="font-style: italic;">RawListener </span>interface. The idea is that the implementors of <span style="font-style: italic;">Callback </span>don't have to know anything about the <span style="font-style: italic;">RawListener </span>or the format of the raw events.<br /><br />However, there's a difference between "don't have to know" and "shouldn't know". If the raw event format is subject to change, then we really don't want the implementors of <span style="font-style: italic;">Callback </span>to depend on that in any way. The problem is, that once a client has their mitts on a <span style="font-style: italic;">Publisher</span>, then they can cast it into a <span style="font-style: italic;">RawListener</span>. Like a population of frogs expanding to fill a new niche in the ecosystem, living code will exploit that.<br /><pre><br /><span style="font-family: courier new;"> void cleverAndRisky(Publisher p)</span><br /><span style="font-family: courier new;"> {</span><br /><span style="font-family: courier new;"> RawListener listener = (RawListener) p;</span><br /><span style="font-family: courier new;"> String rawEvent = // details omitted</span><br /><span style="font-family: courier new;"> listener.onRawEvent(rawEvent);</span><br /><span style="font-family: courier new;"> }</span><br /></pre><br />In <a href="http://www.pluralsight.com/blogs/dbox/">Don Box</a>'s excellent book, <span style="font-style: italic;">Effective COM</span>, he offers some compelling arguments about the dangers of the <span style="font-style: italic;">QueryInterface </span>method, which is basically a cast. (Incidentally, I think the first chapter of his book is among the finest technical writing I've ever read.) Whenever a class implements interfaces used for different purposes, one runs the risk of a client writing brittle code.<br /><br />I've grown fond of using <a href="http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.3">Inner Classes</a> to attack this problem. Consider an improved <span style="font-style: italic;">Transformer </span>implementation below. With this new approach, the <span style="font-style: italic;">cleverAndRisky </span>method above won't ever work. This doesn't complicate the <span style="font-style: italic;">Transformer </span>code too much, and it sets a good example of paying careful attention to what gets exposed.<br /><pre><br /></callback><span style="font-family: courier new;">class Transformer implements Publisher</span><br /><span style="font-family: courier new;">{</span><br /><span style="font-family: courier new;"> private List<callback></span><span style="font-family: courier new;"> allCallbacks;<br /> <br /></span><span style="font-family: courier new;"> public void registerCallback(Callback c)</span><br /> <span style="font-family: courier new;"> {</span><br /> <span style="font-family: courier new;"> allCallbacks.add(c);</span><br /> <span style="font-family: courier new;"> }<br /><br /></span><span style="font-family: courier new;"> private class RawListenerImpl implements RawListener<br /> {<br /></span><span style="font-family: courier new;"> public void onRawEvent(String s)</span><br /> <span style="font-family: courier new;"> {</span><br /> <span style="font-family: courier new;"> String transformedString = transform(s);</span><br /> <span style="font-family: courier new;"> foreach (Callback c : allCallbacks)</span><br /> <span style="font-family: courier new;"> {</span><br /> <span style="font-family: courier new;"> c.onEvent(transformedString);</span><br /> <span style="font-family: courier new;"> }</span><br /> <span style="font-family: courier new;"> }</span><br /> <span style="font-family: courier new;"> }</span><br /><span style="font-family: courier new;"></span><br /><span style="font-family: courier new;"> private String transform(String s)</span><br /><span style="font-family: courier new;"> // details omitted</span><br /></pre><br />Now, I'm not saying that you have to treat users of your code like two-year-olds, who will poke their fingers into every dangerous socket you leave open. Programmers are a pretty smart bunch. But I am suggesting that the public part of an API should be given careful thought. It's a subtle point, but the public API includes what I can cast interfaces into.<br /><br />Keeping track of this sort of thing sets a good example. Be mindful of what you do when you are in a leadership position. Take pride when the troops imitate you.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0tag:blogger.com,1999:blog-3257506294674819641.post-9061949269139354052007-11-05T05:18:00.000-05:002007-11-05T05:23:25.279-05:00Noether's TheoremIn my last semester as an undergraduate Physics concentrator, I took an initially promising class that turned out to be very depressing. In it, we learned that energy is not conserved. Now, everyone knows about the law of conservation of energy. The patent office has even been known to deny patents on the grounds that purported inventions resemble <a href="http://en.wikipedia.org/wiki/Perpetual_motion">perpetual motion machines</a>, which would violate the principle. And yet, much in the way that Newton’s laws fail in an Einsteinian cosmos, energy is not really conserved.<br /><br />Here’s how it goes. It’s well accepted that the universe is expanding. This is a colloquial way to express the more precise notion that the distances between everything are getting larger. Space is not expanding into anything larger, in the way that a cake fills up the volume of an oven. We don’t notice this effect because our lives are incredibly short and because forces like gravity and electrostatics hold familiar objects together despite the expansion.<br /><br />It’s also well known that light propagates in waves, and that the energy in a beam of light depends on the wavelength. More energetic waves have shorter wavelengths. Well, consider a ray of light traveling along in vacuum for a very long time. If left alone long enough, the distances between the crests of its wave will increase because of the expansion of the universe. This increases the wavelength, and robs the beam of energy. Put whimsically, even light gets tired as it ages.<br /><br />Our little group was shaken by this line of reasoning. The course was an elective, and attended by maybe a dozen curious students. I don’t think we could recall a single problem set endured over the years that didn’t rely on energy conservation somewhere. So we just sat there for a few moments digesting this idea. Finally one of my study partners spoke up. “Professor, you’ve just undone the last four years of our lives,” he managed to get out.<br /><br />Some years later, as a graduate student (in Mathematics, no less), I came to understand a far deeper principle. <a href="http://en.wikipedia.org/wiki/Noether%27s_theorem">Noether’s theorem</a> marries conservation laws to symmetries. Symmetry here has a specialized meaning that’s richer than the layman’s definition. If a deep symmetry can be found in nature, then some observable quantity must be conserved.<br /><br />Specifically, if an experiment performed today would demonstrate the same behavior if performed tomorrow, then we say that the laws of Physics are invariant under translation in time. Invariance under time translation is an entirely reasonable and rather timid assumption. It’s an example of a symmetry (in the mathematical sense) . Noether’s theorem tells us that this symmetry implies the law of conservation of energy. Other symmetries imply other conservation laws.<br /><br />Armed with this understanding, conservation laws were displaced from my perspective as fundamental notions, and became natural consequences of mild assumptions about the world. This happy discovery more than made up for the earlier depressing one.<br /><br />With this more profound perspective, it’s not so upsetting to contemplate that energy might not be conserved over time scales that are non-trivial fractions of the age of the universe. In fact, we might even expect it! We’d have to start thinking up <a href="http://en.wikipedia.org/wiki/Thought_experiment">gedankens</a> that violate conservation, like the aging light beam above.<br /><br />Why has all this come to mind when thinking and blogging about software architecture?<br /><br />It comes to mind because over time I’ve found that some “best practices” that I’d embraced previously only make sense in limited contexts. This is a depressing discovery, akin to the feelings I had as an undergraduate described above. It’s suggests that we can only hope to architect systems on a sandy intellectual foundation.<br /><br />However, whether or not a practice is best, or even good, is not happenstance. Rather, it’s a consequence of some deeper principle when certain assumptions are applied. The analogy to Noether’s theorem is too close not to be struck by it. This is a happy discovery, and I plan to expand on this idea and offer a concrete example or two in subsequent posts.Morgan Creightonhttp://www.blogger.com/profile/10229228897201330840noreply@blogger.com0