Eigene OOP-Sprache

Xin

Programmiererer schrieb:

Anhang: Villeicht hat ihr ja noch Ideen WIE man das umsetzten kann und nicht nur was

Das wird schwierig, wenn Du vorher nicht beschlossen hast, was Du umsetzen willst.

Was willst Du überhaupt schreiben? Eine problemorientierte Sprache, also eine Sprache, die ein spezielles Problem(welches?) möglichst gut löst, oder eine nicht problemorientierte Sprache, die möglichst alle Probleme möglichst akzeptabel lösen kann. Eierlegende Wollmilchsäue sind schwieriger zu züchten, hab' ich mir sagen lassen.

Entwickelst Du eine neue Programmiersprache, für die Du einen Compiler brauchst, oder entwickelst Du ein Paket aus Compiler und Sprache - also eine Sprache, die einen speziellen Compiler braucht, der wiederum eine spezielle Sprache braucht?

Hast Du bereits eine Programmiersprache (und wenn auch nur eine kleine zum Ausprobieren) entwickelt und umgesetzt? Weißt Du, wie Du einen Sprung zu einem Label machst, dass Du im Quelltext noch gar nicht gefunden hast?

Weißt Du, wie ein Parser aufgebaut ist? Wie man verschachtelte Strukturen liest, also zum Beispiel verschachtelte if-Anweisungen oder Expressions wie a = 4+3*4, wo man Operatorprioritäten berücksichtigen muss. Oder sich durch Strukturen durchhangelt: a = b.c->d;
Wenn nein - egal das kann man lernen. Wäre aber gut, wenn Du dafür halbwegs fit in der Programmierung bist.

Wieviel Programmiererfahrung hast Du eigentlich? Ein Compiler ist kein mythische Blackbox, sowas kann jeder schreiben. Aber wenn's was werden soll, kann etwas Erfahrung nicht schaden.
Quick'n'Dirty ausprobieren, AHA!, wegschmeißen, sauber neu schreiben.
Hast Du Erfahrung mit größeren Projekten, also etwas, was nicht nur aus 4 Dateien + Include Files besteht? Projektverwaltung? Projektaufbau? Make-Files?
Und solange Du das offensichtlich Just-For-Fun machst, solltest Du eine Sprache entwickeln, die Dir auch Spaß macht und die Dir sinnvoll Arbeit abnehmen kann.

Wenn Du eine Sprache entwickeln möchtest, kannst Du auch mit einem Front-End für eine andere Sprache anfangen, also ein Art Compiler, der Deine Sprache in C oder C++ Sourcecode umsetzt. Cfront war vor 20 Jahren ebenso entstanden, nennt sich heute C++.

Also die Frage wieder zurück: Was möchtest Du denn schreiben und wenn Du Dich selber einschätzt - was könntest Du mit Deinem jetzigen Wissensstand umsetzen?

Mal eben einen Compiler anzufangen, weil man grade Lust dazu hat, wird nicht viel bringen, mit 100kB Sourcecode kommt man da nicht weit.

Was willst Du überhaupt schreiben? Eine problemorientierte Sprache, also eine Sprache, die ein spezielles Problem(welches?) möglichst gut löst, oder eine nicht problemorientierte Sprache, die möglichst alle Probleme möglichst akzeptabel lösen kann. Eierlegende Wollmilchsäue sind schwieriger zu züchten, hab' ich mir sagen lassen.

Ich fühle mich gut genug und will es echt mit Eierlegende Wollmilchsäue versuchen.

Entwickelst Du eine neue Programmiersprache, für die Du einen Compiler brauchst, oder entwickelst Du ein Paket aus Compiler und Sprache - also eine Sprache, die einen speziellen Compiler braucht, der wiederum eine spezielle Sprache braucht?

Auch hier will ich den Hardcoreweg einschlagen. Jetzt mal ehrlich. Ich habe viel Zeit genug erfahrung in der Programmierung und werde das Projekt (nachdem ich natürlich einen großen beitrag geleistet habe , OpenSource stellen (GPL ?!))

was könntest Du mit Deinem jetzigen Wissensstand umsetzen?

hmm ... das ist eine schwere Frage. Villeicht hilf es wenn ich sage, dass ich seid 11 Jahren VB, seid 9 jahren c/c++ (danach OpenGL und QT) programmiere.

Xin

Programmiererer schrieb:

Was willst Du überhaupt schreiben? Eine problemorientierte Sprache, also eine Sprache, die ein spezielles Problem(welches?) möglichst gut löst, oder eine nicht problemorientierte Sprache, die möglichst alle Probleme möglichst akzeptabel lösen kann. Eierlegende Wollmilchsäue sind schwieriger zu züchten, hab' ich mir sagen lassen.

Ich fühle mich gut genug und will es echt mit Eierlegende Wollmilchsäue versuchen.

Okay, schonmal testweise etwas programmiersprachenartiges geschrieben? Die Frage fand' ich eigentlich am spannendsten ;->
Weil 'ich fühle mich gut genug' erinnert mich an Volker Pispers "gefühltes Wissen" - vergleichbar mit 'Temperatur 20 Grad, gefühlt 15 Grad'...

Programmiererer schrieb:

Entwickelst Du eine neue Programmiersprache, für die Du einen Compiler brauchst, oder entwickelst Du ein Paket aus Compiler und Sprache - also eine Sprache, die einen speziellen Compiler braucht, der wiederum eine spezielle Sprache braucht?

Auch hier will ich den Hardcoreweg einschlagen. Jetzt mal ehrlich.

Jetzt mal ehrlich, als ich angefangen habe Genesys zu entwickeln hab' ich an das gedacht, was ich grade programmiere. Bißerl C und C++, das kann doch nicht so schwer sein. Dann programmierte ein anderes Projekt und stieß auf neue Probleme. Und ich programmierte den Compiler. Noch ganz andere Probleme, ich mit der ersten Idee nicht berücksichtigt hatte.
Dann wollte ich es richtig machen. Das Konzept habe ich soweit klar, ich habe 4 Jahre lang programmiert und mir alles aufgeschrieben. Ich will das auch umsetzen, aber trotz 20 Jahren Programmiererfahrung sehe ich da doch noch eine (sehr! interessante) Herausforderung drin.

Programmiererer schrieb:

Ich habe viel Zeit genug erfahrung in der Programmierung und werde das Projekt (nachdem ich natürlich einen großen beitrag geleistet habe , OpenSource stellen (GPL ?!))

Darf ich fragen, wie alt Du bist? Möge sich Sidewinder auch wieder auf der Seite winden, aber um den geht's ja grade nicht.
Die Frage, die ich stelle, ist die Folgende: Kann es sein, dass Du die Schritte, die Du nach Fertigstellung Deiner Sprache tun möchtest, schon besser geplant hast, als das eigentliche Projekt?
Auch ich mache mir Gedanken zu einer Lizenz für Genesys. Auch, ob ich ihn als OpenSource rausgebe. Aber eine Antwort auf die Frage habe ich noch nicht - nichtmal im Entferntesten. Ich hab' mit dem eigentlichen Projekt noch genug zu tun.
Ob sich jemals jemand für Genesys interessieren wird, weiß ich nicht. Entsprechend uninteressant ist es, sich jetzt darübr Gedanken zu machen, was ich nach Genesys mache.

Am Rande: Große Beiträge sollte man groß schreiben, sonst sind es nämlich kleine beiträge... scnr ;->

Programmiererer schrieb:

was könntest Du mit Deinem jetzigen Wissensstand umsetzen?

hmm ... das ist eine schwere Frage. Villeicht hilf es wenn ich sage, dass ich seid 11 Jahren VB, seid 9 jahren c/c++ (danach OpenGL und QT) programmiere.

Nein, das sagt mir, dass Du vor 11 Jahren angefangen hast zu programmieren. Was Du in der Lage bist umzusetzen sagt es mir nicht. Es kann auch heißen, dass Du seit 11 Jahren einen Computer besitzt und damals mal VB installiert hast. 9 Jahre C/C++ Erfahrung ist nicht verkehrt, aber was Du damit umgesetzt hast, weiß ich deswegen auch nicht. Wieviel davon ist C++? Wieviel Zeit lief VB parallel? Was hast Du in der Zeit programmiert, was wie ein Compiler vor allem auf Datenstrukturen basiert?

Schau Dir die Fragen aus meinem vorherigen Posting nochmal an. Da sind viele Fragen, die Du Dir beantworten solltest.
Fang nicht an einen Compiler zu schreiben, ohne diese Tests zu machen. Ich habe einige Wochen Testprogramme geschrieben, dann erst den Compiler angefangen und diesen Anfang trotzdem komplett weggeworfen. Auch in der jetzigen Version gab es funktionierende Elemente, sechs Wochen Arbeit, 7 Tage die Woche. Es funktionierte, wurde von mir aber für nicht gut genug befunden. Markiert, Steuerung-X, 6 Wochen Arbeit in der Tonne und nochmal von vorne.
Compiler sind die Programme, die Grundlagen schaffen für Betriebsysteme und für Applikationen. Kompromisse sind hier nicht gefragt.

"Language shapes the way we think,
and determines what we can think about."
(B.L. Whorf)

Versteh' mich nicht falsch, ich will Dich nicht davon abhalten, im Gegenteil. Aber ich halte es für sinnvoll, erstmal auszuprobieren und zu lernen, bevor Du das Projekt - natürlich nachdem Du einen großen Beitrag geleistet hast - der Open-Source-Gemeinde schenkst. Es wäre doch Zeitverschwendung gewesen, wenn die Open-Source-Gemeinde dann dankend ablehnen würde.

Leiste Deinen Beitrag mit einem ersten Schritt: Du gehst in Deine Buchhandlung und besorgst Dir das Drachenbuch - oder besser die. Die sind nicht mehr ganz taufrisch, aber immer noch das Standardwerk zum Thema.
Und beantworte die Fragen, die ich Dir gestellt habe. Hier oder nur für Dich. Wenn alle Fragen ein "Go" haben, schreib Deine Sprache.

Leiste Deinen Beitrag mit einem ersten Schritt: Du gehst in Deine Buchhandlung und besorgst Dir das Drachenbuch - oder besser die. Die sind nicht mehr ganz taufrisch, aber immer noch das Standardwerk zum Thema.

Die beiden Drachenbücher habe ich schon bestellt (hätte ich villeicht nochmal erwähnen sollen).

Aber gut, ich gehe nochmal jede Frage von dir durch:

Entwickelst Du eine neue Programmiersprache, für die Du einen Compiler brauchst, oder entwickelst Du ein Paket aus Compiler und Sprache - also eine Sprache, die einen speziellen Compiler braucht, der wiederum eine spezielle Sprache braucht?

Die Frage habe ich schon beantwortet... Ich will den Hardcore weg einschlagen. Nicht das Ziel ist mir wichtig sondern der Weg.

Weißt Du, wie ein Parser aufgebaut ist? Wie man verschachtelte Strukturen liest, also zum Beispiel verschachtelte if-Anweisungen oder Expressions wie a = 4+3*4, wo man Operatorprioritäten berücksichtigen muss. Oder sich durch Strukturen durchhangelt: a = b.c->d;

Nein, aber das kann/will ich wirklich noch lernen. Wird das Thema in den Drachenbüchern behandelt?

Nein, das sagt mir, dass Du vor 11 Jahren angefangen hast zu programmieren. Was Du in der Lage bist umzusetzen sagt es mir nicht. Es kann auch heißen, dass Du seit 11 Jahren einen Computer besitzt und damals mal VB installiert hast. 9 Jahre C/C++ Erfahrung ist nicht verkehrt, aber was Du damit umgesetzt hast, weiß ich deswegen auch nicht. Wieviel davon ist C++? Wieviel Zeit lief VB parallel? Was hast Du in der Zeit programmiert, was wie ein Compiler vor allem auf Datenstrukturen basiert?

Also vor 11 Jahren fing ich an mit VB zu programmieren. Jeder der VB kennt, weiß, dass man schnell die Grenzen erreicht. Deßhalb stieg ich ca. 2 Jahre später auf C um. Nachdem ich die Grundlagen drauf hatte, wechselte ich zu C++. Seid 4 Jahren "kann" ich schon OpenGL, seid 3 Jahren mache ich was mit QT.

Ich hoffe, dass somit alle Fragen beantwortet sind. Und damit es nochmal jeder weiß: Vom Compiler bin ich noch weit entfernt. Ich kann ja noch nicht mit einem Compiler anfangen, bevor ich nicht weiß wie meine Sprache überhaupt aussehen soll!!!

volkard

keiner sollte compiler benutzen, den er nicht selber programmieren kann.

Xin

Programmiererer schrieb:

Entwickelst Du eine neue Programmiersprache, für die Du einen Compiler brauchst, oder entwickelst Du ein Paket aus Compiler und Sprache - also eine Sprache, die einen speziellen Compiler braucht, der wiederum eine spezielle Sprache braucht?

Die Frage habe ich schon beantwortet... Ich will den Hardcore weg einschlagen. Nicht das Ziel ist mir wichtig sondern der Weg.

Da Du Dich schon drauf vorbereitest das ganze unter GPL? zu veröffentlichen, scheint mir, dass Du schon ein Ziel hast.
Für jeden Weg, der weiter als 100kB geht, sollte man passende Ausrüstung dabei haben.
Die "Mal eben auf den Gipfel"-Mentalität gibt den Auftakt für jede Software-Technik-Vorlesung: der Großteil der entwickelten Software funktioniert nicht oder so schlecht, dass sie nicht eingesetzt wird.

Programmiererer schrieb:

Weißt Du, wie ein Parser aufgebaut ist? Wie man verschachtelte Strukturen liest, also zum Beispiel verschachtelte if-Anweisungen oder Expressions wie a = 4+3*4, wo man Operatorprioritäten berücksichtigen muss. Oder sich durch Strukturen durchhangelt: a = b.c->d;

Nein, aber das kann/will ich wirklich noch lernen. Wird das Thema in den Drachenbüchern behandelt?

Ich hab' die beiden Bücher zu Hause, aber ich muss zugeben, dass ich sie nie komplett gelesen habe. Mehr Überflogen.
Ausdrücke kommen drin vor, ich habe auch mal nachgeschlagen, wie sie dort behandelt werden, es aber es wieder vergessen.
Ich habe das aus einem anderen Buch gelernt, das davon ausgeht, dass Operatoren und deren Prioritäten konstant sind und darauf einen sehr schlechten, aufgeblasenen und somit sehr redundanten Aufbau für alle Operatorprioritäten brachte. Jede Operator-Priorität bekam ihre eigene Funktion, die die jeweiligen Operatoren dieser Priorität bearbeitete.
Das ganze ist stackintensiv und vor allem redundant (=fehleranfällig).
Ich habe nur eine Funktion für alle Prioritäten und dieser Algorithmus wurde geschrieben, bevor ich das Drachenbuch gekauft hatte. Drei Tage hingesetzt, viel Papier bekritzelt und heraus kam ein Algorithmus, vielleicht 30 Zeilen, der alles erschlägt. Er steht iirc auch nicht im Drachenbuch drin, aber was da jetzt genau drin stand weiß ich auch nicht mehr.
Mein Algorithmus funktioniert ja, also las ich andere Sachen.
Ich habe mir das Drachenbuch mehr als "Zitatesammlung" zugelegt.

Programmiererer schrieb:

Deßhalb stieg ich ca. 2 Jahre später auf C um. Nachdem ich die Grundlagen drauf hatte, wechselte ich zu C++. Seid 4 Jahren "kann" ich schon OpenGL, seid 3 Jahren mache ich was mit QT.

Ich hoffe, dass somit alle Fragen beantwortet sind. Und damit es nochmal jeder weiß: Vom Compiler bin ich noch weit entfernt. Ich kann ja noch nicht mit einem Compiler anfangen, bevor ich nicht weiß wie meine Sprache überhaupt aussehen soll!!!

Wie weit Du vom Compiler entfernt bist, hängt davon ab, wie gut Du Datenstrukturen organisieren kannst. Ein Compiler ist auch nur ein "Daten einlesen" und "Daten wegschreiben".
Wie weit Du von einer brauchbaren Sprache entfernt bist, hängt davon ab, wieviel Verständnis Du für's Programmiersprechen hast, also beim Schreiben bemerkst, dass es an dieser Stelle hakt, man sich umständlich ausdrücken muss und ob es an dieser Stelle wichtig ist, eine besseren "Satzbau" zu bekommen.
Die Prioritäten für & oder | wurden sinnvoll hoch (== schwach bindend) gewählt. Leider hat niemand den Sinn verstanden und die Operatoren wurden in einem anderen Zusammenhang viel häufiger benutzt, wo eine niedrigere Priorität günstiger gewesen wäre. Also gilt heute, dass man besser alles klammert, was mit binären Operatoren zu tun hat, um ihnen eine starke Bindung zu verschaffen.

Wenn man die Klammern nicht mehr zählen kann, oder redundand programmieren muss, weil die Sprache es anders nicht hergibt, oder man sich so tief verschachtelt, dass man selbst bei Breitbild-Monitoren rechts aus dem Rand rausschreibt, dann findet man recht schnell Sprachkonstrukte, über die vielleicht mal nachgedacht werden muss.

Interessant fand ich auch, mal zu sehen, wer eigentlich auf die Idee gekommen ist, eine Zuweisung mit '=' zu beschreiben. Programmiersprachen haben einen Hang zur Mathematik, aber '=' verlangt Gleichheit um wahr zu sein. Ich kann jeden Mathematiker (zum Teil) verstehen, der sich weigert eine Sprache zu nutzen, wo man 'A = A + 1' schreiben darf. In mathematischer Semantik ist das ganz einfach falsch. Die vergleichen jetzt seit ein paar tausend Jahren und letztes Jahrhundert kommt einer daher und sagt "Nöö, ich find das so lustiger." und ändern die Semantik. Ich würde als Informatiker auch etwas blöd gucken, wenn 'if' in Zukunft 'function' und 'int' dann 'while' heißen würde.
Früher gab es Sprachen, da wurde ein Vergleich mit '=' gemacht und eine Zuweisung mit 'LET':
"LET A = 4" - Lass a gleich 4 sein. Da man viel zuweist, hat Basic das LET mit der Zeit verloren: "A = 4".
In C ist Zuweisung '=' und Gleich ist '=='. Pascal hat das mit ':=' etwas geschickter gemacht: Pascal hat von Algol kopiert.
Schau Dir die Fehler der anderen an, da gibt es vieles, was man verbessern kann.

Schreib Testprogramme und guck Dich um, was eine neue Sprache besser machen sollte. Java und C# sind recht neu - was ist die Kritik an diesen Sprachen!? Warum wurde die Kritik nicht berücksichtig, obwohl die Sprachen doch eigentlich vom Reißbrett kommen und zumindest C# eigentlich nicht gewachsen ist.

Java und C# sind recht neu - was ist die Kritik an diesen Sprachen!? Warum wurde die Kritik nicht berücksichtig, obwohl die Sprachen doch eigentlich vom Reißbrett kommen und zumindest C# eigentlich nicht gewachsen ist.

Dafür habe ich dieses Topic auf gemacht. Ich wollte eigentlich nur Fragen, was ihr anders machen würdet ^^

Aber das mit dem '=' finde ich schon mal gut.
Auch nervt mich ständig, dass ich prinft, printf und nochmal printf für die konsole eingeben muss. Viel cooler würde ich so z.B. finden:

< "&a"  // eine art scanf
> "Text ... blub"  // printf
> "%a inhalt von a"

Gut, dass ist jetzt villeicht schlecht durchdacht, aber trotdem is ist kürzer

Xin

Programmiererer schrieb:

Aber das mit dem '=' finde ich schon mal gut.

Das wird in Genesys auch anders aussehen.

Programmiererer schrieb:

Auch nervt mich ständig, dass ich prinft, printf und nochmal printf für die konsole eingeben muss. Viel cooler würde ich so z.B. finden:
< "&a"  // eine art scanf
> "Text ... blub"  // printf
> "%a inhalt von a"
Gut, dass ist jetzt villeicht schlecht durchdacht, aber trotdem is ist kürzer

Schau Dich doch einfach in anderen Sprachen um.

Auf Commodore Basic konnte statt print auch '?' nehmen, was später vom Computer zum PRINT aufgeblasen wurde.

10 ? "Hallo Welt"

PHP kanns noch einfacher, vermutlich so einfach, dass man es nicht mehr unterbieten kann

Hallo Welt

alternativ auch:

<? print "Hallo Welt"; ?>

<? 
   $a = 4;
   print "Inhalt von a: $a"; 
?>

Lösungen gibt es viele... Passt das ganze ins Sprachkonzept ist eher die Frage...

zafiro

//edit ... ne, doch nicht

DEvent

man kann ja natürlich jeden scheiss in einen ASCII-Zeichen codieren.
wieso nicht gleich if als ? schreiben ?
In C++ habt ihr cout < "blaaa" und cin > c das ist doch kurz genug ?
Konsole ist sowieso sowas von out-of-date...

das Problem ist das es eine Sprache gibt, die eines ganz gut kann, aber dann wieder was anderes fehlt.
Java: Generics, aber keine Templates, keine Operatorenüberladung
C++ : umgekehrt zur java
C# : auch keine Templates
(waren nur Beispiele)

Xin

zafiro schrieb:

Jo, sehr vielen Danke Xin. Sowas suche ich halt. Wie weiß muss ich eigentlich mit der "Sprach-Überlegung" gehen. Muss ich echt jede überdenken, oder würde eine grobe richtung reichen. So wie das hier halt:

< "&a" // eine art scanf
> "Text ... blub" // printf
> "%a inhalt von a"

(is ja uch erst eine grobe idee)

Wenn Du eine problemorientierte Sprache schreibst, nimmst Du Dir das Hauptproblem und definierst es so, dass es sinnvoll, eindeutig, verständlich, lesbar und leicht zu lernen ist.
Die Aufgabe von PHP war Text zu produzieren. Darum ist ein Hallo Welt in PHP extrem einfach. Ein XML Parser ist nicht schön, aber in PHP machbar. Einen Compiler würde ich eher nicht in PHP schreiben - was nicht bedeutet, dass es nicht möglich wäre, ich würde lediglich andere Sprachen vorziehen, die zum Thema Datenstrukturen etwas besser gerüstet ist.

Wenn Du eine nicht problemorientierte Sprache schreiben möchtest, hast du es etwas komplizierter. Du musst sehr viele Sprachkonstrukte unterstützen und die so definieren, so dass sie sinnvoll, eindeutig, verständlich, lesbar und leicht zu lernen sind. Und das ist alles andere als einfach, den die bekannten Sprachen sind da auch nicht zufriedenstellend. C/C++ ist sinnvoll, meistens eindeutig, aber eben nicht immer, verständlich wenn man die Regeln gelernt hat, lesbar, wenn man die Regeln beherrscht und Ergebnisse sind in C/C++ nicht ohne einen gewissen Aufwand zu erzielen. Man sieht, dass C/C++ von Leuten entwickelt wurde, die eine Sprache schaffen wollten, die für ihre Bedürfnisse geschaffen ist. In damliger Zeit erfüllte sie auch die Kriterien verständlich und leicht zu lernen.
Heute sind wir 20-30 Jahre weiter und die Bedürfnisse liegen so, dass alle programmieren wollen, aber keiner mehr Zeiger lernen möchte.

Wenn Du Deinen Schwerpunkt da anlegst, kommt vielleicht etwas wie Java raus. Sobald Du rausfindest, dass die Idee ohne Zeiger zu arbeiten nicht so klever war, wirfst Du C# ins Rennen.
Überhaupt scheint mir, dass jeder es als wichtig anlegt binnen 20 Minuten einen Prototyp zeigen zu können, der zwar nix kann außer ein, zwei Fenster zu öffnen. Hier liegen derzeit offenbar Bedürfnisse. Visuelle Programmiersprachen genannt. Sowas ist praktisch, wenn man in 20 Minuten irgendein Ergebnis braucht. Bei einem ernstzunehmenden Projekt interessiert die GUI wohl am wenigsten.

Letztenendes musst Du also auch Schwerpunkte setzen, wie wichtig etwas für Dein Problem ist. Eine Sprache ist nicht nur eine Lösung, sondern auch ein Statement. Ich halte Zeiger für wichtig, also werde ich Zeiger anbieten und vom Entwickler verlangen, dass er weiß, was ein Zeiger ist. Ich halte 'Garbage Collection' für Müll und habe mich aus mehreren Gründen dagegen entschieden, obwohl ich auch die Vorteile einer Garbage Collection sehe. Bleibt die Frage, wie man die Vorteile retten kann, ohne den Unsinn einer Garbage Collection zu starten und das ganze in ein Sprachkonzept zu gießen. Da kann man schon einige Zeit mit verbringen.
Wie kann ich garantieren, dass ich keine Meldungen bekomme wie bei JavaScript (IE6) "Zeiger auf nicht mehr existierendes Objekt". JavaScript (IE6) interessiert mich nicht, wenn ich als Entwickler da stehe und nichts mehr machen kann, weil die GarbageCollection meine Objekte wegwirft.

Die Frage lautet immer, wo liegen Nachteile in Bezug auf ein bestimmtes Problem? Warum hat man etwas erfunden, um eine Arbeit zu erleichtern? Erleichtert es die Arbeit wirklich? Welche Nachteile hat diese Erfindung. Welche Alternativen gibt es? Hat die Alternative Vorteile für meine Sprache? Kann ich die Alternative bei mir sinnvoll einbauen? Kann ich das sinnvoll umsetzen? Wenn ich das nicht kann, dann heißt es erst lernen, dann umsetzen und es im Zweifelsfall lassen. Ich nutze lieber eine kleine Sprache, die funktioniert als eine große Sprache, die mir alles abnimmt, aber leider Mienenfeld aus Bugs ist.

Hier mal ein Beispiel, wo C nicht eindeutig ist:

int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );

Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.
Dieses Problem tut C oder C++ keinen Abbruch, da es nicht kompilierbar ist, also leicht zu finden. PHP leistet sich da schon ganz andere Dinge
(die mir aufgefallenen Sachen sind aber mit V4.3 behoben worden).

Aus solchen Mißgeschicken kann man aber lernen. Könnte man zumindest.
Dass ein derartiger Wurm nicht auch in Genesys steckt, kann ich nicht garantieren. Sowas findet man in der Regel erst später.
Aber wenn man das Problem identifiziert, findet sich eine einfache Standardlösung, auf die man achten muss.
Man muss bekannte Fehler ja nicht um jeden Preis wiederholen.

GPC

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:
int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );
Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Ich würde noch weiter gehen und sagen, du beginnst mit /* nen Kommentar und kriegst deshalb n Haufen Probleme

Xin

GPC schrieb:

Xin schrieb:
Hier mal ein Beispiel, wo C nicht eindeutig ist:
if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.
Ich würde noch weiter gehen und sagen, du beginnst mit /* nen Kommentar und kriegst deshalb n Haufen Probleme

Nimm den Leuten doch nicht den Spaß, ich habe extra dahinter geschrieben, was passieren sollte, damit nicht gleich die Warnlampen angehen, wenn man /* liest. */

GPC

hrhrhr, alter Halunke

das topic ist im falschen forum und bittet um verschiebung

groovemaster

Programmiererer schrieb:

Also eine Idee wäre es von mir schon mal die ganzen variablentypen wegzulassen, dass es php ähnlich wird.

Ganz schlechte Idee. Damit nimmst du der Sprache einen Teil des anwendbaren Spektrums und machst daraus eine limitierte Sprache. Das würde sich wohl kein (zumindest C++) Programmierer wünschen. Aber du hast Recht, wenn es um Typ Automatisierung geht. Da gibt es durchaus noch Spielraum für Verbesserungen und solche werden im nächsten C++ Standard wohl auch kommen.

thordk schrieb:

ich sehe eigentlich keinen trifftigen grund, der gegen schwache typisierung spricht.

Ich schon. Dann würden wohl noch mehr Dummies C++ programmieren, ohne auch nur die leiseste Ahnung von Softwareentwicklung zu haben. Die Welt würde zugrunde gehen und das Armageddon kommen. Gute Nacht!

thordk schrieb:

c++ ist steinzeit.

Naja, höchstens Antike, wenn wir mal die Entstehungszeit betrachten.

thordk schrieb:

um jeden scheiss muss man sich selbst kümmern, nicht mal der müll wird einem vor die tür gebracht!

Und warum ist das die Schuld von C++, wenn du nicht vernünftig damit umgehen kannst?
In C++ musst du sicherlich mehr machen, als in einigen anderen Sprachen. Allerdings ist vieles davon einfach eine Frage der Routine.

volkard schrieb:

thordk schrieb:

es erschwert natürlich die analyse und ist fehleranfällig. aber mal ehrlich, wieviele speicherlecks und potentielle segmentation fault quellen hat das durchschnittliche c++ programm?

keine.

Aber auch nur deine Programme. Die Realität sieht leider anders aus. Grundsätzlich hast du aber Recht, ein C++ Programm muss keine Speicherlecks oder Segfaults haben.
Deinen Wunsch mit den Compilezeitfunktionen habe ich mir übrigens auch schon manchmal gewünscht. Eigentlich müsste die Sprache es lediglich ermöglichen, dass man Compilezeitkonstanten als Parameter und Rückgabewert definieren kann. const reicht dafür ja nicht aus.

Grundsätzlich glaube ich nicht, dass ein Nachfolger von C++ Sinn machen würde (tut ja eigentlich auch D schon nicht wirklich). Warum? Nun, der eine definiert es zu low-level, der andere zu high-level. Letztendlich ist keiner damit wirklich zufrieden. Ist ja jetzt auch schon nicht anders. Warum gibt es denn so viele Programmiersprachen? Weil jeder andere Anforderungen hat, und jeder glaubt, seine Sprache könnte das am besten. Deshalb gibt es auch nicht _die_ eierlegende Wollmilchsau bei den Programmiersprachen. Und wie Xin schon sagte, was die Zukunft bringt, können wir sowieso nicht voraussagen. Also bleibt uns nur, mit dem zu leben was wir haben (im Grunde gibt es ja auch alles). Und wer das am besten kann, anstatt jedes belanglose Detail im Einzelnen niederzumachen (nein, ich nenne keine Namen ), hat einfach die grössten Chancen, was auf die Reihe zu bekommen. Der Rest fällt früher oder später einfach durchs Sieb.

Zudem würde ich diese Diskussion nur für sinnvoll halten, wenn man sie in zwei Bereiche teilt. Die einen definieren ihre OOP Sprache für low-level, die anderen für High-level. Beides gleichzeitig ist in einfacher Form einfach nicht möglich.

Wenn ich einen Nachfolger von C++ dennoch entwickeln würde, dann wäre das wohl C++ ... mit vielen Verbesserungen im Detail (Kontrollstrukturen, dynamische Speicherreservierung, Literale, builtin Container, etc.pp) und Erweiterungen (zB hat aspektorientierte Programmierung einige gute Ideen). Den Kern würde ich trotzdem beibehalten, wie OO, strikte und statische Typisierung, kein GC (höchstens optional), native Binaries, usw.

Xin schrieb:

Hier mal ein Beispiel, wo C nicht eindeutig ist:
int a = 8, b = 2;
int *p = &b;                           // Zeiger p zeigt auf Variable b

if( a/*p == 4 ) printf( "Yepp\n" );    // Wenn a geteilt durch das, worauf p zeigt gleich 4 ist, also 8/2 == 4
else            printf( "Nopes\n" );
Entsteht hier ein Programm, dass "Yepp" ausgibt oder kompiliert der Compiler das Programm gar nicht erst und bricht mit Fehlermeldung ab?!
Man weiß es nicht, es ist nicht eindeutig. Ich würde sagen das Programm wird in der Regel nicht kompiliert.

Wer sauber formatiert codet länger (anstatt fehler zu beheben)

Helium

groovemaster schrieb:

Wenn ich einen Nachfolger von C++ dennoch entwickeln würde, dann wäre das wohl C++ ... mit vielen Verbesserungen im Detail (Kontrollstrukturen, dynamische Speicherreservierung, Literale, builtin Container, etc.pp) und Erweiterungen (zB hat aspektorientierte Programmierung einige gute Ideen). Den Kern würde ich trotzdem beibehalten, wie OO, strikte und statische Typisierung, kein GC (höchstens optional), native Binaries, usw.

Zitier bitte mal kurz, wo vorgeschrieben sein soll? (ich beziehe mich auf das fett markierte).

groovemaster

Wozu? Ausserdem habe ich solch eine Sprache ja nirgendwo spezifiziert, also kann ich dir auch schlecht Textstellen zitieren.

Helium

Du hast geschreiben, dass wenn du einen C++-Nachfolger erfinden würdest du den Kern beibehalten würdest. Da nichts anderes genannt wurde, war der Kern von C++ gemeint. Dann hast du das aufgezählt, was für dich den Kern von C++ ausmacht und darunter befand sich unter anderem "native Binaries". Für dich sind native Binarys also ein Teil des Kerns von C++. Da ich das nicht wusste, bzw. sogar für falsch halte, wollte ich, dass du mir sagst, wie du darauf kommst, dass es ein Teil des Kerns von C++ ist.

So, noch ausführlicher kann ich das jetzt aber nicht mehr ausführen. Sollte es immer noch Missverständnisse geben, gebe ich auf.