Im vergleich zum Irak-Krieg? Oder alle Kinder dieser Welt für 5 Jahre zu ernähren?

Hier wunderschön visualisiert.

So viel ist klar - man sieht was wichtig ist im Staat und was nicht. Leider.

via

Zu "Ergie" von Rainer von Vielen

In meiner Freizeit beschäftige ich mich gerade viel mit Ruby - sowohl The Ruby Way, als auch The Ruby Programming Language sind dafür gute Bücher.

Und ich muss sagen, das Ruby ist nicht unspannend. Zwar gibt es auch einiges dass ich ganz schön eklig finde (z.B. das Flip-Flop Statement, oder dass so viel mit globalen Variablen gearbeitet wird, oder dass viele Sachen so komplex sind.

Aber darum gehts hier gar nicht. Mir geht es hier um die Erkenntnis wieso und unter welchen umständen man Blöcke als etwas anderes sehen möchte als anonyme Funktionen.

Das dauert nämlich bis man das merkt.

Zuerst einmal die Konfusion: Ruby hat eine Syntax für Methoden

def method(positional_argument, *all_other_arguments)
  # some body
end

und eine für Blöcke

10.times do |positonal_argument, *all_other_arguments|
  # some body
end

Wieso der Unterschied? Wieso macht man Blöcke nicht einfach zu normalen Funktionen die man dann auch gleich mit () aufrufen kann anstatt immer ein a_block.call() verwenden zu müssen?

Echte Lambdas gibt es ja noch zusätzlich in Ruby.

Well, den Unterschied in der Syntax verstehe ich immer noch nicht. Aber dahinter steht der Grund dass Blöcke eine andere Aufgabe haben als Methoden - der Punkt ist nämlich dass man sie gerne als Teil der sie lexikalisch umgebenden Methode betrachten möchte damit man sie nutzen kann um mit ihnen Kontrollstrukturen zu implementieren. Hier mal ein Beispiel:

def find(needle, haystack)
  haystack.each.with_index do |index, element|
    if element == needle
      return index
    end
  end
  return nil
end

(Also als Python Programmierer muss ich ja sagen dass die end statements ganz schön auf die Nerven gehen. Doppelte Zeilenanzahl für null zusätzliche Information oder Nützlichkeit. But I digress.)

Das spannende daran ist die Zeile return index. Seht ihr was daran besonders ist? Ich Puzzle es mal auseinander als wäre der Block eine funktion, dann wird es klar.

find ruft einen iterator auf dem haystack auf, d.h. übergibt ihm eine Funktion die das richtige Element findet. Diese Funktion erhällt ein Element aus dem haystack und einen index und gibt diesen index zurück wenn das element das gesuchte ist.

Und da ist das Problem: Damit find funktioniert muss return index find verlassen und nicht nur die iterator-funktion.

Das ist der Grund wieso man Blöcke als etwas anderes als Funktionen/Methoden betrachten muss wenn man sie nutzen will um damit Kontrollstrukturen implementieren zu können und ihre volle Nützlichkeit für Abstraktionen verwenden zu können.

Liegt es vielleicht wie auf Stackoverflow angekündigt an der Sprache?

Jedenfalls fand ich den ersten Kommentar hervorragend.

"Python on Pails" just doesn't have the same feel to it... – ephemient
  @Ephemient: I believe it would be Python on Planes. – Jimmy
  @Jimmy: Who needs planes? import antigravity ;-) xkcd.com/353 – Vinay Sajip
  Is there a Java in Jails? – Nosredna

lol Eindeutig, die Sprache ist schuld.

I am always amazed at the very nice features of JavaScript on the one hand and the very, very bad features of it on the other side.

Here's something I learned the other week that I find quite interesting: eval vs. new Function. Here's what I wanted to achieve: I was looking for a way to do some meta-programming with JavaScrip, specifically prevent the problem that any variable you assign to but don't declare ends up as a member of the global object.

The problem is that name lookup in JavaScript is quite peculiar. First it consults the current function activation for local variables and then it goes straight back to the window object and just prepends all it's contents to the local namespace.

Doh. This has the very bad consequence that every variable you forget to declare via the var someVariableName syntax becomes part of the global object - and therefore itself global.

Now you can change this lookup by inserting some of your objects in this lookup chain by using the somewhat controversial with statement like so:

var namespace = {foo:'bar'};
with (namespace) {
    // this scope now has a local variable foo with the value bar
}

This is considered a bad feature, as it means that if you assign to foo that will assign a new value to namespace but if you assign to something else or mistype, that will still end up on the global object. Not very nice - and therefore most JavaScript programmers don't use with ever.

Still with some working and eval it can be used to re-map free functions transparently, so that you can do something like this:

var namespace = {
    equals: function(actual, expected){
        if (actual !== expected)
            console.log('actual', actual, 'does not equal expected', expected);
    }
}

function test(aDescription, aTestFunction) {
    useNamespaceForFunction(namespace , aTestFunction)();
}

test("that I can call equals as a free function", function(){
    equals(1,1);
});

Which would allow you to not pollute the global namespace with all the testing equality functions but still call them in a convenient way (that is without needing to go through an object.

All in all, quite nice really - even though I haven't really found a use for this yet. :-)

Implementing the useNamespaceForFunction however isn't quite as straightforward as I had thought - here's my first go at it:

function useNamespaceForFunction(aNamespace, aFunction) {
    with (aNamespace) {
        return  eval('(' + aFunction + ')');
    }
}

I have since learned that actually using new Function to do the eval might be quite a good idea as the whole point of it is that it ignores the namespace around it, so here's my version two:

function useNamespaceForFunction(aNamespace, aFunction) {
    var namespacingCode = "with (aNamespace) { return (" + aFunction + "); }";
    // using new Function instead of eval to prevent the current namespace leaking into the eval<
    return new Function("aNamespace", namespacingCode)(aNamespace);
}

So, lets see what uses come up for this technique - I've seen some js code that does an Interpreter of sorts with this trick - but thats about it.

So - I didn't achieve my initial goal - but I did come nearer to it. So I'll call it a success here for now.

If you find any use for this technique, please let me know!

[browser:open-source/javascript-hacks/trunk/namespacing-functions.js Get the source!]

Python is a wonderfull language - except when it's not.

For example calling a super-method is really, really hard. Here's an example:

class Super(object):
    def method(self):
        pass

class Sub(Super):
    def method(self):
        super(Sub, self).method()

This is bad because of several reasons:

If your class names become longer this becomes more and more unreadable, consider this Acceptance-Test

class CanEnterUsernameAndPasswordOnLoginForm(TestCase):
    def setUp(self):
        super(CanEnterUsernameAndPasswordOnLoginForm, self).setUp()
        # more

You need to repeat the class name in each method that calls super. This is especially bad if you rename your class as you need to repeat the name in so many places - also there might be situations where having the wrong name doesn't bomb but just calls the wrong code. Also if you move methods up and down the class-inheritance-chain this becomes more and more annoying.

Well, so I looked at what you can do with some meta-programming - and lo and behold there's a lot you can do.

Here's an example what I ended up with:

class Super(object):
    super = SuperProxy()
    def method(self):
        pass

class Sub(Super):
    def method(self):
        self.super()

Yeah! Now that's simpler. to call super you can use several syntaxes:

• self.super() just calls the super method of the same name and hands it all arguments that the current method got
• self.super('foo') this way you can hand specific methods to the super-class and prevent the automatic gathering of arguments. If you prefer explicit - this is it.
• self.super.some_method() self.super is exactly the same as what the super-method returns (so it's the same as super(ThisClass, self)) so you can use it to call any method on the superclass and hand it any arguments you want.

Well, so I consider this a boon for any bigger python project as it considerably eases the pain of working with class-hierarchies, and best of all you can import it into your project one superclass at a time.

Oh, and please tell me if you use it and like it. :-)

So [browser:/open-source/python-simple-super/trunk/simple_super.py here's the code!]

Die Welt hat ein Interview mit Juli Zeh geführt, in der sie darüber spricht, was sie gerade als staatstheoretisches Konzept ausarbeitet - und wie darin Parteien nicht vorkommen.

Das ist spannend - insbesondere weil ich mich im Rahmen der Piratenpartei und des Liquid Democracy e.V. und eben auch privat seit Jahren mit genau diesem Thema beschäftige.

Julis (und auch meine) Motivation ist dabei, dass die Parteien als "vorportioniertes Politikbündel", das man so fressen oder es lassen kann, inzwischen mehr zurückhaltende als vorwärts tragende Kraft sind.

Da ist zum einen der Zwang, dass ich mich für ein Politikbündel irgendeiner Partei entscheiden muss, wobei aber jedes Bündel für sich in mehr Punkten meiner Meinung widerspricht als ich es unterstützten kann.

Zum anderen die Tendenz, dass Parteien einen immer stärkeren Fokus auf Machterhalt, Personen und Einflussnahme von reichen Industriezweigen entwickeln.

Genau das aber will Juli - und ich - nicht. Demokratie als sachlicher Diskurs unter Einbeziehung allen verfügbaren Wissens und ohne Populismus - das ist eine Vision, die jetzt vielleicht endlich durch die neuen Möglichkeiten des Internets in erreichbare Nähe gerückt ist.

Worum es mir geht ist das Nachdenken über neue Formen der politischen Partizipation.

Wir sehen in der Struktur der Legislative das eigentliche Problem und wollen diese ändern.

Jeder Bürger soll die Möglichkeit erhalten, an so vielen politischen Fragen mitzudiskutieren und mitzuentscheiden, wie er möchte. Das nennen wir "Flüssige Demokratie", weil jeder jederzeit selbst entscheiden kann, wie tief er sich in ein Thema einbringen will und kann.

Wenn mich etwas nicht interessiert, kann ich weiterhin eine Partei wählen, damit sie mich vertritt. Wenn ich zu einem bestimmten Thema (z.B. Bundeswehreinsatz in Afghanistan) selbst abstimmen möchte kann ich das aber jederzeit tun. Und wenn es darum geht mein Fachwissen (z.B. als Informatiker) in die Umsetzung eines Konzepts einzubringen (z.B. zur Frage, wie man die Verwaltung besser transparent machen kann) dann steht es mir frei, in der Konzeptionsphase schon mit einzusteigen oder selbst ein Konzept zu entwickeln und an der ganzen Entstehung mitzuarbeiten.

Das ist eine Vision, die weit über alles hinausgeht, was mir als Konzept bisher begegnet ist. Vor allem aber ist es genau dieser flüssige Ansatz, der dieses Konzept in die Lage versetzt, nahezu unendlich zu skalieren. Mein Dorf, mein Landkreis, mein Land, mein Kontinent, meine Welt - überall kann ich mich dort beteiligen, wo ich es als am Wichtigsten erachte.

Nur als Nebensatz: Ich bin der Meinung dass ein bedingungsloses Grundeinkommen eine hervorragende Bezahlung für genau diese freiwillige demokratische Arbeit ist und wir es daher dringend brauchen.

Mehr Details zu dieser Idee gibt es auf: http://liqd.de und auf allen anderen Links in diesem Artikel.

Ich bin Martin Häcker, ich bin Vorstand der Piratenpartei Landesverband Berlin. Wir haben bei der letzten Bundestagswahl 3,4 % der Stimmen der Berliner erhalten. Und wir wollen das trojanische Pferd sein, das diese Vision in die Parlamente trägt, indem wir es innerhalb der Partei einsetzen, um unser Programm gemeinsam - wirklich basisdemokratisch - zu erarbeiten.

Yeehaw!

Na wenn das nicht ein tolles erstes Bundestagswahlergebnis für die Piraten ist!

Bundesweit waren es 2,0 % - 'immerhin' 0,5 % besser als das erste Ergebnis der Grünen (mit denen wir ja so oft verglichen werden).

katerausschlaf

Eine ganz gute Übersicht über die Ergebnisse gibt es bei ARD

I've long had a fascination with SmallTalk style blocks in Objective-C. So much so, that I learned a lot about how C and GCC work when I implemented them on the primitive of GCCs nested functions myself.

[browser:open-source/closures-in-objc/trunk Heres the Source]

Of course, just as I had it working, Apple deprecated GCCs nested functions, as they where implemented using a trampoline on the stack. And of course, a trampoline being executable code they where out when the non executable stack came in.

Ah well.

BUT, Apple just released with Snow-Leopard a new compiler feature [Blocks]!

Yay, closures in C!

So here's how it looks if you implement the Smalltalk collection iteration protocoll in ObjC. (Note: this of course are not propper ObjC-Names, but each Smalltalker will none the less get a tear in their eye when they see this)

#import <Foundation/Foundation.h>

@implementation NSArray (BlocksTest)

- (void) do:(void (^)(id))aBlock;
{
    // Take care, -enumerateObjectsUsingBlock: wraps an auto-release pool around the iteration
    [self enumerateObjectsUsingBlock:
        ^(id obj, NSUInteger idx, BOOL *stop) {
            aBlock(obj);
        }];
}

- (NSArray *) collect:(id (^)(id))aBlock;
{
    id collectedItems = [NSMutableArray arrayWithCapacity:[self count]];
    [self do:^(id each) {
        [collectedItems addObject:aBlock(each)];
    }];
    return [collectedItems copy]; // REFACT: consider to drop copy
}

- (id) detect:(BOOL (^)(id))aBlock;
{
    // Take care, -enumerateObjectsUsingBlock: wraps an auto-release pool around the iteration
    __block id resultObject = nil;
    [self enumerateObjectsUsingBlock:
        ^(id obj, NSUInteger idx, BOOL *stop) {
            if (aBlock(obj)) {
                resultObject = obj;
                *stop = YES;
            }
        }];
    return resultObject;
}

- (id) detect:(BOOL (^)(id))aBlock ifNone:(id (^)())errorBlock;
{
    id foundElement  = [self detect:aBlock];
    if (foundElement)
        return foundElement;
    else
        return errorBlock();
}

- (id) inject:(id)aValue into:(id (^)(id, id))aBlock;
{
    // Need to take care with retain here, because apple wraps an auto-release pool around the block iterator. :/
    __block id collected = [aValue retain];
    [self do:^(id each){
        collected = [aBlock([collected autorelease], each) retain];
    }];
    return [collected autorelease];
}

- (NSArray *) reject:(BOOL (^)(id))aBlock;
{
    id selectedObjects = [NSMutableArray arrayWithCapacity:[self count]];
    [self do:^(id each){
        if (aBlock(each))
            return;
        [selectedObjects addObject:each];
    }];
    return [selectedObjects copy]; // REFACT: consider to drop copy
}

- (NSArray *) select:(BOOL (^)(id))aBlock;
{
    return [self reject:^(id each){ return (BOOL) ! aBlock(each); }];
}
@end


#define log(objcObject) fprintf(stdout, "%s\n", [[objcObject description] UTF8String])

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    id array = [NSArray arrayWithObjects:@"first", @"second", @"third", nil];

    log(@"\ndo:");
    [array do:^(id each){
        log(each);
    }];

    log(@"\ncollect:");
    log([array collect:^id(id each){
        return [each uppercaseString];
    }]);

    log(@"\ndetect:");
    log([array detect:^(id each){
        return [each isEqual:@"second"];
    }]);

    log(@"\ndetect:ifNone:");
    log([array detect:^(id each){ return NO; } 
                        ifNone:(id)^{ return @"Yeehaw!"; }]);

    log(@"\ninject:into:");
    log([array inject:@"" into: ^ id (id concatenation, id element){
        return [concatenation stringByAppendingString:element];
    }]);

    log(@"\nreject:");
    log([array reject:^(id each){
        return [each hasSuffix:@"nd"];
    }]);

    log(@"\nselect:");
    log([array select:^(id each){
        return [each hasSuffix:@"d"];
    }]);

    [pool drain];
    return 0;
}

Ain't that pretty?

[browser:open-source/smalltalk-like-iterators/trunk Here's the current version!]

Spannend - vor allem die diversen Analysen im Netz dazu.

Peter Piksa hat die beste Zusammenfassung der Ereignisse die ich kenne.

Besonders Spannend finde ich da die Nachlese von Markus Hansen der sehr schön die Fakten zu Körperlicher Gewalt auf den Tisch legt.

Sehr Lesenswert.

ist auch meine Sache.

Und die von Gerhart Baum. Der immerhin ein Innenminister war der tatsächlich Gesetze für Bürgerrechte gemacht hat.

Ahoi!