Wieso gibt es keine gute Programmiersprache?

[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.

[v.]

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

[turbo autist]

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.

[zufallswert]

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

[Gast]

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.

[Gast]

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.

[9]

C ist doch nur was für Frickler.

[Wutz]

Tyrdal schrieb:

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

Auch du kannst oder willst nicht lesen und verstehen.
C hat keine Bugs. Der Bug sitzt vor dem Monitor.
Der fehlerhafte Gebrauch von Sprachgrundlagen durch den Programmierer ist nicht Schuld der Sprache sondern immer Schuld des Programmierers.
Bei eigenem Versagen die Sprache als "Schuldigen" zu titulieren ist eine naiv-dilettantische Schutzbehauptung. (entlarvbar nur durch Leute mit Ahnung, aber nie durch die meistadressierten Empfänger solcher Aussagen: Manager,Chefs in allgemeiner Form,Kunden,IT-Berater,...)

[SeppJ]

Wutz schrieb:

Tyrdal schrieb:

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

Auch du kannst oder willst nicht lesen und verstehen.
C hat keine Bugs. Der Bug sitzt vor dem Monitor.

Trotzdem sind die Fehler am Ende da. Und in den Fällen, die besagter Gnome-Entwickler beschreibt, gilt "Mit Rust wär das nicht passiert". Das ist dann schon ein Nachteil (nicht Fehler) der Sprache, wenn sie leicht zu Fehlern in Programmen führt, die mit andere Sprachen nicht aufgetreten wären.

Du erinnerst mich hier sehr an Arcoth und C++. Sofort Beißreflex, sobald jemand Kritik am Lieblingskind äußert.

[Columbo]

Wutz schrieb:

C hat keine Bugs. Der Bug sitzt vor dem Monitor.

Halt einfach die Klappe, Wutz. Du hast von Software-Entwicklung ungefähr soviel Ahnung wie ich vom Vögeln.

Wutz schrieb:

Und es gibt auch eine Lösung dafür: Klappe halten bzw. Finger weg von C, wenn man keine Ahnung hat.

Neh, die Lösung heißt Finger weg von C, die Sprache ist ein Desaster.

hustbaer schrieb:

Explicit müsste Default sein, und das was man schreiben muss "wenn man es so meint" müsste dann z.B. "implicit" heissen.

Das sehe ich weniger als Nachteil der Sprache, sondern eher als Umgewöhnung: statt eines anzunehmen, nehmen wir etwas anderes an. Da viele Konstruktoren tatsächlich implicit sein sollen, sparen wir durch deinen Vorschlag nichts; die Sprache wird nur leichter zu lernen, was definitiv ein Goodie ist, aber eben nichts bringt, wenn wir schon einen Haufen kompetenter Seniors engagiert haben. Ich verstehe unter einem tatsächlichen Nachteil in der Sprache selbst (d.h. nicht in ihrem Einsatz in speziellen Domains, in ihrer Erlernbarkeit, etc. sondern in ihrer Struktur) eine Eigenschaft, die

• das ausführbare Programm verlangsamt, unsicherer macht oder auf irgendeine Art beschränkt,
• unnötige Arbeit oder Aufmerksamkeit des Programmierers voraussetzt (dazu gehören IMO nicht Dinge die wir durch Gewohnheit missverstehen, weil jede differenzierte Sprache sowieso Umgewöhnung impliziert),
• die Sprache schlecht erweiterbar oder skalierbar macht, auch im Bezug auf Parallelität (hier sind imperative Sprachen klar im Nachteil; funktionale Sprachen wie ML skalieren dank ihrer Immutabilität exzellent über mehrere Kerne).

Natürlich ist es bescheuert, dass & schwächer bindet als == , aber sobald wir diese Tatsache verstanden haben, oder noch besser - wir Warnungen anknipsen und lesen - ist das kein Problem mehr.
Deswegen überzeugt mich das Argument der Defaults einfach nicht: wir können sie sowohl aneignen als auch heuristische Warnungen implementieren.

Ansonsten? Einfach die geilste Sprache aller Zeiten. Irre ausdrucksstark, gut optimierbar und performance-orientiert, erlaubt sowohl low-level als auch generische, abstrakte Konstrukte, hat gut Syntaxzucker, eine aktive Standardisierungscommunity die im Dreijahrestakt haufenweise Neuerungen rausbringt und einen Präprozessor, falls doch mal was nervt. Und weil ich den Großteil meines Intellekts in sie investiert habe, werde ich sie auch bis zum letzten Drücker verteidigen.

Wenn wir aber von C++ in der Praxis sprechen, gibt es natürlich sehr viele Probleme. Die Liste der unintuitiven Grammatik, Semantik usw. ist sehr, sehr lang. Ich würde nicht unbedingt ein großes Projekt in C++ schreiben oder managen wollen, die Sprache ist zu heftig für Juniors.