PureBoard

KG, Du wärst der erste, der Die Beziehung mit MasterCreating (oder wie die Firma heißt) beenden würde

Es gab doch schon einige gute Vorschläge.

@ Falo und 7x7: Zumindest von meiner Seite war das mit Danilo durchaus ernst gemeint also das sollte kein Scherz sein.

@ Kaeru: "ernsthaft" beantworten ist eh so 'ne Sache... dieser Thread basiert schon auf einer völlig hypothetischen Situation, sodaß es eigentlich eh unmöglich ist, wirklich ernsthaft zu beantworten. Ich sehe das auch eher als "einigermaßen" spaßigen Thread, wo vielleicht das ein oder andere interessante dabei rauskommt (vielleicht auch nicht). Daher sehe ich das jetzt nicht so verbissen, soll doch ruhig jeder ein bißchen seinen Senf dazugeben

@Zehe: Mir ging`s auch nur um Konversation.

ts-soft hat geschrieben:Ein wirklicher Wunsch von einem der Älteren:
Module!
Damit meine das, was NTC schon angedeutet hat, das Includes einen
eigenen Variablen-Scope sowie private Proceduren haben (also deren Namen
auch in anderen Includes vorkommen darf, solange sie in der Include nicht
Global (oder Exportiert) werden.

Das wäre geradezu himmlisch!

Gruß, Little John

> Ich sehe das auch eher als "einigermaßen" spaßigen Thread, wo vielleicht das ein oder andere interessante dabei rauskommt (vielleicht auch nicht).
> Daher sehe ich das jetzt nicht so verbissen, soll doch ruhig jeder ein bißchen seinen Senf dazugeben
ok, in diesem Sinne hypothetel ich auch mal ein bißchen.

marco2006 hat geschrieben:KG, Du wärst der erste, der Die Beziehung mit MasterCreating (oder wie die Firma heißt) beenden würde.

ich weiß nicht, warum diese Beziehung fortbesteht.
Aber wenn ich eine riesige Konventionalstrafe zahlen müßte,
um das Marketing für Deutschland wieder zurück zu bekommen,
würde ich den Vertrag auch bestehen lassen.

Also, was mich am meisten stört (und wie ihr wißt, bin ich echt zufrieden mit PB) ist das Warten auf eine fehlerbereinigte Version.
Die 4.20 final erschien vor ca. 3 Monaten und es wurden haufenweise Bugs beseitigt. Ein Update wäre schon sinnvoll und gerechtfertigt.

Gut, was soll ich mich beschweren, ich programmiere zwar fleißig, aber ich nutze vielleicht 30% der Befehle (wenn überhaupt). Im Grafikbereich (2D und 3D) habe ich fast noch gar nichts gemacht.

Naja, da ich kein Profi bin, würd ich wohl am ehesten erstmal Leute suchen, die mitarbeiten. Da wäre Fred wohl die erste Adresse. Dann würd ich mich hinsetzen und den Compiler ausführlich kommentieren und die Inneren Structuren betrachten.
Wenn ich´s dann hinkriegen würde, damit um zu gehen:

0.)Ich würde Mehrzeilensupport mittels "_" einführen (denn ich stell mir nicht vor, dass das länger als ne Stunde dauern kann)
1.)Module einbauen
2.)Freak sagen, er soll endlich StructureEntrys in die Autovervollständigung hinter "\" anzeigen lassen


3.)Ich würde versuchen, den Compiler leichter erweiterbar zu machen. Mit So funktionen wie RegisterWindow/Gadget/Image(adresse)
3.1)Ich würde aus der Request-Liste zuerst alles raussuchen, was nur ich als Autor und Veränderer des Compilers bewerkstelligen kann.
Dann würd ich mir zuerst meine Lieblinge raussuchen und wenn ich mich nicht entscheiden kann halt einen kleinen Poll starten, was gemacht werden soll.
3.2)Ich würde Versuchen, eine Lib-For-Money-Aktion ins Leben rufen. Denn ich muss ganz ehrlich sagen, auch wenn ich selbst mal 1 oder 2 dieser "Ich brauch ne Funktion"-Requests gepostet hab, gehen mir die auf den Sack. Wenn ich eine Funktion brauche alla DesktopX() DesktopY(), mehr Soundfunktionen, dann schreibe ich als PB-Anwender sie mir selbst, oder ich frage wen, der das kann. Dazu muss nicht immer der Hauptprogrammierer herhalten.

3.2)Ich würde das Unterforum FeatureRequest&Wishlist in Compilerwishes, IDE-Wishes & Libwishes aufteilen.

3.4)Die Lib-For-Money-Aktion würde so aussehen:

-User fragt nach Funktionen
-Für das schreiben dieser Libraries sind die anderen PB-Anwender zuständig. Der User kann natürlich auch Finanzielles anbieten.
-Ist die Lib meiner Meinung nach würdig, bei PB einzug zu erhalten, würde ich einen meiner Meinung nach angemessenen Betrag bieten, damit ich

1.) den Quelltext bekomme (der vom Autor kommentiert sein muss)
2.) die Lib unter der gleichen Lizenz wie PB im Paket anbieten kann
3.) guten Lib-Programmierern würde ich eine aktive Mitarbeit anbieten.

Das würde zwar erstmal meinen Gewinn schmälern, aber da die Zahl an Libs so schneller steigt und der Compiler mehr Aufmerksamkeit bekommt, würde PB bald Professioneller werden und die Kosten würden steigen.

Bestimmte Features würden dann auch für Registrierte Nutzer einmalige Kosten verursachen, irgendwo von Leben muss ich ja auch

4.)Das Marketing würd ich auch verbessern, mich wundert z.B. bis heute, warum zum Release von 4.0 nichtmal ne Nachricht bei Heise.de erschienen ist.

5.)Ich würde mir einen Punkt 3.3 ausdenken (Na, wer hats gemerkt? )

6.)Bei dieser 4.0 Game-Developement-Sache muss natürlich wat gemacht werden wegen dem Halbnackten Weib auf dem Cover. Ich würd die Hälfte ersetzen, die Momentan noch angezogen ist

Tja, und zu guter letzt würd ich mir ein Großes Z auf die Heckscheibe kleben

Die Idee mit "Modulen" bzw Includes, die nicht neu compiliert werden, wenn nix geändert wurde, halte ich eher für gefährlich. Was passiert z.B. wenn ein Macro in einem Include definiert wurde, aber im Hauptsource (oder in nem andern Include) verwendet wird? So oder so müssten also sämtliche Includes neu geparst werden, und dann dürfte die Zeitersparnis schon wieder mächtig zusammenschmelzen. Das würde den Code und internen Aufbau des Compilers noch komplizierter machen als er jetzt schon ist, und das für einen IMHO fraglichen Gewinn (mal ganz davon abgesehen, dass der Compiler an sich doch eh schon wesentlich schneller ist als der Compiler manch anderer Sprache).

Was Inline-C angeht: Wozu? Wer in C programmieren will, nimmt doch nicht PB, sondern nen C-Compiler. Mag sein, dass es nen Haufen interessanter C-Libraries gibt, aber jemand, der C kann, braucht AFAIK doch kein Inline-C um diese Libs in PB verwenden zu können. Eins der Hauptfeatures von PB ist doch grade, dass es recht schlank ist - warum also das Ganze noch mit nem C-Compiler mästen? Ausserdem: Wenn Fred jetzt nen Inline-C implementieren würde, würde es keine 2 Jahre dauern, bis hier lauthals nach nem Inline-C++ geschriehen wird.

Meine Wunschfeatures wären im Moment (in absteigender Reihenfolge):
- eine Möglichkeit, um eine Code-Zeile auf mehrere Text-Zeilen zu verteilen
- deutlich mehr Datentypen (sämtliche jetzigen Datentypen auch als unsigned-Variante und BOOL).
- OOP (wers nicht will, muss es ja nicht nutzen und kann auch prozedural programmieren)

Auf die angekündigte 64Bit-Version von PB freu ich mich schon.

Ansonsten wäre natürlich ein deutlicher Ausbau der fähigkeiten der Mail- und FTP-Libs wünschenswert. Auf PB 4.30 bin ich schon gespannt, die neue OGRE-Version werd ich zwar selber nicht nutzen, aber da gibts sicherlich einige PB-User, die damit ein paar geile Spiele machen werden...

hardfalcon hat geschrieben:Die Idee mit "Modulen" bzw Includes, die nicht neu compiliert werden, wenn nix geändert wurde, halte ich eher für gefährlich. Was passiert z.B. wenn ein Macro in einem Include definiert wurde, aber im Hauptsource (oder in nem andern Include) verwendet wird? So oder so müssten also sämtliche Includes neu geparst werden, und dann dürfte die Zeitersparnis schon wieder mächtig zusammenschmelzen. Das würde den Code und internen Aufbau des Compilers noch komplizierter machen als er jetzt schon ist, und das für einen IMHO fraglichen Gewinn (mal ganz davon abgesehen, dass der Compiler an sich doch eh schon wesentlich schneller ist als der Compiler manch anderer Sprache).

Der Hauptvorteil wäre für mich, dass die einen eigenen Namensraum haben. Die könen von mir aus ruhig jedes Mal mit compiliert werden.

Gruß, Little John

Zu den einzelnen Modulen gehört natürlich eine Header-Datei wie in C, in
der alle Makros, Konstanten und Procedure-Deklarationen stehen, damit es
richtig funktioniert. Der Compiler könnte die Header-Datei dann ja
selbstständig aus dem normalen Source erstellen und ins selbe Verzeichnis
packen. Der Programmierer muss sich darum dann nicht kümmern.