Drawing Blanks

Premature Optimization is a Prerequisite for Success

Archive for October 2010

The Flyweight Design Pattern

leave a comment »

I think that the Flyweight Pattern is underrated. It is not all about saving memory. In many cases, Flyweights also add convenient syntax and clear semantics to the code. They are almost like “enums on steroids”. Here is a coding idiom that I frequently use:

class Flavor
    private Flavor(string displayName, Color colorCode)
        this.displayName = displayName;
        this.colorCode = colorCode;

    private string displayName;
    public string DisplayName { get { return displayName; } }
    private Color colorCode;
    public Color ColorCode { get { return colorCode; } }
    public static readonly Flavor Vanilla = 
        new Flavor("Vanilla", Color.FromRgb(0xF4, 0xE7, 0xC6));
    public static readonly Flavor Chocolate = 
        new Flavor("Chocolate", Color.FromRgb(0x8B, 0x45, 0x13));
    public static readonly Flavor Pineapple = 
        new Flavor("Pineapple", Color.FromRgb(0xEE, 0xEE, 0x00));

    public static IEnumerable<Flavor> AllFlavors
        get { yield return Vanilla; yield return Chocolate; yield return Pineapple; }

    public static Flavor Parse(string displayName)
        return (from f in AllFlavors 
                where string.Compare(f.displayName, displayName) == 0 
                select f).First();


Now we can do tons of convenient things like:

icecream.Flavor = Flavor.Chocolate;
if (icecream.Flavor == Flavor.Vanilla) {…}
comboBox.DataContext = Flavor.AllFlavors;
productPanel.Background = new SolidColorBrush(icecream.Flavor.ColorCode);


Written by bbzippo

10/26/2010 at 5:18 am

Posted in programming

Pretty Orbits

leave a comment »

I’d like to share some “computer-generated art”. Below are images generated by a program that I wrote in 1997. It was written in Delphi 1 under Windows 3.1 on a 25MHz 386 PC (yes, one with a “turbo” button). The executable still runs just fine (but not much faster than it used to) under Win 7 on a modern PC.

The program is really simple, it just plots a discrete R^2 map (i.e. a sequence of points). The formulas are very simple too. Most of them are based upon the Gingerbreadman map http://en.wikipedia.org/wiki/Gingerbreadman_map (btw, “gingerbreadman” has tons of stupid anagrams)

qmw1 qmw2

Read the rest of this entry »

Written by bbzippo

10/20/2010 at 3:42 am

Posted in fun, math, programming

Hilbert’s 3rd problem and the Axiom of Choice

leave a comment »

I’ve just learned something exciting: contrary to what I thought, the solution of Hilbert’s 3rd Problem ( http://en.wikipedia.org/wiki/Hilbert’s_third_problem ) does not in fact depend on the Axiom of Choice.

I was under the wrong impression that Dehn’s counterexample was something weird and non-constructive, similar to the Banach-Tarski paradox, because it required the AC. Wikipedia too, only mentions Dehn’s proof that relies on the existence of Hamel’s basis in R over Q.

Well, Dehn’s proof is really cool, and I love Hamel’s basis (I wrote about it here https://bbzippo.wordpress.com/2009/11/05/i-think-therefore-vector-basis-exists/ ), but I was always kind of sad when I was thinking that this problem that is so “finitistic” and “linear” could not be solved without the AC.

Apparently, it could 🙂

The other day I got bored and googled “Hilbert’s Third Problem Axiom of Choice” and found this


Now I’m happy, except I don’t like the terms “scissors-congruent” and “equidecomposable”. What’s wrong with “equicomposable”? 🙂

Written by bbzippo

10/15/2010 at 5:01 am

Posted in math

The illusion of reuse; the fallacy of misnomer

with 2 comments

Udi Dahan expressed many interesting thoughts here http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/ . Those thoughts strongly resonate with some of mine, although I don’t fully agree with everything he says. I just want to rant and whine a bit share some of my observations on this subject.

Someone writes a component that performs a complex business function and has a very simple interface. You just call Machine.Work() – it’s that easy. It’s extremely easy to reuse, and this reuse saves you tons of lines of code. So it’s claimed to be highly reusable. But it’s not. Under the hood of this Machine there are so many responsibilities and dependencies, that make it too specialized. So the reuse is really limited to a handful of scenarios. No problem – we can parameterize the machine at the cost of just a few extra lines of code for the caller. Machine.Mode=a; Machine.Kind=b; Machine.BypassUnneededStuff=true; Machine.Work(). Well, you see, in my particular case the resulting behavior is not precisely what I expect, in addition you introduced bugs because you didn’t cover all m to the power n combinations of parameters in your unit test. And the next set of parameters that you add will likely break other use cases.

This is how in my opinion extra dependencies are introduced and the SRP and loose coupling are sacrificed in the name of illusory reuse. But real Reuse is sacrificed too! “Illusory reuse” means that reuse was the intent, but it’s not the result. (Note: When Udi writes “dependencies multiply by reuse”, he means something very different. But I’m not arguing)

Building blocks are more reusable than the machine that is built out of them. So please give me access to those blocks and I’ll just build the machine that I need. This is what Design Patterns are all about. Loosely couple reasonably sized blocks. Reassemble them to solve the task at hand.

A couple of real-world examples.

Read the rest of this entry »

Written by bbzippo

10/01/2010 at 8:23 am

Posted in programming