Die Stärken von PureBasic kann man definitiv nicht mit nur einer Hand abzählen. Aber das fehlende C-Backend ist keine davon, war nie eine davon und wird auch nie eine davon sein. Man könnte es sogar eher als eine der Schwächen bezeichnen. Denn im Gegensatz zu einem guten C-Compiler fehlt es einem Assembler an vielen Optimierungsmöglichkeiten, die bei PureBasic über den PB-Transpiler geregelt werden müssen. Denn das Programmieren mit einem Assembler ist in der Regel viel viel Kleinschrittiger und macht dadurch Optimierungen seitens des Assemblers einfach unfassbar komplex. Bei C hingegen liefern die Compiler schon erheblichste Optimierungen mit, da der zu Grunde liegende Code einfach weniger Kleinschrittig und somit leichter zu optimieren ist.
Als Stärken für PureBasic zähle ich ganz klar:
1. Klare einfache Syntax mit einer optischen strikten Trennung. Zum Beispiel der Unterschied zwischen einer Variable und einer Konstante.Blöcke haben einen beschreibenden Anfang und ein beschreibendes Ende (naja BASIC-Typisch eben) usw.
2. Ein strikter Sprachgebrauch in der Dokumentation und eine klare Benennung von Sprachfeatures. Ein gutes Beispiel dafür sind Keywords. In PureBasic sind Keywords genau das, was Keywords auch sein sollen. Schlüsselwörter, die dem Compiler sagen, wie das Programm zu erzeugen und wie mit Variablen und anderen Konstrukten umzugehen ist. In vielen vielen anderen Sprachen hingegen wird der Begriff Keyword auch für "Build-In Functions" verwendet, die Programmfunktionalität zur Verfügung stellen. Keywords sollten aber keine Programmfunktionalität liefern. Sie sollen nur den Ablauf und die Beziehungen innerhalb des Codes beschreiben. Aber in PureBasic ist alles, was Programmfunktionalität liefert in Bibliotheken und darunter in Prozeduren klar ausgewiesen. Das macht die Arbeit damit sooooo viel leichter.
3. In der Doku werden die Bibliotheken klar nach ihrem Einsatzzweck benannt. Bei der fragmentierten Programmierung, wie das in anderen modernen Umgebungen der Fall ist, gestaltet sich die Suche nach geeigneten Bibliotheken zeitraubend, da diese nur selten nach ihrem Einsatzzweck sauber gelistet sind und sich zudem alles hinter ihren Fancy Namen versteckt. Python sei hier einmal als Beispiel genannt. Man hört davon, das man mit Python das Qt Framework nutzen kann und sucht nach Modulen. Wie zur Hölle soll man bei dem Namen PySide darauf kommen, das sich dahinter die eigentlich beste Qt-Implementierung für Python versteckt? Oder wie soll man eine vernünftige Datenbankbibliothek ohne ORM für z.B. MariaDB/MySQL finden, wenn alle nur von SQLAlchemy reden, welches aber ORM und eine Unterstützung für fast alle DBMS Systeme mitliefert? Bei PureBasic weiß ich, wo ich suchen muss.
4. Die Bibliotheken selbst. Ich finde hätten die Herschafften nicht so viel Zeit mit Spiderbasic verplämpert, hätten wir hier jetzt viel mehr haben können. Aber auch so ist der Bibliotheksumfang schon ganz ordentlich. Bei PureBasic wirken die Bibliotheken auch so, als würden diese klar zur Sprache gehören und verfolgen nach Möglichkeit einen Vergleichbaren Ansatz, wie diese zu nutzen sind. Dieses zusammenschustern aus externen Quellen, die unterschiedliche Güte von Dokumentationen, die teils deutlich abweichenden Nutzungswege machen in anderen Sprachen das Programmieren teils echt zur Folter. In Python oder Node (JS) heißt die Doku Google oder Stackoverflow und viele suchen sich nur noch Snippets raus und passen diese an, um an ihr Ziel zu kommen. Denn es gibt einfach keine wirklich zentrale Anlaufstelle für Wissen und jeder kocht da seine eigene Suppe.
Und es gibt da noch einige mehr Punkte. Aber es wird gerade doch sehr Offtopic.
Aber Apple hat mit dem M1 nun einmal gezeigt, wie Leistungsfähig und vor allem wie effizient diese ARM-Dinger arbeiten können. Dabei stehen die selbst ja noch am Anfang. Und auch der Raspberry Pi bietet viel Potenzial, Ist aber nun einmal nicht mit PureBasic kompatibel. Die Intel-Macs werden nun einmal jetzt nach und nach verschwinden und wenn PureBasic die Kompatibilität zu Max OSX on ARM nicht herstellen kann, würden sie früher oder später viele Nutzer einbüßen, da sich hier nun einmal auch viele Mac-Entwickler tummeln. Vor allem im englischen Forum. Zudem könnte das C-Backend später helfen, weitere externe Bibliotheken sauber einzubinden. Vielleicht fließen dadurch noch modernere und interessantere Bibliotheken in die Umgebung ein, die sich mit dem Assembler-Backend nur sehr mühselig oder garnicht einbinden ließen.
Und Windows für ARM wird genauso ein Reinfall wie Windows RT. Man versucht zwar, mit Hilfe von Virtualisierung die x86 Anwendungen zum laufen zu bekommen. Doch am Ende wird dies einfach daran scheitern, das für zeitkritische Anwendungen der Performanceverlust einfach nicht umgangen werden kann, die Leute im Zuge dessen darauf verzichten werden und weiterhin die x86 Variante nutzen. Und welcher Entwickler soll sich am Ende darauf einstellen? Da hat Apple eine bessere Position. Denn durch den Wegfall der Intel-Macs, wird es irgendwann keinen Grund geben, die Intel Macs weiterhin zu supporten und die Entwickler werden zwangsweise umsteigen. Das ist der Vorteil an einem geschlossenen Ökosystem, welches eher kleinere Planeten besiedelt, anstatt wie bei Windows ganze Galaxien einnimmt. Microsoft kann Windows x86 nicht einfach wegschmeißen. Die Abhängigkeiten von diesem System sind einfach immens und man würde sich am Ende selbst schlachten.
Aber ob der M1 am Ende auch für die Windows-Welt so gut ist? Adobe weiß, welche Zielgruppe überwiegt und wird dann ggf. rechnen, ob das parallele unterstützen von x86 noch lukrativ ist oder ob es sich für sie nicht doch lohnt, ARM den Vorzug zu geben. Und selbst wenn nicht. Arbeiten sie dann am Ende an beiden Architekturen gleichermaßen oder wird der x86 zur ungeliebten Stiefmutter? Steinberg? Abbleton? Native Instruments? Was werden die alle machen? Denn Windows für ARM muss sich erst einen ordentlichen Marktanteil erarbeiten, damit das Unterstützen der Plattform sich lohnt. Alle wollen die Henne sein. Aber aus welchem Ei soll die Henne schlüpfen?
Und vor allem. Warum drifte ich immer so hart ins Offtopic ab? Ich sollte mich echt mal schämen
Am Ende ist das C-Backend logische Konsequenz und auch wichtig, da die Technologien einfach nicht stehen bleiben und auch ein PureBasic zumindest ein wenig in diese Richtung gehen muss. Klar werden auch Browser immer wichtiger. Aber Spiderbasic war und ist da einfach der völlig falsche Ansatz. Die sollen das lieber ruhig sterben lassen und sich voll und ganz auf PureBasic konzentrieren. Dann wird es auch gut. Das andere da war meiner Meinung nach nie gut und wird auch nie gut werden.
