Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Ada und Spark: Mehr…
  6. T…

Es ist keine Frage der Programmiersprache

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Es ist keine Frage der Programmiersprache

    Autor: apriori 12.06.19 - 13:18

    > C ist ein Minenfeld, wo man das zehn Jahre studiert haben muss um kein
    > verstecktes Problem einzubauen. Wer hat nur zum Beispiel diese idiotische
    > Idee gehabt, Verhalten undefiniert zu lassen. Stichwort nasal demons.
    > Bessere Sprachen könne da schon etwas verbessern. Und wenn man als
    > Programmierer nicht zehtausend Fallstricke im Hinterkopf behalten muss,
    > vielleicht sieht man dann auch den eigenen Fehler den man macht.

    Das kann ich nur unterschreiben. Ich habe bereits so einige C- und C++-Projekte
    von ehemaligen Möchtegern-Gurus geerbt. Sie waren voller offensichtlicher
    Fehler. Für mich ist eine Sprache, welche die Grundannahme "Wir sind alle im
    Zweifelsfall völlig inkompetent" (und dafür sehe ich Beweise jeden einzelnen Tag - und ja, da nehme ich mich nicht raus) hat, definitiv lieber. Es ist doch relativ simpel: Je strenger eine Sprache ist, desto weniger Mist kann gebaut werden. Die hohe Kunst ist es jetzt, Produktivität und Sicherheit zu kombinieren. Für Nischen kommt noch hohe Performanz hinzu.

    Wieso man sich in Kreisen C/C++ immer wieder auf elitistisches "Ich bin Gott und mache keine Fehler"-Denken zurückzieht, ist mir völlig schleierhaft. Wie viele Gegenbeweise brauchen wir noch? So eine Denkweise ist vollkommen unwissenschaftlich und geradezu esoterisch.

    Es hat seine Gründe, warum immer wieder neue Sprachen entwickelt werden. Das nennt sich Wissenschaft, ergo: "Dinge mal anders machen" und absolut erforderlich. Viele Erkenntnisse aus diesen Sprachen fließen ja auch in etablierte Sprachen ein (z.B. Linq, als Derivat von Lazyness und Functors aus Haskell) und bereichern diese. Hierbei ist aber auch die Frage, wie erweiterbar ist die etablierte Sprache noch (ohne alles auf den Kopf zu stellen). Und hier stößt man bei C++ schon ziemlich an Grenzen. Man will 100%-ige Rückwärtskompatibilität (finde ich vollkommen schwachsinnig, da die Bereiche, die so arg konservativ sind, dass sie eine Dekade hinterher hängen, nichtmal je ihren Compiler updaten würden, also kann man sich das auch schenken). Ich finde aber auch den Invest C++ wieder auf den "Stand der Zeit" zu bringen, vergeudete Zeit. Wo müsste man überall ansetzen?

    1. Cross-plattform-Buildsystem (eins, das auch versteht, wie ein Projekt präzise aufgebaut ist und kein
    dummer Batch-Executor (make, ninja, etc.)). CMake als Buildsystemgenerator ist ein schlechter Scherz, wenn man
    es selbst mit dem in die Tage kommenden Maven, Gradle (selbst MSBuild/Nuget), sbt, cargo oder dergleichen vergleicht.
    2. Archaisches Kompiliermodel (Header/Implementation) entfernen. Man nenne mir nur einen einzigen Vorteil davon,
    Verweise über mehrere Dateien manuell synchron zu halten. Das hier im Wesentlichen die Link-Time gesteuert wird, ist
    mir als Nutzer völlig egal. Ich bin kein Babysitter für den Compiler/Linker.
    3. Modulsystem etablieren (und damit idiotische stateful Includes loswerden)
    4. Paketmanager mit bequemen Deployment entwickeln (conan.io? Nope. Da 1. nicht erfüllt, bleibt es krampfig)
    5. Brauchbaren IDE-Support und Tooling/Linting, welches sich *präzise* wie der Compiler verhält (vlt. dadurch, dass es auch der Compiler ist). Libclang? Nope, instabiles Interface/AST. Language-server-protocol-Implementierungen gibt es AFAIK, aber sie sind wegen 2. und 3. extrem inperformant. Viele IDEs nutzen noch immer in vielen Fällen inkorrekte
    Heuristiken (Beispiel: Codenavigation zu einer Überladung einer Funktion. Überladung wird nicht korrekt aufgelöst)
    Clang-Tidy etc. sind ja mittlerweile in VS eingebaut. Das ist ja ganz nett, wenn Microsoft Solutions Cross-Plattform für C++ irgendeine Relevanz hätten. Sonst ist es doch häufig arg krampfig, Tooling an ein C++-Projekt anzubringen (es gibt ja keine einhaltliche Projektbeschreibung. Und nein, eine stumpfe Operationsliste à la compile_commands.json ist kein Projekt).
    6. Fragwürdige syntaktische Konstrukte abschaffen. Ich nenne hier nur zwei Beispiele:
    - Der ","-Operator in if-Conditions.
    - Das Assignment ("=") in if Conditions, mit anschließendem Boolcast des Ausdrucks
    7. Undefined behavior loswerden. Restlos. Und hier verwechselt die C++-Community noch immer echte undefined behavior mit expression based optimization mit den ständig wiederholten Behauptungen "mit undefined behavior lässt sich aber ganz toll Code optimieren". Das ist Blödsinn. Wenn undefined behavior auch exakt das ist ("ich kann machen was ich will"), gibt es nichts zu optimieren, da das Programm in sich unsound und beliebig ist. Das kann nicht gewollt sein. Bei expression based optimization würde man einen Ausdruck A in einen äquivalenten (bezüglich welcher Relation auch immer, z.B. unter Berücksichtigung von Seiteneffekten) Ausdruck B umwandeln.
    Als Zwischenschritt könnte ein Compiler bei jeder "undefined behavior" (welche auch gern mit "implementation defined behavior" verwechselt wird, da ja leider gültig, da "undefined behavior" = beliebiges verhalten) mindestens warnen. Der Aufwand, das in gegenwärtige Compiler einzubauen, dürfte exorbitant sein.

    Und ich weiß nicht. Alleine diese wenigen Punkte, bevor das richtig rund läuft, sind wohl locker ne Manndekade an Aufwand. Wozu die Zeit darin verschwenden?
    Es gibt auch einige Dinge, die ich an jeder einzelnen Sprache zu meckern habe, dennoch mag ich auch gegenwärtig besonders die Rust-Experience. Zumindest hat die Sprache/das Ökosystem ein deutlich solideres und skalierbares Fundament, in das es sich lohnt, zu investieren.

    Als Declaimer: Ich bin kein C++-Newbie und nutze die Sprache seit mehr als 15 Jahre. Dennoch hab ich mal über den Tellerrand geguckt. Und hui, was es da alles gibt, das Welten besser ist - für 99% der Anwendungsfälle.

  2. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 12.06.19 - 15:40

    apriori schrieb:
    --------------------------------------------------------------------------------
    > Als Declaimer: Ich bin kein C++-Newbie und nutze die Sprache seit mehr als
    > 15 Jahre. Dennoch hab ich mal über den Tellerrand geguckt. Und hui, was es
    > da alles gibt, das Welten besser ist - für 99% der Anwendungsfälle.

    mMn ist selbst Pascal (besonders ObjectPascal) besser als C (bzw. C++). Klarere Syntax und ein Compiler, der in der Regel nicht mal ein Buildsystem braucht. Leider hat irgendwann in den 80ern Pascal gegen C verloren. Schade eigentlich. Hätte sich Pascal als "die Sprache" durchgesetzt (im Gegensatz zu C) wären wir glaube ich in einer besseren Welt. Aber was solls.

  3. Re: Es ist keine Frage der Programmiersprache

    Autor: apriori 12.06.19 - 15:52

    Ja, Pascal war damals nach QBasic meine 2. Programmiersprache überhaupt. Und ja, sie war eigentlich ganz nett. Die Dokumentation damals von Borland war super, sowie auch die Beispiele.
    Klar, syntaktisch auch ein wenig wirsch (ich sage nur "End" bzw. "End.").
    Falls dich übrigens ein von Pascal und Python inspiriertes modernes Pendant interessiert, guck dir
    https://nim-lang.org/ mal an.

    Es wäre schön, wenn wir eines Tages C/C++ und all der Bullshit, der damit verbunden ist, mal hinter uns lassen könnten ... und nicht immer wieder Wege fänden, offensichlichsten Designpfusch zu feiern.

  4. Re: Es ist keine Frage der Programmiersprache

    Autor: Steffo 12.06.19 - 18:30

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > das sagen 1, 2, viele über z.b. python auch ...
    >
    > die eigentliche frage für nicht eigebildete ist:
    >
    > unterstützt meine umgebung heute, morgen und übermorgen xyz-kacke, wie
    > verbreitet ist diese kacke, wie lange wird diese kacke halten/wieviel
    > aufand gibt es in der pflege ... essentiel: tut das weh und kann man das
    > essen?!

    Du hast meinen Post wohl nicht in seiner Gänze begriffen. Worauf ich hinaus wollte ist, dass es zumindest sinnvoll sein kann sich mit anderen Programmier-Konzepten zu befassen. D. h. nicht zwingend, dass man sie auch produktiv einsetzt. Aber allein hin und wieder mal über den Tellerrand zu schauen, kann dich zu einem besseren Entwickler machen und dann programmierst du unter Umständen fehlerfreier C, C++ was auch immer.

  5. Re: Es ist *auch* eine Frage der Programmiersprache

    Autor: GodsBoss 12.06.19 - 21:53

    > Immer wieder lese ich diese Behauptung.
    > Aber das ist quatsch. Ich kann auch mit der besten und sichersten Sprache
    > scheiß Programme schreiben, die einen Fehler nach dem Anderen machen.
    >
    > Es ist immer einer Frage des Könnens.
    > Ein guter Programmierer schreibt in jeder Sprache gute Programme, ein
    > schlechter schreibt immer schlechte Programme egal in welcher Sprache.
    >
    > Sich auf die Fähigkeiten eines Compilers zu verlassen, Fehler zu finden
    > bzw. zu behandeln, ist fahrlässig.
    > Schon viel zu oft hab ich den Kommentar gehört: "Ich dachte da kümmert sich
    > der Compiler drum", wenn ich einen tief verborgenen Fehler aufgestöbert
    > habe.

    Natürlich kann man sicherheitsrelevante Fehler in allen Programmiersprachen machen. Aber der Artikel ist auch nicht mit "Absolute Sicherheit durch bessere Programmiersprachen", sondern mit "Mehr Sicherheit durch bessere Programmiersprachen" betitelt. Und hat damit Recht, denn es gibt eine ganze Klasse von Fehlern, nämlich die Buffer Overflows, die der Entwickler in Sprachen wie C sehr leicht einbauen kann und in Sprachen wir Java quasi gar nicht.

    "Kompiliert, funktioniert" kenne ich aus meinem Umfeld ausschließlich als Witz.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  6. Re: Es ist *auch* eine Frage der Programmiersprache

    Autor: Hello_World 13.06.19 - 17:50

    GodsBoss schrieb:
    --------------------------------------------------------------------------------
    > Und hat damit Recht, denn es gibt eine ganze
    > Klasse von Fehlern, nämlich die Buffer Overflows, die der Entwickler in
    > Sprachen wie C sehr leicht einbauen kann und in Sprachen wir Java quasi gar
    > nicht.
    Java verhindert keinen einzigen Buffer overflow. Es werden lediglich die Auswirkungen entschärft, da nicht unkontrolliert Speicherbereiche überschrieben werden. Der Bug ist aber immer noch vorhanden und führt dann wahrscheinlich zu einer IndexOutOfBoundsException. Ein Fortschritt vielleicht, aber keine gute Lösung. Eine gute Sprache sollte darauf abzielen, dass solche Fehler gar nicht erst passieren. Beispiel Rust: hier verhindert der Typchecker use-after-free-Fehler. Nicht dadurch, dass zur Laufzeit geprüft wird, ob dieser Fehler aufgetreten ist, sondern dadurch, dass die Sprache bereits zur Compilezeit Code verbietet, bei dem die Abwesenheit von use-after-free-Fehlern nicht bewiesen werden kann. Diese Art von Fehlervermeidung ist die Zukunft.

  7. Re: Es ist *auch* eine Frage der Programmiersprache

    Autor: GodsBoss 13.06.19 - 19:52

    > > Und hat damit Recht, denn es gibt eine ganze
    > > Klasse von Fehlern, nämlich die Buffer Overflows, die der Entwickler in
    > > Sprachen wie C sehr leicht einbauen kann und in Sprachen wir Java quasi
    > gar
    > > nicht.
    > Java verhindert keinen einzigen Buffer overflow. Es werden lediglich die
    > Auswirkungen entschärft, da nicht unkontrolliert Speicherbereiche
    > überschrieben werden. Der Bug ist aber immer noch vorhanden und führt dann
    > wahrscheinlich zu einer IndexOutOfBoundsException.

    Das unkontrollierte Überschreiben von Speicherbereichen ist der Buffer Overflow. Ein Fehler ist weiterhin im Programm, wie du richtig beschreibst, er ist nur eben nicht mehr sicherheitskritisch.

    > Ein Fortschritt
    > vielleicht, aber keine gute Lösung. Eine gute Sprache sollte darauf
    > abzielen, dass solche Fehler gar nicht erst passieren. Beispiel Rust: hier
    > verhindert der Typchecker use-after-free-Fehler. Nicht dadurch, dass zur
    > Laufzeit geprüft wird, ob dieser Fehler aufgetreten ist, sondern dadurch,
    > dass die Sprache bereits zur Compilezeit Code verbietet, bei dem die
    > Abwesenheit von use-after-free-Fehlern nicht bewiesen werden kann. Diese
    > Art von Fehlervermeidung ist die Zukunft.

    Hier gebe ich dir gerne Recht, Fehler zur Compile- statt Laufzeit zu finden ist natürlich immer besser. Mir ging es in meinem Beitrag aber um den Sicherheitsaspekt.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  8. Re: Es ist keine Frage der Programmiersprache

    Autor: nille02 18.06.19 - 17:58

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Ohne Segnung des Entwicklungsrechners mit dem Blut einer Jungfrau und
    > rituellem Nackttanz bei Mondlicht vor jedem 7 Compilevorgang ist das
    > trotzdem als hochgradig nachlässiges Verhalten zu betrachten.

    Dann solltest du aber kein HolyC nutzen. Nicht das noch jemand die Apokalypse auslöst ;)

  9. Re: Es ist keine Frage der Programmiersprache

    Autor: demon driver 24.06.19 - 21:08

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > > entwickeln, aber es HILFT.
    > Problem ist, dass sich zu sehr auf diese "Hilfe" verlassen wird. Stichwort:
    > Trügerische Sicherheit.
    > Was letztenendes dazu führt, dass Tests vernachlässigt werden.

    Das ist erst mal nur eine unbelegte Behauptung.

  10. Re: Es ist keine Frage der Programmiersprache

    Autor: demon driver 25.06.19 - 13:19

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > > Aber Abstraktion spart Zeit
    > > und damit Geld und macht es einfacher [...]
    >
    > liefert das ergebnis dem verwendetem kompiler auf gedeih und verderb aus,
    > unabhängiger ist anders geschrieben.

    Von "unabgängiger" kann sich niemand was kaufen, und konsequent dürfte man dann nur noch Assemblerprogramme schreiben.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Information und Technik Nordrhein-Westfalen (IT.NRW), Düsseldorf
  2. BWI GmbH, München, Rheinbach
  3. PLAKATUNION Außenwerbe-Marketing GmbH & Co.KG, Hagen
  4. Universität Passau, Passau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 114,99€ (Release am 5. Dezember)
  2. 349,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Indiegames-Rundschau: Von Bananen und Astronauten
Indiegames-Rundschau
Von Bananen und Astronauten

In Outer Wilds erlebt ein Astronaut in Murmeltier-Manier das immer gleiche Abenteuer, in My Friend Pedro tötet ein maskierter Auftragskiller im Auftrag einer Banane, dazu gibt es Horror von Lovecraft: Golem.de stellt die Indiegames-Highlights des Sommers vor.
Von Rainer Sigl

  1. Indiegames-Rundschau Verloren im Sonnensystem und im Mittelalter
  2. Indiegames-Rundschau Drogen, Schwerter, Roboter-Ritter
  3. Indiegames-Rundschau Zwischen Fließband und Wanderlust

Ricoh GR III im Test: Kompaktkamera mit Riesensensor, aber ohne Zoom
Ricoh GR III im Test
Kompaktkamera mit Riesensensor, aber ohne Zoom

Kann das gutgehen? Ricoh hat mit der GR III eine Kompaktkamera im Sortiment, die mit einem APS-C-Sensor ausgerüstet ist, rund 900 Euro kostet und keinen Zoom bietet. Wir haben die Kamera ausprobiert.
Ein Test von Andreas Donath

  1. Theta Z1 Ricoh stellt 360-Grad-Panoramakamera mit Profifunktionen vor
  2. Ricoh GR III Eine halbe Sekunde Belichtungszeit ohne Stativ

In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
In eigener Sache
Neue Workshops zu agilem Arbeiten und Selbstmanagement

Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

  1. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung
  2. In eigener Sache Zweiter Termin für Kubernetes-Seminar
  3. Leserumfrage Wie können wir dich unterstützen?

  1. Equiano: Googles Seekabel erschließt abgelegene Südatlantikinsel
    Equiano
    Googles Seekabel erschließt abgelegene Südatlantikinsel

    Das Equiano-Seekabel von Google wird einen Abzweig an die Insel St. Helena machen. Doch die Kapazität übersteigt den Eigenbedarf bei weitem, weshalb die Saints zahlende Mitbenutzer suchen: Satellitenbetreiber.

  2. Gipfeltreffen: US-Konzerne wollen schnelle Antworten zu Huawei-Lizenzen
    Gipfeltreffen
    US-Konzerne wollen schnelle Antworten zu Huawei-Lizenzen

    Die Chefs von Cisco Systems, Intel, Broadcom, Qualcomm, Micron Technology, Western Digital und Google wollen endlich Klarheit zu Huawei. Trump hat am Montag eine schnelle Bearbeitung von Anträgen auf Lieferungen an Huawei zugesagt.

  3. Automated Valet Parking: Daimler und Bosch dürfen autonom parken
    Automated Valet Parking
    Daimler und Bosch dürfen autonom parken

    In Stuttgart können Besucher ohne Begleitung das automatisierte Parken eines Mercedes ausprobieren: Daimler und Bosch haben die Freigabe für das Automated Valet Parking erhalten.


  1. 19:25

  2. 17:38

  3. 17:16

  4. 16:30

  5. 16:12

  6. 15:00

  7. 15:00

  8. 14:30