Toluu : The Mechanical Bride

The Mechanical Bride

Clojure. Wow.December 2 2008

Someone finally did it. They created a LISP that I want to use. Too bad it's for the JVM. :-)

Most of my complaints about LISPs are the same as everyone else's. Few libraries, less documentation, and poor interoperability. I never found a LISP that had everything I wanted. I'm repelled by the complexity of Common Lisp and vexed by Scheme's completely avoidable verbosity. It also find that languages like F# and Haskell do a better job of encouraging practices that minimize mutable state. Putting all that aside, even if a free Lisp with standard libraries as extensive as that of .NET or Java existed I just don't have time to relearn how to print "Hello word," nor should I have to.

Enter Clojure. It runs on the JVM and as such can use any Java library. As for syntax it takes a very conservative approach, adding just enough to make a big difference in readability. Clojure has tremendous potential. Its encourages the use of sequences, has lots of handy immutable data structures, and some nice syntax for creating them. It's weird but Clojure programming feels almost as much like F# as it does Scheme.

I have to call one particular syntactical decision out in particular. The choice of lambda syntax is brilliant:

(reduce #(%1 + %2) (range 100))

Clojure's got macros (of course), optional type annotations, even a working Software Transactional Memory implementation(!). Having done some simple benchmarking I was pl

Protected Dependency Properties Are Not ReallyNovember 26 2008

I discovered an interesting fact yesterday. I was attempting modify ImplicitStyleManager to support the DefaultStyleKey property. Previously I was just using the concrete type of the object I was styling to retrieve its style from the resource dictionary. Unfortunately this prevented types derived from System.Windows.Controls.Button from getting styled as buttons. This diverged from WPF's behavior and understandably we got flack for it on CodePlex. When I saw that the property was protected I thought "game over." Luckily Silverlight Toolkit team member Justin Angel didn't give in so easily.

Justin: "Lemme try something."

Me: "Justin we can't access protected members. I mean we could add an interface or something..."

Justin: "Just gimme a sec."

After a few moments he IM'ed me something very much like this:

internalclass DefaultStyleKeyRetriever : Control
{
///<summary>
/// Initializes a new instance of the DefaultStyleKeyRetriever class.
///</summary>
public DefaultStyleKeyRetriever()
{

Auto-sizing Canvas for Silverlight and WPFNovember 12 2008

One of the first issues I ran into when I was learning WPF was that the Canvas didn't size to its contents. I was attempting to render a graph and I wanted to stick a Canvas in a ScrollViewer and have the scroll area grow as more content was added outside the current bounds of the Canvas. While searching for a solution I noticed on various forums that several other developers were looking for a solution to this problem. At the time I didn't know enough about writing custom layout containers to write my own Canvas and I soon found myself diverted.

Today I work for Microsoft and am partly responsible for Silverlight Charts. Now that I'm rather comfortable writing layout containers I figured I'd spend a few minutes and bang out a Canvas control that provides all the flexibility that I'd always wanted. Ladies and gents I present DynamicCanvas.

In addition to restoring the WPF Bottom/Right properties that are missing from Silverlight's Canvas the DynamicCanvas adds CenterLeft, CenterTop, CenterRight, and CenterBottom properties. In WPF these properties are convenient but not strictly necessary as you can use a multi-binding and a converter to center your objects declaratively. However Silverlight 2 does not support multi-bindings which makes it rather more difficult to ensure that objects will remain c

Haskell for C# Programmers Part 2: Understanding IONovember 5 2008

One of the most difficult things for C# developers to understand about Haskell is the way in which it performs stateful tasks such as IO. In part 1 I explained the difference between methods and pure functions. Pure functions always return the same value if passed the same arguments and don't change the state of the system. C# methods that change state (ex. change a global variable, return a pseudo-random number, write to disk) are considered "impure." In C# we can create both pure functions and methods. In Haskell it is only possible to create pure functions. This might seem strange. After all without impure operations you can't even generate a random number. That would make for a pretty dull poker game eh?

"Who cares about purity?"

Impure programs are a lot like machines with moving parts. Every time you look at them they are in a different state. In contrast pure programs are like machines with no moving parts. They are, on close inspection, just formulas executed by the computer. Want to take a guess which machine is more reliable?

In addition to the benefits of clarity and increased reliability it turns out that compilers can also make certain types of optimizations if they can be sure that code is pure. That's one of the reasons Haskell can be very fast despite the fact that it is such a high-level language.

"That's all well and good but

Using ImplicitStyleManager and Theme ContainersNovember 4 2008

No doubt many of the developers and designers who are exploring Silverlight have had some exposure to WPF. As a result they may be used to relying on implicit styles to ensure their application's have a uniform look and feel. WPF's implicit styling behavior ensures that styles in the resources of an element are applied to their logical descendents. Take the following WPF XAML snippet for example: