möchte­gern­geek

Bisher habe ich immer nur kurze Fragmente in JavaScript geschrieben, die meist nur Gimmicks bezweckten oder Bibliotheken aufrufen. JavaScript ist im Moment möglicherweise die wichtigste Sprache: Schließlich ist sämtlicher clientseitiger Code des Webs JavaScript — und dank Node wohl auch nennenswerte Teile des Servercodes. Zumindest macht man nichts falsch, wenn man sich etwas mit JavaScript vertraut macht. Deshalb ist das neuste — und simpelste — Mitglied meiner Snake Sammlung [1, 2, 3, 4] in JavaScript gehalten.

Ausprobieren kann man es gleich hier:

In der Spielwelt herrschen helikale Randbedingungen, hauptsächlich weil es etwas anderes ist als gewöhnliche periodische Ränder. Außerdem hat es den Vorteil, dass man keinen Pause-Modus braucht, weil diese Randbedingungen dafür sorgen, dass die Schlange sich nicht beißt, wenn man sie einfach geradeaus laufen lässt.

Ich habe gehört, dass JavaScript sich in den letzten Jahren stark weiterentwickelt hat. Tatsächlich scheint mir diese Sprache einige interessante Sprachelemente erhalten zu haben, wie arrow functions x => x*x für lambdas oder den spread operator ... den ich am ehesten mit Pythons splat * vergleichen möchte. Ich will nicht behaupten, dass das folgende kartesische Produkt der beste Code oder leserlich wäre, aber interessant allemal:

let SIZE = 3;
let numbers = [...Array(SIZE).keys()];
let a = [].concat(
    ...numbers.map(
        x => numbers.map(
            y => [x, y]
        )
    )
);
console.log(a);

Anscheinend gibt es mit der nächsten geplanten Version (ES6) noch mehr nette Sprachelemente. Unter anderem Module. Ich bin geradezu sprachlos, dass man bisher keine Sprachunterstützung für die Verteilung des Quellcodes über mehrere Dateien hatte. Anscheinend bin ich noch zu sehr von den Konzepten der „C-artigen“ Sprachen beeinflusst.

Da jsnake nur ein paar Zeilen in einer Datei sind und sich ein ganzes GitHub Repository deshalb nicht lohnt, habe ich es in einen Gist hochgeladen.

In meinem letzten Einträgen ist bereits angeklungen, dass ich Rust mag. Und wie die Erfahrung [1, 2, 3] zeigt, dauert es nie lange bis ich eine Snake-Abwandlung programmiere.

Dieses Mal verfolgt der Autopilot die Strategie des smart kinetic walk, (ein Model aus der statistischen Physik zur Simulation von Polymeren,) um sich nicht selbst zu beißen — leider setzt diese Strategie ein unendlich großes Spielfeld voraus.

Die grundlegende Idee ist, dass die Schlange immer wenn sie sich selbst begegnet prüft welcher nächste Schritt sie in einer Schlaufe fängt und welcher nach außen führt. Mit offenen Randbedingungen, also auf einem unendlich großen Feld lässt sich dass das in konstanter Zeit erledigen, wenn die Schlange an jedem Segment ihres Körpers die Anzahl der Rechts- und Linksdrehungen speichert. Bei periodischen Randbedingungen funktioniert das allerdings nicht mehr, sodass der Autopilot eine Best-First-Search durchführt. Auf offenen Randbedingungen würde es ausreichen einen Weg vom potentiell nächstem Schritt zu einem beliebigen Punkt außerhalb eines Rechtecks, das die Schlange einschließt, zu finden. Bei periodischen Randbedingungen ist es nicht so eindeutig. Ich habe mich entschlossen, dass die Schlange sich nur so bewegen soll, dass immer ein Pfad zu ihrem Schwanz existiert. Tatsächlich führt diese Strategie zu unterhaltsamen und nicht perfekten Spielverläufen.

Der Vollständigkeit halber sind noch ein nicht vorausplanender und ein perfekter, aber langweiliger, Autopilot dabei.

Da die Quellen auf GitHub liegen, ist es nur vier Zeilen entfernt — weniger, wenn der Rustcompiler bereits installiert ist.

    # curl https://sh.rustup.rs -sSf | sh  # never copy `| sh` in your terminal
    git clone https://github.com/surt91/rsnake
    cd rsnake
    cargo run --release

Das Vicsek-Modell wurde 1995 vorgeschlagen, um das Schwarmverhalten von Vögeln oder Fischen zu modellieren. Die Idee ist, dass jedes Individuum seine Bewegungsrichtung an der seiner Nachbarn anpasst. Wenn jedes Individuum genügend Nachbarn hat und die Störeinflüsse nicht zu groß sind, bilden sich Schwärme. Videos von solchen Schwärmen werden auf allen größeren Konferenzen der Statistischen Physik gezeigt — und jetzt auch hier.

Auf GitHub findet sich das Programm, das ich für obiges Video geschrieben habe. Es ist in Rust geschrieben und zeigt die Simulation per Piston auf dem Bildschirm.

Ich habe sehr großen Gefallen an Rust gefunden — gerade für ein Projekt wie dieses scheint es ideal geeignet. Es ist so schnell wie C, aber man muss sich keinerlei Gedanken um den Speicher machen und einige andere Fehlerklassen, die der Compiler direkt verhindert. Rayon macht Parallelisierung so einfach wie OpenMP — mit dem Vorteil, dass der Compiler einen Fehler ausgibt, falls es eine Variable gibt, aus der parallel gelesen und geschrieben wird.

Als Beispiel, warum ich Rust als sehr leserlich und elegant empfinde, möchte ich folgendes (unvollständige) Beispiel ansehen.

pub enum Proximity {
    Neighbors(usize),
    Radius(f64)
}

pub struct Vicsek {
    proximity: Proximity,
}

impl Vicsek {
    fn update(bird: &mut Bird) {
        match self.proximity {
            Proximity::Neighbors(n) => self.update_direction_neighbors(bird, n, noise),
            Proximity::Radius(r) => self.update_direction_disk(bird, r, noise),
        }
    }
}

Die Methode update() passt die Richtung an, in die ihr Argument im nächsten Zeitschritt fliegen soll. In meiner Simulation gibt es zwei Möglichkeiten: entweder orientiert man sich an seinen n nächsten Nachbarn oder an allen Vögeln innerhalb eines Radius von r. Der Datentyp Proximity kann eines von beiden beinhalten — welches vorhanden ist, kann elegant per Pattern-Matching ermittelt werden.

Brauche ich länger, um Rust zu schreiben als C oder C++? Vermutlich, aber ich verbringe weniger Zeit mit dem Debuggen. Netto also mehr Spaß.