Autor: Jens-Arne Reumschüssel (---.dip0.t-ipconnect.de)
Datum: 04.05.21 23:56
Ja, die Gemeinde ist rapide kleiner geworden. Das ist extrem schade. Natürlich ist es unter diesen Umständen klar, dass XProfan wohl nicht mehr weiterentwickelt wird. Gleichwohl verstehe ich diese Entwicklung unter den Nutzern nicht so ganz, denn trotz aller Einschränkungen, wenn man sie denn so nennen möchte, gibt es keine Sprache, die ich kenne, die mit so einfachen Mitteln so eindrucksvolle Ergebnisse erzeugt. Die "Einschränkungen", die ich oben meinte, sind im Wesentlichen der Umstand, dass XProfan keinen nativen Code erzeugt, und vielleicht noch, dass der Code nicht 64bit-fähig ist. Trotzdem frage ich mich, warum es so weit gekommen ist.
Warum hat "Profan in die Schulen" nicht eingeschlagen? Dabei wäre XProfan auch heute noch die perfekte Programmiersprache, um junge Menschen an das Thema heranzuführen. Das müsste in einem Alter ansetzen, in dem noch nicht das Smartphone jegliches Interesse an eigener Kreativität erstickt hat. Es ist mir unklar, warum das von den Verantwortlichen in Politik und Bildung nicht aufgegriffen wurde/wird.
Das Problem des nicht-nativen Codes lässt sich leicht umgehen, indem man all das, was wirklich schnell sein muss (und das ist meistens fast überhaupt nichts!) entweder über XProfan-Inline-Assembler, Profan2Cpp, nProcs (XPSE) oder notfalls eine andere Sprache realisiert, die native DLLs erzeugt. Mich überzeugt daher das Lamento nicht, dass es zwangsläufig der Tod einer so eleganten und einfachen Sprache wie XProfan sein muss, dass sie interpretiert ist.
Aber eines ist wohl auch klar: XProfan ist mehr oder weniger ausgereizt. Man kann damit alles machen, was damit irgendwie möglich ist. Große Erweiterungen lassen sich damit nicht mehr umsetzen, die man nicht sowieso durch API-Programmierung selbst hinbekommen kann. Die letzte extrem wichtige Erweiterung waren Hash-Arrays. Neben 64bit und nativem Code wüsste ich nicht, was man im derzeitigen XProfan-Universum noch hinzufügen müsste/könnte. Wenn es also eine Zukunft geben soll, die aus mehr als uns "Profan-Greisen" besteht, müsste man sich ernsthaft um die Frage kümmern, ob es nicht einen Weg geben könnte, nativen Code zu erzeugen. Aber wenn das so einfach wäre, hätte Roland es mit Sicherheit schon längst getan.
Ok, Entschuldigung, ist etwas länger geworden. Und ich bleibe bei Profan, solange es geht. Bei JRPC3 ging's nicht, weil es da bei jeder Zeile um Geschwindigkeit ging, aber das ist bisher das einzige Mal, dass ich wirklich abtrünnig geworden bin und den Kerncode in einer anderen Sprache geschrieben habe (PureBasic). Und da habe ich es bisher trotz intensiver Bemühungen nicht einmal hinbekommen, ToolTips für den Optionsdialog zum Laufen zu bekommen. Da stimmt wohl irgendwas mit meiner Window-Procedure oder mit meinem Messageloop noch nicht. Soviel dazu, wie einfach und elegant XProfan ist; um so einen Mist muss man sich da einfach nicht kümmern!
Beste Grüße, Jens-Arne
|
|