The lowest common denominator

There's a lot of discussion about functional programming these days. Not everyone might think that functional additions to a language are such an essential benefit. But as you might know until now I think it really is. I think that a functional programming style can lead to a higher form of abstraction. And more abstraction in your code leads to lesser lines of code which leads to fewer bugs.

In our current project we're working with C# 2.0. But some us are really looking forward taking advantage of the C# 3.0 features. Though we all agree, that not everyone might have the ambition, the time or the interest to make himself deeply familiar with the new features within a narrow time frame. This leads me to another currently much discussed topic in the blogosphere: the lowest common denominator. Does a feature lead to better code if there are still a lot of people not understanding it?

Well, it depends. Do you actively try to leverage programmers which are behind? Do you have a review process in your SDLC? Do you have a critical mass on programmers in your project already familiar with the technology or at least willing to adopt and master the new features? Do you have a culture in your company where fascination is getting nurtured?

What do you think? Do you have own experience in adopting new technologies within a project lifetime?

Ambition vs. LINQ

If you would be given the opportunity to choose your data query abstraction language from those two examples:

LINQ:
products.Where(p => p.Category == "Food").OrderBy(p => p.Price).Select(p => p.Name).Take(2);


Ambition:
Product.select {|p| p.category == "Food" }.sort_by { &:price }.map{ &:name }.first(2)


Which of these implementations would you prefer? I really like them both, though the second one is even more concise.

String#to_proc

Raganwald is one of my favorite bloggers. Every entry he writes inspires me and makes me think. A while ago he ported String#to_proc from Oliver Steele's functional javascript library to ruby. You have to read his entry for yourself but one thing that caught my eye was his definition of the factorial function using String#to_proc:


factorial = "(1.._).inject &'*'".to_proc
factorial[5] # -> 120


I don't know about you, but I think implementations like this are showing us whats possible in this language.

Never stop writing raganwald! Thanks.

Currying und partielle Funktionsapplikation Part 2

Letztes Mal habe ich Currying und partielle Funktionsapplikation in C#, Scheme und Ruby verglichen. Da ich aber funktionale Programmierung hauptsächlich in meiner Freizeit studiere und meine Brötchen immer noch vorwiegend mit .NET verdiene, ist es für mich - eine zugegebenermassen höchst angenehme - Pflicht, das ganze noch kurz in F# anzuschauen.

Deshalb hier also nur ganz kurz als Ergänzung zum letzten Post das Beispiel in F#:

#light
let add a b = a + b
printf "result %i" ((add 2) 3)

let inc = add 1
let result = inc 3
printf "\nresult %i" result

Huh!? Currying wird in F# (wie in Haskell auch) schon von der Sprache selbst unterstützt und es ist hier möglich, eine beliebige Funktion ohne Umweg partiell zu applizieren.

Nice.

Currying und partielle Funktionsapplikation

Vor einiger Zeit habe ich mich (hier) mit Currying und partieller Funktionsapplikation in C# 3.0 beschäftigt. Ich will in diesem Eintrag die Implementation von Wes aufgreifen und anschauen wie eine solche in Scheme und Ruby aussehen könnte.

Grundlage ist die simple Addition:

Func<int,int,int> add = (x,y) => x + y;

Die Funktion Curry für eine generische Funktion mit zwei Argumenten kann in C# als Extension Method implementiert werden und sieht in der Implementation von Wes Dyer folgendermassen aus:

public static Func<A, Func<B, R>> Curry<A, B, R>(
                  this Func<A, B, R> f)
{
return a => b => f(a, b);
}

Mit dieser Funktion ist es also möglich, die Argumente schrittweise zu binden wie wir in der Anwendung klar erkennen können:

Func<int,Func<int,int>> curriedAdd = add.Curry();
Console.WriteLine(curriedAdd(3)(5)); //8

Wie Wes weiter erklärt, kann dieses Konzept weiter generalisiert werden in ein Konzept mit dem Namen 'partielle Funktionsapplikation'. Mit diesem Konzept ist es möglich aus einer Funktion eine ganze Familie von Funktionen zu erzeugen. In unserem Beispiel wollen wir bei der Funktion add das erste Argument mit 1 binden und so eine triviale Inkrementierungs-Funktion erhalten.

Func<int, int> inc = add.Partial(1);

Die Funktion Partial zitiere ich auch wieder direkt von Wes. Sie sieht folgendermassen aus:

public static Func<B, R> Partial<A, B, R>(
                   this Func<A, B, R> f, A a)
{
return b => f(a, b);
}

Thanks again, Wes!

Wenn ich mir das so anschaue, erinnert es mich ein klein wenig an das Überladen von Methoden in der Objektorientierung. Mit beiden Konzepten ist es möglich, den Aufruf einer Funktion/Methode zu vereinfachen indem bestimmte alternative Signaturen angeboten werden. (Die Puristen unter euch mögen mir diesen profanen Vergleich verzeihen!)

Als relativer Anfänger im Umgang mit Scheme habe ich mir angeschaut wie eine solche Implementation in diesem LISP-Dialekt aussehen könnte. Für die Curry-Funktion bin ich auf folgende Implementation gekommen.

(define add
 (lambda (a b)
   (+ a b)))

(define curry
 (lambda (f)
   (lambda (a)
     (lambda (b)
       (f a b)))))

(define curried-add (curry add))
((curried-add 3) 5)  ;; => 8

Auffallend ist hier, dass ich kein funktionales Äquivalent für 'Extension Methods' gefunden habe. Erfahrenere Scheme Benutzer könnten hier vermutlich mit einer prägnanteren Implementation aufwarten.

Trotzdem hier auch noch die Implementation von Partial:

(define partial
 (lambda (f a)
   (lambda (b)
     (f a b))))

(define inc (partial add 1))
(inc 3) ;; => 4

Jetzt wollen wir aber auch noch sehen wie das ganze in Ruby aussehen könnte. Zuerst die Funktion Curry:

add = lambda{|a,b| a + b}
class << add
  def curry
    lambda{|a| lambda{|b| self.call(a,b)}}
  end
end

curried_add = add.curry
curried_add.call(3).call(6)   # => 9

Hier habe ich es vorgezogen, Curry auf dem Objekt add zu implementieren da mir die Anwendung so einfacher schien. Und schliesslich auch eine Ruby-Version von Partial:

class << add
  def partial val
    lambda{|a| self.call(a,val)}
  end
end

inc = add.partial 1
inc 4   # => 5

Wenn ich die verschiedenen Implementation miteinander vergleiche, fällt mir persönlich zuerst einmal der etwas grössere Programmieraufwand für C# auf. Es wird wieder einmal die Tatsache deutlich, dass es sich um eine statisch typisierte Sprache handelt und wir zugunsten einer Typenprüfung beim Kompilieren etwas mehr schreiben müssen. Bei der Ruby-Version fällt vor allem der explizite Aufruf von Proc#call auf.

Als nächstes gäbe es dann wohl den Y-Combinator in der verschiedenen Sprachen zu vergleichen.

Mixins und Klassenmethoden

Als ich zum ersten Mal dem Prinzip der Objektorientierung begegnete welches besagt 'Bevorzuge Komposition der Vererbung' fand ich dieses auf Anhieb einleuchtend. Obwohl Polymorphismus im Fall von einer 'is a'-Beziehung und einer noch nicht zu tiefen Klassenhierarchie sicher nahe liegend ist und eine perfekte Lösung darstellt, gibt es trotzdem viele Fälle wo eine solche Kopplung zu weit geht. (Und wir womöglich sogar das LSP verletzen würden!)
Module in Ruby sind für solche Situationen natürlich geradezu prädestiniert da sie uns erlauben, solche Beziehungen mit Mixins abzubilden. Mit Modulen kann in Ruby zudem auch das Konzept der Mehrfachvererbung implementiert werden.

Nun hatte ich aber diese Woche die Anforderung, Klassen über Module mit Methoden zu erweitern und nicht Instanzen. Aufgrund der Art wie Ruby das Schlüsselwortes 'self' handhabt, lassen sich Klassenmethoden nicht ganz so einfach wie Instanzmethoden 'hineinmixen'.

Aber wie immer mit Ruby war Hilfe nicht weit und die Dokumentation führte zu der Methode 'included(othermod)'. Mit diesem Callback können nun auch Klassen mit Methoden erweitert werden ohne dass die Syntax vom Client her angepasst werden müsste:

module Mixin
 def self.included other_module
  other_module.extend ClassMethods
 end

 module ClassMethods
  def bar?
   true
  end
 end
end

class Foo
 include Mixin
end

puts Foo.bar? #=> true

Linq und Memoization

Gestern habe ich mir ein Video von Wes Dyer angeschaut. In diesem Interview beschreibt Wes (ein Mitarbeiter des C#-Kompiler-Teams und ein ziemlich smarter Typ) die Vereinfachung eines Singleton-Pattern mittels Extension Methods. Da mir das ganz gut gefallen hat, beschloss ich das ganze mit der Beta von 'Orcas' auszuprobieren und hier nachzuvollziehen. Nachfolgend also dieses Beispiel.

Eine typische Implementation des Singleton-Pattern sieht meist etwa so aus:

    public class Foo
    {
        private static Foo _instance = null;

        public static Foo GetInstance()
        {
            if (_instance == null)
                _instance = CreateFoo();

            return _instance;
        }

        private static Foo CreateFoo()
        {
            //some interesting stuff
            return new Foo();
        }
    }

Das ist soweit trivial und sollte keinem von uns Kopfzerbrechen bereiten. (Auf den Sinn und die Notwendigkeit des Patterns und allfällige Singletonitis wollen wir hier nicht eingehen) In einigen Sprachen ist dieses Pattern bereits sogar in die Standart-Bibiliothek integriert worden. (e.g Ruby)

Etwas – zugegebenermassen nur sehr wenig – komplizierter wird es hier, wenn wir Gruppen von Instanzen verwalten wollen. Zum Beispiel stellen wir uns für das gegebene Beispiel vor, dass wir pro Zahl eine eigene Instanz verwalten wollen. Ein erster Versuch könnte uns zum Beispiel zu folgender Implementation führen:

   public class ComplicatedFoo
   {
      private static Dictionary<int,ComplicatedFoo> 
       _dictionary = new Dictionary<int,ComplicatedFoo>();
 
       public static ComplicatedFoo GetInstance(int n)
       {
           ComplicatedFoo foo = null;
           if (!_dictionary.TryGetValue(n, out foo))
           {
               foo = CreateComplicatedFoo(n);
               _dictionary.Add(n, foo);
           }
           return foo;
       }
 
       private static ComplicatedFoo 
                           CreateComplicatedFoo(int n)
       {
           //some interesting stuff
           return new ComplicatedFoo();
       }
   }

Wir nehmen also erstmal ein Dictionary zu Hilfe um diese Struktur abzubilden. Wenn wir dies aber genauer anschauen, stellen wir fest, dass es sich hier um die Verbindung von einer Funktion (inkl. Parameter) und einem Resultat handelt. Mit anderen Worten: Memoization.
Memoization implementieren wir in C# 3.0 mittels einer ‚Extension Method’. Im unserem Fall mit einer Methode mit einem Argument und einem Resultat könnte diese Methode so aus:

    static class FunctionExtensions
    {
        public static Func<A, R> 
                   Memoize<A, R>(this Func<A, R> f)
        {
            var map = new Dictionary<A, R>();
            return a =>
              {
                  R value;
                  if (map.TryGetValue(a, out value))
                      return value;
                  value = f(a);
                  map.Add(a, value);
                  return value;
              };
        }
    }

Wenn wir nun diese Memoization-Funktion auf unsere vorige Implementation anwenden, so führt uns das zu folgendem Code:

    public class FunctionalFoo
    {
        private static Func<int, FunctionalFoo> 
           getInstance = ((Func<int, FunctionalFoo>)
                 (n => CreateFunctionalFoo(n))).Memoize();

        public static FunctionalFoo GetInstance(int n)
        {
            return getInstanceMemoized(n);
        }

        private static FunctionalFoo 
                               CreateFunctionalFoo(int n)
        {
            //some interesting stuff
            return new FunctionalFoo();
        }
    }

Der Vorteil dieser Implementation ist natürlich, dass wir unsere Memoize-Funktion beliebig wiederverwenden können. (Gesetzt wir haben die entsprechende Signatur in unsere CreateFoo-Methode.)

Ziemlich cool IMHO. Thanks Wes!

Mocks vs Stubs

Ein Blog welches ich seit einiger Zeit - mit der mir verfügbaren Sorgfalt - verfolge, ist jenes von Jay Fields. Ein weiterer ThoughtWorker der stets mit qualitativ hochwertigen Posts aufwartet.

Den Unterschied zwischen Mocks und Stubs haben wir ja bereits hier definiert. Bei meinen eigenen TDD-Streifzügen bin ich jedoch zur Überzeugung gekommen, dass auch hier wieder keines von beiden für sich allein genommen die silberne Kugel ausmacht. In einem bereits etwas älterem Post von Jay habe ich dann diesen, für mich sehr sinn-stiftenden Abschnitt gefunden, den ich gerne mit euch teile möchte:

Using a mock to verify the class under test interacts in an expected manner with a dependency is natural. However, tests should verify behavior of a dependency independently of other dependencies. For all dependencies who's behavior is not currently under test a stub is preferred. By using stubs in this manner you convey the message that only the interaction of the class under test and the mocked dependency is important.

Eine etwas mehr 'Absicht-getriebene' Definition. Und da ich versuche, Code zu schreiben, welcher die dahinter liegenden Absichten bestmöglich kommuniziert, gefällt mir diese stützende Beschreibung besonders gut.

Python und .NET - IronPython

Da ich meine Tantiemen bekanntlich mit .NET verdiene habe ich letztens ein wenig mit IronPython - einer Python Implementation für die CLR - experimentiert. Richtig, in Sachen dynamische Sprachen ist mein Favorit Ruby. Aber schliesslich ist IronPython ja der ‚proof-of-concept’ einer dynamischen Sprache für die CLR, ist komplett in C# geschrieben und läuft auf dem .NET Framework 2.0 und auf Mono. Ausserdem wird eine mühelose, bidirektionale Integration mit ‚managed code’ versprochen. Gründe genug also meine Hirnzellen mit etwas syntaktischen Neuerungen bemühen zu dürfen.

Die Python-Syntax ist ein wenig gewöhnungsbedürftig. So sind zum Beispiel die Einrückungen von Bedeutung. Sie ersetzen die geschweiften Klammern die wir zum Beispiel von C# her kennen.

Eine Methode kann also zum Beispiel folgendermassen definiert werden:

>>> def addOne(x):
...   return x+1
...
>>> print addOne(2)
3

Eine triviale Klasse so:

>>> class MyClass(object):
...   def doSomething():
...     return 'in doSomething'
...

Wir können die Methoden einer Klasse mit der Methode ‚dir’ inspizieren. Als Rubyisten werden wir mit Reflection-Features natürlich geradezu verwöhnt.

>>> t = MyClass()
>>> dir(t)
['__class__', '__dict__', '__doc__', '__init__', '__module__', '__new__', '__red
uce__', '__reduce_ex__', '__repr__', '__weakref__', 'doSomething']

Meine Methode war also korrekt eingerückt. Vererbung ist natürlich auch möglich:

>>> class MySecondClass(MyClass):
...   pass
...
>>> dir(MySecondClass)
['__class__', '__dict__', '__dict__', '__doc__', '__init__', '__module__', '__ne
w__', '__reduce__', '__reduce_ex__', '__repr__', '__weakref__', 'doSomething']

Aber wir wollen jetzt etwas von .NET sehen. Fangen wir an mit Datenstrukturen. Am besten mit einem Hash. Genauer: Einer .NET-Hashtable in IronPython. Nach einigen Gehversuchen sieht das dann so aus:

C:\Program Files\IronPython-1.0.1>ipy.exe
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import System
>>> from System.Collections import *
>>> h = Hashtable()
>>> h["a"] = "Ruby"
>>> h["b"] = "Smalltalk"
>>> h["c"] = "IronPython"
>>> for e in h: print e.Key, ":", e.Value
...
a : Ruby
b : Smalltalk
c : IronPython

Das ist doch schon mal etwas. .NET-Datentypen und Python-Syntax. Eine aus sozialer Sicht durchwegs tolerante Hochzeit. Um weitere .NET-Bibliotheken benutzen zu können, müssen wir aber das CLR-Modul laden und die einzelnen Referenzen hinzufügen. Im Moment geschieht also noch folgendes:

>>> d = XmlDocument()
Traceback (most recent call last):
File , line 0, in ##11
NameError: name 'XmlDocument' not defined

Wenn wir versuchen den Namespace zu importieren geschieht auch noch nicht viel mehr:

>>> from System.Xml import *
Traceback (most recent call last):
File , line 0, in ##12
File , line 0, in __import__##4
ImportError: No module named Xml

Aha. Das Modul, resp. die Referenz muss also erst hinzugefügt werden. So wie wir es in .NET-Code auch tun würden. Allerdings müssen wir hier erst noch das CLR-Modul laden damit wir diese Referenzen richtig hinzufügen können:

>>> import clr
>>> clr.AddReference("System.Xml")
>>> from System.Xml import *
>>> d = XmlDocument()
>>> d.ToString()
'System.Xml.XmlDocument'

Eigene .NET-Bibliotheken lassen sich übrigens ganz ähnlich importieren:

>>> import clr
>>> clr.AddReferenceToFile("mylibrary.dll")

Um jedoch auch WinForms-Komponenten benutzen zu können und zum Beispiel ein Form anzuzeigen müssen wir dafür sorgen dass der ‚Message-Loop’ richtig behandelt wird. Dazu finden wir nach der Installation von IronPython ein Batch-File ‚winforms.py’ im Unterverzeichnis ‚Tutorial’ welches einen entsprechenden Thread eröffnet und dies sicherstellt.

Alles in allem lässt sich sagen, dass IronPython sicher ein interessantes Projekt ist. Es zeigt dass die CLR auch eine mächtige Plattform für dynamische Sprachen sein kann. Natürlich gefällt mir die Syntax und der Stil von Ruby besser. Das wird sich auch nicht ändern. Aber zumindest als kleine Versuchsumgebung für .NET werde ich sicher in Zukunft das eine oder andere Mal IronPython zu Rate ziehen.

self.memory.get_chapter(:ferret).mark!

Some private projects were keeping my quiet busy in the last weeks. One issue which was absorbing some of my time was the ruby port of lucene: ferret. To be specific it was not even ferret itself. It was my ignorance. But I am smarter now.
I had problems with our swiss special character set. If trying to save an entry in rails I always the same error:

Exception (: Error occured at :704
Error: exception 2 not handled: Error decoding input string.

Yes. That one was quiet obvious. There had to be a problem with my locales. Well, unfortunately I was searching in the wrong corners and my first solution was setting the locales in my rails environment so I added

ENV['LANG'] = 'de_DE.UTF-8'

to my environment.rb. But nothing changed. Still the same error. Okay, lets ask one of my close friends: Googlix. He revealed that maybe another addition in my environment file would work:

$KCODE = 'u'
require 'jcode'

Okay. But nope. That wasn't it either. I should have taken a nap. I should have put myself an hour in my samadhi tank. (If I only had one of those!).
Finally I decided that the Issue must be not one of my rails setup instead I got suspicious about my operating system. Maybe I misconfigured it. Okay so fire some configuration up:

dpkg-reconfigure locales

Hell no! I didn't have the corresponding package installed for 'de_DE.UTF-8'!! I must have been asleep while setting up my new debian sarge. Well, don't blame yourself. Just don't make the same mistake twice!