PureBoard

Argh, Ok war zu schnell.......

Wie gesagt durch Formatierung sieht man ganz gut wo was zugehört.

Xin hat geschrieben:Diese Diskussion ist so dermaßen obsolete, wer dies als Argument für oder gegen eine Sprache setzt, sucht keine Argumentation, sondern wünscht sich mit allen Mitteln Recht zu bekommen. Wer unbedachte Scheinargumente für seine Argumentation verwenden muss, disqualifiziert sich für eine qualifizierte Argumentation.
Unqualifizierte Argumentation ist keine Argumentation, ohne Argumentation, keine produktive Diskussion. Damit wären wir wieder bei dem Punkt, wo die Diskussion obsolete wird.

Hiermit möchte ich Dich offiziell für den "Best Posting Of All Times Award 2005" vorschlagen!

Jap,
Ich glaube er hat recht alles hat vor/nach-teile.
Was nun besser ist ist Sache der eigenen einstellung das weis man selbst am besten.

125 hat geschrieben:Was nun besser ist ist Sache der eigenen einstellung das weis man selbst am besten.

Um zu entscheiden was besser oder schlechter ist muß man
erstmal die verschiedenen Möglichkeiten kennen und sie dann
objektiv betrachten.

Du sagst aber einfach objektorientierte Programmierung, C++,
und alles Andere was Du nicht kennst oder nicht verstehst, ist "doof".

Du sagst auch: ...dabei ist es nur eine Gewöhnungssache und macht für einen
richtigen Programmierer keinen großen Unterschied, da er sich
auf die Sache einfach einstellt.

In vielen Sprachen schreibt man auch name.struktur_member
und objekt.methode & objekt.variable, in PB eben name\struktur_member
und name\interface_funktion().
Da nimmt man dann meist das was in vielen Sprachen verbreitet ist,
da es Programmierer schon gewohnt sind und es somit beim Umstieg
hilft.

Jemand der nur PB kann, der wird dadurch erstmal mehr Probleme
beim Umstieg auf andere Sprachen haben, da in PB zuviel im
Alleingang gemacht wird.

Mitreden kannst Du eh erst wenn Du die andere Seite (C++, OOP etc.)
richtig kennst, d.h. damit aktiv programmiert hast.
Vorher kannst Du die Vorteile noch garnicht kennen, da Du nicht
den Überblick hast.

Statt jetzt einfach zu sagen "das ist doof", solltest Du Dich erstmal
aktiv mit diesen Dingen auseinandersetzen und es verstehen lernen.

also
vonwegen ich kenne die andere Seite nicht kannst du so nicht sagen.

Ich hab mal in C++ Consolen Sachen geproggt. Ich habe schon PHP JS und noch ein paar andere sachen.

Ich fand den PB Syntax einfach leicht und einfach verständlich.
Jeder muss wissen in was er programmieren will.

ich fand C++ in der Console ziemlich komplex. Fand die Consolen Befehle von PB einfacher. Ich finde das schon allein krank das ich für ein und Ausgabe / Stringverwendung verschiedene sachen includen muss und sie nicht von Anfang an unterstützt werden ich glaube die beiden Dateien hießen String.h und Stdio.h ? Weis es nicht mehr genau ist länger her.
Hab mir auch letztens OOP beispiele angeguckt.

Du kannst also nicht sagen das ich nicht beide Seiten kenne.

Das mit Variable.Typ und Typ Variable ist in der tat gewohnheit. Ich mags einfach lieber

dass du in C die string.h und die stdio.h brauchst, liegt einfach daran,
dass C an sich nur ca. 10-20 befehle hat, dar rest ist als funktionen implementiert,
u.a. eben durch string.h und stdio.h
du könntest auf diese auch verzichten, wenn du alles selbst codest.

zum vergleich dürftest du dann auch nur 5-10% der PB-Befehle verwenden.

der grosse befehlsumfang von PB entspricht praktisch dem includen von ner menge billiotheken (.h) in C

Jau, das ist ja das schöne an PB.
Man öffnet seinen jaPBe (z.B.), hackt einige Zeilen (so ein paar hundert), und ist nahezu völlig befreit von syntaktischem Ballast.
z.B. sowas wie Audiobuffer 'on-the-fly' mit Sounddaten zu füllen, die über ein Fenster manipuliert werden können, ist mit PB ratz fatz erledigt.

Selbiges hatte ich mit Java versucht, aber bis man da mal die ganzen Audio-Instanzen und -Interfaces passend zusammengebastelt hat und dann noch an ein AWT-Fenster gekoppelt, vergehen Jahrhunderte. Dateizugriffe per OpenFile(...) ? Nicht im Traum!


(Das aaaaber.... lasse ich jetzt hier mal explizit unter den Tisch fallen)

"Systemprogrammierung" kann man auch sehr gut in Pascal (turbo)
betreiben, wenn man denn den richtigen pascal-Compiler dafür hat,
der witz ist ja, daß für viele spezielle plattformen nur asm oder c compiler
verfügbar sind!

(wer rechtschreibefehler findet, darf sie gern behalten!)[/quote]

Kaeru Gaman hat geschrieben: dass du in C die string.h und die stdio.h brauchst, liegt einfach daran,
dass C an sich nur ca. 10-20 befehle hat, dar rest ist als funktionen implementiert,
u.a. eben durch string.h und stdio.h
du könntest auf diese auch verzichten, wenn du alles selbst codest.

zum vergleich dürftest du dann auch nur 5-10% der PB-Befehle verwenden.

der grosse befehlsumfang von PB entspricht praktisch dem includen von ner menge billiotheken (.h) in C

PureBasic kann ja nicht zaubern, es macht dies nur alles
automatisch.

Bei C/C++ sage ich dem Compiler welche Dinge ich im Source
verwendet habe, so daß er nur diese Header einbindet und somit
die Funktionsdeklarationen lesen kann.

Der PB-Compiler macht das automatisch bei Start. Da werden
die Libs auf Funktionen gescannt und die .res (Strukturen, Konstanten,
Interfaces) geladen, so daß der Compiler das alles kennt.
Der Nachteil dabei: Umso mehr Libs/Funktionen, Interfaces,
Konstanten, Strukturen usw. eingelesen werden müssen,
desto langsamer wird dadurch auch der einzelne Kompiliervorgang
an der Konsole.

PB nutzt da noch eine gute Möglichkeit um die Kompilierung
von einer IDE aus zu beschleunigen: Der Compiler wird beim
starten der IDE in den Hintergrund geladen und liest dann seine
Informationen ein, also Libs/Funktionen, Strukturen, Interfaces,
Konstanten.
Beim kompilieren von der IDE aus muss das nun nicht jedesmal
wiederholt werden, wodurch man sich so die Zeit zum einlesen
jedesmal spart.
Beim kompilieren von der Konsole aus hilft das aber nicht, da
PB nicht mehrere Module/Sourcen zur gleichen Zeit kompilieren
kann.

In C/C++ sagt man dem Compiler also was man verwenden
möchte. Das hat den Nachteil das man es immer hinschreiben
muß, und den Vorteil das somit nicht alle bekannten Strukturen,
Funktionen, Konstanten usw. eingebunden werden, obwohl sie
nicht gebraucht werden.

Die .res in PB kann man mit vorkompilierten Headern in C/C++
vergleichen. Viele Leute nutzen aber auch diese Möglichkeit in C/C++
nicht um das kompilieren zu beschleunigen.

Eine PureBasic-Lib ist einfach nur ein vorkompilierter Header
und die eigentliche Lib zusammen. Und es wird automatisch
eingebunden.

PB ist da halt auch eher ein Minimal-System mit Standard-Funktionen.
Würde man alle Strukturen, Konstanten, Funktionen und Objekte
aus dem P-SDK, DX-SDK usw. in PB durch .res und Libs einbinden,
dann würde der Startvorgang von PB erheblich langsamer werden.
Man denke dabei nur an hunderte Interfaces & Interface-IDs (IID)
zur modernen WinAPI-Programmierung.

Der nächste wichtige Punkt ist die Erweiterbarkeit. In C/C++
kann man so beliebig neue Libs einbinden und sagt dem Compiler
einfach welche Funktionen sich darin befinden (durch das einbinden
des Headers für die entspr. Lib).

Damit im Zusammenhang steht das PB nicht zu z.B. C und C++ Libraries
kompatibel ist, d.h. man muß entweder einen Wrapper dafür
schreiben oder den Source direkt ändern und daraus extra
eine PB-Lib machen.

In freeBasic wurde das IMO etwas besser gelöst. Dort kann
man auch C-Libs einfach dazulinken und deklariert dazu einfach
nur die in der Lib enthaltenen Funktionen.
Auch kann man in freeBasic einzelne Module kompilieren die dann
alle zusammengelinkt werden können. Somit muss man nicht jedesmal
komplett das große Projekt kompilieren, sondern nur das geänderte
Modul.

Mal angenommen ich programmiere mit C++ unter Windows
viele Programme. Konsoleprogramme und GUI-Programme.
Da kann ich mir doch ganz einfach 2 Header machen, die die
Header und Macros/Define einbindet die ich immer dafür
brauche.
Für GUI-Programme binde ich z.B. immer den Header <DK_Win> ein,
und für Konsoleprogramme <DK_Console>.
Im Header "DK_Win" wird dann alles eingebunden was ich immer
zur WinGUI-Programmierung brauche, so z.B. Windows.h,
und mein eigenes Klassensystem DCS.hpp wo Klassen für
Fenster, Gadgets usw. deklariert werden.

Wenn Jemand das "&&" und "||" nicht gefällt, oder er es unleserlich
findet, dann braucht er in seinen persönlichen Header nur hinzufügen: ...und schon kann er schreiben: Man kann sich also selbst die Arbeit sehr erleichtern indem
man sich einen eigenen Header macht und dort ein paar Sachen
deklariert und einbindet die man immer braucht.
Wäre doch Quatsch immer wieder alles in jeden Source
reinzuschreiben.

Aber dazu genug.

Was ich für sehr wichtig halte ist die Offenheit und Erweiterbarkeit
der Sprache, was speziell für fortgeschrittene Programmierer
unbedingt nötig ist.
Wenn Xin nicht nur so eine kleine "Anfängersprache" entwerfen
will, wird er das sicherlich mit beachten.

Die Macros, Templates, verbunden mit dem großen OOP-System
bei C++ geben dem Programmierer sehr viele Möglichkeiten
von denen Anfänger nicht die geringste Ahnung haben.

Es sind einfach zu viele Möglichkeiten der Sprache, die Anfänger
natürlich noch nicht kennen können. Während man PB locker in
2 Monaten lernen kann, dauert das in C++ meist einige Zeit
länger, da es viel mehr Möglichkeiten und Techniken zu lernen
gilt.

Das meinte ich auch bei Dir, 125. Die Genialität von C++ kann
man erst verstehen wenn man auch die fortgeschrittenen Dinge
davon gelernt hat. Dazu gehören nunmal Templates und die STL
und das ganze OOP-System.


PureBasic kann da IMO auch noch einiges von anderen Systemen
und Compilern lernen. Auch ist PB ist zu verschlossen und inkompatibel
zu anderen Compilern. Dadurch kann man C-Libraries nicht ohne
Umwege einbinden, und andersrum keine Libraries für C mit PB
schreiben.


@Xin: Möchtest Du es "richtig anpacken" und eine größere
Sprache und einen entspr. Compiler dazu entwickeln, oder
eher ein "kleines Ding" wie z.B. PB oder BlitzBasic, wodurch
es Anfängern zwar einfach gemacht wird, fortgeschrittene
Techniken für erfahrene Power-Programmierer aber auf der
Strecke bleiben? Oder ein Mix aus beidem?

Danilo hat geschrieben:

Kaeru Gaman hat geschrieben: @Xin: Möchtest Du es "richtig anpacken" und eine größere
Sprache und einen entspr. Compiler dazu entwickeln, oder
eher ein "kleines Ding" wie z.B. PB oder BlitzBasic, wodurch
es Anfängern zwar einfach gemacht wird, fortgeschrittene
Techniken für erfahrene Power-Programmierer aber auf der
Strecke bleiben? Oder ein Mix aus beidem?

Das Projekt begann aufgrund der Erkenntnis, dass mir C++ zu klein wurde. Um "einfache" Aussagen zu treffen, musste ich wiederholt Klassen und Templates entwickeln, die ich mir in der Sprache gewünscht hätte. Die STL ist da ein guter Einstieg, aber ich fühlte mich dennoch teils zu eingeschränkt. Also habe ich das Projekt an den Nagel gehängt und mir überlegt, was das Projekt vereinfacht hätte.
Besonders fiel mir auf, dass meine oft Idee einfach war, aber die dafür erforderliche Aussage im Sourcecode sehr lang.
Wenn ich wissen will, wieviel PS ein Auto hat, kann ich nicht fragen. "Wieviel PS hat der Motor vom dieses Auto?", sondern wenn ich sicher programmieren will, muss ich fragen "Wenn dieses Auto existiert, dann prüfe, ob es einen Motor besitzt und wenn es einen Motor besitzt, dann gucke nach, wieviel PS der Motor hat."
Mache ich das so nicht umständlich, könnte es u.U. sein, dass ich ein Segmentation Fault kassiere. So werden viele SEHR einfache Gedanken zu komplizierten Fragestellungen - in allen Sprachen.
Das war '99. Inzwischen habe ich viel überlegt

Wie gesagt: Ausgangspunkt ist C++. Ich ändere einiges an der Syntax, aber ich habe noch kein Konzept aus C++ entfernt, da alle Konzepte in C++ sinnvoll sind.
Ich habe aber auch Tutorien gemacht, wo ich Leuten Programmieren in C und C++ beigebracht habe. Viele haben Schwierigkeiten am Anfang und als Dozent braucht man viel Geduld, um die Informationen für den EInstieg immer wieder zu erklären, bis sie verstanden werden. Das Problem war in der Regel, dass man für ein "Hello World" Variablen erklären muss, was ist ein include, wofür braucht man das, was ist stdio.h, was kann das, warum int main(void), was heißt return, wie benutzt man printf(), was bedeutet "\n" und wie sagt man dem Compiler, dass man da ein Programm draus kompilieren will.

Der erste Einstieg in C/C++ ist frustrierend, soviel Aufwand nur für nur eine kleine Zeile Text. Ich habe Erwachsene unterrichtet, aber etwas Erfahrung beim Unterrichten von lernschwachen, leicht zu frustrierenden Kindern, war hier SEHR hilfreich. Das waren Informatikstudenten, die auch alles zu kompliziert fanden, sich selbst für zu dumm hielten - wobei ich aber allerdings auch sagen muss, dass viele Schüler/Studenten extrem wenig Frust ertragen können und schnell Probleme haben, wenn es nicht SOFORT läuft.
Andersherum läßt die unwissende Herangehensweise den Anfänger in viele kleine Fallen hereintappen.

Wer eine Funktion in C/C++ schreibt, lernt, dass man hinter geschweiften Klammern kein Semikolon schreibt.
Wenn hinter if einen Anweisungsblock definiert hat, lernt man, dass hinter einer geschweiften Klammer kein Semikolon schreibt.
Schreibt man eine Struktur oder Klasse schreibt, lernt das Gegenteil.

Das Semikolon hinter der schließenden Klammer ist logisch, aber für den Einsteiger erstmal ungewöhnlich. Falle... Frust... "C++ ist scheiße!"
Um zu verstehen, warum da ein Semikolon hingehört und anderswo keins, muss man wieder etwas dazu lernen - die Definition einer Funktion und die Definition einer Klasse sind nicht 1:1 übertragbar, man befindet sich in einem größeren Kontext, nach der Definition ist der Befehl eben noch nicht zu Ende.

Das muss auch mit weniger Frust gehen und die Sprache darf nach Möglichkeit keine Fallen besitzen, die den normalen Lernfrust noch weiter erhöhen. Man sollte sich ransetzen können und das zuvor gelernte 1:1 auf ein höheres Konzept übertragen können.

C++ ist eine SEHR gute Sprache, und für eine gute neue Sprache ist die Funktionalität von C++ Mindestvorraussetzung. C++ aber bietet auch Potential zur Verbesserung, grade beim Einstieg.