Wieso gibt es keine gute Programmiersprache?

Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden und die Leute haben es noch immer nicht hinbekommen, eine gute Programmiersprache zu schreiben?

C:

Die beste Sprache heutzutage, und das, im Kombination mit C's Alter, spricht Bände
Nur grundlegende Generics
Keine gute Compile-Time-Evaluation (damit meine ich so etwas wie C++14's constexpr)
Build-Horror
Weder Modules noch Namespaces

C++:

Überall falsche Defaults wegen Rückwärtskompatibilität: enum, const-Methoden, switch-break, explicit, ...
iostreams
Build-Horror (im Gegensatz zu C hat diese moderne Sprache absolut keine Entschuldigung dafür, keine Modules zu haben)
Header-Horror, in Anlehnung an obigen Punkt kommen hier auch noch die Abscheulichkeiten mit .inl etc. dazu

Absolut kein Ecosystem dahinter, genauso wenig wie Libraries
__traits, __traits, __traits
Unabdingbarer GC (ja, unabdingbar! Standardbibliothek kompiliert nicht ohne)

Java:

Keine Funktionen
Keine Funktions-/Methodenzeiger o.Ä.
Keine gute Compile-Time-Evaluation
GC/VM, daher extrem langsam, träge und resourcenintensiv (nicht jeder hat ein Rechenzentrum unter dem Tisch)
clone(), finalize(), clone(), finalize(), clone(), finalize()
Reinkarnation von falschen Defaults
Devs haben verbissen alles künstlich eingeschränkt

Rust:

Langatmige Syntax
Keine gute Compile-Time-Evaluation
Beschnittene Generics
Diese hochgepriesene Ownership-Sache ist komplett broken und kostet wesentlich mehr Zeit und Haare als die wöchentlichen 10min Debuggen in C

Golang:

Keine gute Compile-Time-Evaluation
Keine Generics
GC
Halb objektorientiert, halb dann doch nicht. Entweder alles oder nichts aber keine halben Dinge.
Man kommt sich, wie in Java, künstlich beschnitten vor

Nim:

Ein-Mann-Projekt, inkl. aller Implikationen
Whitespaces als Syntaxelement

Sprachen mit dynamischem Typensystem habe ich mal nicht aufgeführt weil ich mich nicht sonderlich für Kinderspielzeug interessiere.
Ich würde mich wirklich sehr über Erfahrungsberichte mit Nim/Nimrod freuen, da ich sehr viel Potential in dieser Sprache sehe. Leider bin ich noch nicht dazu gekommen, mich mit ihr intensiv auseinanderzusetzen.

Mechanics

turbo autist schrieb:

Ich würde mich wirklich sehr über Erfahrungsberichte mit Nim/Nimrod freuen

Hab grad zum ersten mal davon gehört und danach gegoogelt... Wenn du schon bei bei D bemängelst, dass überhaupt kein Ecosystem dahinter ist, dann dürfte es bei Nim wohl kaum besser ausschauen.

https://www.haskell.org/

Columbo

turbo autist schrieb:

Überall falsche Defaults wegen Rückwärtskompatibilität: enum, const-Methoden, switch-break, explicit, ...

enum class tut was du möchtest, imperative Sprachen sind nicht standardmäßig überall immutable, switch-break kapier ich gerade nicht, und explicit ist irgendwie kein Argument: schreib halt explicit wenn du es so meinst. Dass du die komplizierteste, ausgeklügeltste Sprache aufgrund eines nachvollziehbaren Standardverhaltens rügen willst, ist nicht sehr überzeugend.

iostreams

Kein Teil von core. Bzw. zero-cost feature (sie globalen Objekte müssen nicht konstruiert werden, wenn sie nicht verwendet werden, kannst ja ne andere Lib nehmen.

Build-Horror (im Gegensatz zu C hat diese moderne Sprache absolut keine Entschuldigung dafür, keine Modules zu haben)

Aber wir bekommen Modules doch schon bald. Ich werde sie sogar übermorgen kurz in einem Talk erläutern. Wir sind also dabei, dieses Problem zu lösen: Kritisiere bitte, was wir als C++20 zu erwarten haben.

Andromeda

turbo autist schrieb:

Java:[list][]Keine Funktionen
[]Keine Funktions-/Methodenzeiger o.Ä.

Das stimmt doch gar nicht: https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html

SG1

Andromeda schrieb:

Das stimmt doch gar nicht:

Jetzt verwirr ihn doch nicht mit Fakten.

Ich glaube gegen C# findeste nix Negatives. :p

Andromeda

v. schrieb:

Ich glaube gegen C# findeste nix Negatives. :p

C# ist ein Java-Nachbau und hat nur auf Microsoft-Plattformen Bedeutung. Und einiges deutet darauf hin, dass Windows und .NET ihren Zenit bereits überschritten haben.

hustbaer

Arcoth schrieb:

turbo autist schrieb:

Überall falsche Defaults

schreib halt explicit wenn du es so meinst.

Manchmal reagierst du schon komisch - wie ein kleines Kind dessen Lieblingsschlumpf man beleidigt hat. Dir isr schon klar was Default heisst, oder?
Nein, nicht "schreib halt explicit wenn du es so meinst". Explicit müsste Default sein, und das was man schreiben muss "wenn man es so meint" müsste dann z.B. "implicit" heissen. Genau so mit den anderen Dingen. Die Kritik ist durchaus nachvollziehbar. Für mich kein Grund C++ nicht zu verwenden, aber schön zu reden gibt es da auch nix.

Andromeda schrieb:

v. schrieb:

Ich glaube gegen C# findeste nix Negatives. :p

C# ist ein Java-Nachbau und hat nur auf Microsoft-Plattformen Bedeutung. Und einiges deutet darauf hin, dass Windows und .NET ihren Zenit bereits überschritten haben.

Ausser Blabla noch was beizutragen?

EOP

https://de.wikipedia.org/wiki/Brainfuck
Have fun!

Andromeda

hustbaer schrieb:

Ausser Blabla noch was beizutragen?

Schau mal hier: http://winfuture.de/news,87623.html

Mechanics schrieb:

Hab grad zum ersten mal davon gehört und danach gegoogelt... Wenn du schon bei bei D bemängelst, dass überhaupt kein Ecosystem dahinter ist, dann dürfte es bei Nim wohl kaum besser ausschauen.

Ja, das habe ich mit den Implikationen des Ein-Mann-Projekts gemeint. Der Compiler generiert aber C-Code, dann kann man wenigstens auf einen guten Teil der Tools für C zurückgreifen.

Arcoth schrieb:

enum class tut was du möchtest

Lesen? Ich sagte, enum hat den falschen Default; enum sollte standardmäßig enum class sein. Siehe hustbaers Post.

Arcoth schrieb:

switch-break kapier ich gerade nicht

case-Fallthough sollte nicht der default sein und break in einem switch sollte nicht explizit geschrieben werden müssen.

Arcoth schrieb:

Kein Teil von core.

Und jetzt? Was willst du mir damit sagen? iostreams sind Teil der STL und somit Teil der Sprache. Wenn ich neu bei C++ bin, dann werde ich mit 99%iger Wahrscheinlichkeit die iostreams benutzen für Terminal- und Datei-IO.

Andromeda schrieb:

Das stimmt doch gar nicht: https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html

Wo ist jetzt die Funktion? Ich sehe nur den Funktor PersonAgeComparator. Und die Syntax mit :: ist laut deinem Link auch nur Synataxzucker für ein Lambda. Wo sind jetzt also die Funktionszeiger?
Lambdas in Java sind mir aber zugegebenermaßen neu, dürften aber auch ein eher kürzlich eingeführtes Feature sein.

was erwartest Du denn eigentlich? Nachdem das Rad erfunden worden war, dauerte es noch Jahrtausende bis zur Erfindung des Autos. Digitale Computer gibt es seit wieviel Jahrzehnten - 7? Der größte Teil der Entwicklung in der Computerprogrammierung steht vielleicht erst noch bevor.

Andromeda

turbo autist schrieb:

Wo ist jetzt die Funktion? Ich sehe nur den Funktor PersonAgeComparator. Und die Syntax mit :: ist laut deinem Link auch nur Synataxzucker für ein Lambda. Wo sind jetzt also die Funktionszeiger?

In der Überschrift "Method References" zum Beispiel. Ob du nun method reference oder function pointer dazu sagst, ist Jacke wie Hose. Im Kern ist es das Selbe.

Beispiel:

double test (Function<Double , Double> f, Double p)
{
   return f.apply(p);
}

double r = test (Math::sqrt, 9.0);  // Math.sqrt über function pointer aufrufen

Es gibt Dinge, die schließen sich mehr oder weniger aus. Z. B. Sicherheit/Komfortabilität.
Bis vor kurz galt auch folgender Ausschluß:
- Sicherheit/Performance
- Wartbarer und lesbarer Code/Performance

Ich finde, rust macht hier einen guten Job bzgl. Performance, Sicherheit, Wartbarkeit und dafür, dass die Sprache verdammt jung ist, macht sie einen sehr guten Eindruck!
Deine Behauptung, dass man C-Code nur 10 Minuten pro Woche debuggen muss, glaubst du wohl selbst nicht, es sei denn, du hast nie ernsthaft damit gearbeitet. Gleiches gilt für C++.
Bei rust hast du zwar eine größere Investition, wenn du Code schreibst, dafür sinkt dann die Investition in Debugging und Wartung. rust lädt auch zu Unit-Tests ein, in dem es Tests in der Sprache miteinbaut und du sogar private Funktionen direkt testen kannst. Weiter kann es dokumentierten Beispiel-Code auf Kompilierbarkeit prüfen. Damit stellt man sicher, dass die Dokumentation aktuell bleibt.
Mein Fazit: Die strengen Sicherheitsgarantien wirken nur auf dem ersten Blick hinderlich. Unterm Strich hat man einen großen Zeitgewinn bei größeren Projekten erreicht. Das teuerste in der Entwicklung ist nun mal immer noch, wenn Bugs in der Produktion auftauchen.

Hier mal ein Zitat eines GNOME-Entwicklers:

Every once in a while someone discovers a bug in librsvg that makes it all the way to a CVE security advisory, and it's all due to using C. We've gotten double free()s, wrong casts, and out-of-bounds memory accesses. Recently someone did fuzz-testing with some really pathological SVGs, and found interesting explosions in the library. That's the kind of 1970s bullshit that Rust prevents.

https://people.gnome.org/~federico/news-2016-10.html#25

Wutz

ShadowClone schrieb:

Every once in a while someone discovers a bug in librsvg that makes it all the way to a CVE security advisory, and it's all due to using C. We've gotten double free()s, wrong casts, and out-of-bounds memory accesses. Recently someone did fuzz-testing with some really pathological SVGs, and found interesting explosions in the library. That's the kind of 1970s bullshit that Rust prevents.

Das ist alles allgemein bekannt. Schon seit 40 Jahren.
Und es gibt auch eine Lösung dafür: Klappe halten bzw. Finger weg von C, wenn man keine Ahnung hat.
Torvalds hat bewiesen, dass man - wenn man Ahnung hat - zuverlässige und performante Implementierungen abliefern kann.
Wenn man es trotzdem nicht lassen kann, ist man halt selbst schuld, und es wird definitiv nicht besser wenn man sich auf andere Sprachen orientiert in der Hoffnung, die offenbarten eigenen prinzipiellen Unzulänglichkeiten bei Design und Entwicklung durch eine andere Sprache ausbügeln zu lassen.

Wutz schrieb:

Das ist alles allgemein bekannt. Schon seit 40 Jahren.
Und es gibt auch eine Lösung dafür: Klappe halten bzw. Finger weg von C, wenn man keine Ahnung hat.
Torvalds hat bewiesen, dass man - wenn man Ahnung hat - zuverlässige und performante Implementierungen abliefern kann.
Wenn man es trotzdem nicht lassen kann, ist man halt selbst schuld, und es wird definitiv nicht besser wenn man sich auf andere Sprachen orientiert in der Hoffnung, die offenbarten eigenen prinzipiellen Unzulänglichkeiten bei Design und Entwicklung durch eine andere Sprache ausbügeln zu lassen.

Ich weiß nicht, in welcher Welt du lebst, aber in der, der ich lebe, werden im Linux-Kernel Schwachstellen gefixt, die zum Teil viele viele Jahre überdauert haben. Eins davon, hat nicht mal dein gelobter Torvalds gefixt:

Die Schwachstelle existiert in ihrer aktuellen Form mindestens seit Kernel 2.6.22 – also seit über neun Jahren. In seinem Code-Commit mit dem Fix erwähnt Kernel-Chef Torvalds, dass es sich um einen "uralten Bug" handele, der schon vor elf Jahren einmal "schlecht" von ihm selbst gefixt worden war. Diese Änderung habe man wieder rückgängig machen müssen; nun sei die Sicherheitslücke allerdings endgültig gestopft.

https://www.heise.de/security/meldung/Dirty-Cow-Uralt-Bug-im-Linux-Kernel-gefixt-3355996.html

Leute wie du implizieren mit ihrer Echte-Männer-Analogie, dass
- Menschen keine Fehler machen
- Code mit der Zeit auch nicht komplexer wird
- ignorieren dass, in allen Projekten kompetentere und weniger kompetentere Leute sind
- Zeitdruck zu noch mehr Fehlern führen
- es keinen Unterschied macht, ob man C oder rust verwendet. Die Qualität sei bei Person X immer dieselbe. Sprich, es wird schwarz/weiß gedacht. Grautöne existieren natürlich nicht.

Wutz

Du kannst nicht lesen. Und kannst oder willst nicht verstehen.
Deine Argumentation ist armselig, du versuchst pubertär anhand von Einzelfällen meine allgemein gehaltenen Aussagen zu widerlegen.
Ich habe nicht gesagt, dass Torvalds keine Fehler macht. Das versuchst du mir aber zu unterstellen um mich daran zu "widerlegen".
Wenn du deinen zitierten Text mal gelesen, verstanden und Ahnung von C hättest:
dann wäre dir deine Offenbarung eigener Unkenntnis über C sicher nicht passiert.
Nochmal für dich als Laien zum Verständnis:
die zitierten "Bullshits" sind grundlegende Anfängerfehler, die jeder halbwegs erfahrene C Programmierer nie begeht, niemand verwendet Zeigercasts wenn er nicht genau weiß, was er tut. Und Ahnungslose wissen nun mal nicht, was sie tun.
Und dilettantisches NULL-Setzen eines Zeigers nach free() zur "Vermeidung" von Laufzeitfehlern bei double-frees (und somit quasi kostenloser Offenbarung von schlechtem Design und fehlendem Überblick durch das Laufzeitsystem) dürfte selbst bei deinem Horizont begreiflich sein.
Der Zitierte desavouiert sich als naiver Laie wenn er sich darüber beschwert, die Sprache sei schuld weil sie ihn nicht vor sich selbst und seinem eigenen Dilettantismus schütze.
C aufgrund dieser offenbarten Ahnungslosigkeit als Bullshit zu bezeichnen ist naiv-dilettantisches Laiengeschwätz, ebenso wie deine Argumentationsweise.

Tyrdal

Das bedeutet im Klartext, es gibt auf dieser Welt keine halbwegs erfahrenen C-Programmierer, denn die Bugs in C gibt es.

C ist doch nur was für Frickler.