OOP in PureBasic die X.

[nco2k]

ich verstehe das geheule einfach nicht.

wir haben alle damals pb gekauft "so-wie-es-ist" und zwar als eine prozedurale programmiersprache. ich kauf mir auch kein auto, in der hoffnung dass ich irgendwann ein kostenloses "update" auf das feature xyz kriegen werde. dann suche ich mir doch von anfang an ein auto, welches das feature bereits hat, wenn ich es sooo sehr haben möchte.

so wie sich manch einer hier benimmt, könnte man meinen, dass die verpackung/homepage voll mit werbung bestückt war, "oop wird in zukunft verfügbar sein", was eben nicht der fall ist. es stand schon immer fest, dass kein oop kommen wird, also wo liegt das problem?

seit jahren kommen nun wunschäusserungen bzgl. oop und jedes mal gabs darauf die gleiche antwort. wie oft will man da noch so penetrant rummachen? irgendwann ist doch auch mal gut...

ps: ich bin grundsätzlich nicht gegen oop. ich bin nur nicht so arrogant, um die entscheidung des herstellers nicht akzeptieren zu können.

c ya,
nco2k

[ZeHa]

Es gibt aber hier nicht nur dich. Denn ich hab dich nicht explizit angesprochen.

Du hast zumindest bei den "2 Lagern" weitergemacht, die ich im Posting davor direkt erwähnt habe.

Ausserdem kommst du nun ja auch wieder fast mit nem Fred-Zitat daher.

Ich wiederhole gerne nochmal, daß dieses "Zitat" kein Unterstreichen dieser Meinung sein soll, und es diente nur dazu, zu erklären, was ich meine.

Wäre es nicht viel sinnvoller wenn wir uns mal hier zusammenhocken und ein paar tolle Argumente pro OOP basteln um damit zu versuchen Fantaisie-Software zu überzeugen?

Können wir schon machen, allerdings hättest Du das auch bereits früher vorschlagen können. Dennoch bin ich mir nicht sicher, wie gut die Chancen stehen, da ja anscheinend regelmäßig der Wunsch nach OOP aufkommt.

Vielleicht sollte man mal eine kleine Chat-Runde eröffnen, wo vor allem die weiteren PureBasic-Mitarbeiter dabei sind (freak & Co), dann könnte man da vielleicht mal genaueres besprechen, evtl. die Gründe erfragen, warum aus OOP bisher nix wurde, und dann mal eine Art "Plan" ausarbeiten (kurz und knackig natürlich, nix über-aufwendiges). Dieser sollte natürlich auch alle Schwierigkeiten beinhalten inkl. möglicher Lösungsvorschläge (gerade auch was die bisherigen LIBs angeht, oder etwaige Spaltungen in PB-4.0 Legacy und PB-5.0 für die Zukunft). Wenn das dann insgesamt 'nen soliden Eindruck macht, könnte man zu Fred gehen und versuchen, ihm das schmackhaft zu machen. Dazu noch ein kleines Umfragen-Ergebnis, wie viele Leute diese Idee gern verwirklicht sehen würden, und dann haben wir vielleicht Glück, daß er seine Meinung ändert. Vielleicht aber auch nicht, und der Aufwand war umsonst.

Vielleicht wäre auch ein 1A funktionierender PreCompiler inkl. 2-3 portierter Libs eine gute Sache, um Fred oder zumindest auch User dafür begeistern zu können. Da gäbe es am ehesten noch die Chancen, das Teil dann als "offizielle OOP-Erweiterung" beim Download gleich mit anzubieten. Somit hätte Fred weiterhin Arbeit mit der eigentlichen PB-Entwicklung, und er hätte ein paar zusätzliche Mitarbeiter, die die OOP-Sachen getrennt dazuprogrammieren. Hiermit wäre dann die Trennung auch sehr klar und ersichtlich, und jeder, der PB mit OOP benutzen würde, wäre sich darüber im klaren, daß das zwar was offizielles ist, aber dennoch nicht zum festen PB-Kern gehört.

Es ist ja nun auch ein PB.NET-Compiler in Arbeit, und da gab es doch auch schon Vermutungen, daß das irgendwann 'ne offizielle Sache wird. Am ehesten müßte man diese Technik dann vielleicht auch abzwacken für das offizielle OOP-Kit. Somit hätte man dann auch noch mehr Konsistenz.

[ZeHa]

so wie sich manch einer hier benimmt, könnte man meinen, dass die verpackung/homepage voll mit werbung bestückt war, "oop wird in zukunft verfügbar sein", was eben nicht der fall ist. es stand schon immer fest, dass kein oop kommen wird, also wo liegt das problem?

Zumindest war das anfangs immer so eine Art "Schwebezustand". Jedenfalls kann ich mich erinnern, oft davon gelesen zu haben, daß OOP möglicherweise noch kommt, weil PB sich eben ständig in Entwicklung befindet. Ich habe dann auch für 4.0 fest mit OOP gerechnet.

Der "Schock" kam dann eben mit dem Interview, das kurz vor dem 4.0-Release veröffentlicht wurde. Erst seit da ist es "offiziell klar", daß es kein OOP geben wird.

[Rings]

...Vielleicht wäre auch ein 1A funktionierender PreCompiler inkl. 2-3 portierter Libs eine gute Sache, um Fred oder zumindest auch User dafür begeistern zu können. Da gäbe es am ehesten noch die Chancen, das Teil dann als "offizielle OOP-Erweiterung" beim Download gleich mit anzubieten. Somit hätte Fred weiterhin Arbeit mit der eigentlichen PB-Entwicklung, und er hätte ein paar zusätzliche Mitarbeiter, die die OOP-Sachen getrennt dazuprogrammieren. Hiermit wäre dann die Trennung auch sehr klar und ersichtlich, und jeder, der PB mit OOP benutzen würde, wäre sich darüber im klaren, daß das zwar was offizielles ist, aber dennoch nicht zum festen PB-Kern gehört.

Hört sich nich schlecht an, jedoch gibt das hier im forum nie was weil
es auch nie ein community-projekt bis zur Reife geschafft hat.
Leider.
Alles was ich bisher gesehen habe war entweder:
-very alpha(buggy)
-ohne Source
-schlecht design't(die oop-konstrukte).

[ZeHa]

Jepp, das ist sicherlich ein Problem. Aber vielleicht ist der PB.NET-Compiler ja die Rettung

[freak]

Ich hatte mir (vor nicht allzulanger Zeit) im englischen Forum mal die Mühe gemacht
und unsere Position zu diesem Thema ausführlich erklärt.
Leider ist der Thread später im Flame untergegangen und inzwischen gelöscht.


> Wäre es nicht viel sinnvoller wenn wir uns mal hier zusammenhocken und ein paar tolle Argumente pro OOP basteln um damit zu versuchen Fantaisie-Software zu überzeugen ?

Zuerst mal geht es hier (zumindest aus unserer Sicht) überhaupt nicht um die
Frage ob OOP als Prinzip gut oder schlecht ist.
Es geht hier um die Frage ob es einen Sinn macht aus PB (einer prozeduralen Sprache)
eine OO Sprache zu machen. (oder eben einen Hybrid aus beidem)

Des weiteren möchte ich anmerken das wir uns zu dem Thema nicht erst seit gestern gedanken
gemacht haben, sonder inzwischen schon seit Jahren.
Unsere Meinung dazu basiert also nicht auf nichtwissen (oder weil wir es nicht könnten, *lol*),
sondern ist das Ergebnis konkreter Überlegungen was eine Implementierung
von OO Features für Auswirkungen auf das Konzept der Sprache an sich hätte.

Ich wage also zu bezweifeln das "ein paar tolle Argumente pro OOP" reichen um unsere Meinung zu ändern.
(es seidenn es handelt sich um bahnbrechend neue Erkenntnisse zu dem Thema )


Here we go...

Zum einen ist es eine Frage des Language-Designs. PB ist nunmal von Grund auf
eine Prozedurale Sprache. Da jetzt noch ein bischen OOP drauf zu packen
führt unweigerlich dazu das das Gesamtkonzept an einigen Stellen nichtmehr
wirklich stimmig ist.

Ein Beispiel dazu ist das was ZeHa angesprochen hat:
Eine OO Sprache mit einem rein prozeduralen Befehlssatz ist Schwachsinn. Auf der anderen Seite
war es immer unsere Philosophie das es in PB (im Gegensatz zu z.B. der Perl Philosophie) nicht
mehrere Wege geben soll um die gleiche, grundsätzliche Funktionalität (hier aufruf einer Library Funktion)
zu erreichen. Einfach jede Lib doppelt zu haben als OO und nicht-OO Version würde
dem aber sehr stark entgegen sprechen.

Das führt dann dazu, das in Resourcen wie Forum, Codearchiv etc, ein totaler
Mischmasch vom Einen und Anderen zu finden ist und Leute die ihre Codes
darauf aufbauen haben dann einen totalen Salat von OO und nicht-OO in ihrem Code.
Wer jetzt kommt und mir weismachen will das das ja kein Problem sei, der hat
keine Ahnung was gute Software-Architektur ist.

(Es gibt noch mehr Aspekte des Designs von PB die gegen eine OO Implementierung sprechen,
aber da will ich jetzt nicht im Einzelnen drauf eingehen.)

Was mich zum zweiten Punkt bringt:
Es ist unsere Meinung (und ja, wir haben viel OOP Erfahrung und sind mit dieser Meinung in der
Softwarewelt auch nicht allein) das solche "Hybrid-Sprachen" nicht die beste Sache sind.
Die wahre Stärke des OO Paradigmas kommt erst dann zu Tage wenn man es
auch vollständig nutzt. Dazu benötigt man eine Sprache die von Grund auf
als OO Sprache konzipiert wurde, und die einen auch dazu zwingt vollständig
OO zu programmieren, und nicht bei jeder Gelegenheit in andere Paradigmen zurück zu fallen.
Eine Sprache der OOP erst nachträglich aufgesetzt wurde kann das nicht.

Ich finde es interessant das C++ hier oft als das "Ein und Alles der OOP Programmierung"
dargestellt wird. Dabei ist das was ich soben genannt habe einer der
Hauptkritikpunkte an C++: Durch seine Herkunft vom prozeduralen C
macht es C++ dem Programmierer sehr einfach einen wunderbar abscheulichen
Mix von OO und prozeduralem Code zu schreiben.
Das macht C++ nicht zu einer schlechten Sprache, aber zu mindest wenn es darum
geht wirklich guten OO Code zu schreiben gibt es vielleicht bessere Alternativen.

In diesem Punkt kann man durchaus auch anderer Meinung sein, aber wir
sind jedenfalls der Meinung das die besten OO Sprachen diejenigen sind die
von Grund auf als solche konzipiert wurden, und das trifft für PB eben nicht zu.
Jetzt aus einer "wir wollen es allen Recht machen"-Mentalität herraus noch
ein bischen OO draufzuklatschen führt unserer Meinung nach nicht zu einem guten Ergebnis.
(Möglich ist es auf jeden fall, aber gut muss es damit noch lange nicht sein)

Wenn man sich in der Landschaft der moderneren Basicdialekte mal umsieht
findet man sehr viele die diesen Weg gegangen sind und OO Features anbieten.
Wer also genau das haben will hat durchaus alternativen zur Verfügung und
muss nicht für immer darauf hoffen das PB sowas bringt.


Um es zusammenzufassen:
- wer eine gute prozedurale Sprache sucht, für den ist PB das richtige.
- wer ein Basic mit ein bischen OO obendrauf sucht hat in einigen anderen Basicdialekten funktionierende Alternativen.
- wer wirklich gut OO programmieren will sucht sich am besten eine Sprache die dafür entwickelt wurde.

Wir versuchen nicht es auf Biegen und Brechen jedem Recht zu machen.
Es gibt nicht umsonst so viele Programmiersprachen auf der Welt. PB muss also nicht Alles für Jeden sein.


... so, da wollte ich mich kurz fassen und habe trotzdem wieder nen Aufsatz geschrieben.
Wenn der Thread jetzt auch noch im Mülleimer landet werde ich böse,
denn nochmal schreibe ich das alles bestimmt nicht.

Also bitte die Disskussion gesittet weiterführen damit das hier nicht im Chaos endet...

[Hroudtwolf]

@Freak

Erstmal danke für deine umfangreiche Stellungnahme zum Thema.

Da ich aber als User viel Interesse an solchen Erweiterungen hätte und dadurch gerne weiterhoffe, bettel ich einfach mal mit ein paar Argumenten weiter die aus meiner Sicht eventuell dafür sprechen würden.

Ich sehe es ein, dass eine, von Grund auf auf prozedural getrimmte Sprache niemals eine Highend OOP- oder Hypriden-Sprache werden würde.
Jedoch währen alleine die paar gewünschten Keywords tolle Werkzeuge für das was viele PB User eh schon mit diesen Interface-Classes tun.
Die sind nämlich wirklich ein Krauss.

Es wäre daher ja alleine schon aus ordnungstechnischer Sicht echt toll sowas zu haben.

Es sind doch in erster Linie nicht mal ne Hand voll Keywords die notwendig wären um diese, fast schon chaotisch anmutenden Konstruierungen von Interface-Classes abzulösen.

Als totaler PureBasic-Fan würde ich natürlich auch künftig nicht mehr davon absehen mit PureBasic zu arbeiten wenn dieser Wunsch ewig einer bliebe.
Es wäre einfach ein toller Gefallen den ihr uns damit tun würdet.

MfG

Wolf

[X0r]

Wer sagt denn, dass es Pure-OOP sein muss? Die Leute, die mit C++ arbeiten haben doch auch keine Problem mit dem Mix.

Der Entwickler von C++ hat auch aus dem prozeduralen einfachen C eine mächtige OO Sprache gemacht. Und, ist das Resultat schlecht? --> Nein!

[DrShrek]

...Wenn man sich in der Landschaft der moderneren Basicdialekte mal umsieht findet man sehr viele die diesen Weg gegangen sind und OO Features anbieten.
Wer also genau das haben will hat durchaus alternativen zur Verfügung und muss nicht für immer darauf hoffen das PB sowas bringt.

Und sind das keine Argumente dafür?
Schon alleine um einfach ein Marktsegment zu bedienen das mehr und mehr an Bedeutung gewinnt?
Und letztlich muss Fred sich ja auch von was ernähren

[milan1612]

...Wenn man sich in der Landschaft der moderneren Basicdialekte mal umsieht findet man sehr viele die diesen Weg gegangen sind und OO Features anbieten.
Wer also genau das haben will hat durchaus alternativen zur Verfügung und muss nicht für immer darauf hoffen das PB sowas bringt.

Dann zeig mir einen Basic Dialekt der:
-OOP hat
-nativ kompiliert (möglichst cross-platform)
-eine umfangreiche Standard Library hat
-einen soliden Editor + GUI Designer hat
-eine aktive, hilfsreiche Community hat
-kompakte Executables erstellt
-für Privatanwender erschwinglich ist
...

So weit ich weiß gibts da nichts was auch nur ansatzweise rankommt