[Tevez]

Hallo,

Ich bin momentan am C++ lernen. Habe aber in letzter Zeit vermehrt gehört dass für GUI's gerade unter Windows, C# mehr Möglichkeiten bieten soll und auch unkomplizierter ist.
Mich würde nun interessieren: Wie sehr unterscheiden sich C++ und C# von der Syntax und von der Konzeption her. Kann ich als C++-Programmierer automatisch oder mit geringem Aufwand auf C# umsteigen wenn nötig? Und hat C# wirklich so viele Vorteile?

Vielleicht gibt es hier ja ein paar Leute die sich mit beiden Programmiersprachen etwas auskennen.

[ojas]

... dass für GUI's gerade unter Windows, C# mehr Möglichkeiten bieten soll und auch unkomplizierter ist.

Stimmt. Das liegt aber nicht an C# selbst, sondern an .NET (der Klassenbibliothek, die mit C# verwendet wird) und an Visual Studio (die IDE, die für Windowsprogramme benutzt wird). Außerdem gilt das nicht gerade unter Windows sondern ausschließlich unter Windows.

Mit Qt gibt es aber auch in C++ eine Möglichkeit, GUIs auf einfache Weise zu erstellen. Und mit ein wenig Mühe sind die Anwendungen dann auch platformunabhängig.

Wie sehr unterscheiden sich C++ und C# von der Syntax und von der Konzeption her.

Von der Syntax her gering. Es sind beides Sprachen, die sich an C anlehnen und Features für objektorientierte Programmierung mitbringen.

Vom Konzept her erheblich.

C#:

• Interfaces
• Automatische Speicherverwaltung
• Kastrierte Pointer

C++:

• Mehrfachvererbung
• RAII
• Speicherlecks

Kann ich als C++-Programmierer automatisch oder mit geringem Aufwand auf C# umsteigen wenn nötig?

Mit geringem Aufwand. Umgekehrt wird's schon schwieriger.

[Headcool]

Stimmt. Das liegt aber nicht an C# selbst, sondern an .NET (der Klassenbibliothek, die mit C# verwendet wird) und an Visual Studio (die IDE, die für Windowsprogramme benutzt wird). Außerdem gilt das nicht gerade unter Windows sondern ausschließlich unter Windows.

Mit Qt gibt es aber auch in C++ eine Möglichkeit, GUIs auf einfache Weise zu erstellen. Und mit ein wenig Mühe sind die Anwendungen dann auch platformunabhängig.

Stimmt nicht. C++ ist eine native Sprache und dank Unterstützung von inline-Assembler kann man jedwedes Programm machen was irgenwie möglich ist. Somit könnte man sich auch eine .NET-Runtime-Environment programmieren und so dank C++ mit einer Sprache programmieren die zwar 100%ig so aussieht wie C#, aber kein C# ist.

Ist halt ziemlich aufwendig. Aber was ich damit sagen will, ist dass man mit C++ keinerlei Einschränkungen hat. Man kann in keiner Sprache ein Programm schreiben, welches man nicht mit C++ auch schreiben könnte.

Es gibt also defacto unendlich Möglichkeiten mit C++ eine GUI unter Windows zu programmieren. Man muss sich halt eventuell seine eigene Bibliothek schreiben.

Meiner Meinung nach sind die wichtigsten Kernpunkte der zwei Sprachen:

C#:
Große Bibliothek
JIT
langsam
Müllabfuhr
schnelle Entwicklung

C++:
nativ
schnell
mächtig
aufwendige Entwicklung

[Thoronador]

Stimmt nicht. C++ ist eine native Sprache und dank Unterstützung von inline-Assembler kann man jedwedes Programm machen was irgenwie möglich ist.

Ja genau, und man nutzt ja auch extra eine Hochsprache wie C++, nur um darin am Ende mit Assembler wieder auf niedriger Maschinenebene programmieren zu können und die Vorteile, welche so eine Hig-Level-Abstraktion mit sich bringt, dabei komplett aufzugeben. Super Idee!

Somit könnte man sich auch eine .NET-Runtime-Environment programmieren und so dank C++ mit einer Sprache programmieren die zwar 100%ig so aussieht wie C#, aber kein C# ist.

Ist halt ziemlich aufwendig.

Vielleicht solltest du den letzten Satz rot vorheben und mit der Aufschrift "Warnung!" versehen. Es ist verdammt aufwendig(!), wenn man in Assembler die .NET-Klassenbibliothek (oder meinetwegen auch irgendeine andere, umfangreiche Bibliothek) nachbauen will. Wer mal eben so ein paar Jahre Zeit, die entsprechende Erfahrung und auch genügend Motivation hat, kann das sicherlich machen. Praktisch wird aber kein guter Programmierer seine Zeit für so ein Unterfangen verschwenden - denn nichts anderes als Zeitverschwendung ist es, was du hier als Möglichkeit vorschlägst. Damit ist diese Möglichkeit bestenfalls für rein theoretische Betrachtungen gut, in der Praxis ist es aber irrelevant, weil's wie gesagt keiner machen würde.

Aber was ich damit sagen will, ist dass man mit C++ keinerlei Einschränkungen hat. Man kann in keiner Sprache ein Programm schreiben, welches man nicht mit C++ auch schreiben könnte.

Newsflash: Die meisten gängigen Programmiersprachen, darunter auch C++ und C#, sind turing-vollständig. Damit kann man theoretisch in jeder der Programmiersprachen erreichen, was man auch in der anderen erreichen kann. Das ist also kein Alleinstellungsmerkmal von C++. Nur unterscheidet sich in den verschieden Sprachen der Programmieraufwand, mit dem man das gewünscht Ergebnis erreicht. Daher entscheidet ein erfahrener Programmierer auch je nach Anwendungsgebiet und Eignung, welche Sprache er für das jeweilige Programm nimmt. Oder um es sinngemäß mit Bjarne Stroustrup zu sagen: "C++ is a nice language to write some code, but C++ is an awful language to write all code."

[Headcool]

Ja genau, und man nutzt ja auch extra eine Hochsprache wie C++, nur um darin am Ende mit Assembler wieder auf niedriger Maschinenebene programmieren zu können und die Vorteile, welche so eine Hig-Level-Abstraktion mit sich bringt, dabei komplett aufzugeben. Super Idee!

Der Vorteil von C++ ist, dass man beides gleichzeitig machen. Man muss ja nicht nur HL- oder nur LL-programmieren. Man kann sein ganzes Programm in HL machen und die 10% des Codes die performance fressen in LL. Man kann zb. in einer virtual Methode(ein HL-Konstrukt) inline-asm-Code(ein LL-Konstrukt) einbauen um so bspw. auf die AVX-Befehlssatzerweiterung zuzugreifen.
Nur LL wäre ziemlich eklig, nur HL wäre ziemlich langsam. In der Mischung davon liegt die Lösung. C++ ist da ein ziemlich guter Kandidat.

Vielleicht solltest du den letzten Satz rot vorheben und mit der Aufschrift "Warnung!" versehen. Es ist verdammt aufwendig(!), wenn man in Assembler die .NET-Klassenbibliothek (oder meinetwegen auch irgendeine andere, umfangreiche Bibliothek) nachbauen will. Wer mal eben so ein paar Jahre Zeit, die entsprechende Erfahrung und auch genügend Motivation hat, kann das sicherlich machen. Praktisch wird aber kein guter Programmierer seine Zeit für so ein Unterfangen verschwenden - denn nichts anderes als Zeitverschwendung ist es, was du hier als Möglichkeit vorschlägst. Damit ist diese Möglichkeit bestenfalls für rein theoretische Betrachtungen gut, in der Praxis ist es aber irrelevant, weil's wie gesagt keiner machen würde.

Natürlich ist es verdammt aufwendig, aber darum geht es ja gar nicht. Es geht darum, dass es geht würde.

Newsflash: Die meisten gängigen Programmiersprachen, darunter auch C++ und C#, sind turing-vollständig. Damit kann man theoretisch in jeder der Programmiersprachen erreichen, was man auch in der anderen erreichen kann. Das ist also kein Alleinstellungsmerkmal von C++. Nur unterscheidet sich in den verschieden Sprachen der Programmieraufwand, mit dem man das gewünscht Ergebnis erreicht. Daher entscheidet ein erfahrener Programmierer auch je nach Anwendungsgebiet und Eignung, welche Sprache er für das jeweilige Programm nimmt. Oder um es sinngemäß mit Bjarne Stroustrup zu sagen: "C++ is a nice language to write some code, but C++ is an awful language to write all code."

Du hast leider nicht verstanden was ich gemeint habe. Ich meinte nicht, dass man jedes Problem in C++ lösen kann was man in einer anderen Sprache lösen kann. Ich meine damit, dass man jedes Problem in C++ mindestens genauso effizient lösen kann wie in einer anderer Sprache.
Sagen wir mal wir haben eine Problemstellung. Dafür gibt es eine perfekte Lösung die abhängig von gewissen Zielen ist(Geschwindigkeit, Speicherverbrauch, Genauigkeit, etc.).
Für diese perfekte Lösung gibt es einen gewissen perfekten Maschinencode. Also gibt es auch einen perfekten Assemblercode. Dank inline-Assembler kann man diese perfekte Lösung auch in C++ bauen.
Bei einer Sprache ohne inline-Assembler wird man sich schwer tun. Die Compiler die normalerweise verwendet werden, verwenden auf komplexeren ISA wie zB x86 nur einen kleinen Teil des gesamten Befehlsatzes. Es ist aber wahrscheinlich, dass die perfekte Lösung auch den ein oder anderen asm-befehl verwendet, den diese Compiler nicht beherrschen. Und somit kann man die perfekte Lösung nicht in allen Sprachen bauen.

Ich sage auch nicht, dass man nur in C++ oder nur in Assembler programmieren sollte. Ich sage, dass man damit die perfekte Lösung bauen kann. Wir sind allerdings leider nicht intelligent genug um solche perfekten Lösungen für größere Programme bauen zu können. Es gibt zuviele Parameter, zuviele Abhängigkeiten. Wir müssen uns mit Dingen wie zb. OO weiterhelfen. Deshalb sind solche Dinge auch nicht perse schlecht, weil sie Menschen helfen besseren Code zu erzeugen. Aber man sollte sich im klaren sein, dass man damit keine Perfektion erreichen kann.

[Thoronador]

Der Vorteil von C++ ist, dass man beides gleichzeitig machen. Man muss ja nicht nur HL- oder nur LL-programmieren. Man kann sein ganzes Programm in HL machen und die 10% des Codes die performance fressen in LL. Man kann zb. in einer virtual Methode(ein HL-Konstrukt) inline-asm-Code(ein LL-Konstrukt) einbauen um so bspw. auf die AVX-Befehlssatzerweiterung zuzugreifen.
Nur LL wäre ziemlich eklig, nur HL wäre ziemlich langsam. In der Mischung davon liegt die Lösung. C++ ist da ein ziemlich guter Kandidat.

Dieser Abschnitt setzt aber eine Anzahl von Annahmen als gegeben voraus, die so nicht zutreffen müssen.

• Eine Sache ist zum Beispiel die Annahme, dass mittels High-Level-Programmierung erstellter Code per se immer langsamer ist als mittels Low-Level-Programmierung erzeugter Code. Diese Annahme ist mindestens fragwürdig wenn nicht sogar falsch, da letztlich immer noch Compiler (und Linker) als Zwischenstufe vorhanden sind, um aus dem Programmcode letztlich die maschinenausführbare Datei zu erzeugen. Jeder gute, moderne Compiler führt aber auch etliche Optimierungen durch, wodurch der am Ende erzeugte Maschinencode schon sehr effizient ist. Beispielsweise kann man im High-Level-Code mittels Iterator einen std::vector komplett durchlaufen, und der dabei erzeugte Code ist bei guten Compilern faktisch identisch zu dem Code, den man erhalten würde, wenn man stattdessen ein Level runtergeht und einen Array nimmt und diesen in einer Zählschleife durchläuft.
• Weiterhin wird dabei angenommen, dass der von Hand geschriebene Assemblercode schnelleren/besseren Maschinencode erzeugt als der vom Compiler erzeugte Code. Bei einem erfahrenen Assemblerprogrammierer mag das vielleicht der Fall sein, im Allgemeinen finde ich das zweifelhaft und es dürfte bei den meisten nur darauf hinauslaufen, dass sie aufgrund des Assemblercodes unnötigerweise mehr Zeit in das Schreiben ihrer Programme investieren, um am Ende Maschinenanweisungen zu erzeugen, die nicht spürbar schneller sind als die von einem optimierenden Compiler erzeugten Anweisungen.
• Die dritte Annahme ist die, dass man einen Compiler nicht von sich aus dazu bringen kann, bestimmte Befehlssatzerweiterungen zu nutzen, siehe das AVX-Beispiel. Das ist schlichtweg falsch. Beim GCC gibt es z.B. die Compileroptionen --mavx und --mavx2, mit denen man explizit die AVX- und AVX2-Erweiterungen im Befehlssatz zulassen kann. Außerdem gibt's mittels --march=corei7 die Möglichkeit, den Code für einen bestimmten CPU-Typ (hier Intel Core i7) zu optimieren. Der Code läuft dann zwar nicht mehr zwingend auf anderen Prozessoren, aber das ist beim Assemblercode ja erst recht nicht gegeben. Ähnliche Optionen gibt es bei GCC für andere Befehlssätze und CPU-Typen.

Vergleichbare Möglichkeiten dürfte es auch bei anderen, aktuellen Compilern geben. Im Zweifelsfall ist es immer noch einfacher, seinen kompletten Code auf dem hohen Abstraktionslevel einer Hochsprache wie C++ zu schreiben und ggf. nur die Compileroptionen anpassen zu müssen, anstatt teilweise Assemblercode zu nutzen und für jeden relevanten Prozessor die Assemblerabschnitte überarbeiten zu müssen.

Natürlich ist es verdammt aufwendig, aber darum geht es ja gar nicht. Es geht darum, dass es geht würde.

Wenn du mir jetzt noch erklären kannst, wie das bei der ursprünglichen Frage weiterhilft, wäre dem Threadersteller vielleicht schon gedient, denn bisher sieht's einfach so aus, dass diese Möglichkeit praktisch nie zum Einsatz kommen wird.

Ich meine damit, dass man jedes Problem in C++ mindestens genauso effizient lösen kann wie in einer anderer Sprache.

Oha, das ist aber eine sehr gewagte Behauptung. Kannst du die auch beweisen?
Da du dich dabei wieder einmal auf Assembler stützt, solltest du besser sagen, dass man in Assembler jedes Problem mindestens genau so effizient lösen kann wie in einer beliebigen anderen Sprache. Denn darauf läuft's doch am Ende hinaus, oder?

[Pyrokar]

Sagen wir mal wir haben eine Problemstellung. Dafür gibt es eine perfekte Lösung die abhängig von gewissen Zielen ist(Geschwindigkeit, Speicherverbrauch, Genauigkeit, etc.).
Für diese perfekte Lösung gibt es einen gewissen perfekten Maschinencode. Also gibt es auch einen perfekten Assemblercode. Dank inline-Assembler kann man diese perfekte Lösung auch in C++ bauen.

Das mag für die angegebenen Ziele stimmen, da diese aber in der Praxis so eher nicht vorkommen, spielt das keine große Rolle. In der Praxis sind zielen Vorgaben bzgl. Geschwindigkeit üblicherweise auf "so schnell wie nötig" und nicht "so schnell wie möglich" ab - u.a. alleine schon wegen des Energiebedarfs. Für Speicherbedarf und Genauigkeit gilt ähnliches. Dafür kommen aber zusätzliche Ziele wie möglichst kurze Umsetzungsdauer, hohe Robustheit und Wartbarkeit dazu. Und schon ist Assembler - und damit auch C++ auf Grundlage der Argumentationskrücke Inline-Assembler - keine per se perfekte Universalsprache mehr.

Worauf ich hinaus will, die rein performance-bezogenen Aspekte mögen ja irgendwo stimmen, sind aber in der Wirklichkeit der Software-Entwicklung, so wie sie dargelegt wurden, vor allem eines:
[Bild: Irrelephant.png]

[Headcool]

Das mag für die angegebenen Ziele stimmen, da diese aber in der Praxis so eher nicht vorkommen, spielt das keine große Rolle. In der Praxis sind zielen Vorgaben bzgl. Geschwindigkeit üblicherweise auf "so schnell wie nötig" und nicht "so schnell wie möglich" ab - u.a. alleine schon wegen des Energiebedarfs. Für Speicherbedarf und Genauigkeit gilt ähnliches. Dafür kommen aber zusätzliche Ziele wie möglichst kurze Umsetzungsdauer, hohe Robustheit und Wartbarkeit dazu. Und schon ist Assembler - und damit auch C++ auf Grundlage der Argumentationskrücke Inline-Assembler - keine per se perfekte Universalsprache mehr.

Worauf ich hinaus will, die rein performance-bezogenen Aspekte mögen ja irgendwo stimmen, sind aber in der Wirklichkeit der Software-Entwicklung, so wie sie dargelegt wurden, vor allem eines:
[Bild: Irrelephant.png]

Wie gesagt. Je nachdem was man braucht gibt es einen anderen "perfekten Code". Man braucht ja nicht immer Speed. Vielleicht braucht man auch kleinen Energieverbrauch oder wie schon gesagt Präzision(bspw. Simulation von Chaossystemen).
Mag sein, dass man nicht immer den perfekten Code für irgendwas braucht, aber zumindestens irgendeinen der nicht so weit davon wegliegt.
Wenn t die Zeit ist die ein perfekte Code(bezüglich Speed) braucht. Irgendjemand schreibt einen C++-Code der xt braucht. Und Irgendjemand schreibt einen Java Code der yt braucht. Dann wissen wir, dass wir durch Optimierung xt auf t verringern können. Aber es sehr wahrscheinlich, dass wir yt nicht mal in die Nähe von t bringen können, egal wieviel wir optimieren. Wenn Speed also ein Kriterium ist(und bei jeder GUI-Anwendung was ja in der Frage des TE stand ist Speed eines der wichtigsten Kriterien) dann sollte man nicht Java einsetzen. Mit C# verhält es sich ähnlich.

Es stimmt was du gesagt hast, dass es noch andere Ziele wie Umsetzungsdauer, Robustheit und Wartbarkeit gibt und dass C++ nicht immer die beste Wahl ist.
Bei ersterem stimme ich dir zu, habe ich allerdings auch schon in meinem ersten Post in diesem Thread erwähnt. Die Frage ist was ist wichtiger. Quantität oder Qualität. Software die in die erste Sparte fällt sind die klassischen Apps wie wir sie von den Smartphones her kennen. Die Software in der letzteren Sparte muss sowohl fehlerfrei als auch schnell sein. Das sind bspw. wissenschaftliche Simulationen wie zb. das entfalten von Proteinen, Wetter etc.
Ich halte nicht viel von der ersten Sparte aber umso mehr von der zweiten. Und deshalb werde ich auch einen Teufel tun und dem TE eine Programmiersprache vorschlagen mit der hauptsächlich qualitativ minderwertige Software geschrieben wird.

Die Robustheit von der du sprichst kann man erreichen indem man einfach keine Fehler macht. Ein Programm dass kein Speicherleck hat braucht auch keinen Garbage-Collector. Ein Programm, dass nicht auf Speicher außerhalb seiner Array-Grenzen zugreift braucht kein boundchecking. Natürlich ist es nicht gerade einfach fehlerfrei zu programmieren.
Aber wer will es schon einfach? Wenn die Informatik einfach wäre, wäre sie arschlangweilig. Je komplexer desto besser.

Die Wartbarkeit hängt weniger von der Sprache sondern vom Programmierparadigma und der Architektur der Software ab. Ein Zebrarätsel wird sich in einer logischen Programmiersprache besser warten lassen als in einer prozeduralen. Und mit besser ist eigentlich schneller gemeint. Da man in der IT grundsätzlich nach Zeit und nicht nach Akkord bezahlt wird ist eine schnellere Wartung nicht zwangsläufig besser.

[Pyrokar]

Dann wissen wir, dass wir durch Optimierung xt auf t verringern können. Aber es sehr wahrscheinlich, dass wir yt nicht mal in die Nähe von t bringen können, egal wieviel wir optimieren. Wenn Speed also ein Kriterium ist(und bei jeder GUI-Anwendung was ja in der Frage des TE stand ist Speed eines der wichtigsten Kriterien) dann sollte man nicht Java einsetzen. Mit C# verhält es sich ähnlich.

Dass JIT/Bytecode-Kompilation per se um Welten(!) langsamer ist als nativer Code, halte ich für einen Irrglauben (gegen Java spricht zur Zeit in erster Linie Oracle). Weitere Diskussionen diesbezüglich sind aber ohne konkrete, repräsentative Benchmarks aber zwecklos.
Aber, gerade für GUI-Anwendungen ist Geschwindigkeit eher unerheblich. Die Reaktionszeit von Menschen ist vergleichsweise langsam. Nicht zu verwechseln ist das mit dem Antwortverhalten - eine GUI sollte nicht blockieren, also sich träge anfühlen. Für größere Hintergrundberechnungen kann man hier niemals mit Geschwindigkeitsoptimierung alles herausholen. Bei Maschine-zu-Maschine Kommunikation ist das anders, hier kann man mit Geschwindigkeitsoptimierungen einiges am Durchsatz machen, wenn nicht ähnlich limitierende Faktoren vorhanden sind.

Die Frage ist was ist wichtiger. Quantität oder Qualität. Software die in die erste Sparte fällt sind die klassischen Apps wie wir sie von den Smartphones her kennen. Die Software in der letzteren Sparte muss sowohl fehlerfrei als auch schnell sein.

Was hat Quantität hier mit Qualität zu tun? Mir geht es um die Umsetzungsdauer für Software mit der gleichen Qualität in unterschiedlichen Sprachen. Qualität ist für mich immer noch nicht ausschließlich oder vorrangig von der Geschwindigkeit abhängig.

Und deshalb werde ich auch einen Teufel tun und dem TE eine Programmiersprache vorschlagen mit der hauptsächlich qualitativ minderwertige Software geschrieben wird.

In jeder Sprache kann man schlechte Software schreiben. Und von uns beiden wird keiner wirklich bewerten können, mit welchen Sprachen vorrangig schlechte Software geschrieben wird. Dazu müssten wir nämlich eine erhebliche Anzahl entsprechender Softwares im Detail kennen.

Die Robustheit von der du sprichst kann man erreichen indem man einfach keine Fehler macht. Ein Programm dass kein Speicherleck hat braucht auch keinen Garbage-Collector. Ein Programm, dass nicht auf Speicher außerhalb seiner Array-Grenzen zugreift braucht kein boundchecking. Natürlich ist es nicht gerade einfach fehlerfrei zu programmieren.

Soweit die Theorie ...

Aber wer will es schon einfach? Wenn die Informatik einfach wäre, wäre sie arschlangweilig. Je komplexer desto besser.

Je einfacher, desto besser. Ich möchte lieber mehr Energie auf die Umsetzung meines eigentlichen Problems verwenden können, statt auf die Umsetzung der Umsetzung verschwenden zu müssen. Letzteres schlägt sich ggf. doppelt nieder - in einer längeren Entwicklungsdauer und geringerer Qualität weil es mehr Möglichkeiten gibt, Fehler zu machen.
Und: Informatik ist alles mögliche, aber nicht in erster Linie Programmieren.

Die Wartbarkeit hängt weniger von der Sprache sondern vom Programmierparadigma und der Architektur der Software ab. Ein Zebrarätsel wird sich in einer logischen Programmiersprache besser warten lassen als in einer prozeduralen. Und mit besser ist eigentlich schneller gemeint.

Im Prinzip gehe ich mit der ersten Aussage mit, die Sprache kann aber, gerade bei mäßiger Dokumentation, eine Rolle spielen.

Da man in der IT grundsätzlich nach Zeit und nicht nach Akkord bezahlt wird ist eine schnellere Wartung nicht zwangsläufig besser.

Und wie ist das, wenn die Wartung auf deine Kosten geht?

[Sumpfkrautjunkie]

Stimmt. Das liegt aber nicht an C# selbst, sondern an .NET (der Klassenbibliothek, die mit C# verwendet wird) und an Visual Studio (die IDE, die für Windowsprogramme benutzt wird). Außerdem gilt das nicht gerade unter Windows sondern ausschließlich unter Windows.

Gibt auch Mono. Ist mit Winforms kompatibel. Sieht zwar hässlich aus, läuft aber.
http://www.mono-project.com/Main_Page

Stimmt nicht. C++ ist eine native Sprache und dank Unterstützung von inline-Assembler kann man jedwedes Programm machen was irgenwie möglich ist. Somit könnte man sich auch eine .NET-Runtime-Environment programmieren und so dank C++ mit einer Sprache programmieren die zwar 100%ig so aussieht wie C#, aber kein C# ist.

Ich meinte nicht, dass man jedes Problem in C++ lösen kann was man in einer anderen Sprache lösen kann. Ich meine damit, dass man jedes Problem in C++ mindestens genauso effizient lösen kann wie in einer anderer Sprache.
Sagen wir mal wir haben eine Problemstellung. Dafür gibt es eine perfekte Lösung die abhängig von gewissen Zielen ist(Geschwindigkeit, Speicherverbrauch, Genauigkeit, etc.).
Für diese perfekte Lösung gibt es einen gewissen perfekten Maschinencode. Also gibt es auch einen perfekten Assemblercode. Dank inline-Assembler kann man diese perfekte Lösung auch in C++ bauen.
Bei einer Sprache ohne inline-Assembler wird man sich schwer tun. Die Compiler die normalerweise verwendet werden, verwenden auf komplexeren ISA wie zB x86 nur einen kleinen Teil des gesamten Befehlsatzes. Es ist aber wahrscheinlich, dass die perfekte Lösung auch den ein oder anderen asm-befehl verwendet, den diese Compiler nicht beherrschen. Und somit kann man die perfekte Lösung nicht in allen Sprachen bauen.

Man kann mit ner anderen turingvollständigen Sprache einfach einen neuen Compiler bauen, der passend toll optimierten Maschinencode erzeugt und inline Assembler als spezielle Kommentare (oder so) unterstützt.



@Topic:
C# bietet mittlerweile auch einfache Möglichkeiten für Mehrkern-CPU Programmierung, imho simpler zu benutzen als vergleichsweise OpenMP und dennoch mit sehr guter Parallelisierungseffizienz (bei meiner bisherigen Erfahrung mindestens gleich gut wie OpenMP)
Das Debuggen ist wesentlich einfacher und man hat eben eine ziemlich mächtige Standardbibliothek.

[Tevez]

Danke für die Antworten (also der Teil der sich auf meine Frage bezog )

Ich kann die genannten Unterschiede als Anfänger jetzt nicht alle einordnen. Aber insgesamt verstehe ich es so, dass es im Endeffekt keinen grossen Unterschied macht, und C# lediglich etwas komfortabler ist als C++, und auch mehr in Richtung Java geht, also komfortablere, sicherere Programmierung, und dafür leichte Einbußen in Performance. Da es mir vorallem wichtig ist, maximale Leistung für meine Programme zu haben, bin ich denke ich dann mit C++ gut aufgehoben.

Und der Punkt mit der Standardbibliothek spielt ja denke ich für die Mächtigkeit der Programmiersprache keine Rolle. Was C# in der Standardbibliothek mehr drauf hat, holt sich C++ halt durch zusätzliche Bibliotheken?

[Sumpfkrautjunkie]

Da es mir vorallem wichtig ist, maximale Leistung für meine Programme zu haben, bin ich denke ich dann mit C++ gut aufgehoben.

Hmm, da wärst du je nach Einsatzgebiet wohl mit Fortran besser beraten Noch besser wäre es natürlich direkt mit VHDL & co in Hardware zu implementieren^^
Was leider oft übersehen wird: Die Hauptgrundlage für ein schnelles Programm sind gute Algorithmen, wie performant der generierte Maschinencode ist, kommt danach.
Mit C++ fährt man auf jeden Fall nicht schlecht und es ist auch sinnvoll, wenn man erst mal eine Sprache am Stück lernt (ohne irgendwas durcheinanderzuwerfen).
Ein Blick über den Tellerrand lohnt sich aber auch, z.B. Pyton als Prototypensprache.

Und der Punkt mit der Standardbibliothek spielt ja denke ich für die Mächtigkeit der Programmiersprache keine Rolle. Was C# in der Standardbibliothek mehr drauf hat, holt sich C++ halt durch zusätzliche Bibliotheken?

Im Grunde ja. Ist aber von der usability etwas anders, da man sich die Bibliotheken erst zusammensuchen und einbinden muss und es auch nicht unbedingt alles aufeinander abgestimmt und aus einem Guss ist.

[Kallreven]

Ich habe beides ausprobiert. C# war recht komfortabel zu programmieren, hat einen aber auch etwas eingeschränkt. Man muss das .net-Framework installiert haben (eventuell kann man es mit mono unter Linux zum laufen bekommen), man ist in Sachen Speicherverwaltung / Zeiger eingeschränkt und ich hatte den Eindruck, dass Arbeit mit Hardware nicht so einfach war.
Im Gegensatz dazu habe ich dann C++ mit Qt verwendet. C++ ist richtig mächtig, es lässt sehr vieles zu, für Anfänger vielleicht auch zu viel (Man kann richtig schmutzigen Code schreiben...) Aber es hat halt viel weniger Bibliotheken am Start. Da kann man aber einfach nachhelfen. Die Installation einer Qt-Entwicklungsumgebung ging sehr leicht von der Hand und das Qt-Framework bietet echt Massen an Klassen Dazu ist es halt super dokumentiert und man findet viel Hilfe im Netz. Dazu ist Qt für viele Platformen verfügbar (Windowse, Linuxe, Mac, ... und bald anscheinend auch Android )

Mein persönliches Fazit: C# ist komfortabler, schränkt aber dafür ein.

Ich benutze nur noch C++ mit Qt.

[Headcool]

Dass JIT/Bytecode-Kompilation per se um Welten(!) langsamer ist als nativer Code, halte ich für einen Irrglauben (gegen Java spricht zur Zeit in erster Linie Oracle). Weitere Diskussionen diesbezüglich sind aber ohne konkrete, repräsentative Benchmarks aber zwecklos.
Aber, gerade für GUI-Anwendungen ist Geschwindigkeit eher unerheblich. Die Reaktionszeit von Menschen ist vergleichsweise langsam. Nicht zu verwechseln ist das mit dem Antwortverhalten - eine GUI sollte nicht blockieren, also sich träge anfühlen. Für größere Hintergrundberechnungen kann man hier niemals mit Geschwindigkeitsoptimierung alles herausholen. Bei Maschine-zu-Maschine Kommunikation ist das anders, hier kann man mit Geschwindigkeitsoptimierungen einiges am Durchsatz machen, wenn nicht ähnlich limitierende Faktoren vorhanden sind.

Kommt darauf an was man unter Welten versteht. Ich finde 120 statt 100% sind schon sehr viel. Dementsprechend halte ich die 300-400% was der Größenordnung entspricht die JIT-Sprache langsamer sind für nicht hinnehmbar.
Benchmarks sind übrigens der völlig falsche Weg um die Performance einer Sprache zu messen. Benchmarks behandeln genau ein spezifisches Problem. In einem echten Programm gibt es hundert verschiedene Probleme. Es gibt Unternehmen die denken mit Java wird alles besser, portieren ihre Software und kommen am Ende dann drauf, dass die Software unbrauchbar langsam geworden ist. Es geht dabei auch gar nicht um die Ausführungsgeschwindigkeit der CPU, es geht darum dass, dass Programm die ganze Zeit warten muss weil irgendwas von der Festplatte/vom Speicher gelesen werden musste weil es nicht mehr in den Cache gepasst hat.
Gerade bei GUI-Anwendung ist Geschwindigkeit das wichtigste überhaupt. Wenn ich auf einen Button klicke, dann hat das Programm im Worst-Case-Szenario nur ~17ms Zeit damit das Ergebnis im nächsten Frame dasteht. Im Best-Case-Szenario sind es fast 34ms. Prinzipiell ist das für einen Computer ewig lang. Sogar ein unperfomantes Notebook könnte in der Zeit eine Szene mit ein paar 100k Polygonen rendern. Aber die klassischen Java-GUIs sind da einfach zu blöd dafür.
Bezüglich der Wichtigkeit von Performance in GUIs. Unser Bewusstsein merkt nicht ob die Änderungen 17ms oder 170ms nach dem Klick auf dem Monitor zu sehen war. Aber unser Unterbewusstsein merkt es. Und es macht die Leute agressiv wenn sie den ganzen Tag mit Software arbeiten die solche langen Verzögerungszeiten haben. Wenn man ihnen dann eine schnellere Software vor die Nase setzt, dann finden sie diese wesentlich besser. Warum sie die besser finden, können sie meistens nicht sagen.
Fairerweise muss man dazusagen, dass das ganze keine JIT-spezifische-Angelegenheit sondern eher eine Java-spezifische Angelegenheit ist. C# ist in dem Bereich wesentlich schneller.

Was hat Quantität hier mit Qualität zu tun? Mir geht es um die Umsetzungsdauer für Software mit der gleichen Qualität in unterschiedlichen Sprachen. Qualität ist für mich immer noch nicht ausschließlich oder vorrangig von der Geschwindigkeit abhängig.

In dem Fall ist C++ sehr weit vorne. Es gibt viele gute Libraries um die Entwicklungszeit zu drücken und gleichzeitig kann man die Qualität soweit steigern wie es einem möglich ist.
Mit JIT-Sprachen kann man eventuell noch schneller entwickeln, aber um auf die Qualität des C++-Programmes zu kommen ist noch weitere Entwicklungsarbeit nötig. Eventuell kann man es mit den zur Verfügung stehenden Mitteln gar nicht mehr erreichen.

In jeder Sprache kann man schlechte Software schreiben. Und von uns beiden wird keiner wirklich bewerten können, mit welchen Sprachen vorrangig schlechte Software geschrieben wird. Dazu müssten wir nämlich eine erhebliche Anzahl entsprechender Softwares im Detail kennen.

Es geht weniger um gute/schlechte sonder eher um sinnlose/sinnvolle Programme.
Dazu muss man nur wissen in welcher Sparte mit welcher Sprache gearbeitet wird. Da im Bereich der naturwissenschaftlichen Simulationen hauptsächlich mit Fortran gearbeitet wird und es sonst fast nirgendwo verwendet wird, kann ich ziemlich schnell zu dem Schluss kommen, dass das durchschnittliche Fortran-Programm ziemlich sinnvoll ist, da es der Forschung dient.

Soweit die Theorie ...

Beim "einfach" geht es um das finden der Lösung. Im "nicht einfach" ging es um das Anwenden der Lösung.
Aber ich wusste schon dass das von dir kommt.

Je einfacher, desto besser. Ich möchte lieber mehr Energie auf die Umsetzung meines eigentlichen Problems verwenden können, statt auf die Umsetzung der Umsetzung verschwenden zu müssen. Letzteres schlägt sich ggf. doppelt nieder - in einer längeren Entwicklungsdauer und geringerer Qualität weil es mehr Möglichkeiten gibt, Fehler zu machen.
Und: Informatik ist alles mögliche, aber nicht in erster Linie Programmieren.

Ich möchte lieber etwas möglichst komplexes haben, sodass es nur sehr wenige Leute gibt die es ebenfalls lösen können, sodass ich mehr Geld dafür verlangen kann. Außerdem macht es Spaß grausigen Code zu entschlüsseln.
Informatik ist all das, was im Endeffekt dazu dient besser zu Programmieren.
Es gibt Leute die verwenden Programmieren als Synonym zur Kentniss der Sprache mit der programmiert wird.
Es gibt Leute die verwenden Programmieren als Synonym zur Kentniss von allem was dient bessere Programme schreiben zu können.
Ich bin einer der letzteren. Eine Definition was richtig ist gibt es aber nicht.

Und wie ist das, wenn die Wartung auf deine Kosten geht?

Dann wäre ich in einem Wirtschaftsforum und nicht in einem Programmierforum unterwegs und würde wahrscheinlich Java propagieren, weil die Mitarbeiter schnellere Ergebnisse liefern und man gleichzeitig keine teuren Arbeitskräfte braucht.

Man kann mit ner anderen turingvollständigen Sprache einfach einen neuen Compiler bauen, der passend toll optimierten Maschinencode erzeugt und inline Assembler als spezielle Kommentare (oder so) unterstützt.

Stimmt. Aber du brauchst dafür immer eine native Sprache. Eine JIT-Sprache ist dazu nicht nötig. Umgekehrt dagegen braucht man beides, denn der JIT-Compiler muss nativ aufgebaut werden.

@Topic:
C# bietet mittlerweile auch einfache Möglichkeiten für Mehrkern-CPU Programmierung, imho simpler zu benutzen als vergleichsweise OpenMP und dennoch mit sehr guter Parallelisierungseffizienz (bei meiner bisherigen Erfahrung mindestens gleich gut wie OpenMP)
Das Debuggen ist wesentlich einfacher und man hat eben eine ziemlich mächtige Standardbibliothek.

OpenMP sollte man nicht verwenden. Die Konkurrenzprodukte wie Intel Cilk Plus sind da wesentlich besser.

Danke für die Antworten (also der Teil der sich auf meine Frage bezog )

Ich kann die genannten Unterschiede als Anfänger jetzt nicht alle einordnen. Aber insgesamt verstehe ich es so, dass es im Endeffekt keinen grossen Unterschied macht, und C# lediglich etwas komfortabler ist als C++, und auch mehr in Richtung Java geht, also komfortablere, sicherere Programmierung, und dafür leichte Einbußen in Performance. Da es mir vorallem wichtig ist, maximale Leistung für meine Programme zu haben, bin ich denke ich dann mit C++ gut aufgehoben.

Auch wenn es eine riesige Java, .NET Fancommunity gibt und dir viele Leute einreden wollen der Performanceunterschied wäre klein, dann komm nicht auf die Idee das zu glauben. Er ist nicht klein. Er mag des öfteren "irrelephant" sein, aber klein ist er nicht.

Hmm, da wärst du je nach Einsatzgebiet wohl mit Fortran besser beraten Noch besser wäre es natürlich direkt mit VHDL & co in Hardware zu implementieren^^

Wenn man mit VHDL "programmiert" muss man sowohl geeignete Hardware als auch Software dafür haben. Software die sich entsprechend parallelisieren lässt, aber auch nicht mordsmäßig viel Speicher frisst muss auch erst mal gefunden werden. Die Hardware sollte dann auch ein entsprechend schneller FPGA sein. Also mit einem 50€ FPGA wird man nicht viel reißen können.
Was ich eher in dem Zusammenhang erwähnen würde wäre GPGPU. Da muss keine neue Hardware angeschafft werden. Und man kann seine Programme auch weitergeben.

Was leider oft übersehen wird: Die Hauptgrundlage für ein schnelles Programm sind gute Algorithmen, wie performant der generierte Maschinencode ist, kommt danach.

Da kann ich dir teilweise zustimmen. Aber leider gibt es Theoretiker die es zu gut mit der Komplexität meinen und nicht darauf achten was die Hardware sagt. Ein O(n) Algorithmus mag sich vielleicht besser anhören als ein 10*O(n) Algorithmus, aber wenn sich zweiteres parallelisieren lässt wie sonstwas und erster Speicher frisst bis der RAM überläuft dann denke ich nicht dass ich den ersten verwenden werde.

[Sumpfkrautjunkie]

Kommt darauf an was man unter Welten versteht. Ich finde 120 statt 100% sind schon sehr viel. Dementsprechend halte ich die 300-400% was der Größenordnung entspricht die JIT-Sprache langsamer sind für nicht hinnehmbar.
Benchmarks sind übrigens der völlig falsche Weg um die Performance einer Sprache zu messen.

Wie kommst du dann auf 300-400% ?

es geht darum dass, dass Programm die ganze Zeit warten muss weil irgendwas von der Festplatte/vom Speicher gelesen werden musste weil es nicht mehr in den Cache gepasst hat.

Ich würde das jetzt nicht als JIT-spezifisches Problem bezeichnen. Mit nativen sprachen kann man da zwar bei den Datenstrukturen bisschen tricksen und mit passende bitanordnungen Platz sparen, man muss die Datenmenge aber trotzdem verarbeiten und die primitiven Datentypen sind ja auch von der gleichen standardisierten Größe (bis natürlich z.B: auf Strings)

Gerade bei GUI-Anwendung ist Geschwindigkeit das wichtigste überhaupt. Wenn ich auf einen Button klicke, dann hat das Programm im Worst-Case-Szenario nur ~17ms Zeit damit das Ergebnis im nächsten Frame dasteht. Im Best-Case-Szenario sind es fast 34ms. Prinzipiell ist das für einen Computer ewig lang.

Dafür muss eine typischen GUI Anwendungen auch nicht ewig lange herumrechnen. Bei Auswertung von größeren Datenmengen machen kleine Details aber schon deutlich mehr aus.

Es geht weniger um gute/schlechte sonder eher um sinnlose/sinnvolle Programme.
Dazu muss man nur wissen in welcher Sparte mit welcher Sprache gearbeitet wird. Da im Bereich der naturwissenschaftlichen Simulationen hauptsächlich mit Fortran gearbeitet wird und es sonst fast nirgendwo verwendet wird, kann ich ziemlich schnell zu dem Schluss kommen, dass das durchschnittliche Fortran-Programm ziemlich sinnvoll ist, da es der Forschung dient.

Wie und ob jemand etwas verwendet ist kein Qualitätskriterum. Populäres Beispiel wären da die die Betamax-Kasetten. Oder im Bereich der Sprachen D, was auch kaum einer verwendet.

Beim "einfach" geht es um das finden der Lösung. Im "nicht einfach" ging es um das Anwenden der Lösung.
Aber ich wusste schon dass das von dir kommt.

Ein Fehlerfreies Programm zu schreiben ist eher ein Ziel und keine Lösung für ein Problem. Du kannst dir halt nicht sicher sein, dass da eben keine Fehler drin sind. Das bedürfte schon formaler Code-Verifikation, wozu man meist keine Zeit und keine Lust hat. Da bringt es auch nicht viel zu wissen, dass man bei absoluter Fehlerfreiheit x und y nicht bräuchte.

Ich möchte lieber etwas möglichst komplexes haben, sodass es nur sehr wenige Leute gibt die es ebenfalls lösen können, sodass ich mehr Geld dafür verlangen kann.

Es muss dann natürlich auch eine Nachfrage geben. Brainfuck ist ja auch arg umständlich/kompliziert, bloß kriegt man da wohl trotz Programmiererknappheit kaum einen passenden Job
Wenn es aber vorrangig um Komplexität geht, wäre die theoretische Informatik wohl eine gute Anlaufstelle.

Stimmt. Aber du brauchst dafür immer eine native Sprache. Eine JIT-Sprache ist dazu nicht nötig. Umgekehrt dagegen braucht man beides, denn der JIT-Compiler muss nativ aufgebaut werden.

Wozu braucht man eine native Sprache um eine ausführbare Datei zu generieren?

Auch wenn es eine riesige Java, .NET Fancommunity gibt und dir viele Leute einreden wollen der Performanceunterschied wäre klein, dann komm nicht auf die Idee das zu glauben. Er ist nicht klein. Er mag des öfteren "irrelephant" sein, aber klein ist er nicht.

Wie kommst du drauf, wenn du Benchmarks als nicht aussagekräftig genug erachtest?
Also ich habe schon JIT-Codes geschrieben, die schneller waren (und trotzdem das gleiche gemacht haben), wie äquivalente c++ programme, welche von älteren Leuten mit mehr Erfahrung geschrieben wurden. Und nun Dass die JIT-Sprachen nicht immer so schnell sein können, wie die nativen möchte ich natürlich nicht abstreiten. Aber so schlimm ist es nun auch wieder nicht.
Kommt im Endeffekt darauf an, was man konkret macht und inwiefern man da in Schwächen von JIT-Sprachen reintappt.

Wenn man mit VHDL "programmiert" muss man sowohl geeignete Hardware als auch Software dafür haben. Software die sich entsprechend parallelisieren lässt, aber auch nicht mordsmäßig viel Speicher frisst muss auch erst mal gefunden werden. Die Hardware sollte dann auch ein entsprechend schneller FPGA sein. Also mit einem 50€ FPGA wird man nicht viel reißen können.
Was ich eher in dem Zusammenhang erwähnen würde wäre GPGPU. Da muss keine neue Hardware angeschafft werden. Und man kann seine Programme auch weitergeben.

Geht ja nur um die Veranschaulichung, dass es 'schneller' geht.

[Pyrokar]

Kommt darauf an was man unter Welten versteht. Ich finde 120 statt 100% sind schon sehr viel. Dementsprechend halte ich die 300-400% was der Größenordnung entspricht die JIT-Sprache langsamer sind für nicht hinnehmbar. Benchmarks sind übrigens der völlig falsche Weg um die Performance einer Sprache zu messen. Benchmarks behandeln genau ein spezifisches Problem. In einem echten Programm gibt es hundert verschiedene Probleme.

Hast du eine Quelle für diese Angabe von 300 bis 400%? Benchmarks sind nicht der falsche weg, Performance zu vergleichen sondern der einzige. Allerdings ist für mich ein Benchmark jedweder Vergleich von Performance verschiedener Systeme hinsichtlich der Erfüllung eines konkreten Kriteriums unter klar definierten Bedingungen. Das müssen also nicht zwangsläufig simple Betrachtungen einer kleinen Teilmenge von Befehlen/Problemen sein.

Es gibt Unternehmen die denken mit Java wird alles besser, portieren ihre Software und kommen am Ende dann drauf, dass die Software unbrauchbar langsam geworden ist.

Welche Firmen denn so zum Beispiel?

Aber die klassischen Java-GUIs sind da einfach zu blöd dafür.

Du verallgemeinerst schon wieder von dem Umstand, dass das vorkommt dahin, dass es per se so ist. Was für Programme meinst du denn? Ich erwähne hier einfach mal Eclipse und yEd als Gegenbeispiele.

Bezüglich der Wichtigkeit von Performance in GUIs. Unser Bewusstsein merkt nicht ob die Änderungen 17ms oder 170ms nach dem Klick auf dem Monitor zu sehen war. Aber unser Unterbewusstsein merkt es. Und es macht die Leute agressiv wenn sie den ganzen Tag mit Software arbeiten die solche langen Verzögerungszeiten haben. Wenn man ihnen dann eine schnellere Software vor die Nase setzt, dann finden sie diese wesentlich besser. Warum sie die besser finden, können sie meistens nicht sagen.
Fairerweise muss man dazusagen, dass das ganze keine JIT-spezifische-Angelegenheit sondern eher eine Java-spezifische Angelegenheit ist. C# ist in dem Bereich wesentlich schneller.

Quelle? Mich interessieren da nicht so sehr die Zahlen sondern die Untersuchung/Untermauerung der These bzgl. der bewussten und unbewussten Wahrnehmung.

In dem Fall ist C++ sehr weit vorne. Es gibt viele gute Libraries um die Entwicklungszeit zu drücken und gleichzeitig kann man die Qualität soweit steigern wie es einem möglich ist.
Mit JIT-Sprachen kann man eventuell noch schneller entwickeln, aber um auf die Qualität des C++-Programmes zu kommen ist noch weitere Entwicklungsarbeit nötig. Eventuell kann man es mit den zur Verfügung stehenden Mitteln gar nicht mehr erreichen.

Bitte präzisiere mal, was du hier mit Qualität meinst.

Beim "einfach" geht es um das finden der Lösung. Im "nicht einfach" ging es um das Anwenden der Lösung.
Aber ich wusste schon dass das von dir kommt.

Nun, wenn es nicht einfach ist, sprich die Wahrscheinlichkeit höher, das Fehler passieren können, dann greife ich doch lieber zu einer Sprache, die gar nicht erst so viele Möglichkeiten bietet Fehler zu machen. Dann sinkt die Wahrscheinlichkeit dafür automatisch. Solange ich meine anderen Anforderungen abgedeckt bekomme, ist das nur vernünftig.

Ich möchte lieber etwas möglichst komplexes haben, sodass es nur sehr wenige Leute gibt die es ebenfalls lösen können, sodass ich mehr Geld dafür verlangen kann. Außerdem macht es Spaß grausigen Code zu entschlüsseln.
Informatik ist all das, was im Endeffekt dazu dient besser zu Programmieren.
Es gibt Leute die verwenden Programmieren als Synonym zur Kentniss der Sprache mit der programmiert wird.
Es gibt Leute die verwenden Programmieren als Synonym zur Kentniss von allem was dient bessere Programme schreiben zu können.
Ich bin einer der letzteren. Eine Definition was richtig ist gibt es aber nicht.

Zunächst einmal gibt es natürlich eine ziemlich klare Definition für die Tätigkeit Programmieren. Und im Wesentlichen umfasst sie das Kodieren von Algorithmen in einer Programmiersprache. Programmieren bezeichnet als Tätigkeit genau genommen überhaupt kein Besitz von Wissen, weder von einer Programmiersprache noch von sonst etwas.

Und dann befasst sich Informatik in manchen Teilgebieten mit Programmierung, das ist richtig, aber Informatik ist nicht zentral darauf ausgerichtet. Informatik beschäftigt sich mit der Berechenbarkeit (theoretische Informatik) bzw. da wo möglich mit der abstrakten Modellierung der Lösung (bspw. Robotik, KI, Computergrafik, Kryptographie) von Problemen, der systematischen Umsetzung möglicher Lösungen (Software-Entwicklung). Natürlich werden die erarbeiteten Lösungen am Ende auch umgesetzt, also programmiert.
Aber um eine fertig ausformulierte Problemlösung zu implementieren braucht es, außer der Kenntnis einer Programmiersprache mit der man diese Umsetzen kann, theoretisch kein weiteres Wissen. Natürlich wird das in der Praxis so kaum vorkommen, dass jemand der etwas umsetzt sonst kein Hintergrundwissen hat. Aber an dem Sachverhalt, dass dieses Wissen nicht nötig wäre, ändert das nichts.

Da kann ich dir teilweise zustimmen. Aber leider gibt es Theoretiker die es zu gut mit der Komplexität meinen und nicht darauf achten was die Hardware sagt. Ein O(n) Algorithmus mag sich vielleicht besser anhören als ein 10*O(n) Algorithmus, aber wenn sich zweiteres parallelisieren lässt wie sonstwas und erster Speicher frisst bis der RAM überläuft dann denke ich nicht dass ich den ersten verwenden werde.

Es gibt Theoretiker, die sich bei ihren Betrachtungen nicht mit der aktuell verfügbaren Hardware befassen. Das ist ein anderer, für die meisten eine eher ungewöhnliche, manchmal auch nicht nachvollziehbare Sichtweise. Aber warum sollte man zwangsläufig aktuelle Hardware als unumstößlich betrachten? Vor allem wenn sich mit der prinzipiellen Berechenbarkeit von Problemen befasst. Eine Aussage wie, "Problem XYZ wäre Komplexität O(whatever) umsetzbar, es müsste aber Hardware entwickelt werden die folgende Kriterien erfüllt: ...", kann durchaus eine wesentliche Erkenntnis sein. Dann müsste man eben noch die Hardware dazu entwickeln, quasi umgekehrt zum etablierten Weg. Ungewöhnlich, aber nicht undenkbar.
Informatik ist eben nicht nur Programmieren (auf momentaner Hardware).

[Cheesecake]

C#:

• Interfaces
• Automatische Speicherverwaltung
• Kastrierte Pointer

C++:

• Mehrfachvererbung
• RAII
• Speicherlecks

Was du bei C# schreibst, gibt es in C++ doch im Prinzip auch. ^^ Speicherlecks sollten dank RAII eigentlich auch kein Thema sein.

[Headcool]

Wie kommst du dann auf 300-400% ?

Die 300-400% sind Erfahrungswerte. Aber nicht von Benchmarks, sondern von Programmen die komplett neu geschrieben wurden(beide Richtungen sind vertreten).

Ich würde das jetzt nicht als JIT-spezifisches Problem bezeichnen. Mit nativen sprachen kann man da zwar bei den Datenstrukturen bisschen tricksen und mit passende bitanordnungen Platz sparen, man muss die Datenmenge aber trotzdem verarbeiten und die primitiven Datentypen sind ja auch von der gleichen standardisierten Größe (bis natürlich z.B: auf Strings)

Es laufen zig Module parallel. Auf der einen Seite läuft der JIT, dann läuft der JIT-kompilierte Code, dann läuft der Garbage Collector usw.
Jedes dieser Module hat seine eigenes Zeug im Speicher. Beim Umschalten gibts einen Code-Cache-Miss in Folge darauf gibt es massig Data-Cache-Misses da die Module ganz wo anderst im Speicher liegen und nicht gerade schlank sind.

Dafür muss eine typischen GUI Anwendungen auch nicht ewig lange herumrechnen. Bei Auswertung von größeren Datenmengen machen kleine Details aber schon deutlich mehr aus.

Da bin ich einer Meinung mit dir. Komischerweise gibt es doch immer wieder Verzögerungen gerade bei den klassischen Java-GUIs. Und das ist etwas wo ich meinen PC am liebsten beim Fenster hinauswerfen würde. Es kann doch nicht sein, dass ich beim Wechseln von einem Tab zum anderen wo vielleicht 10 Widgets geladen werden müssen, auf einem modernen PC eine spürbare Verzögerung entsteht, während es ein Spiel schafft in jedem Frame mehrere Millionen Polygone zu rendern.

Wie und ob jemand etwas verwendet ist kein Qualitätskriterum. Populäres Beispiel wären da die die Betamax-Kasetten. Oder im Bereich der Sprachen D, was auch kaum einer verwendet.

Wir sind hier nicht im Consumerbereich wo die User keine Ahnung von dem haben was sie benützen. Insofern kannst du das nicht so einfach in andere Bereich übertragen. Bezüglich der Programmiersprache D. Eine Sprache ist nur sogut wie ihr bester Compiler. Da D ähnlich wie C++ ist und die C++-Compiler zu den Besten gehören hat D einen schweren Stand. Dazu kommt noch das Henne-Ei-Problem.

Ein Fehlerfreies Programm zu schreiben ist eher ein Ziel und keine Lösung für ein Problem. Du kannst dir halt nicht sicher sein, dass da eben keine Fehler drin sind. Das bedürfte schon formaler Code-Verifikation, wozu man meist keine Zeit und keine Lust hat. Da bringt es auch nicht viel zu wissen, dass man bei absoluter Fehlerfreiheit x und y nicht bräuchte.

Ich muss zugeben, dass absolute Fehlerfreiheit übertrieben ist. Es gibt Programme die haben soviele Bugs dass es nervt, es gibt Programme die haben soviele Bugs dass man es merkt und es gibt Programme die haben so wenige Bugs dass man keine sieht. Viele Tausende Programme zeigen, dass letzte Sparte möglich ist.

Es muss dann natürlich auch eine Nachfrage geben. Brainfuck ist ja auch arg umständlich/kompliziert, bloß kriegt man da wohl trotz Programmiererknappheit kaum einen passenden Job
Wenn es aber vorrangig um Komplexität geht, wäre die theoretische Informatik wohl eine gute Anlaufstelle.

Was? Mit Brainfuck kriege ich keinen Job? Ich habe die letzten 10 Jahre Brainfuck gelernt und meine Skills darin perfektioniert, weil ich gedacht habe damit würde ich einen Spitzenjob bekommen

Wozu braucht man eine native Sprache um eine ausführbare Datei zu generieren?

Irgendwie muss der JIT-Compiler den du benutzt ja geschrieben worden sein.

Wie kommst du drauf, wenn du Benchmarks als nicht aussagekräftig genug erachtest?
Also ich habe schon JIT-Codes geschrieben, die schneller waren (und trotzdem das gleiche gemacht haben), wie äquivalente c++ programme, welche von älteren Leuten mit mehr Erfahrung geschrieben wurden. Und nun Dass die JIT-Sprachen nicht immer so schnell sein können, wie die nativen möchte ich natürlich nicht abstreiten. Aber so schlimm ist es nun auch wieder nicht.
Kommt im Endeffekt darauf an, was man konkret macht und inwiefern man da in Schwächen von JIT-Sprachen reintappt.

Wie gesagt. Es geht um Erfahrung bezüglich Komplettportierungen von C++ zu Java und umgekehrt. Das Problem bei Benchmarks ist, dass man meistens nur ein sehr kleines Programm hat. In dem Fall sind JIT-Sprachen gar nicht so langsam. Aber kleine Programme muss man im Normal-Fall auch gar nicht optimieren. Problem von JIT-Sprachen sind eher größere Programme. Wenn der Cache gut gefüllt ist, wenn der Garbage Collector viel zu tun hat, wenn der Speicher fragmentiert ist, gerade dann muss eine JIT-Sprache gut performen. Denn gerade für große Programmen ist die hohe Abstraktionsebene ja gedacht.
Und natürlich gibt es Programme die in Java & Co. schneller sind als in C++. Gerade weils es auch in C++ viele Möglichkeiten gibt ineffizient zu Programmieren. Wenn ich zB. in C++ in einer engen Schleife immer kleine Datenmengen alloziere wird das ewig brauchen, weil es jedes mal ein Kontextwechsel gibt. Wenn ich das gleiche in Java mache, dann dauert das nicht solange weil die Java-Speicher-Verwaltung mehr Speicher im Vorraus alloziert als sie braucht.
Aber ich kann auch in C++ so eine Speicher-Verwaltung schreiben. Eine die viel intelligenter ist, mit Alignement, Defragmentierung und und und.

Hast du eine Quelle für diese Angabe von 300 bis 400%? Benchmarks sind nicht der falsche weg, Performance zu vergleichen sondern der einzige. Allerdings ist für mich ein Benchmark jedweder Vergleich von Performance verschiedener Systeme hinsichtlich der Erfüllung eines konkreten Kriteriums unter klar definierten Bedingungen. Das müssen also nicht zwangsläufig simple Betrachtungen einer kleinen Teilmenge von Befehlen/Problemen sein.

Die 300-400% sind Erfahrungswerte.
Mit deiner Definition von Benchmark habe ich keine Probleme. Das Problem ist, dass gerade wenn Sprachen verglichen werden nur sehr kleine Programme verwendet werden. In anderen Bereichen funktioniert das wesentlich besser. Bei 3d-Grafik-Benchmarks zB. Da läuft fast 1:1 das was auch in einem Spiel also in der Realität laufen soll.
Beim Vergleich von Programmiersprachen ist das leider noch nicht angekommen.

Welche Firmen denn so zum Beispiel?

Kleine und Mittelständische Unternehmen hauptsächlich. Die Großen Unternehmen erkennen zunehmen den Nachteil von "langsamen" Sprachen. Sie zB. Facebook, PHP und HipHop. Außerdem haben die großen Unternehmen große interne Bibliotheken. Damit ist einer der Hauptgründe um zu C#/Java zu greifen nicht existent.

Du verallgemeinerst schon wieder von dem Umstand, dass das vorkommt dahin, dass es per se so ist. Was für Programme meinst du denn? Ich erwähne hier einfach mal Eclipse und yEd als Gegenbeispiele.

Mag sein, dass es auch Ausnahmen gibt, aber Eclipse ist keine davon. Bei Eclipse ist es zwar nicht annähernd so schlimm wie bei so manch anderen Programmen, aber vom Ideal sind sie definitiv noch entfernt.

Quelle? Mich interessieren da nicht so sehr die Zahlen sondern die Untersuchung/Untermauerung der These bzgl. der bewussten und unbewussten Wahrnehmung.

Da habe ich mal eine Doku auf youtube gesehen. Ich finde sie aber leider nicht. Aber es gibt zu Demonstration des Effektes zahlreiche Tests. Hier der entsprechende Wiki-Eintrag zu dem Thema.

Bitte präzisiere mal, was du hier mit Qualität meinst.

Fehlerfreiheit, Geschwindigkeit, Speicherverbrauch, Usability, Design und Featurereichtum sind die für mich wichtigsten Eigenschaften. Je nach Zielgruppe ist das aber anderst. Die meisten Konsumenten brauchen zB. nicht so viele Features, dafür noch mehr Usability und Design.

Nun, wenn es nicht einfach ist, sprich die Wahrscheinlichkeit höher, das Fehler passieren können, dann greife ich doch lieber zu einer Sprache, die gar nicht erst so viele Möglichkeiten bietet Fehler zu machen. Dann sinkt die Wahrscheinlichkeit dafür automatisch. Solange ich meine anderen Anforderungen abgedeckt bekomme, ist das nur vernünftig.

Damit habe ich grundsätzlich kein Problem. Ein Problem sind eher deine Anforderungen die bei weitem nicht so streng und perfektionistisch wie mit meine Anforderungen.

Zunächst einmal gibt es natürlich eine ziemlich klare Definition für die Tätigkeit Programmieren. Und im Wesentlichen umfasst sie das Kodieren von Algorithmen in einer Programmiersprache. Programmieren bezeichnet als Tätigkeit genau genommen überhaupt kein Besitz von Wissen, weder von einer Programmiersprache noch von sonst etwas.

Dann würde ein Affe der auf einer Tastatur herumtrampelt ein Programmierer sein. Er schreibt zwar zu 99,99..99% falschen Code, aber es besteht eine Chance, dass er ein Programm schreibt.

Und dann befasst sich Informatik in manchen Teilgebieten mit Programmierung, das ist richtig, aber Informatik ist nicht zentral darauf ausgerichtet. Informatik beschäftigt sich mit der Berechenbarkeit (theoretische Informatik) bzw. da wo möglich mit der abstrakten Modellierung der Lösung (bspw. Robotik, KI, Computergrafik, Kryptographie) von Problemen, der systematischen Umsetzung möglicher Lösungen (Software-Entwicklung). Natürlich werden die erarbeiteten Lösungen am Ende auch umgesetzt, also programmiert.
Aber um eine fertig ausformulierte Problemlösung zu implementieren braucht es, außer der Kenntnis einer Programmiersprache mit der man diese Umsetzen kann, theoretisch kein weiteres Wissen. Natürlich wird das in der Praxis so kaum vorkommen, dass jemand der etwas umsetzt sonst kein Hintergrundwissen hat. Aber an dem Sachverhalt, dass dieses Wissen nicht nötig wäre, ändert das nichts.

Ich drücke es mal anderst aus. Es gibt die Theorie und es gibt die Praxis. Die Praxis ist die Programmierung, die Theorie ist das was man in die Programmierung einbaut. Und weil man es in die Programmierung einbaut ist es Teil davon.

Es gibt Theoretiker, die sich bei ihren Betrachtungen nicht mit der aktuell verfügbaren Hardware befassen. Das ist ein anderer, für die meisten eine eher ungewöhnliche, manchmal auch nicht nachvollziehbare Sichtweise. Aber warum sollte man zwangsläufig aktuelle Hardware als unumstößlich betrachten? Vor allem wenn sich mit der prinzipiellen Berechenbarkeit von Problemen befasst. Eine Aussage wie, "Problem XYZ wäre Komplexität O(whatever) umsetzbar, es müsste aber Hardware entwickelt werden die folgende Kriterien erfüllt: ...", kann durchaus eine wesentliche Erkenntnis sein. Dann müsste man eben noch die Hardware dazu entwickeln, quasi umgekehrt zum etablierten Weg. Ungewöhnlich, aber nicht undenkbar.

Wenn es nicht komplett unwahrscheinlich ist, dass es diese Hardware jemals geben wird, habe ich kein Problem damit. War ja zB. beim Raytracing-Algorithmus genauso.
Womit ich ein Problem habe ist, dass die Komplexität oftmals als alleiniges Kriterium für gut/schlecht beachtet wird. Dabei ist gerade die Hardwareentwicklung ein ebenso wichtiges Kriterium.
Um das am Bsp. des raytracing-Algorithmus zu erklären. Der hat eine Komplexität von x*O(n). n sind die Anzahl der Pixel. Ohne weiteres Wissen ist das weder gut noch schlecht. Wichtig ist dass, was auch immer in der Klammer steht(ob n, n^2,..) langsamer wächst als die Performance verfügbarer Hardware. Umgekehrt dagegen, könnte es sein, dass der Algorithmus heute funktioniert, morgen aber nicht mehr funktioniert.

Informatik ist eben nicht nur Programmieren (auf momentaner Hardware).

Informatik ist ideal zu programmieren. Auch wenn die Tipparbeit am Ende jemand anderer übernimmt.

[Pyrokar]

Die 300-400% sind Erfahrungswerte.
Mit deiner Definition von Benchmark habe ich keine Probleme. Das Problem ist, dass gerade wenn Sprachen verglichen werden nur sehr kleine Programme verwendet werden. In anderen Bereichen funktioniert das wesentlich besser. Bei 3d-Grafik-Benchmarks zB. Da läuft fast 1:1 das was auch in einem Spiel also in der Realität laufen soll.
Beim Vergleich von Programmiersprachen ist das leider noch nicht angekommen.

Erfahrungswerte von wem, wo/wie gemessen, in welchen Anwendungen? So wie du das hier darlegst sind das einfach Behauptungen.
Gerade bekannte/große/etablierte Benchmarks müssen immer mit Vorsicht genossen werden, da hier teilweise speziell für diese optimiert wird. Der dadurch suggerierte Performance-Vorteil ist im allgemeinen Fall aber so nicht vorhanden. Das mal so am Rande.

Kleine und Mittelständische Unternehmen hauptsächlich.

Und ein weiteres Allgemeinplätzchen.

Die Großen Unternehmen erkennen zunehmen den Nachteil von "langsamen" Sprachen. Sie zB. Facebook, PHP und HipHop.

Sicher, ab einer gewissen Dimension der Skalierung spielt der JIT-Overhead eine entscheidende Rolle. Facebook ist extrem riesig. Dazu kommt, dass PHP unter den JIT/Interpreter-Sprachen, soweit ich weiß, vergleichsweise (sehr) langsam ist.
V8 als Laufzeitumgebung für ECMA/JavaScript übersetzt zum Beispiel Code in native Maschinenbefehle. Es gibt sogar ein Szenario, wenn auch nur zu Demonstrativzwecken, in dem V8 schneller ist als Kompilieren mit gcc und anschließendes ausführen ist.

Da habe ich mal eine Doku auf youtube gesehen. Ich finde sie aber leider nicht. Aber es gibt zu Demonstration des Effektes zahlreiche Tests. Hier der entsprechende Wiki-Eintrag zu dem Thema.

Ich meinte nicht selektive Wahrnehmung an sich - das es die gibt, ist klar. Ich meine Nachweise für die konkrete Aussage, dass "unbewusste Langsamkeit" zu einem schlechten Nutzungserlebnis führt.

Fehlerfreiheit, Geschwindigkeit, Speicherverbrauch, Usability, Design und Featurereichtum sind die für mich wichtigsten Eigenschaften. Je nach Zielgruppe ist das aber anderst. Die meisten Konsumenten brauchen zB. nicht so viele Features, dafür noch mehr Usability und Design.

Dann haben wir verschiedene Vorstellungen von Qualität. Für mich ergibt sich Qualität nicht bloß aus absoluten Werten gewisser Kriterien, sondern v.a. aus der Relation dieser zuzu geforderten Werten - anders ist Qulität nicht quantitativ überprüfbar - und den zur Verfügung stehenden Ressourcen.

Damit habe ich grundsätzlich kein Problem. Ein Problem sind eher deine Anforderungen die bei weitem nicht so streng und perfektionistisch wie mit meine Anforderungen.

Bezüglich Rechenzeit und Speicherbedarf ist das wohl so. Ich messe auch anderen Umständen eine höhere Bedeutung zu. Du machst den Eindruck, als ob du alles außer der Performance als Beiwerk siehst. Das kann jeder so halten wie er will, sind ja persönliche Meinungen. Ich bin mir aber sicher, dass es in der Industrie nicht nur um Performance geht.

Dann würde ein Affe der auf einer Tastatur herumtrampelt ein Programmierer sein. Er schreibt zwar zu 99,99..99% falschen Code, aber es besteht eine Chance, dass er ein Programm schreibt.

Mir ging es darum, dass du munter Begrifflichkeiten durcheinander mischst. Ich habe nicht gesagt, dass man zum Programmrieren keine Sprache kennen muss.
Und worauf ich letztendlich hinaus wollte, ist, dass man zum implementieren eines Algorithmus nicht wirklich verstehen muss, was er tut. Oder bei der Umsetzung eines Entwurfs es unerheblich ist, ob man die getroffenen Entwurfsentscheidungen nachvollziehen kann. Die wirkliche geistige Leistung liegt im Enwturf des Algorithmus oder eines Designs.

Ich drücke es mal anderst aus. Es gibt die Theorie und es gibt die Praxis. Die Praxis ist die Programmierung, die Theorie ist das was man in die Programmierung einbaut. Und weil man es in die Programmierung einbaut ist es Teil davon.
[...]
Informatik ist ideal zu programmieren. Auch wenn die Tipparbeit am Ende jemand anderer übernimmt.

Wenn du das so siehst. Ich habe eine andere Sicht auf Informatik, die sie nicht nur auf Programmierung reduziert.

Wenn es nicht komplett unwahrscheinlich ist, dass es diese Hardware jemals geben wird, habe ich kein Problem damit. War ja zB. beim Raytracing-Algorithmus genauso.
Womit ich ein Problem habe ist, dass die Komplexität oftmals als alleiniges Kriterium für gut/schlecht beachtet wird. Dabei ist gerade die Hardwareentwicklung ein ebenso wichtiges Kriterium.

Wenn es um die Auswahl von Algorithmen für die Umsetzung eines Problems geht, spielt das natürlich eine Rolle. Aber ich kennen auch keinen, der dabei die Komplexität einer der beiden Dimensionen vernachläßigen würde. Und vor der Tatsache verschließt sich auch die Theorie nicht - es gibt da ja auch Average-Case-Betrachtungen.