Anmerkung: Der Text entstand vor PMVs Beitrag, bin aber noch nich zum abschicken gekommen.
Aus meiner Sicht wären sowohl Modules als auch etwas erweiterte OOP-Ansätze richtig.
Ich hoffe ja auch immernoch, dass endlich mal mehrzeiliger Code eingeführt wird (nicht als default, sondern z.B. per "_" am Zeilenende).
Ich glaube aber, dass die Frage nach Modules und OOP zunehmend auch auf erweitertes Interesse am Produkt PureBasic deutet.
PureBasic ist immernoch ein Nischenprodukt, aber der vermehrte Einsatz in Unternehmen ist klar zu erkennen.
Dazu muss man nur mal im Forum umschauen, das ist in den letzten Jahren IMHO viel mehr geworden.
Da ist jetzt die Frage, ob die Anwender das überhaupt wollen.
Schließlich muss man ja bei Programmierern unterscheiden:
Die Teilzeit-Hobby-Programmierer im solocoding
Ich gebe den Leuten recht, die sagen, dass sie PureBasic lieben, weil es so ne schön kompakte Sprache ist, mit der man sich sehr
schnell mal ein kleines Tool oder ein Spiel als Wochenendprojekt zusammenschreiben kann. Ich liebe es auch, dass PB "reiner" Quelltext ist, nicht wie bei Delphi oder VB, wo man erstmal einen Überladenen Visual-Designer hat, den man extra austricksen muss, um sich die Event-Schleife frei zu gestalten. Wenn dann Projekte nicht als QuelltextDateien, sondern als XML-Dateien oder am besten noch als irgendwelche Binärkonstrukte vorliegen, geht das IMHO garnich klar.
Die Vollzeit-Opensource-bzw.-Berufsprogrammierer
Hier muss man beachten, dass nicht einer am Programm arbeitet, sondern viele. Und dass es auch sein kann, dass ein völlig unbedarfter das Projekt vielleicht mal übernimmt. An dieser Stelle muss dann auch etwas mehr Ordnung mit ein bisschen mehr "BigBrother" dabei eingesetzt werden. Ich denke nicht, dass PureBasic sich diesem Finanzstarken Anwenderbereich fern halten sollte, da können wir alle nur von profitieren. Oder hätte einer von euch ein Problem damit, wenn der Chef sagt "Das nächste Großprojekt wird in PureBasic umgesetzt"? (Vorrausgesetzt natürlich, Code- und Projektmanagement passen)
Module: Der Compiler von PureBasic ist sau schnell, die Frage ist, ob ein modularer Compilierungsprozess ihn zu sehr bremsen würde. Unumstritten ist aus meiner Sicht aber der Vorteil interner Variablen und Funktionen mittels Public und Private. Zum Einen wird es so einfacher, fremden Quelltext ein zu binden, ohne Wechselwirkungen zu erzeugen. Mal im Ernst, wenn ihr ein Include einbindet und die Fehlermeldung "Structure Punkt is already declared" kriegt und dann seht "AHA, Member sind x und y, hab ich bei meiner auch", achtet ihr dann darauf, welchen Typen die haben und ob ihr die Structure ohne weiteres ersetzen könnt? Das ist jetzt nur mal ein Beispiel, welche Probleme es mit Includes geben kann. Und spart euch "ja, ich achte da immer drauf". Nobody is perfect.
Ein weiterer Vorteil ist, dass bei einer Übernahme des Projekts bzw. bei einer Einarbeitung als neuer Mitarbeiter schwerwiegende Fehler vermieden werden. Beispiel: Kommunikation über RS232 mit einer Steuereinheit für Hydraulikventile. Die Funktion "Baggerarm_Senken" sollte Private sein und nur innerhalb von "Baggerarm_Senken_Falls_OK" aufgerufen werden. Ein Neuer würde wohlmöglich "Baggerarm_Senken" aufrufen und dann den Porsche vom Chef nicht beachten, den der Umgebungssensor erfasst und in "...Falls_OK" gemeldet hätte.
(Merkt man, dass Ich grad an Mobilhydraulik arbeite?
)
OOP: Ich finde es absolut überflüssig, alles in OOP zu packen. Es gibt aber aus meiner Sicht durchaus Stellen, an denen es Sinnvoll ist. Beispiel wären hier fliegende Raketen in einem SpaceShooter. Viele einzelne Elemente, die eigene Eigenschaften haben.
Aus meiner Sicht sollte man vor allem "SELF" noch einführen und zumindest ein offizielles HowTo zur Verwendung von Interfaces herrausgeben. (Wenn es so ein
offizielles HowTo schon gibt, verbessert mich bitte.)
Zu den ganzen PreCompilern: Ich finde es toll, dass sich Leute daran setzen, so etwas zu schreiben. Ein Hobbyprogrammierer wird auch sicherlich seine Projekte darin schreiben können. Einige PreCompiler sind OpenSource, sodass man, wenn der Programmierer es denn leid ist selbst daran weiter entwickeln kann. Hobby halt.
Im professionellen (wirtschaftlichen) Bereich sieht es da aber IMHO schon anders aus. Erstens baut man mit dem PreCompiler eine weitere Fehlerquelle ein, zweitens sind es Hobbyprojekte, bei denen man keinen direkten Ansprechpartner hat, drittens wird eine Firma
sich nicht auf die Idee einlassen, den PreCompiler selbst weiter zu führen, falls die Entwicklung eingestellt wird.
Wichtig wäre IMHO auch, das Projektmanagement weiter zu entwickeln, ohne rein auf Projekte zu setzen. Aber Dinge wie Versionsverwaltung sollten angeboten werden. Freaks Ansatz, eine DLL-Schnittstelle für die GUI zu entwickeln ist super, wichtig für Zusatzfunktionen ist aber aus meiner Sicht auch, dass nicht jede Zusatzfunktion ein eigenes Fenster braucht, sondern dass man es in einem oder maximal 2 Fenstern erschlagen kann.
Wenn dann noch die Revolutionäre Idee kommt, wie man den Quelltext richtig kommentiert (Mein Vorschlag wäre eine Autovervollständigung nach ";": "GRUND: ,Autor: , Datum:, Beschreibung:(Als Nutzung für Variablen und Funktionen),ACHTUNG: ). Wohlgemerkt, nicht ganz ernst gemeint.
Aber es gibt doch nix schlimmeres als "GUI_Aufbauen();Baut die GUI auf".
Achja, und wenn ich eine Art von FeatureRequests nicht mehr sehen kann ist das sowas wie "mehr Mathefunktionen" oder "DesktopCaretX() and DesktopCaretY()". Aus meiner Sicht sollte man Fred nicht damit aufhalten, dass ER für uns Funktionen schreibt. Ich denke, das wichtigste ist, dass er die Sprache an Stellen erweitert, die wir nur schwerlich bis garnicht selbst bewerkstelligen können und die Auswirkungen auf das Aussehen des Quelltextes haben.
So, my 2€s
Mfg Franky
