Vorstellung [Hier ist Scann0r]

[grum.py]

Rust existiert nicht um mehr zu können als C++, im Gegenteil das Ziel ist weniger zu tun.

Das wollte ich schon immer mal haben: Eine Programmiersprache, die nicht alles kann, was ich gern programmieren möchte.
Räusper.

C++ erlaubt dir ohne guten Grund massive Fehler zu machen, häufig führen die sogar zu Sicherheitslücken.

Dann ist der Entwickler schlecht. Sicherheitslücken kriegst du mit ziemlicher Sicherheit auch in Rust programmiert. Einfach mal einen Wert nicht abfragen. Buffer Overflows verhindert Rust jedenfalls auch nicht effizient.

Eine Sprache die Turing Complete ist zu erschaffen ist trivial und passiert Leuten teilweise aus versehen.

CSS3 ist turingvollständig. :K
Können wir das als Argument somit ausklammern?

Code der für 1.0 geschrieben wurde, kompiliert mit einem aktuellen Compiler noch, auch wenn man diesen jetzt vielleicht anders schreiben würde.

C++-Compiler können übrigens in der Regel auch rostiges K&R-C kompilieren.

[BlackJack]

@grum.py: Was kannst Du denn in Rust nicht programmieren was in C++ geht? Also so vom Endergebnis her? Rust ist als Ersatz für C++ konzipiert und schränkt damit nicht willkürlich ein, sondern da wo es sinnvoll ist, also Sachen die man in C++ zwar machen kann, aber besser nicht sollte, zum Beispiel weil es fehleranfälliger ist, oder weil es zu viele Möglichkeiten gibt letztendlich das gleiche auszudrücken weil sich die Sprache weiterentwickelt hat, aber der alte Kram noch enthalten ist.

Klar, wenn man mit C++ nicht klar kommt muss das natürlich am Programmierer liegen. Auf keinen Fall an der Sprache. Genau wie man Fortran in jeder Sprache schreiben kann, kann man natürlich auch in jeder Sprache fehlerhaften Code mit Sicherheitslücken schreiben. Das ist ja aber gar nicht der Punkt, sondern wie leicht es einem die Sprache macht etwas falsch zu machen beziehungsweise wie schwer sich keine Lücken einzufangen, zum Beispiel weil die Sprache zu komplex ist, als das man das überblicken kann. Insbesondere auch als Anfänger.

Das C++ auch C kompilieren kann, sehe ich eher als Problem. Der Vergleich passt auch nicht auf die von mir beschriebene Situation bei Rust. Das Problem was ich hatte war mit prä-1.0-Versionen, also als die Sprache noch nicht fertig war, man deshalb Stabilität auch noch nicht so wirklich erwarten konnte. Hab gerade mal nachgeschaut, der letzte Compiler den ich ausprobiert hatte war die 0.12.0-pre-nightly im September 2014. Die 1.0 kam Mai 2015 heraus. Ich gehe mal davon aus die Sprache ist seit 1.0 deutlich stabiler als vor zwei Jahren. Es gibt zum Beispiel wie ich gerade sehe nicht mehr die beiden Zeigertypen und Beispiele die die mal benutzen und mal schon nicht mehr und Texte die zu keinem der beiden so richtig passen. Ich sollte mir das also mal wieder ansehen.

[grum.py]

Was kannst Du denn in Rust nicht programmieren was in C++ geht?

Du hast doch behauptet, in Rust ginge nicht alles. :K

Rust ist als Ersatz für C++ konzipiert

Ich glaube ja, die Existenz nicht jeder Sprache ist wirklich sinnvoll. Wie viele weitgehend gescheiterte Versuche, C++ abzulösen, gab es schon? Programmiert irgendwer ernsthaft mit D oder Go (oder C# )? Eben, ich kenn' da auch keinen.

Klar, wenn man mit C++ nicht klar kommt muss das natürlich am Programmierer liegen.

Korrekt. Ich behaupte aus eigener Erfahrung, es ist möglich, mit jeder Sprache klarzukommen. Ich käme wahrscheinlich auch mit Rust klar, ich will nur nicht.

Genau wie man Fortran in jeder Sprache schreiben kann, kann man natürlich auch in jeder Sprache fehlerhaften Code mit Sicherheitslücken schreiben.

Die erste Sprache färbe tatsächlich stets auf alle weiteren ab, habe ich mal gelesen.
Meine erste Sprache war aber Pascal und ich glaube nicht, dass ich in Python wie in Pascal schreibe.

zum Beispiel weil die Sprache zu komplex ist, als das man das überblicken kann. Insbesondere auch als Anfänger.

Anfänger, deren erste Sprache C++ ist, dürften mit C++ weniger Probleme haben als solche, deren erste Sprache Python ist.

Das C++ auch C kompilieren kann, sehe ich eher als Problem.

Wieso?

[BlackJack]

Ich habe behauptet man kann sich mit Rust nicht so leicht in den Fuss schiessen wie mit C++. Wenn man das natürlich machen will, dann kann Rust im Endeffekt weniger. Aber das will ja keiner, deshalb wollte ich gerne wissen was man nicht machen kann, aber in der Regel will.

Das die Existenz von Programmiersprachen nicht immer sinnvoll ist würde ich unterschreiben. Genau bei C++ bezweifele ich das nämlich. Und nur weil etwas was sehr weit verbreitet ist, sich deswegen schlecht ablösen lässt, ist es noch lange nicht sinnvoll oder sollte weiter benutzt und nicht irgendwann mal durch etwas besseres abgelöst werden. D hat das Problem das keine grosse Origanisation dahinter steht. Go, C#, und Java werden tatsächlich ernsthaft benutzt.

Ich behaupte aus eigener Erfahrung das es nicht möglich ist *sinnvoll* mit jeder Sprache klar zu kommen. Ich mag Sprachen und schaue mir immer wieder gerne alte und neue Sprachen an und bin auch durchaus offen für Neues, was über meinen bisherigen Horizont hinaus geht. Nur bei C++ habe ich massive Probleme. Insbesondere *weil* ich schon so viele andere Sprachen gesehen habe, verstehe ich nicht wieso man sich so etwas antut, diese Komplexität die man da ständig beachten muss, obwohl dabei am Ende kein Mehrwert gegenüber Sprachen herum kommt, die wesentlich weniger komplex sind, oder die einen bei hoher Komplexität wenigstens nicht so einfach in offene Messer rennen lassen.

Insofern mag es stimmen das C++ als Erstsprache einfacher ist, weil man sich nicht ständig fragt warum das in C++ im Gegensatz zu anderen Sprachen alles so schrecklich ist. Wenn man nichts anderes kennt, fällt das vieleicht nicht so auf.

Das C++ auch C beinhaltet, eine andere Sprache mit sehr ähnlicher Syntax, erhöht die Komplexität unnötig. Wenn man C++ beherrschen möchte, muss man auch C können, obwohl man in C++ doch eigentlich alles ausdrücken kann was man in C machen kann. Zumal C-Code so gar kein idiomatischer C++-Code ist. Das man in C geschriebene Bibliotheken einbinden kann ist wichtig, weil es davon viele gibt und Betriebssysteme in der Regel darin geschrieben sind, aber das kann man ja auch machen ohne C direkt in die Sprache zu integrieren. Das machen Rust und D anders, und auch bei C#, Java, und Python gibt es ein „foreign function interface“ um C-Bibliotheken anzusprechen, ohne das die jeweilige Sprache C als Untermenge hat.

[grum.py]

Ich habe behauptet man kann sich mit Rust nicht so leicht in den Fuss schiessen wie mit C++.

Nur, wenn du unsauberes C++ schreibst. Sauberes C++ schießt dir nirgends hin. Da sitzt das Problem wie üblich vor dem Bildschirm.

deshalb wollte ich gerne wissen was man nicht machen kann, aber in der Regel will.

Performance groß, Ressourcennutzung klein. Geht mit Rust nicht.

Das die Existenz von Programmiersprachen nicht immer sinnvoll ist würde ich unterschreiben. Genau bei C++ bezweifele ich das nämlich.

C++ ist für andere Dinge geeignet als Python. (Du würdest keinen Kernel in Python schreiben, oder?) Welche Lücke Rust füllt, erschließt sich mir aber nicht. Rust existiert nur, weil Mozillianer zu doof für C++ sind, scheint mir. Ganz davon abgesehen, dass ich von Programmiersprachen, die einer großen "Firma" (ob nun "gemeinnützig" oder nicht) gehören, eher abgeschreckt bin.

Go, C#, und Java werden tatsächlich ernsthaft benutzt.

Bei Java erstaunt mich das am meisten, aber wer benutzt bitte Go? Google selbst jedenfalls meines Wissens so gut wie gar nicht, die haben dafür einiges an Pythoncode rumliegen. Das hat sicherlich gute Gründe.

Ich behaupte aus eigener Erfahrung das es nicht möglich ist *sinnvoll* mit jeder Sprache klar zu kommen.

Beispiel?

Nur bei C++ habe ich massive Probleme. Insbesondere *weil* ich schon so viele andere Sprachen gesehen habe, verstehe ich nicht wieso man sich so etwas antut, diese Komplexität die man da ständig beachten muss

Muss man nicht. Schau doch bitte mal spaßeshalber C++17 an. Es hat sich einiges geändert in den letzten Jahrzehnten. Viele der Hilfskonstrukte von "früher" sind nicht mehr nötig, sogar die explizite Typendeklaration nicht mehr in jedem Fall.

obwohl dabei am Ende kein Mehrwert gegenüber Sprachen herum kommt, die wesentlich weniger komplex sind, oder die einen bei hoher Komplexität wenigstens nicht so einfach in offene Messer rennen lassen.

Doch, optimale Nutzung von Ressourcen. Klar kannst du auch in Java oder C# eine ausreichend komplexe Software programmieren. Die sind dann halt nicht ganz so nett zu deiner Rechnerauslastung.

Das C++ auch C beinhaltet, eine andere Sprache mit sehr ähnlicher Syntax, erhöht die Komplexität unnötig.

Das ist ja auch nicht ganz richtig. C ist fast eine Teilmenge von C++, das ist nicht nur "ähnlich". Aber "komplexer" wird davon nichts, oder würdest du Rust auch als "unnötig komplexen Assembler" bezeichnen? Gegenüber C mit seinen, äh, (Eigenheiten*)* ist so ein schöner C++17-Code eine wahre Wohltat für den gebeutelten Verstand.

Wenn man C++ beherrschen möchte, muss man auch C können

Nein. Es hilft bei der Codeoptimierung, aber du sozusagen kannst ein Leben lang guten C++-Code schreiben, ohne eine einzige Zeile C zu verstehen.

Das man in C geschriebene Bibliotheken einbinden kann ist wichtig

Nur, wenn du es willst. Ich habe mal spaßeshalber mit der libcurl (antiker C-Code) in C++ herumgespielt. Das fühlt sich schon beim Schreiben wie ein Fremdkörper an. Du musst aber nicht unbedingt C-Bibliotheken einbinden, du könntest auch einfach eine in C++ nutzen.
Oder selbst schreiben. Zusammenkleben ist eher was für Javaleute. Das ist dann aber kein Programmieren.

[DasIch]

Wie du schon selbst feststellt kann man Probleme mit C++ bekommen. Der Programmierer muss darauf achten dass sie nicht entstehen. Sprachen wie Rust garantieren dass Probleme die bei C++ auftauchen können nicht passieren und erlauben es einem auf die wirklich wichtigen Dinge zu konzentrieren.

Das erlaubt auch Dinge anzustellen die mit Sprachen wie C oder C++ effektiv unmöglich sind. Ein gutes Beispiel dafür wären komplexe Algorithmen die ohne Kopien oder Speicher Allokation auskommen auskommen wie Parser. Das ist in Rust kein Problem wäre aber in C oder C++ mit einem riesigen Aufwand verbunden.

[grum.py]

komplexe Algorithmen die ohne Kopien oder Speicher Allokation auskommen auskommen wie Parser.

https://github.com/matt-42/iod#a-fast-m ... r--encoder :K

Nachtrag: Ach so, der Nachsatz. Mein Fehler. Eine eigene Bibliothek ist natürlich eine gewisse Komplexität. Für Parser würde ich aber auch zu Bison und nicht zu einer vollwertigen Sprache greifen - auch nicht zu Rust.
Wie gesagt: Das richtige Werkzeug für die richtige Aufgabe... und die richtige Aufgabe für Rust sehe ich nicht.

[DasIch]

Wenn man so einen Parser in Rust schreibt weiß ich dass was die Speicherverwaltung angeht nichts schief geht weil es kompiliert. Wie beweist du mir dass eine C++ Implementation da keine Fehler macht?

[snafu]

Ich habe behauptet man kann sich mit Rust nicht so leicht in den Fuss schiessen wie mit C++.

Nur, wenn du unsauberes C++ schreibst. Sauberes C++ schießt dir nirgends hin. Da sitzt das Problem wie üblich vor dem Bildschirm.

Es geht den beiden aber offenbar nicht darum, dass jemand nach 10 Jahren C++ Erfahrung irgendwann mal guten C++ Code schreibt, sondern dass guter C++ Code auch relativ schnell für Einsteiger machbar ist. Und in dem Punkt macht C++ dem Neuling meistens mehr Probleme als eine Sprache, die mit weniger Komplexität für alltägliche Aufgaben auskommt.

[grum.py]

Wenn man so einen Parser in Rust schreibt weiß ich dass was die Speicherverwaltung angeht nichts schief geht

Naja. Auch hier: Doofer Benutzer = großes Problem.

Es geht den beiden aber offenbar nicht darum, dass jemand nach 10 Jahren C++ Erfahrung irgendwann mal guten C++ Code schreibt, sondern dass guter C++ Code auch relativ schnell für Einsteiger machbar ist.

Ich behaupte, das ist möglich. Wenn man halt nicht gerade mit einer völlig anderen Sprache (Python?) anfängt, ist es erstaunlich leicht, C++ zu begreifen. Vollständiges Auswendiglernen der Spezifikation halte ich allerdings für überflüssig.

[BlackJack]

@grum.py: Mit der Argumentation sitzt das Problem *immer* vor dem Bildschirm. Das entkräftet in keiner Weise das man in C++ viel leichter unsauberen Code schreiben kann, auch wenn man sich wirklich Mühe gibt das nicht zu tun, als in anderen Programmiersprachen. Was diese anderen Programmiersprachen besser macht, weil man da ganz einfach nicht so viel zusätzlich im Kopf behalten muss was mit dem eigentlichen Problem welches man lösen will, gar nichts zu tun hat.

War ja kar das Du das Argument bringst das C (ohne ++) die Sprache ist in der man alles programmieren sollte. Bin ich auch stark dafür. Ist einfach das schnellste. C++ braucht man dafür nicht. Geschwindigkeit ist halt nicht alles, und wenn es einen Teil gibt der Geschwindigkeit braucht, gibt es immer noch C, Fortran, und Assembler.

Ich würde keinen Kernel in Python schreiben, aber auch nicht in C++. Die meisten nehmen auch C dafür. Andererseits wäre RPython vielleicht ein Kandidat. Rust wäre möglich. So oft schreiben Leute aber auch keinen eigenen Kernel.

Genau Rust ist die Sprache für die Leute die zu doof für C++ sind. Also sehr viele. Schlau genug für C++ zu sein ist kein Kompliment. Das sind Leute die stolz darauf sind unnützes Zeug zu können, womit man sich in anderen Sprachen gar nicht erst beschäftigen muss. Dann bin ich gerne zu doof und zahle auch gerne mit ein bisschen Laufzeit, die in den meisten Fällen eh nicht wirklich wichtig ist, und falls dann doch halt mit C gelöst werden kann.

Warum schrecken Dich Organisationen ab? Hinter C++ stehen sogar mehrere Organisationen. Es hat nicht primär mit der Sprache selbst zu tun, sondern mit dem Vertrauen das die Sprache eine kritische Masse erreicht und weiter gepflegt wird. D ist nett, aber wenn Digital Mars alle viere von sich streckt ist halt die Zukunft der Sprache ungewiss. Python wäre sicher auch weniger erfolgreich wenn da nicht grosse Namen als Anwender hinter stehen würden. Es reicht halt nicht wenn eine Sprache gut ist (dann würden alle Lisp programmieren ), die Leute müssen da auch irgendwelche Vorbilder sehen und darauf vertrauen das die Sprache gepflegt wird.

Doch Google selbst benutzt Go und ich kenne auch Programmierer die beruflich Go programmieren.

Na mit welcher Sprache komme ich wohl so überhaupt nicht klar. Rate doch mal.

C++17 ist doch noch Zukunft. Wurden da alte Sachen rausgeworfen? Ist der Code mit dem man da draussen in der Wildnis klarkommen muss schon auf idiomatisches C++17 umgeschrieben? Falls nicht, bis wann ist das der Fall?

Der Preis für die angeblich optimale Ressourcennutzung ist mir halt zu hoch. Vor allem werden da Ressourcen optimal genutzt, von denen in der Regel genug da sind. Ich stecke lieber mehr RAM in den Rechner als das ich mir Gedanken mache die ich mir nicht machen muss wenn sich das nur durch einen kleinen Faktor in Speicherverbrauch und Rechenleistung niederschlägt. Ich als Programmierer und meine Zeit bei der Programmierung und Fehlersuche sind Ressourcen und die werden von C++ definitiv nicht optimal genutzt. Mir ist in den allermeisten Fällen Python schnell genug. Punktuell an den Stellen wo es das nicht ist, greife ich zu Cython oder der Einbindung einer C-Bibliothek.

Oh Mann, da schreibe ich absichtlich immer das C fast eine Untermenge von C++ ist, und dann schreibe ich das einmal nicht so präzise…

Mir ist jetzt nicht klar wie Du auf „unnötig komplexer Assembler“ kommst. Falls Du auf das ”nightly”-Feature inline Assembler abzielst, das ist noch experimentell und steht ausserdem nicht direkt zur Verfügung, sondern muss erst freigeschaltet werden. Wenn das in die Sprache übernommen wird, dann kann man mit Rust vielleicht tatsächlich etwas machen was man mit Standard-C++ nicht machen kann: Kernel programmieren.

Du kennst Dich anscheinend mit Java nicht so gut aus. Was mich da unter anderem gestört hat ist das die nicht wie zum Beispiel in Python, vorhandene Bibliotheken in C verwenden, sondern wirklich alles in Java neu Programmiert hat. Nö Danke. Das ist auch wieder Ressourcenverschwendung alles noch mal zu programmieren.

Und natürlich ist zusammenkleben Programmieren. Nichts anderes macht man ständig auf den verschiedensten Ebenen. Es sei denn man schreibt wirklich Assembler und greift direkt auf die Hardware zu.

Ja, doofer Benutzer = grosses Problem. Und in anderen Sprachen halt doofer Benutzer = weniger grosses Problem. Darum C++ schlechter als Sprachen in denen das kein so grosses Problem ist. Du bist halt stolz darauf das Du die Komplexität gemeistert hast und bist nun angepisst, dass das nicht nötig ist, weil es bessere Sprachen gibt.

[grum.py]

Mit der Argumentation sitzt das Problem *immer* vor dem Bildschirm.

Beim Programmieren: Ja. Wenn eine Sprache Funktionen hast, die du nicht verstehst, dann ist es nicht die Aufgabe der Sprache, damit aufzuhören.

Das entkräftet in keiner Weise das man in C++ viel leichter unsauberen Code schreiben kann, auch wenn man sich wirklich Mühe gibt das nicht zu tun, als in anderen Programmiersprachen.

Ich habe auch schon mal gelesen, man könne in Python nur sauberen Code schreiben. Ist genau so falsch. Wie sauber dein Code ist, hängt allein von deinem Programmierstil ab. In jeder Sprache.
Um beim Bild zu bleiben: Wer mit COBOL angefangen hat, der wird ganz schön viel Python schreiben.

Was diese anderen Programmiersprachen besser macht, weil man da ganz einfach nicht so viel zusätzlich im Kopf behalten muss was mit dem eigentlichen Problem welches man lösen will, gar nichts zu tun hat.

Nur, weil du mehr Möglichkeiten hast, heißt das nicht, dass du sie nutzen musst. Du kannst in C++(17) wunderbar prozedural und ohne einen einzigen expliziten Pointer, ohne Casten und ohne Dateitypen runterprogrammieren, wenn dir danach ist. Was musst du da zusätzlich im Kopf behalten? Selbst die Validität erklärt dir im Zweifelsfall der Compiler, dafür musst du nicht selber denken.

wenn es einen Teil gibt der Geschwindigkeit braucht, gibt es immer noch C, Fortran, und Assembler.

Fortran habe ich bisher nicht benutzt, aber sein alter Konkurrent COBOL ist ziemlich träge. :K

Ich würde keinen Kernel in Python schreiben, aber auch nicht in C++.

Warum nicht? Bei C musst du deutlich mehr beachten. Ich dachte, das missfällt dir?
Unter Umständen ist C++ auch schneller, moderne Compiler haben durchaus interessante Optimierungsmechanismen.

Schlau genug für C++ zu sein ist kein Kompliment. Das sind Leute die stolz darauf sind unnützes Zeug zu können, womit man sich in anderen Sprachen gar nicht erst beschäftigen muss.

Du meinst: Komplexe Strukturen zu begreifen, im Gegensatz zu denen, die von ihnen heillos überfordert sind und, statt genug Lernwillen aufzubringen, lieber in Foren dagegen wettern, wie doof C++ ist, weil es so viele Möglichkeiten hat?
Mal über BASIC nachgedacht?

Dann bin ich gerne zu doof

Darf ich das in meine Signatur aufnehmen?

und zahle auch gerne mit ein bisschen Laufzeit, die in den meisten Fällen eh nicht wirklich wichtig ist, und falls dann doch halt mit C gelöst werden kann.

Du möchtest lieber in der Sternchensprache C schreiben, in der Sich-in-den-Fuß-schießen eigentlich notwendige Voraussetzung für ein lauffähiges Programm ist, und wetterst gleichzeitig gegen C++, das einige dieser Fallstricke umgeht oder ganz entfernt, weil es "zu gefährlich" ist? Das ist mir gerade zu kompliziert.

Warum schrecken Dich Organisationen ab? Hinter C++ stehen sogar mehrere Organisationen.

Hinter C++ steht vor allem ein ISO-Komitee.

Es reicht halt nicht wenn eine Sprache gut ist (dann würden alle Lisp programmieren )

Das würde ich übrigens durchaus befürworten. Ein bisschen mehr Standardbibliotheken könnten diesem Ökosystem nicht schaden, Quasistandards (zum Beispiel ASDF/UIOP) sind immer ein wenig misstrauisch zu betrachten.

ie Leute müssen da auch irgendwelche Vorbilder sehen und darauf vertrauen das die Sprache gepflegt wird.

"Ändert dauernd sein API" ist nun nicht unbedingt eine gute Voraussetzung, um damit zu programmieren.

Doch Google selbst benutzt Go

Wo?

C++17 ist doch noch Zukunft.

Alle namhaften Compiler unterstützen den aktuellen Technical Report bereits seit längerer Zeit.

Wurden da alte Sachen rausgeworfen?

Ja, zum Beispiel Trigraphen (schade eigentlich) und auto_ptr.

Ist der Code mit dem man da draussen in der Wildnis klarkommen muss schon auf idiomatisches C++17 umgeschrieben?

Mein C++17-Compiler kann C++98-Code kompilieren, wenn ich ihn nicht explizit darauf hinweise, dass er das nicht tun soll. In diesen C++98-Code Funktionen aus C++17 einzufügen wird keinen halbwegs brauchbaren Compiler daran hindern, ein lauffähiges Programm zu erzeugen.

Bei - zum Beispiel - Python 2 und 3 sieht das schon anders aus, nicht?

Der Preis für die angeblich optimale Ressourcennutzung ist mir halt zu hoch. Vor allem werden da Ressourcen optimal genutzt, von denen in der Regel genug da sind.

"Ich hab' ja 32 GB RAM, da kann mein Webbrowser ruhig 16 benutzen" und andere Ärgernisse der modernen Softwareindustrie...
Ich finde das rücksichtslos und Software, die so verschwenderisch mit Ressourcen umgeht, hat zumindest auf meinem Rechner keine große Zukunft.

Ich stecke lieber mehr RAM in den Rechner als das ich mir Gedanken mache die ich mir nicht machen muss wenn sich das nur durch einen kleinen Faktor in Speicherverbrauch und Rechenleistung niederschlägt.

Das ist übrigens einer der Gründe für den schleichenden Tod Javas: Diese völlige Ignoranz gegenüber der Ressourcenbelegung.

Ich als Programmierer und meine Zeit bei der Programmierung und Fehlersuche sind Ressourcen und die werden von C++ definitiv nicht optimal genutzt.

Dann bist du nicht ausreichend im Umgang mit der Debugger-Toolchain geschult, wofür die Sprache aber herzlich wenig kann.

Mir ist in den allermeisten Fällen Python schnell genug. Punktuell an den Stellen wo es das nicht ist, greife ich zu Cython oder der Einbindung einer C-Bibliothek.

Viel praktischer als C++-

Mir ist jetzt nicht klar wie Du auf „unnötig komplexer Assembler“ kommst.

Assemblersprache ist eine Teilmenge jeder mir bekannten Hochsprache. "Da ist ja eine andere Sprache mit drin, deswegen ist die Sprache scheiße" ist insofern ein eher unzureichendes Argument. Du musst die unterliegenden Funktionen ja nicht nutzen.

dann kann man mit Rust vielleicht tatsächlich etwas machen was man mit Standard-C++ nicht machen kann: Kernel programmieren.

Wieso sollte man das nicht können?

Du kennst Dich anscheinend mit Java nicht so gut aus.

Wieso? Was war an meiner Aussage nicht zutreffend?

Und natürlich ist zusammenkleben Programmieren.

Nö. Dafür musste nicht programmieren können. Können die meisten auch nicht, die so was machen. Sonst würden sie es nicht machen.
Ich schreibe mein Zeug eigentlich ganz gern mal selber. Dann weiß ich wenigstens, wo was steht.

Du bist halt stolz darauf das Du die Komplexität gemeistert hast und bist nun angepisst, dass das nicht nötig ist, weil es bessere Sprachen gibt.

Ich benutze ja keineswegs nur C++.

[BlackJack]

@grum.py: Ich kann nicht C++17 programmieren wenn ich nicht völlig isoliert alleine vor mich hinprogrammieren möchte. Ein bedeutender Anteil am Programmieren besteht darin Quelltext von anderen zu lesen. Also muss ich alles lesen und verstehen können was mir da so über den Weg läuft, und das wird ziemlich sicher nicht nur C++17 sein. Wahrscheinlich eher wenig, wenn man bedenkt wie neu C++17 ist.

Und dann muss ich mir über Speicherverwaltung gedanken machen und so Sachen wie „exception safety“ (oder ich kann keine Ausnahmen verwenden, was ich als Rückschritt empfinden würde).

Fortran wird auch heute noch benutzt weil der Compiler teilweise mehr Rückschlüsse ziehen kann als bei C und deshalb effizienteren Code erstellen kann. Allerdings möchte man Fortran eher nicht für etwas anderes als Rechenoperationen mit/auf Arrays verwenden. Deshalb wird sie auch genau dafür hauptsächlich verwendet und diese Bibliotheken dann in Programmen eingebunden die in anderen Sprachen geschrieben sind.

In C muss ich bei der Sprache auf weniger achten als bei C++. Eben weil die Sprache einfacher ist.

Nochmal: Das Problem bei C++ sind nicht die vielen Möglichkeiten, sondern die vielen Möglichkeiten sich damit in den Fuss zu schiessen. Kann mit komplexen Strukturen umgehen. Mein Lernunwillen kommt von unnützer Komplexität die mir am Ende mehr Arbeit und Fehlerquellen liefert als das sie nützlich ist.

Was soll ich über BASIC nachdenken? Die Sprache ist nicht ausdrucksstark genug. Für den C64 okay wenn die Leistung ausreicht und das Programm nicht zu komplex ist. Oder es ist ein Dialekt der im Grunde nur eine moderne Sprache wie C# oder Java in anderer Syntax ist.

Ich möchte weder in C noch in C++ schreiben. Nur wenn etwas zu langsam oder zu hardwarenah ist, dann würde ich lieber einen kleinen übersichtlichen Teil in C schreiben statt in C++. Was ich nicht kann und auch nicht lernen kann. Da bin ich zu blöd zu. Kannst Du gerne in Deine Signatur aufnehmen. Ich kann verschiedene Maschinensprachen, C, Java, Python, Haskell, Prolog, Smalltalk, JavaScript, Scheme, und noch so einiges andere. Einzig C++ geht nicht. Ich habe es mehrfach versucht, diese Sprache ist einfach nur schrecklich.

Wo Google Go benutzt? Auf Rechnern!? Komische Frage.

Der Punkt ist das *ich* C++98-Code lesen und verstehen können muss, auch wenn ich selbst nur C++17 schreibe. Das hat nichts mit dem Compiler zu tun.

Die Browser die soviel Speicher verbrauchen sind alle in C++ geschrieben. Das hat also weniger mit der Programmiersprache zu tun, sondern mit dem Programmierer. Geschwindigkeit wird da offenbar durch exzessives Cachen von gerenderten Seiten(teilen) als Grafik erreicht. Chrome verwende ich unter anderem deswegen nicht. Aber die Abwägung Geschwindigkeit vs. Speicherplatz ist sprachunabhängig. Entweder mach berechnet etwas (immer wieder) oder man hat vorberechnete Tabellen und schaut nur schnell nach. Das war auch schon auf dem C64 so.

Bei Java kann man viel spekulieren. Es kann auch sein das sie beim rauswerfen von schlechten Sachen bei C++ ein wenig zu stark übertrieben haben und es zu strikt gemacht haben. „Checked exceptions“ waren IMHO ein Fehler. Und die geschwätzige Syntax. Was sie ja jetzt in Java 8 durch lambda-Funktionen etwas abmildern und mit Streams mehr funktionale Programmierung versuchen. Und es gibt mit C# Konkurrenz die am Anfang nicht da war. Schleichenden Tod sehe ich übrigens nicht. Es ist ein Rückgang, aber der wird sich irgendwo einpendeln. Zumal es für die JVM noch andere Sprachen gibt, die dem Ökosystem frisches Leben geben. Clojure und Scala sind Sprachen die eine gewisse Verbreitung haben und auch nicht so schnell wieder verschwinden.

Die Sprache kann dafür das ich eine Debugger-Toolchain brauche die mir nicht viel nützt, weil ich die Sprache ja schon nicht kann. Wie soll mir dann die Debugger-Toolchain was nützen. Und dafür muss das ja auch erst einmal kompilieren bevor ich den Debugger verwenden kann. Der nützt mir bei 5 Bildschirmseiten Fehlerausgabe wegen eines Templates so rein gar nichts.

Ja, Cython oder `ctypes` oder `cffi` finde ich viel praktischer als alles in C++ zu schreiben. Vor allem weil ich es *sehr* selten brauche, denn das meiste ist Python, und das man eine Anbindung an eine Bibliothek benötigt für die es noch keine fertige gibt, ist auch eher selten.

Assembler ist nicht Teilmenge von C oder C++. Oder wurde das in C++ mittlerweile tatsächlich mit aufgenommen? Es ist Untermenge von D. Und bei Rust ist es in den experimentellen Builds. Ansonsten ist es für Hochsprachen doch eher ungewöhnlich. Das oft Compiler von den ”unteren Hochsprachen” auch eine nicht-standardisierte Möglichkeit bieten Assembler in den Quelltext zu schreiben zählt nicht.

Genau deswegen kann man zumindest in reinem C zum Beispiel keine Kernel programmieren. Denn in aller Regel braucht man dafür Maschinencode der nicht mit Standard-C erreichbar ist. Zum Beispiel wenn es spezielle Maschinenbefehle gibt um von einer Unterbrechungsbehandlung zurück zu springen, oder gezielt Prozessorregister für MMUs oder Traps oder ähnliches zu setzen oder abzufragen, oder wenn I/O nicht in den Speicher in den normalen Adressraum abgebildet wird, sondern über spezielle Maschinenbefehle angesprochen werden muss.

Ein Programmierer der alles selber programmieren will, auch wenn es das schon fertig und getestet als Bibliothek gibt ist kein Programmierer der Wert auf seine Zeit und robuste Programme legt. Aber das ist er ja schon dann nicht wenn er C++ dafür verwendet.

[grum.py]

Ich kann nicht C++17 programmieren wenn ich nicht völlig isoliert alleine vor mich hinprogrammieren möchte.

Doch, außer, du machst das für Geld.
Und selbst dann ist allein die Schuld deines Arbeitgebers, an veralteten Standards festzuhalten. Richtig, älteren Quellcode muss man gelegentlich lesen. Macht aber nichts, neue Compiler können auch mit uralten Standards umgehen. Python 3 hingegen hat große Probleme, Code aus Python 2 zu verstehen. Kompatibilität ist in diesem Forum vermutlich ein ganz schlechtes Argument.

Speicherverwaltung ist in modernem C++ tatsächlich optional. Möglich, aber nicht notwendig.

C soll einfacher sein als C++? Mal versucht, in C Text zu manipulieren? Wenn dir C++ prinzipiell zu viel kann, ist BASIC (nö, das läuft auch unter Win64) die logische Konsequenz.

Ich kann verschiedene Maschinensprachen, C, Java, Python, Haskell, Prolog, Smalltalk, JavaScript, Scheme, und noch so einiges andere. Einzig C++ geht nicht.

Respekt. Mit Haskell komme wiederum ich nicht klar. Zu viele Klammern.

Ja, Go auf Rechnern. Aber für welche Software? Von Google kenne ich da keine.

Browser sind auch deshalb so lahmarschig, weil irgendwelche BWLer nicht verstanden haben, wofür ein Browser da ist. Eine schlanke Version von Firefox wäre mal was...

Java kann jetzt Lambda? Wie die meisten anderen Sprachen, C++ eingeschlossen? Hui... Die furchtbaren Java-Stacktraces sind einer der Gründe, warum ich Clojure, Scala und Perl6 eher lächerlich finde. In einem Blog stand dazu mal eine passende Frage: Does your runtime still barf JVM stack traces? 5 Bildschirmseiten Fehlerausgabe? Da muss der Benutzer schon gewaltig verkackt haben...

Ja, du kannst in Python wie in Java, Lisp, C++, Node.js, Ruby... eine ganze Menge Code einfach aus Vorhandenem zusammenklicken. Aber davon begreifst du deine eigene Software nicht. Viel Spaß beim Debuggen.

Assembler ist nicht Teilmenge von C oder C++.

Doch, natürlich. Am Ende kommt genau das heraus. Auch in Rust.
Und natürlich ist das Schlüsselwort asm keine Besonderheit von Pascal. (Wobei die Frage, wieso so wenige Kernel in Pascal geschrieben werden, auch mal interessant wäre.) C++ kennt es jedenfalls.

[bwbg]

Zu viele Klammern in Haskell? Du hast wohl die ($)-Funktion übersehen

C++ wirkt in vielen Fällen kryptisch. Das ist dem Sprachumfang geschuldet. Haskell wirkt auch kryptisch. Hier ist das Paradigma ursächlich.

Sprachen sind einer Marktwirtschaft unterworfen. Sie müssen mir anderen konkurrieren und sich weiterentwickeln. Viele tun das auch, unterwerfen sich jedoch der Abwärtskompatibilität. Werden hier nun neue Sprachbestandteile hinzugefügt, wächst zwangsläufig der Umfang.

Bildlich geschrieben: Jede Sprache bietet Möglichkeiten, sich in die Füße zu schießen. Manche Sprachen ließen gar einen NRA-Kongress sprachlos werden.

[grum.py]

Dem Markt sind Programmiersprachen weitgehend egal, sie sind ja selten die Produkte. Entscheidend ist, was in ihnen programmiert wird, würde ich sagen.

Und da gibt es bei C++ aus guten Gründen recht viel.

[Sirius3]

@gumpy: So viel unqualifizierte Kommentare, das halt ich jetzt nicht mehr aus. Klar löscht man alle zwei Jahre seinen kompletten Code, weil eine neue C++-Version rauskommt, und man ja immer nur mit dem neusten Standard schreibt. Und auf einen Schlag sind auch alle Bibliotheken, die man so braucht auch nur noch mit dieser Version geschrieben.
Nur weil C von der Komplexität einfach ist, heißt das noch nicht, dass man deshalb alles von Grund auf selbst schreiben muß. Stringmanipulation macht man gar nicht, weil man dafür Python verwendet oder nimmt eine Bibliothek, die die entsprechenden Funktionen bereitstellt. Ich weiß jetzt nicht, wie es mit C++17 aussieht, aber Unicode-Unterstützung war zumindest bis vor kurzem quasi nicht vorhanden.

Von dem, was ein Browser macht, hast Du keine Ahnung. Alle Programmierer außer Dir als unfähig hinzustellen, weil sie ach so viel Speicher verschwenden, ...

Dass es einen Unterschied macht, ob man Assembler-Befehle nativ unterstützt, oder einfach nur Textzeilen blind in den fertig compilierten Code kopiert, hast Du noch nicht verstanden. C++ macht nichts anderes und es gibt keine zwei Compiler-Varianten, die das auf die selbe Art und Weise tun.

C++ geht den Weg, immer etwas neues Draufzupacken, um ja nicht die Rückwärtskompatibilität zu zerstören. Dass Code der in der Variante 98 geschrieben wurde, dann doch nicht mit 17 zusammenarbeitet, ist dann die andere Seite der Geschichte. Der Python-Guru hat sich für einen radikal anderen Weg entschieden und hat nach langer Planung alte Zöpfe abgeschnitten. Was dabei rauskam, ist eine neue Sprache mit sehr ähnlicher Syntax.
C++ ist die gleiche Sprache, man muß aber komplett anders programmieren.
Beim Umstieg wird man in Python also gezwungen ein bißchen etwas anzupassen, sonst läuft gar nichts. Bei C++ zwingt einen nur eine alte Bibliothek, die nicht komplett neu geschrieben wurde, dazu, alles bisherige wegzuwerfen und wieder C++98 zu programmieren, obwohl man denkt, man könnte das doch mischen.

[grum.py]

Klar löscht man alle zwei Jahre seinen kompletten Code, weil eine neue C++-Version rauskommt, und man ja immer nur mit dem neusten Standard schreibt.

Moment, Moment: Diese Implikation habe ich nirgends getroffen. C++ ist es egal, welchen seiner Standards du verwendest.

Und auf einen Schlag sind auch alle Bibliotheken, die man so braucht auch nur noch mit dieser Version geschrieben.

Also ich kann in C++ durchaus zehn Jahre alte Bibliotheken mit neuen Sprachfeatures kombinieren. Wo liegt das Problem?

Stringmanipulation macht man gar nicht, weil man dafür Python verwendet oder nimmt eine Bibliothek, die die entsprechenden Funktionen bereitstellt.

Ich habe noch nie eine C-Anwendung geschrieben, bei der ich das unbedingte Bedürfnis hatte, Pythoncode einzubinden. :K Und natürlich kannst du versuchen, Probleme zu lösen, indem du einfach mehr Bibliotheken einbindest, aber das erscheint doch aus meiner Perspektive eher als Holzweg.

Ich weiß jetzt nicht, wie es mit C++17 aussieht, aber Unicode-Unterstützung war zumindest bis vor kurzem quasi nicht vorhanden.

In C hingegen ...
C++17 hat u8-String-Literals als Neuerung bekommen, verhält sich damit ungefähr wie Python.

Von dem, was ein Browser macht, hast Du keine Ahnung. Alle Programmierer außer Dir als unfähig hinzustellen, weil sie ach so viel Speicher verschwenden, ...

Ich weiß, dass es auch anders geht, weil ich weiß, was ein Browser macht. Das Problem ist, dass er mehr machen soll als bloß Websites anzuzeigen. (Vgl. NetSurf, der kann nix anderes, startet schnell, ist kompakt, verzichtet aber auf komplexe CSS- oder JavaScript-Funktionen. (Die JavaScript-Engine dort ist noch eher neu, aber eben auch auf Ressourcenschonung optimiert.)

Dass es einen Unterschied macht, ob man Assembler-Befehle nativ unterstützt, oder einfach nur Textzeilen blind in den fertig compilierten Code kopiert, hast Du noch nicht verstanden.

Ob ich Assemblerbefehle "übernehme" oder "irgendwo hin kopiere", erscheint mir jetzt nicht wie ein gewaltiger Unterschied. Vom Prozessor werden sie in jedem Fall genau so ausgeführt, wie sie reinkommen. :K In diesem Fall wäre etwas Erläuterung tatsächlich super.

C++ geht den Weg, immer etwas neues Draufzupacken, um ja nicht die Rückwärtskompatibilität zu zerstören.

Das stimmt nicht, C++ entfernt häufiger "alte" Features. Nur halt nicht alles auf einmal.

Der Python-Guru hat sich für einen radikal anderen Weg entschieden und hat nach langer Planung alte Zöpfe abgeschnitten. Was dabei rauskam, ist eine neue Sprache mit sehr ähnlicher Syntax.

Python2, Python3... Perl5, Perl6... auf dass sich die Lager einander um die Weltherrschaft streiten mögen. Und das soll jetzt irgendwie besser sein?
Immer, naja: häufig, wenn ich versuche, eine ausreichend komplexe Anwendung in Python zu schreiben (ich bin gern bereit zuzugeben, dass Python eine der besten Sprachen für Prototyping ist), scheitere ich eher früher als später daran, dass die meisten Bibliotheken mit meiner jeweils ausgesuchten Pythonversion nicht zusammenarbeiten. Ein Hurra der Kompatibilität.

Bei C++ zwingt einen nur eine alte Bibliothek, die nicht komplett neu geschrieben wurde, dazu, alles bisherige wegzuwerfen

Konkretes Beispiel? Die libcurl zum Beispiel ist nicht mal in C++ geschrieben, sondern gut abgehangener C-Code, und meinem C++17-Compiler ist es völlig egal, dass ich sie trotzdem einbinde.

[BlackJack]

@grum.py: Ich denke ich verstehe jetzt warum Du das Problem nicht verstehst: Wenn man immer alles selber schreibt, dann muss man natürlich keinen Code lesen und verstehen den andere geschrieben haben. In der realen Welt sieht es halt anders aus. Da muss man vorhandenen Code verwenden und mit anderen Leuten zusammenarbeiten. Das ist wahrscheinlich auch die Schuld des Arbeitgebers, das der Teams von mehreren Programmierern an Programme setzt, und nicht will das Zeit und Geld damit verschwendet wird, dass jeder von Null mit der Standardbibliothek und nichts anderen anfängt. Oder sollte man sich die STL auch selbst programmieren, damit man auch wirklich versteht was man da macht? Sind Betriebssystemaufrufe erlaubt, oder schreibt man sich den Kernel auch besser selbst? Firmware in Peripheriegeräten?

Was soll „Speicherverwaltung ist in modernem C++ tatsächlich optional“ bedeuten? Ich kann C++-Programme schreiben ohne mir über Speicherverwaltung Gedanken machen zu müssen? Also grössere Programme die tatsächlich dynamisch Objekte anlegen und die in der Gegend herum reichen? So wie das in Sprachen mit automatischer Speicherverwaltung geht?

Die Sprache C *ist* einfacher und weniger komplex als C++. Vergleiche einfach mal den Umfang von Syntaxkonstrukten und zugehöriger Semantik. Das sollte eigentlich offensichtlich sein. Und ja, ich habe schon Programme in C geschrieben die Texte manipulieren.

Warum BASIC die logische Konsequenz sein soll wenn einem C++ zu komplex ist, verstehe ich nicht. Warum nicht Python? Io? Smalltalk? …? Warum führt das zwangsläufig zu BASIC? Und welcher Dialekt davon?

Go ist eine Sprache die gut für webbasierte Dienste geeignet ist, aufgrund der Unterstützung für nebenläufige Programmierung („goroutines“) und der Standardbibliothek (z.B. HTTP-Kram). Dafür wird Google das dann wohl auch einsetzen. Zum Beispiel für dl.google.com, der Downloadserver für alle möglichen Google-Produkte/-Dienste.

Browser werden hauptsächlich von BWLern benutzt? Denn die Benutzer sind für fette Browser verantwortlich. Das Spielchen „wir fangen mal eine schlanke Version von Software X an, weil die mittlerweile viel zu fett ist“, endet in aller Regel damit das die Benutzer sich erst freuen, und dann nach und nach mehr Features verlangen bis die neue Software genau so fett ist wie die alte. Oder fetter. Das sind keine BWLer die das planen.

Falls die fünf Seiten Java-Stacktraces eine Replik auf meine Kritik an C++-Template-Fehlermeldungen sein sollte: Liegt wahrscheinlich an mir, aber ich verstehe bei den Template-Fehlermeldungen Null, weil die voll von irgendwelchen verschachtelten internen Templates sind, während Stacktraces zur Laufzeit in der Regel irgendwo den Teil enthalten den ich geschrieben habe, meistens am Ende, und ich dort üblicherweise auch die Stelle finde an der ich den Fehler gemacht habe, oder die ich näher Untersuchen muss um den Fehler zu finden. Bei Template-Fehlermeldungen verstehe ich gar nichts. Da habe ich mal von einem C++-Programmierer den Rat bekommen, den betroffenen Code wegwerfen und sorgfältig neu schreiben, in der Hoffnung den gleichen Fehler nicht noch mal zu machen, weil Template-Fehlermeldungen niemand wirklich versteht der sich nicht durch die Interna der Templates des jeweiligen Compilers wühlt.

Man begreift seine eigene Software wenn man Bibliotheken benutze statt alles neu zu schreiben. Das ist der normale Weg Software zu schreiben. Das machen alle, selbst C++-Programmierer. Nur so Spezialisten wie Du nicht. Ich habe auch keine Probleme beim Debuggen. Warum sollte man?

Assembler ist nicht Teilmenge von einer *Sprache* nur weil es Compiler gibt die die Sprache in Assembler übersetzen können. Wenn man der Argumentation so folgt, dann ist JavaScript eine Teilmenge von C und C++ weil man die mit ``emscripten`` zu JavaScript kompilieren kann.

Das Schlüsselwort ASM gibt es in Pascal nicht. Das gibt es in ausgewählten Compilern, die das jeweils nicht 100% gleich implementieren, weil es nicht zur Sprache Pascal gehört.

Browser ohne CSS und JavaScript? Versuch damit mal produktiv das Internet zu benutzen. Da kommst Du heute nicht mehr weit. Schlanker Browser wäre schön, aber benutzbar sollte das Internet, so wie es ist, halt schon noch bleiben.

Also entweder kann man mit einem aktuellen C++ Compiler auch alten Code übersetzen oder es werden alte Features entfernt. Beides geht nicht.

Und bei der Python-Programmierung hast Du Probleme mit der Versionskompatibilität von Bibliotheken? Was für Bibliotheken? Ich denke dann versteht man seine Programme nicht mehr und kann die auch nicht mehr debuggen? Warum programmierst Du das nicht alles selbst? Jetzt verwirrst Du mich ein wenig.

[grum.py]

Ich denke ich verstehe jetzt warum Du das Problem nicht verstehst: Wenn man immer alles selber schreibt, dann muss man natürlich keinen Code lesen und verstehen den andere geschrieben haben.

Muss ich manchmal, versuche ich aber zu vermeiden. "Not Invented Here". Ich kann Leute nicht ernst nehmen, die für triviale Funktionen einfach irgendein Paket einbinden. Über den Node.js-Zusammenbruch "neulich" habe ich schallend gelacht. Ein Dreizeiler, von dem Hunderte Pakete abhängen, weil alle zu faul sind, das selber zu schreiben. Wer keinen Bock auf Programmieren hat, der sollte es vielleicht besser lassen.

Oder sollte man sich die STL auch selbst programmieren, damit man auch wirklich versteht was man da macht?

Nicht unbedingt. In den meisten Fällen wäre das Verschwendung. In Python schreibe ich mir ja auch nicht meinen eigenen Datenbankadapter, der am Ende doch nur das Gleiche macht wie sqlite3. Aber nicht jede Sprache hat erschöpfend umfassende Standardbibliotheken. C zum Beispiel verzichtet aus gutem Grund darauf, dir die Boilerplate zu servieren.

Was soll „Speicherverwaltung ist in modernem C++ tatsächlich optional“ bedeuten? Ich kann C++-Programme schreiben ohne mir über Speicherverwaltung Gedanken machen zu müssen?

Ja. Beziehungsweise bedingt: malloc() u.a. sind nicht zwingend notwendig, um ein C++-Programm zu schreiben. Objekte musst du schon noch instanziieren, aber was die im Speicher machen, musst du nicht explizit festlegen.

Die Sprache C *ist* einfacher und weniger komplex als C++.

Korrekt. Deswegen musst du da auch mehr berücksichtigen. Wie viele Sternchen haben deine C-Programme denn so?

Warum BASIC die logische Konsequenz sein soll wenn einem C++ zu komplex ist, verstehe ich nicht. Warum nicht Python? Io? Smalltalk? …? Warum führt das zwangsläufig zu BASIC? Und welcher Dialekt davon?

Lass' mich doch wenigstens einmal ein bisschen übertreiben. Alternativ auch Pascal, noch so eine typische Anfängersprache. Ich habe mich auch sehr lange nicht an C++ rangetraut, weil es so anders war, nachdem ich QBASIC, Visual Basic, Pascal, ein bisschen Delphi u.a. "ausprobiert" hatte.

Go ist eine Sprache die gut für webbasierte Dienste geeignet ist, aufgrund der Unterstützung für nebenläufige Programmierung („goroutines“) und der Standardbibliothek (z.B. HTTP-Kram).

Ah, verstehe. Allerdings fehlte mir bisher der Zusammenhang zum Googleportfolio. Steht ja nirgends, so weit ich das sehen konnte.

Browser werden hauptsächlich von BWLern benutzt?

Nicht ganz. Ich hatte darüber vor einer Weile mal einen Rant geschrieben. (Werte Moderatoren: 'tschuldigt, falls das hier nicht so gern gesehen ist.) Zusammenfassung: Seit irgendwelche Wirtschaftsfuzzis das bis dahin einigermaßen brauchbare Web als Markt entdeckt haben, ist es mit dem Fokus auf Kompaktheit vorbei. Wir Benutzer könnten super darauf verzichten, dass Firefox auch als Betriebssystem für ein Officepaket benutzt werden kann. Ein Browser soll, das behaupte ich, ein Betrachter für HTML-Dokumente und keine Plattform sein. Nein, Benutzer haben sich das nicht ausgesucht.

Falls die fünf Seiten Java-Stacktraces eine Replik auf meine Kritik an C++-Template-Fehlermeldungen sein sollte: Liegt wahrscheinlich an mir, aber ich verstehe bei den Template-Fehlermeldungen Null (...)

Das ist wahrscheinlich auch Erfahrungssache. Ich habe noch nie furchtbarere Fehlermeldungen als die von Java gesehen. :K
Vielleicht muss man sich daran auch nur gewöhnen.

Das machen alle, selbst C++-Programmierer. Nur so Spezialisten wie Du nicht.

"Alle", natürlich. Zum Glück nicht, sonst wäre der Markt eine ziemliche Monokultur. Gibt es ja schon ist ein erschreckend schlechtes Argument gegen das Schreiben neuer Programme oder Bibliotheken.

Assembler ist nicht Teilmenge von einer *Sprache* nur weil es Compiler gibt die die Sprache in Assembler übersetzen können.

Wir schweifen ein bisschen ab. Das ursprüngliche "Problem", das du hattest, war ja, dass C++-Compiler auch C verstehen, was du für schlecht hältst. Dass HTML-Betrachter oft auch JavaScript "können", stört dich aber nicht? gcc wäre ohne Unterstützung für ANSI-C vermutlich auch nicht merklich kleiner, insofern ist mir immer noch nicht ganz klar, was nun daran so schlimm sein soll.

Das Schlüsselwort ASM gibt es in Pascal nicht. Das gibt es in ausgewählten Compilern, die das jeweils nicht 100% gleich implementieren, weil es nicht zur Sprache Pascal gehört.

Und der Unterschied zwischen asm in Turbo Pascal und asm in Free Pascal besteht zum Beispiel worin?

Browser ohne CSS und JavaScript?

Nein, beides wird unterstützt, nur nicht unbedingt alle "Features". Aber das ist beim Chrome ja trotz der zehnfachen Ressourcenbelegung auch nicht anders.
Ich finde es übrigens entspannend, ohne JavaScript zu "surfen". Eine Website, die es voraussetzt, dass ich ihr erlaube, Code auf meinem Rechner auszuführen, um sie auch nur ansehen zu können, ist mir doch eher suspekt. Und auch für "Interaktion" sollte das nicht unbedingt notwendig sein. Sieht halt besser aus ist ein unzureichendes Argument. :K (Wohl wissend, dass ich den Fehler auch schon selbst gemacht habe.)

"Produktiv das Internet benutzen"? Meine Güte. Das Ding ist (auch) ein Unterhaltungsmedium. Was willst'n da produktiv sein?