Python ist generell schwer in den Sprachfamilien einzuordnen. Dafür arbeitet einfach Python recht eigen und verfolgt schon recht außergewöhnliche Konzepte. Zudem vermischt die Sprache recht viel. Python ist eine Sprache, die versucht, sich aus allem das interessanteste herauszunehmen und in einer Sprache zu vereinen. Für absolute Anfänger ist Python daher eine coole und recht frische Sprache, wohingegen Coder aus der C-Familie es schwerer haben, sich mit Python anzufreunden. Coder aus der Urbasic-Ecke, wo damals noch viel mehr mit Keywords gearbeitet wurde, haben es deutlich leichter mit Python, als zum Beispiel Purebasic oder Visual Basic Coder, die mit den Urbasics nicht viel zu tun hatten. Gerade die Art, wie Keywords genutzt werden, kann ein wenig verwirrend sein. Aber Python schult auch einiges an Disziplin, da dort die korrekte Einrückung essentiell ist, da Codeblöcke nicht mit Kaywords oder Zeichen abgeschlossen werden.
Aber man muss leider sagen, das Python aktuell die beste Möglichkeit ist, für den Pi zu programmieren. Interpretersprachen eignen sich allgemein besser, solche Einplatinencomputer zu programmieren. Denn wenn sie richtig umgesetzt wurden, erwartet einem auf einem x86 System das gleiche Ergebnis, wie es auf einem Pi der Fall wäre. Dadurch kann man gemütlich auf dem PC programmieren und die Funktionalität testen. Auf dem Pi selbst muss das Testergebnis nur noch auf der Zielhardware validiert werden. Man ist dadurch nicht gezwungen, die Programme direkt auf der Zielhardware zu schreiben. Eine Webanwendung in PHP schreibe ich ja auch auf meinem PC und teste sie dort, bevor ich sie auf einen Server schmeiße, der irgendwo anders in DE oder Europa oder sonstwo steht.
Dem einen gefällt es vielleicht, auch auf der Zielplattform zu programmieren und zu testen. Aber wenn man nicht redundant mit Pi's eingedeckt ist, kann es nervig werden. Speicherkarte mit Raspian fertig machen, Peripherie anschließen, Purebasic IDE und Compiler installieren, dann auf dem Ding programmieren, debuggen, kompilieren und testen. Dann die Produktivumgebung aufsetzen, Speicherkarten tauschen, eigene Anwendung installieren usw usw. Und wenn man dann das ganze noch mit einer zweiten eigenen Anwendung erweitern will und das "Produktivsystem" komplett ohne UI arbeitet oder der Pi ohne Peripherie dahinwerkelt, stellt sich dann die Frage: Zweiten Pi zum programmieren kaufen oder Datensicherung der Speicherkarte machen und den ganzen Spaß dann von vorne?
Wenn man mit den GPIO-Block arbeiten will, kommt man natürlich nicht um das programmieren auf dem Pi selbst herum. Aber es ist etwas anderes, wenn man dafür Server oder Anwenderprogramme schreiben will. Dann halte ich es für angenehmer, die Programme auf dem PC zu schreiben und auf dem Pi nur in der Zielumgebung zum Abschluss durchzutesten, als am Ende gezwungen zu sein, alles auf dem Pi zu machen. Für mich müsste also PB ARM für Pi auch den Compiler samt der Libraries ohne IDE auf dem Pi installierbar sein und sollte bis zu einem gewissen grad kompatibel mit den PB- Libraries sein (auf die 3D Engine könnte ich selbst z.B. komplett verzichten). Das würde dann auch die Wahrscheinlichkeit reduzieren, das meine Anwendung auf dem Pi nicht läuft, obwohl sie auf dem PC korrekt arbeitet. Eine andere Möglichkeit wäre es, wenn sich für den Pi auch auf dem PC kompilieren lassen würde. Dann kann ich mir das kompilieren per Remote über z.B. Putty komplett sparen und kann die Anwendung auf dem Zielsystem direkt testen.
Ich vermute aber eher, das es wieder ein einheitliches Komplettpaket wie für alle anderen Plattformen wird. Das bedeutet ich brauch einen zweiten Pi, eine weitere Eingabegarnitur und muss es als zweitgerät an meinen Monitoranschließen. Und aus Platzgründen darf ich dann immer wieder Tastatur und Maus abbauen, wenn ich den PC nutzen möchte. Na da freue ich mich ja schon riesig drauf
Das Ding fährt auf jeden Fall innerhalb weniger Sekunden hoch, MySQL-Server läuft, PHP-FPM-Framework läuft, Webseite kann abgerufen werden. Super gut.