PureBoard

Diese Webseite habe ich besucht -->

https://www.amazon.de/PureBasic-Profess ... =purebasic

Dort hat ein User namens Franky666 am 31.01.2018 eine Beurteilung von PureBasic abgeliefert.

Stimmen die Aussagen dieses Users ?

Der schreibt da so viele negative Dinge über PureBasic, dass man den Eindruck gewinnt, die Programmiersprache PureBasic sei ein verbuggter Alptraum.

1. Keine objektorientierte Programmierung möglich

Nichtig, da man beim Kauf dieser Programmiersprache eigentlich weiß oder wissen muss, dass es eine prozedurale Programmiersprache ist. Das ist so wie, wenn ich einen Kleinwagen kaufe und dann feststelle, dass ich damit keine Möbel transportieren kann. Diese Information hätte man auch vorher nachlesen können.

2. Viele Bugs in den mitgelieferten Bbliotheken, die viele Workarounds benötigen

Unter Windows kann ich das nicht bestätigen. Ich finde da kaum Bugs. Das kann unter Linux aber auch anders sein.

3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres System, um Zeigervariablen für Fenster usw. zu verwalten. Wenn man zum Beispiel mit Hilfe der mitgelieferten Bibliotheken ein Fenster erstellt, erhält man nicht die übliche Zeigervariable ("hwnd"), sondern eine ID, mit der nur PureBasic etwas anzufangen weiß. Dies eschwert die sprachübergreifende Verwendung erheblich (So kann z.B. ein Fenster, welches von einer eingebundenen Bibliothek aus erstellt und dessen Zeiger an das eigene PureBasic-Programm zwecks Weiterverarbeitung übergeben wird, nur umständlich oder gar nicht über die Funktionen der mitgelieferten Bibliotheken angesprochen werden, da dieses Fenster ja nicht im internen System von PureBasic eingebunden ist und der Befehl fehlt, um dieses nachholen zu können.)

Es gibt eigentlich in PB und WinAPI viele Möglichkeiten, die richtige ID zu ermitteln. Bei meinen Anwendungen konnte ich bis jetzt fast jedes Gadget modifzieren, wie ich das gerne hätte.

4. Die Bibliotheken sind vom Funktionsumfang stark eingeschränkt, so dass man mit direkten API-Zugriffen ergänzen muss, was die Portabilität gänzlich kaputt macht. Mit nur einmal programmieren und dann auf Windows und Linux kompilieren zu können, ist spätestens hier endgültig vorbei.

Das stimmt. Rein plattformunabhängig wird es teilweise sehr schwierig, da man mit der jeweiligen API-Schnittstelle des Betriebssystems viel mehr Möglichkeiten hat. Aber es gibt bereits in Foren viele API-Lösungen für alle Betriebssysteme. Dann ist es auch plattformunabhängig.

Bezüglich der anderen Punkte kann ich nichts sagen.
Am besten ist es, die Demo selber auszuprobieren und selber entscheiden, ob PB gut genug ist oder ob eine andere Sprache besser geeignet ist.

@RSBasic

Recht herzlichen Dank für deine Antwort !

HachHerrje!

Hier stand vorher ein Text, der so ziemlich mit dem von RSBasic übereinstimmte (sogar das Beispiel mit dem Auto hatte ich verwendet)

Grüße ... Peter

Ich habe mir einfach mal den Spaß gemacht und bin Punkt für Punkt durchgegangen:

• 1. Um eine Unsigned-Word-Variable zu erhalten, muss man eine Variable vom Typ Unicode-Character "missbrauchen" und Unsigned-Long-Variablen sind nur durch umständliche Tricksereien vorhanden

  Das ist richtig und wird bereits im englischen Forum diskutiert.

• 2. Konsolen-Anwendungen für Linux sind nur bedingt POSIX-tauglich hinzubekommen. Das fängt bereits damit an, dass das Darstellen farbiger Texte sehr fehlerhaft (und damit gänzlich unbrauchbar) ist.

  Kann ich nicht beurteilen.

• 3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres System, um Zeigervariablen für Fenster usw. zu verwalten. Wenn man zum Beispiel mit Hilfe der mitgelieferten Bibliotheken ein Fenster erstellt, erhält man nicht die übliche Zeigervariable ("hwnd"), sondern eine ID, mit der nur PureBasic etwas anzufangen weiß. Dies eschwert die sprachübergreifende Verwendung erheblich (So kann z.B. ein Fenster, welches von einer eingebundenen Bibliothek aus erstellt und dessen Zeiger an das eigene PureBasic-Programm zwecks Weiterverarbeitung übergeben wird, nur umständlich oder gar nicht über die Funktionen der mitgelieferten Bibliotheken angesprochen werden, da dieses Fenster ja nicht im internen System von PureBasic eingebunden ist und der Befehl fehlt, um dieses nachholen zu können.)

  Sinnfrei finde ich das nicht, denn der hier angesprochene ("hwnd") ist ja in Windows, und wird in Linux ggf. völlig anders behandelt.

• 4. Die Bibliotheken sind vom Funktionsumfang stark eingeschränkt, so dass man mit direkten API-Zugriffen ergänzen muss, was die Portabilität gänzlich kaputt macht. Mit nur einmal programmieren und dann auf Windows und Linux kompilieren zu können, ist spätestens hier endgültig vorbei.

  Da er "die Bibliotheken" nicht spezifiziert, ist die Aussage wertlos!

• 5. Arrays sind nur schwer nutzbar. Unter anderem fehlt hier die Möglichkeit, ein Array mit vorgegebenen Werten zu initialisieren, wie es in den meisten Programmiersprachen mit einem "meinArray[4] = [1,2,3,4]" möglich ist. Man muss zuerst das Array erstellen und nachträglich mittels FOR-Schleife befüllen.

  Das die Möglichkeit fehlt, ein Array mit (eigenen) Werte zu initiallisieren stimmt. Aber sind sie deswegen "schwer nutzbar"?

• 6. UTF-8 wird unter Linux teilweise fehlerhaft verarbeitet (auch wenn man explizit angibt, dass diese Zeichenkodierung anzuwenden ist) - Ein No-Go

  Wie oben, kann ich nicht beurteilen

• 7. Die Bibliothek zum Wiedergeben von Sound spielt mache WAV-Dateien einfach nicht ab, obwohl die enthaltenen Audiodaten in einem Format vorliegen, das laut Dokumentation unterstützt wird.

  Ich kann dazu keine Bug-Reports im Forum finden.

• 8. Schlechte Unterstützung von gängigen Multimediaformaten, dafür jedoch beste Unterstützung für exotische FastTracker-Uraltformate, die schon lange niemand mehr verwendet.

  Um was gehts hier?

• 9. In den Sprite-Bibliotheken, die für 2D-Spiele gedacht sind, wird z.B. die Transparenz auf manchen Systemen ignoriert. Solche Fehler macht es komplett Unbrauchbar, da außer Verzicht auf diese Bibliotheken keinerlei Chance besteht, dieses Problem zu umgehen.

  Wie oben, Ich kann dazu keine Bug-Reports im Forum finden.

• 10. Manche GetXXXX()-Befehle neigen dazu, sporadisch völligen Unsinn zurückzugeben, was die Fehleranfälligkeit erhöht (z.B. ein negativer Wert für die Spieldauer einer Musikdatei oder eine völlig falsche Mausposition)

  Wie oben, Ich kann dazu keine Bug-Reports im Forum finden.

• 11. Mache Befehle erwirken gar nichts. Wenn man z.B. die Hintergrundfarbe eines Fensters mittels SetWindowColor() festlegt, ändert sich die Farbe einfach nicht.

  Wie oben, Ich kann dazu keine Bug-Reports im Forum finden.

@Kiffi & Stargate

Vielen Dank für eure Antworten !

STARGÅTE hat geschrieben:

• 1. Um eine Unsigned-Word-Variable zu erhalten, muss man eine Variable vom Typ Unicode-Character "missbrauchen" und Unsigned-Long-Variablen sind nur durch umständliche Tricksereien vorhanden

  Das ist richtig und wird bereits im englischen Forum diskutiert.

Dieser Umstand ist im englischen Forum hier ausgiebig diskutiert worden. Über den Namen des Variablentyps ".u" (Unicode character) kann man in der Tat verschiedener Meinung sein, aber von "missbrauchen" kann keine Rede sein. Jeder kann - wie in dem Thread demonstriert - über ein Makro .u in z.B. .ub (für unsigned byte) umbenennen. Das Problem mit den fehlenden Unsigned Long Variablen ist in der Tat vorhanden und wird in dem verlinkten Thread ebenfalls diskutiert. Als Grund werden Performance-Einbußen genannt.

3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres System, um Zeigervariablen für Fenster usw. zu verwalten.

Diese Kritik kann ich nicht nachvollziehen. Man kann für jedes Fenster mit WindowID() und Gadget mit GadgetID() das jeweilige Handle (und dies plattform-unabhängig) ermitteln. Teilweise auch die Handles z.B. von Gadget-Untereinträgen, wie z.B. GadgetItemID() beim TreeGadget.

Einige andere Kritikpunkte beziehen sich wohl auf die Linux-Version. Ein "Franky666" ist im englischen Forum mit "Location: Germany" seit Januar 2008 registriert und hat dort bis heute 16 Beiträge verfasst: eine Linux Bug-Meldung, drei Beiträge im Linux-Unterforum und einige wenige weitere Beiträge.

Die Probleme mit der Linux-Version von PureBasic sind leider nicht ganz von der Hand zu weisen und haben ihren Ursprung in der Umstellung von GTK2 auf GTK3. Die meisten noch nicht behobenen Linux-Probleme lassen sich lösen, indem man weiterhin GTK2 verwendet (in den Compiler-Optionen hinter "Library Subsystem:" gtk2 eintragen). Das eigentliche Problem liegt auch nicht bei PureBasic, sondern bei GTK3. Einen interessanten Einblick über die Probleme mit GTK3 gibt Fred in diesem Blog-Eintrag. Ausserdem hat freak im Oktober 2017 in seinem Urlaub eine ganze Reihe von GTK3-Problemen beseitigt. Da dies oft nur häßliche Hacks sind, die bei neuen GTK3-Versionen erneut Probleme verursachen könnten, hat freak für PB 5.70 ein neues Subsystem "qt" entwickelt, das das Qt-Framework statt GTK+ unter PureBasic verwendet und das in Zukunft zum voreingestellten Standard-Framework in PureBasic werden soll.

Mein Hauptkritikpunkt an der Amazon-Bewertung von "Franky666" liegt darin, dass er überhaupt nicht differenziert und alles in einen Topf wirft. Er macht nirgendwo klar, dass sich seine Kritikpunkte teilweise nur auf die Linux-Version (und dort nur auf Probleme mit GTK3) beziehen.

@Shardik

Vielen Dank für deine Antwort !

Einfach selber testen es ist ja nicht so das es keine Demo gibt.

Hallo Vampirmonster,

diese Beurteilung ist ja schrecklich.

So eine Beurteilung würde ich für jede andere Programmiersprache sicherlich noch viel schlimmer hinbekommen.

Hier werden einzelne Dinge herausgepickt und werfen im Gesamtbild ein schlechtes Licht auf "PureBasic".


1. Keine objektorientierte Programmierung möglich.

Wird wohl auch in den nächsten 10, 20, ... Jahren so bleiben.
Das macht die Programmiersprache nicht schlechter.

2. Viele Bugs in den mitgelieferten Bibliotheken, die viele Workarounds benötigen.

Finde bitte eine andere Programmiersprache die auf keinem Framework basiert und diesen Funktionsumfang im Kern mitbringt.
(Im Vergleich mit anderen Basicdialekten hat PureBasic im Verhältnis der mitgelieferten Befehle recht wenig Bugs.)

3. Die Bibliotheken verwenden teilweise ein (sinnfreies) proprietäres System, um Zeigervariablen für Fenster usw. zu verwalten. Wenn man zum Beispiel mit Hilfe der mitgelieferten Bibliotheken ein Fenster erstellt, erhält man nicht die übliche Zeigervariable ("hwnd"), sondern eine ID, mit der nur PureBasic etwas anzufangen weiß. Dies eschwert die sprachübergreifende Verwendung erheblich (So kann z.B. ein Fenster, welches von einer eingebundenen Bibliothek aus erstellt und dessen Zeiger an das eigene PureBasic-Programm zwecks Weiterverarbeitung übergeben wird, nur umständlich oder gar nicht über die Funktionen der mitgelieferten Bibliotheken angesprochen werden, da dieses Fenster ja nicht im internen System von PureBasic eingebunden ist und der Befehl fehlt, um dieses nachholen zu können.)

Sinnfrei ?
PureBasic ist sehr gut durchdacht.
PureBasic bietet eine gute API Unterstützung.

4. Die Bibliotheken sind vom Funktionsumfang stark eingeschränkt, so dass man mit direkten API-Zugriffen ergänzen muss, was die Portabilität gänzlich kaputt macht. Mit nur einmal programmieren und dann auf Windows und Linux kompilieren zu können, ist spätestens hier endgültig vorbei.

Dieser Punkt ist Blödsinn.
Finde eine Programmiersprache ohne festes Framework (.Net, JAVA,,...) mit direktem API-Zugriff und so vielen guten integrierten Bibliotheken (Funktionen).
C, C++, Python, etc. haben im Kern alle nur sehr wenig Standard-Bibliotheken.

Noch ein wichtiger Plus-Punkt für PureBasic wäre die sehr nette und aktive Community.

(Anbei: Punkt 1 würde die Grundfesten erschüttern, aber die Einbindung von C++ erleichtern. )