Wieso gibt es keine gute Programmiersprache?

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.

Andromeda

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.

Columbo

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

scrontch

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!

Andromeda

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.

SeppJ

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!

Andromeda

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.

SideWinder

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 Erfahrung

wenn 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

Mechanics

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.

Bitte ein Bit

Arcoth schrieb:

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

Ok...

Ein schlechter Handwerker macht immer das Werkzeug verantwortlich.

Es mag Leute wie ich geben, die in einer solchen Situation das Sägeblatt absichtlich verkehrt herum montiert. Oder ein Steinbohrer für Holzarbeiten empfiehlt.

---

Das größte Manko an C ist das fehlen einer Standard-STL und einer anständigen Speicherverwaltung (siehe RAII). So eine Allokationskaskade ist in C mühsam zu implementieren. Da machen auf einmal alte Programmier Relikte (goto) Sinn. Laien produzieren hier gerne Speicherlöcher. Und die fehlende Funktionsüberlagerung führt dazu, dass es X Funktionen für eine Funktionalität gibt. Bsp.: sprintf, _sprintf, sprintf_s, StringCbPrintf, StringCchPrintf.

Ich kenne und nutze 5 unterschiedliche C Compiler (Atmel Studio,...) für unterschiedliche Platformen. Da wäre es schön wenn man überall eine einheitliche STL hätte, ohne dass man sich für eine Open Source Variante entscheiden, diese auf anderen Platformen portieren und ausgiebig testen muss.

Und so manches Projekt wurde von globalen Variablen erschlagen. Die einfache Syntax verlockt so manchen Laien zu so manchen Programmiersauereien.

hustbaer

Arcoth schrieb:

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;

Also mir begegnen weitaus mehr Konstruktoren die explicit sind als welche die implicit sind. Bzw. welche die explicit sind oder es sein sollten, denn dass explicit oft vergessen wird (viele kennen das Keyword gar nicht), ist für mich Fakt. Ich sehe dauernd Code wo Konstruktoren die z.B. Ownership des 1. Arguments übernehmen oder total sinnfreie Konvertierungen wie Filename => File durchführen eben gerade nicht explicit sind.
D.h. einerseits würde man sich mMn. definitiv etwas Tipparbeit sparen, und dann wäre explicit halt das "safe Default" das einfach zu weniger Fehlern führt.

Speziell das Ergänzen von explicit wenn man dem 2. Parameter nen Default-Wert verpasst (oder gar den 2. Parameter ganz entfernt) wird häufig vergessen. Das kann man vermeiden indem man - wie ich - explicit grundsätzlich an jeden Konstruktor dranschreibt, ausser eben an die paar wenigen die wirklich implicit sein sollen. Tun aber auch von den wenigen Programmierern die überhaupt auf explicit achten nicht viele.

Arcoth schrieb:

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.

Tjoah. Dummerweise hat kaum jemand ausreichend viele kompetente Seniors. Zumindest nicht ausreichend viele ausreichend kompetente Seniors.

Ich finde C++ auch cool. Definitiv. Aber es gibt da doch einige Dinge die ich als Schwachpunkt ansehe. Und explicit ist eins davon.

5cript

Die explicit Sache macht nur bei einem Parameter Sinn, und in verdammt vielen Fällen WILL ich die Konvertierung. Ich schmeiß auch mit der braced initialization um mich, und da müsste ich sonst immer den Typ vorschreiben.
Ich sehe selten einen Grund explicit zu schreiben, bzw ich würde mich dabei sogar selbst behindern.
Der einzige Fall der mir sofort einfällt ist unique_ptr, weil da es verdammt gefährlich wär, wenn der ctor nicht explicit wäre.

Also da wage ich zu wiedersprechen. So viele Konstrutktoren die ich geschrieben habe waren nur ein bruchteil davon sinnvoll explicit.
Vielleicht programmieren wir ja auch völlig unterschiedlich.

5cript schrieb:

Vielleicht programmieren wir ja auch völlig unterschiedlich.

Ja, tun wir scheinbar. std::size_t soll nicht implizit in std::vector konvertierbar sein und std::string auch nicht in std::fstream . Hingegen soll unsigned long long mit Freuden implizit in std::bitset konvertierbar sein.
Implizit konvertierbar heißt für mich soviel wie "selbe Daten, andere Darstellung". Widening ist eine andere Darstellung für die selben Daten, daher korrekterweise implizit. Aber std::vector ist nie eine andere Darstellung eines std::size_t s, daher soll - was auch der Fall ist - dieser Konstruktor explizit sein, sodass der Nutzer gezwungen ist, die Konstruktion - die ja wie gesagt keine Umwandlung ist - mithilfe eines Casts oder eines Aufrufs zu betonen.

5cript

Solche Fälle produziere ich nicht.

Wenn für mich eine Klasse einen parameter nimmt, dann ist die Konvertierung ok, wenn ich sie benutzen will. Wenn sie das nicht ist, dann ist explicit genau richtig, aber solche Fälle habe ich selten.
Ich programmiere ja nicht hirnlos...

Ich muss nicht bevormundet werden, nur weil es in manchen Fällen falsch ist. Ich weiß ganz genau was ich tue.

Columbo

hustbaer schrieb:

(viele kennen das Keyword gar nicht)

Du arbeitest also mit Anfängern?

Zumindest nicht ausreichend viele ausreichend kompetente Seniors.

Dann mach halt einen Style Guide, zwing die Leute ihn sich anzuschauen.

Siehst du dich etwa als Junior?

Ich bin Student, sonst gar nichts.

Ich muss nicht bevormundet werden, nur weil es in manchen Fällen falsch ist. Ich weiß ganz genau was ich tue.

wie gut das man immer nur alleine an einem Projekt arbeitet - und besonders immer nur neuen eigenen Code schreibt - falls du es vergessen hast: es ist immer das höchste Ziel das Produkt mit den notwendigen Feature so schnell und so fehlerfrei wie möglich auf den Markt zu bringen - und dort zu halten/warten - das erzeugt mehr Zeit und Geld um weitere Investitionen in andere Produkte/Features zu tätigen - das bedarf meistens mehr als einen Mitarbeiter - aber wenn man denkt das das Geld für deine Arbeitsleistung so oder so irgendwie erwirtschaftet wird - und nur die Qualität deiner Module entscheident ist wird es mit dem argumentieren ein wenig schwierig

wenn explict von Anfang an implizit gewesen wäre (geht eben nicht wegen Kompatitbilität) müsstes du dich auch nicht wund tippen und viele Fehler die daran hängen wären damit schon mal vom Tisch und davon gibt es eben viele kleine Dinge die in C++ wegen der Kompatitbilität nicht so supertoll sind - und arbeite selbst schon >20 Jahre mit C/C++ in allen Tiefen