Jan, when I asked a guy a few days later for options to develop under OS X, he told me that his operating system may be OS X, but for development purposes he has an array of Ubuntu VMs. For realtime audio and video synthesis, however, that is not an option.

Auch: Ich fand bisher fast jedes von mir benutzte Betriebssystem (MS-DOS, Windows 3.11, Windows 98, Windows XP, Slackware, Suse, Ubuntu, Debian GNU/Linux, OSX) irgendwie hakelig in der Grundausstattung. Sobald etwas vollumfänglich einrichten konnte, ging es dann – aber das ging und geht eben nicht mit allen Systemen zufriedenstellend; wird wohl so ein hackerige[s] Ding sein.

Nix App Store, nix Lion. Ansonsten habe ich mit OS X ähnlich viel Ärger wie mit GNU/Linux und Windows, aber auf anderen Ebenen. OS X kann ich wenigstens meistens produktiv nutzen und es wird nur hakelig, wenn ich hackerige Dinge tun will. Linux war die ganze Zeit hakelig (und die Apologeten mögen mich gepflegt Götz von Berlichingen). Windows war entweder stabil und produktiv oder horrend kapott.

Mit XCode 4 hat Apple das ganze in den App Store verlegt, den es für Snow Leopard und Lion gibt … für eine kurze Zeit sogar tatsächlich kostenpflichtig, für Snow Leopard ist das möglicherweise immer noch so. Für Lion ist XCode wieder kostenlos.

In meinem Kopf spukt rum, dass ich auf GitHub auch mal ein Repo gesehen habe, wo jemand einfach die von Apple veröffentlichten Quellen genommen und daraus eine Toolchain gebastelt hat, aber finde das grade nicht. Mist.

Und warum muss ich “Franz” groß schreiben? Das ist doch doof.

Ja, weil ich bzpw. an 3 verschiedene Dinge gleichzeitig denken muss um die 205 zu erklären. Weil die Python-Standardlibrary bzw. schon ihr String-Teil zu komplex ist um ihn auswendig zu können. Weil es zwei separat zu evaluierende Bedingungen an eine Zeile sind statt einer Beschreibung der Zeile.

Auch: manchmal ist the simplest thing eben kein Python-Skript bzw. gar kein Programm, sondern ein sed-Einzeiler.

Das Laufzeitverhalten hängt von der Implementation von .startswith und len() einerseits bzw. der Regex-Engine andererseits ab.

Was Franz Beckenbauer angeht: Klar ist oft genug eine Zukunft denkbar, in der die gleiche Lösung in der selben Domäne weitgehend wertlos ist. Aber Versagen ist bei Filtern dieser Art billig – einen Kommentar fälschlicherweise zuzulassen ist weder sicherheitskritisch noch besitzt es großes Stör-Potential. Beides ist bei Email-Validierung oder URL-Parsen anders: Da werden im Zweifelsfall nämlich nützliche Informationen verworfen.

Wenn eine ähnlich simple Antispam-Lösung für die ehemals populäre Riesenmaschine ausreicht, brauche ich mir übrigens garantiert keine Gedanken über mittelgroße Plattformen zu machen.

Und die simpelste Lösung, die grade noch so funktioniert ist halt auch nur eine Lösung, solange sie funktioniert. Franz Beckenbauer funktioniert u.a. deswegen so gut, weil es als Spamfilterlösung nicht weit genug verbreitet ist um es per Spambot zu lösen – für jede mittelgroße Plattform reicht das schlicht nicht, weil jede endliche Menge von Lösungen früher oder später in die plattformspezifischen Bots einprogrammiert wird; sollte sich das webweit durchsetzen würde die KI-Forschung auf einmal einen großen Schritt nach vorne machen (AFAIK hat das die Texterkennung aus dem gleichen Grund schon getan).

Sowohl du als auch ich müssen eine Weile überlegen, um ein mentales Modell der Funktionsweise von Regexes zu erstellen – das oft genug auf subtile Weise falsch ist. So ist mein URL-Regex sensitiv gegenüber der locale.