Wieso gibt es keine gute Programmiersprache?

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

muemmel

Hi,

allseitig gute Programmiersprachen gibt es wirklich nicht. Ich vermute mal, es wird sie auch nicht geben. Jede Programmiersprache ist eine Abstraktion und Einschränkung auf eine bestimmte Anwendung.
SQL ist z.B. eine sehr gute Sprache zum arbeiten mit Datenbanken. Aber ein Programm schreiben, das Wellen auf Dauerbruchfestigkeit nachweist wäre schon sehr anspruchsvoll.
Für solche Berechnungen war Fortran damals der Renner (auf dem MainFrame auch heute noch). Mit Fortran Datenbanken auswerten mag gehen, aber es ist ein Krampf.
Cobol ist in der Finanzmathematik kaum zu schlagen, aber damit einen CAD-Arbeitsplatz programmieren, da nehmen wir aber doch lieber was anderes.
In den letzten Jahren der DDR war Forth eine regelrechte Hype. Alles sollte in Forth gehen. Nur Forth wurde zur Echtzeitsteuerung von Radioteleskopen entwickelt. Sicher auch für Waschmaschinen- und Geschirrspülersteuerungen sehr brauchbar. Aber will man damit wirklich ein Buchhaltungsprogramm schreiben?
C war von Hause aus als maschinenunabhängiger Assembler geplant. Ist eine sehr schöne kleine elegante Sprache, die auf Grund ihrer Abgrenzung gute Möglichkeiten für leistungsfähige und fehlerarme Compiler bietet. Ich habe damals sehr gerne mit C gearbeitet. Aber in Sachen Abstraktionsmöglichkeiten und Objektorientiertheit hat sie ihre Grenzen. Für kleine Sachen immer noch gut zu brauchen, aber mit größer werdenden Programmen sehr schnell unhandlich. Und es erfordert sehr viel Disziplin vom Programmierer, die nicht jeder hat.
Als eierlegende Wollmilchsäue waren damals PL/1 und Algol68 angedacht. Beide sehr leistungsfähig, vor allem PL/1 von Echtzeitprogrammierung bis Finanzmathematik geeignet. Aber einfach zu groß, zu unhandlich, zu kompliziert.
Heute spricht mit Recht von beiden keiner mehr.
ADA war als Alleskönner-Sprache für Anwendungen mit höchstem Sicherheitsanspruch ausgelegt. Flugzeugsteuerungen werden wohl zum Teil heute noch in ADA programmiert. Aber kennt sonst noch einer jemanden der ADA verwendet.
Pascal war als Lehrsprache entwickelt. Das reine Pascal hat aber auch nicht überlebt. Allerdings hat es unter Borland in der weiterentwicklung Delphi ein zweites Leben (und insgeheim ganz viele Eigenheiten von C++) eingehaucht bekommen. Für nicht zu große Anwendungen unter Verwendung der VCL und für Datenbankanwendungen ist es immer noch eine sehr leistungsfähige Sprache, die sich schnell und übersichtlich programmieren lässt und selbst vor parallelisierung nicht zurückschreckt. Wird aber (abgesehen vono Lazarus) nur vom Borland-Nachfolger Embarcadero angeboten.
Für parallelverarbeitung war lange Zeit Occam der Renner, gibts hier bei uns im Forum noch einen, dem die Sprache was sagt?
C++ hab ich damals mit dem alten Borland Turbo-C++ gemacht und war sehr zufrieden damit. Mit den alten C++Buildern von Borland war ich dagegen nicht so sehr zufrieden. Programme, die ohne Fehlermeldungen komplett abstürzen und auch die Entwicklungsumgebung mit runterreißen machen keinen Spaß. Irgendwie war damals die Anbindung der Delphi-VCL an C++Quelltext nicht so optimal gelöst. Das konnte Delphi damals besser. Aber trotzdem ist C++ eine extrem leistungsfähige Sprache, die aber in ihrer Komplexität mittlerweile PL/1 überholt haben dürfte. Vorteil von C++, dass man mit dem Befehlssatz von C schon anfangen kann erste Programme zu schreiben und sich schrittweise tiefer einarbeiten kann. Vorteil auch gute Literatur für C++ (Stroustrup, Scott Meyers...). Aber auch C++ benötigt den disziplininierten Programmierer. Dafür sind die OOP- und Abstraktionsmöglichkeiten sehr gut, so dass auch sehr große Projekte noch gut händelbar sein können.
Java ist damals angetreten, ein C++ für alle die sein zu wollen, die für C++ nicht gut oder nicht diszipliniert genug waren. Mittlerweile ist es aber auch schon ein ziemlicher Saurier geworden.
Bei mit im Betrieb haben sie damals "Compiler" für die Übersetzung von NC-Maschinen-Programmen, sowie eine Steuerung eines Integrierten Fertigungsabschnittes in dBase II programmiert. Hat auch funktioniert. dBase war da, und einer des konnte auch (ich nicht). Der Rest waren Eda-Kosten (der war ja eh da).
Irgendwie ist die Summe der Huckel in der Straße eigentlich konstant. Sie sid nur unterschiedlich angeordnet.

Gruß Mümmel

SideWinder

Andromeda schrieb:

hustbaer schrieb:

Ausser Blabla noch was beizutragen?

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

https://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Assembler-stabil-Go-im-Aufwind-3458803.html

Sieht also aus, als wäre C# sehr stabil. Es gibt einfach mehr Vielfalt als vor 5 Jahren. BTW: stärkster Anstieg in den Top10: Visual Basic .NET.

MfG SideWinder

Was mich eher wundert als die Abwesenheit universell idealer Programmiersprachen ist, daß die heute verwendeten Paradigmata überwiegend aus den 1950er bis 1970er Jahren stammen. Oder gibt es Features in gängigen modernen Programmiersprachen, die nicht zumindest im Prinzip schon zwischen 1950 und 1980 erfunden worden waren?

muemmel

Hi Zufallswert,

zufallswert schrieb:

Was mich eher wundert als die Abwesenheit universell idealer Programmiersprachen ist, daß die heute verwendeten Paradigmata überwiegend aus den 1950er bis 1970er Jahren stammen. Oder gibt es Features in gängigen modernen Programmiersprachen, die nicht zumindest im Prinzip schon zwischen 1950 und 1980 erfunden worden waren?

Ich würde sagen, generische Programmierung ist neuer.

Gruß Mümmel