Wieso gibt es keine gute Programmiersprache?
-
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/PerformanceIch 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.
-
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.
-
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.
-
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.
-
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,...)
-
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.
-
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
implicitsein 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.
-
Arcoth schrieb:
Neh, die Lösung heißt Finger weg von C, die Sprache ist ein Desaster.
Ein schlechter Handwerker macht immer das Werkzeug verantwortlich.
C ist super. Wäre es nicht so, würde es heute kaum noch jemand benutzen (wie BASIC). C ist sowas wie eine portable Assemblersprache. Minimalistisch und leistungsstark. Das Swiss Army Knife der Programmierung.
-
Andromeda schrieb:
C ist super. Wäre es nicht so, würde es heute kaum noch jemand benutzen (wie BASIC). C ist sowas wie eine portable Assemblersprache. Minimalistisch und leistungsstark. Das Swiss Army Knife der Programmierung.
Vielleicht für zweitausend LOC Projekte
Andromeda schrieb:
Ein schlechter Handwerker macht immer das Werkzeug verantwortlich.
Ach, und die Krankenschwestern, die beschuldigt werden, wenn total inkonsistent designte Infusionspumpen in den Krankenhäusern rumliegen, die waren ja so schuld am Desaster!Weil das Werkzeug einfach total ok war, oder? Aber die Therac Unfälle, in denen "inkorrekte Operation" vorgeworfen wurde, nachdem mehrere Menschen Verbrennungen dritten Grades durch Software-Fehler davontrugen! Total die Schuld der Operatoren!
-
ich frag mich wirklich, wie man so dermaßen herablassend und beleidigend werden kann...
Wenn populäre C-Software da draußen (OpenSSL ist ein weiteres Beispiel) nur so vor Fehlern und Sicherheitslücken strotzen, hilft es wenig zu sagen, dass das alles Anfänger seien. Die Fehler sind da und die Software und Libs sind da und werden benutzt!
Es macht einen Unterschied, ob eine Sprache Sicherheitsmechanismen hat oder eben nicht. Es macht auch einen Unterschied, ob ich mich in ein Auto mit Gurt, ABS, ESP, Airbag, Müdigkeitserkennung etc. setze oder in ein Auto, das das alles nicht hat. Dass das alles einen Unterschied macht, zeigen doch die Statistiken (*).(*) https://de.wikipedia.org/wiki/Verkehrstod#/media/File:Verkehrstote_Deutschland.svg
-
ShadowClone schrieb:
https://de.wikipedia.org/wiki/Verkehrstod#/media/File:Verkehrstote_Deutschland.svg
Aha! Und der Knick bei 1990 ist weil da der ISO C Standard rauskam!
-
scrontch schrieb:
ShadowClone schrieb:
https://de.wikipedia.org/wiki/Verkehrstod#/media/File:Verkehrstote_Deutschland.svg
Aha! Und der Knick bei 1990 ist weil da der ISO C Standard rauskam!
Ernsthaft?! Denk mal scharf nach was 1990 in D passiert ist!
-
Arcoth schrieb:
Andromeda schrieb:
C ist super. Wäre es nicht so, würde es heute kaum noch jemand benutzen (wie BASIC). C ist sowas wie eine portable Assemblersprache. Minimalistisch und leistungsstark. Das Swiss Army Knife der Programmierung.
Vielleicht für zweitausend LOC Projekte
Der größte Teil der meisten Betriebssysteme ist, seit C existiert, in C programmiert worden. Mit 2k LOC kommst du nicht hin.
-
Andromeda schrieb:
Arcoth schrieb:
Andromeda schrieb:
C ist super. Wäre es nicht so, würde es heute kaum noch jemand benutzen (wie BASIC). C ist sowas wie eine portable Assemblersprache. Minimalistisch und leistungsstark. Das Swiss Army Knife der Programmierung.
Vielleicht für zweitausend LOC Projekte
Der größte Teil der meisten Betriebssysteme ist, seit C existiert, in C programmiert worden. Mit 2k LOC kommst du nicht hin.
Aber das ist doch gerade das Thema dieser Nebendiskussion, dass genau diese grundlegende Software oft Sicherheitslücken enthält, eben weil dort so viel in C gemacht wurde!
-
SeppJ schrieb:
Der größte Teil der meisten Betriebssysteme ist, seit C existiert, in C programmiert worden. Mit 2k LOC kommst du nicht hin.
Aber das ist doch gerade das Thema dieser Nebendiskussion, dass genau diese grundlegende Software oft Sicherheitslücken enthält, eben weil dort so viel in C gemacht wurde!
Sicherheitslöcher und u.ä. Bugs sind meistens Nachlässigkeit, Faulheit und Schlamperei. Niemand hat sich wirklich um die Softwarequalität gekümmert. Auch damals gab es schon Lint, womit viele versteckte Bugs gefunden wurden. Heute gibt es weitaus mehr: https://de.wikipedia.org/wiki/Liste_von_Werkzeugen_zur_statischen_Codeanalyse#C.2FC.2B.2B
Inklusive Entwicklungsrichtlinien wie MISRA, SPICE, usw.Es liegt also weniger an der Pogrammiersprache, als am Willen des Programmierers, qualitativ hochwertige Software zu schreiben.
-
Ist mir ja fast zu blöd hier mitzumachen, was ein Thread-Titel, besser gleich dicht machen...
Natürlich gibt es nicht DIE BESTE (TM) Programmiersprache, aber es gibt sehr wohl sehr gute Programmiersprachen für jeweils verschiedene Einsatzzwecke. Moderne Sprachen wie TypeScript oder C# machen das Programmieren auch für den Programmierer sehr angenehm, das ist in C vielleicht etwas weniger der Fall, weil man sich um viel mehr Einzelheiten kümmern muss, aber dafür hat man eben auch hier und dort mehr Möglichkeiten.
Gibt's zu dem Thema wirklich einen mehrseitigen Artikel?
MfG SideWinder
-
Es liegt also weniger an der Pogrammiersprache, als am Willen des Programmierers, qualitativ hochwertige Software zu schreiben.
es bringt nichts mit der Qualität der Entwickler zu argumentieren -
ich hab schon für viele Firmen gearbeitet und bisher war das größte Problem immer noch das finden von guten Softwareentwicklern oder Leadern - egal in welcher Sprache - davon gibt es einfach nicht so viele - und wer was anderes denkt hat einfach noch zu wenig Erfahrungwenn man mal in mehreren Mio-Zeilen Projekte in verschiedenn Sprachen gearbeitet hat und auch die selbstgeschriebenen Mio-Zeilen Quelltext locker überschritten hat sieht man die Softwareentwicklungswelt und die Ursache der Probleme aus einem anderen Blickwinkel - und auch erst dann kann man nach meinem Gefühl beurteilen was gut oder schlecht ist - alles andere ist doch wirklich nur irgendwie spielen
und die Qualität einer Programmiersprachen an anderen Projekten festzumachen ist sinnfrei - an Linux z.B. arbeiten sehr viele Top C-Entwickler - da ist keine per se Aussage zu der Qualität von C möglich - es hängt am Team - Linus und seiner enger Stab wären in jeder Programmiersprache fehlerfreier/besser als die meisten egal ob C++, Javascript oder Perl (und wenn man auf >40 Platformen laufen will gibts eben nur C als Antwort - fertig ist die Laube)
eine Programmiersprache welche viele der machbaren Fehler von gängigen Programmiersprachen "unprogrammierbar" macht ist besser für den kommerziellen Erfolg - weil unabhängig vom Team - je mehr die machbaren Fehler auf den Algorithmus reduziert werden um so besser
nach meiner Meinung geht Rust (als C/C++ Ersatz) da in die richtige Richtung wenn auch noch lange nicht fertig - aber ich sehe da mehr Zukunft als in anderen imperativen oder den funktionalen Sprachen - lasst die mal das Ownership Prinzip rundschleifen, Zero-Cost-Abstraktion durchziehen und noch ein bisschen mit den Traits/Macros spielen könnte da wirklich was draus werden - keine andere "neue" Programmiersprache war jemals so nah drann eine wirkliche C/C++ "Ablösung" zu sein
-
Arcoth schrieb:
Ich würde nicht unbedingt ein großes Projekt in C++ schreiben oder managen wollen, die Sprache ist zu heftig für Juniors.
Siehst du dich etwa als Junior? Ich kann das so nicht bestätigen, wir haben ein (relativ gesehen) sehr großes Projekt in C++ und ich seh da jetzt keine großartigen Probleme. Auch unsere Junior Entwickler kommen zurecht. Und es gibt so viele verschiedene Komponenten, Anforderungen und Stile, dass ich das Projekt nicht in einer anderen Sprache schreiben wollen würde.
