Candletalk

Das mit dem instabilen Betrieb 24/7-Windows-Betrieb stimmt definitiv nicht.

Ich kannte schon vor 16 Jahren mindestens ein bedeutendes Unternehmen in Deutschland, welches seine gesamte Existenz im unmittelbaren Realtime-Produktions-Bereich an Windows (damals NT 4.0) koppelte, die damals bei in ganz D benutzten Produkten einer der Markt-Führer waren mit mehreren Mio. Einzel-Aufträgen pro Tag. Das war so hoch angebunden, daß bei einem Absturz als dem absoluten Super-Sonder-Ausnahmefall vier !! Mann kamen, zwei fürs Vier-Augen-Prinzip, einer für deren Überwachung und noch ein Supervisor für die Zugangs-Kontrolle zum Rechen-Zentrum während dieser Wartung. Und die haben damals schon Realtime-Replikation über Speicher-Netzwerke gemacht mit 4-facher Datenhaltung (2-mal im Rechenzentrum, 1-mal im anderen Gebäude am Standort, 1-mal an einem Remote-Katastrophen-Ausweich-Standort.

Ansonsten ist Windows auch im SAP-Bereich (wovon der gesamte Unternehmens-Prozeß abhängen kann) durchaus eine gängige Plattform, wo ich sogar Installationen kenne, die jeden Tastatur-Anschlag remote auf Server an anderen Standorten übertragen und eine jahrelange Top-Stabilität haben.

Da ist Windows bei professioneller Adminstration weit besser als sein Ruf, wobei ich anmerke, daß ich Unix-artige System lange vor Windows kannte und auch heute noch auf jeden Windows-Rechner zuerst mal Cygwin einspiele und darum nicht etwa ein Unix-Hasser bin. Bei meinen privat genutzten Rechnern ist das Verhältnis Win : Linux übrigens trotz immer mal wieder intensiven Nachdenkens über einen Umstieg 6 : 1, was insbesondere beim Betrieb virtualisierter Umgebungen und dem Erwerb nackter Hardware und Extra-Betriebs-System ökonomisch von den Anschaffungs-Kosten völlig daneben ist, aber wenn man 20 Jahre mit der Windows-Adminstration vertraut ist, sind die Gesamt-Aufwände für eine geordnete Adminstration von Linux doch höher als der letztliche Nutzen eines Umstieges.

Ich nehme sogar in Amazons Cloud meist aus Gewohnheit, selbst für Aufgaben, die mit Linux genauso gut gehen, die etwas teureren Windows-Instanzen, obwohl ich es mir da fallweise mit nur einem Klick aussuchen kann.

Hier noch zwei Posts von Krümel und mir aus dem Thread mit der ursprünglichen Anregung zu Sho zu den Pro's und Contra's zu Python.

Vielleicht könnten noch einige Insider, insbesondere systemtrader und Purri, was zu der Sinnfältigkeit der Beschäftigung mit Python sagen?

Es wäre im Sinne einer Aufwands-/Nutzen-Abschätzung nämlich schon schön, etwas zum prinzipiellen Interesse Dritter in diesem Forum an Python und evtl. nachnutzbaren Resultaten damit zu erfahren, denn daß mir Python zumindest soweit bekannt ist, daß ich es respektiere, wenn auch nicht über alle Maßen liebe, weiß ich auch ohne die Veröffentlichung in einem Trading-Forum, alleine darum, weil ich oft genug gezwungen bin, es durch Vorgaben von dritter Seite als zu Integrations-Zwecken heran zu ziehen.

In dem Sinne tendierten die Posts in diesem Thread eher zu Arbeit als zu neu erwachtem tiefstem Python-Enthusiamus.

Ein bisher noch Python-Outsider seiender Neu-User sollte sich durch solche Diskussionen übrigens nicht abschrecken lassen, er macht mit dem Erlernen dieser Sprache nichts falsch. Es geht eher um graduelle Geschmacks-Nuancen als um wirkliche Schwerst-Mängel.

Es ist zwar immer etwas abschreckend mehrere aufeinander aufbauende Software-Pakete ohne automatische Paket-Verwaltung einspielen zu müssen, aber aufbauend auf den funktionierenden Installations-Hinweisen auf der Sho-Hauptseite und den von dort verlinkten Seiten habe ich für die Arbeit mit Sho unter anderen denkbaren Konfigurationen die folgende Arbeits-Umgegung ausgewählt und ohne irgendwelche Probleme in der angegebenen Reihenfolge installiert und wider Erwarten auch sofort zum Laufen (mindestens die Demo mit dem Plot lief) gebracht:

1. Windows XP (weil der Rechner, den ich im Moment vor mir habe, das gerade hatte, nicht etwa weil es Probleme mit Windows 7 [liefere gerne später einen Erfahrungs-Bericht dazu nach] geben würde, obwohl XP gar nicht bei den Minimal-Voraussetzungen genannt wurde)
2. Microsoft .NET 4.0 (zwingende Voraussetzung für den Sho Installer, muß ggf. nachinstalliert werden, wenn nur frühere Versionen des .NET-Frameworks auf dem Rechner sind)
3. IronPython 2.7
4. Sho 2.0.5 for IronPython 2.7
5. MS Visual Studio Shell 2010 (Integrated) Ob es dabei zu irgendeiner Wechselweirkung mit anderen Visual Studio 2010 Paketen kommt, kann ich nicht sagen, da auf dem Recher nur Visual Studio 2008 installiert ist.
6. Python Tools for Visual Studio

Danach sollte man noch ggf. nötige Patches über die normale Windows-Update-Funktion nachinstallieren, die nicht in den Paketen enthalten sind.

Trotz der durch die Interpretation im Prinzip bedingten eher geringeren Geschwindigkeit wird Python auch öfter für numerische Aufgaben genutzt, weil diverse dazu nötige Module mit optimiertem Code direkt effizient auf die Ziel-Umgebung abbilden oder die Einbindung in Cluster (s. u.) ermöglichen, wenn man wirklich mal Heavy-Number-Crunching machen möchte.

Angenehm ist auch die stillschweigende Nutzung der Big-Integer-Arithmetic, ähnlich wie man sie z. B. auch aus LISP oder Scheme kennt.

Will man auch für weitere Aufgaben stärker optimierten Code schreiben, kann man zu Cython (cython.org) greifen. Allerdings sollte man stets beachten, daß auf heutiger Technik bei Standard-Aufgaben die Optimierungs-Ergebnisse kaum ins Gewicht fallen und bei wirklich langsamen Aufgaben eher an der Zeit-Komplexität der Algorithmen als an der Implementierung mit irgendwelchen Feinheiten im Programm-Code angesetzt werden sollte.

Ebenso bringt bei I/O-lastigen Aufgaben eine andere Software-Plattform sehr wenig, da muß man an der Hardware ändern, z. B. durch Einsatz von SSD, großen RAID-Verbünden (für sporadische Nutzung kaum ökonomisch sinnvoll) oder der Nutzung von Cloud-Clustern, die es z. B. bei Amazon EC2 beachtlichen Hardware-Ressourcen zu ziemlich guten Preisen (insbesondere bei nur kurz-zeitiger Nutzung), auf Wunsch auch zusammen mit Speicher-Netzwerken gibt.

Neben Amazon ist mit Microsofts Azure eine weitere große Cloud verfügbar, für die es auch speziell ausgerichtete Python-Module gibt.

Python wird in diversen alternativen Implementationen angeboten.

Die erste Implementation war CPython python.org, die auch die Referenz-Implementation ist. Auf der Seite kann man auch die Installer für Windows finden (wenn man denn diese Implementation benutzen will), unter unixoiden Betriebs-System sollte Python schon installiert sein.

Weiterhin ist Python ist unter vielen Betriebs-Systemen und verschiedenen Laufzeit-Umgebungen verfügbar. Je nach der Ziel-Umgebung kann sie weitergehend mit anderen dort verfügbaren Bausteinen verbunden werden, welches unter der CLR des Microsoft .NET-Frameworkes mit IronPython besonders gut gelungen ist. Für eine Nutzung in einer virtuellen Java-Maschine wurde Jython geschaffen.

Außerdem gibt es mit PyPy eine Implementation in Python selbst, so daß man für den Compiler-Bau Bootstrapping erlaubt, ohne die Programmier-Sprache zu wechseln. Für praktische Zwecke würde ich diese Implementation nicht präferieren.

Für eine vorgesehene Nutzung von Microsoft's Sho, der guten Einbindung in das .NET-Framework und der Visual Studio Shell mit den Python Tools for Visual Studio (vollständige Installations-Anweisung der gesamten Tool-Chain folgt in einem späteren Post) ist die Benutzung der .NET-Variante IronPython sie beste Wahl.

Da die Vielzahl der heute existierenden Programmier-Sprachen kaum überschaubar ist und die Fans einer jeden Unmengen positiver Argumente für gerade ihre Sprache finden, merke ich mal zusätzlich zu meinem "Totschläger"-Spruch "Alles wird anders, aber kaum etwas wird besser" an, daß schon 1986 in einem Klassiker der Software-Literatur von Brooks richtig festgestellt wurde, daß es keine Silber-Kugel (zum Töten des Werwolfes der Komplexität) gibt - und sich das bei allen immer wieder den Anschein überragender Neuigkeit erheischen wollender Technologien auch in den seitdem vergangenen 25 Jahren nicht grundlegend geändert hat. Manchmal ist die Diskussion um die "richtige" Technologie eingeschlossen die enthaltene(n) Programmier-Sprache(n) auch nur ein purer Glaubens-Krieg.

Solange mit dem Auftreten neuer Technologien nicht alte rückstandsfrei in die neuen eingearbeitet werden, verschärft sich das Problem durch die mitgeschleppten Altlasten und Sonder-Inseln eher noch, da in der Praxis ja nicht mal auf die Schnelle alle vorhandene Software zum Null-Tarif auf die neuen Technologien portiert werden kann. Besonders schlimm ist, daß gerade die am schlechtesten gemachten Software-Teile am längsten leben, da sie wegen ihrer Unverständlichkeit und des daraus folgenden Risikos bei Störungen am schwersten umzustellen sind.

Daher hängt beim üblichen (schlechten) Stand der Dokumentation der Entwicklungs-Grundlagen und der früher (und manchmal auch heute noch) sehr schlechten Qualität des Quell-Codes die Geschwindigkeit der Übertragung auf neue Technologien weniger von der neuen Technologie als vom Verständnis der Implementation in der alten Technologie ab, da das alternative völlig Neu-Implementieren (from scratch) oft schon aus Gründen der Verantwortlichkeit oder der Kapazitäten nicht opportun ist.

Der Wechsel zu einer anderen Programmier-Sprache nur aus Mode-Gründen ist ohne schwerwiegende Gründe wie deutlich funktionalerer Bibliotheken, einer vorgegebenen Arbeits-Umgebung durch die beschäftigende Institution oder die anderweitige Software-Umgebung oder verbesserter Stabilität, Interaktivität oder Skalierbarkeit nicht sinnvoll. Insbesondere werden durch den Wechsel von einer gewohnten Umgebung, deren Feinheiten man aus längerer Erfahrung genauestens bis ins kleinste Detail kennt, keinerlei schnelle Produktivitäts-Gewinne möglich, sondern vielmehr ist ein Monate dauernder schwerer Produktivitäts-Einbruch zu erwarten.

Unter ungünstigen Umständen kann diese Produktivitäts-Verminderung sowohl bei einzelnen Programmierern als auch bei größeren Teams zu starker Demotivation führen, wobei diese Umstände nicht wirklich objektiv sind, sondern auch stark von den subjektiven Vorlieben und Befindlichkeiten der Beteiligten abhängen. Spätestens wenn einzelne Team-Mitglieder ausscheiden und dann zu der Mehr-Belastung durch die Überleitung der Technologien noch weitere Mehr-Arbeit verursacht wird, ist die Gefahr des Scheiterns groß, schlimmstenfalls sogar mit Rückwirkungen auf das alte Produkt.

Das häufig angeführte Argument schnellerer Resultate mit Skript-Sprachen triff nicht zu bei der Nutzung von modernen Arbeits-Umgebungen mit inkrementeller Compilierung, wie z. B. Eclipse wo (besonders in der dort großartig unterstützten Java-Entwicklung) der Build-Prozess mit einer so minimalen Roundturn-Zeit belastet, daß man schnelle Laufzeit bei der Ausführung und blitz-schnelle System-Erstellung gemeinsam bekommen kann. Die oft als Vorteil genannte Möglichkeit auf die Deklaration von Variablen und ihren Typen verzichten zu können, ist gerade bei größeren Programmen eher ein schwerer Nachteil, der häufig zu schlecht entdeckbaren Fehlern oder Problemen führt und das Refactoring massiv erschwert.

Da es aber leider immer wieder mal eine neue Sau gibt, die bis zu ihrem (manchmal schon frühzeitigen) Tod durchs Dorf gehetzt wird, und in der offenen Community der Software-Leute für jede neue Sprache auch neue Enthusiasten gefunden werden, läßt sich bei Vorliegen interessanter Software, die darin implementiert wurde, LEIDER die Beschäftigung mit immer neuen Sprachen nur bedingt vermeiden.

Aus Produktivitäts-Sicht ist - bei allem Interesse an einfach nur anderen Dingen, wie es alle Kreativen in ihren Genen haben - die Aufsplitterung der Kompetenz und Leistungs-Kraft auf mehrere Tätigkeits-Bereiche eher abträglich, wenngleich es auch manchmal durch den Vergleich übergreifender konzeptioneller Unterschiede echte Aha-Erlebnisse gibt.

Mit Python landet man dabei wenigstens nicht auf einem völlig abstrusen technologischen Ast und mit IronPython kriegt man gleich die Vorteile des .NET-Frameworks mit, so daß man damit wenigstens leben kann.

Einfacher als Java, C oder C++ ist Python schon, gegenüber Javascript kann es allenfalls durch seine größere mtigelieferte Bibliothek punkten. Wer noch gar keine Programmier-Sprache kennt, macht mit Python aber kaum was falsch und er wird schnell gute Resultate erzielen und über die bessere Konsistenz als z. B. bei PHP erfreut sein.

Python ist eine mittlerweile auch schon 20 Jahre alte, über mehrere Sprach-Versionen gereifte, in den letzten Jahren deutlich zunehmende Verwendung findende objekt-orientierte Script-Sprache, die meist interpretiert wird. Neben der Stand-Alone-Nutzung für beliebige Allzweck-Programmier-Aufgaben wird Python auch in diversen Programmen zur Erweiterung des Funktions-Umfanges eingebettet und steht dort im Wettbewerb zu Sprachen wie Javascript, Visual Basic for Applications, Lua und weiteren. Der Name kommt übrigens nicht von der Schlange sondern von den Komikern Monty Python.

Ein besonders wichtiges Merkmal ist neben einfachem Sprach-Aufbau und einer übersichtlichen Strukturierung des Quelltextes, wo optische Einrückungen auch logische Bedeutung haben, die Philosophie "Batteries included", was auf die umfassende Standard-Bibliothek verweist.

Angeregt durch

• Purri's - wie immer lesenswerten - Beitrag zum auf Python basierenden Sho von Microsoft Research,
  
• die schon mal beiläufig im abgestorbenen Trade Statistik Sheet stattgefundene Erwähnung,
  
• die mehrmalige Erwähnung durch systemtrader, der zumindest nach der Board-Suche (1, 2, 3, 4) bisher offenbar der einzige hiesige (als solcher geoutete) Python-Verwender fürs Traden/Backtesten ist, und
  
• die mehrfache Erwähnung in verschiedenen Threads in ST's eigenem Board (1, 2, 3, 4)
  

möchte ich hiermit einen Thread zum Thema "Python für Trading- und Backtest-Aufgaben" starten, auch wenn ich, wie schon im Backtesting-Software-Thread erwähnt, kein großer Fan immer neuer Technologien um ihrer selbst willen bin, wobei ich hoffe, daß im Laufe dieses Threads die handfesten Vorteile der Nutzung von Python (so sie denn wirklich handfest sind) deutlicher Kontur annehmen.

Alle Python-Fans, solche die es werden wollen und sonstige ggf. auch nur minimal an der Benutzung von Python im Trading-Umfeld Interessierte, sind herzlich eingeladen.