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. DATAGROUP Köln GmbH, Köln
  2. Deloitte, Düsseldorf, Hamburg
  3. Haufe Group, Freiburg
  4. BG-Phoenics GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 4,32€
  2. (-87%) 2,50€
  3. 26,99€
  4. 4,19€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kickstarter: Scheitern in aller Öffentlichkeit
Kickstarter
Scheitern in aller Öffentlichkeit

Kickstarter ermöglicht es kleinen Indie-Teams, die Entwicklung ihres Spiels zu finanzieren. Doch Geld allein ist nicht genug, um alle Probleme der Spieleentwicklung zu lösen. Und was, wenn das Geld ausgeht?
Ein Bericht von Daniel Ziegener

  1. Killerwhale Games Verdacht auf Betrug beim Kickstarter-Erfolgsspiel Raw
  2. The Farm 51 Chernobylite braucht Geld für akkurates Atomkraftwerk
  3. E-Pad Neues Android-Tablet mit E-Paper-Display und Stift

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

  1. Hacker-Attacke: Datenleck bei Freenet-Tochter Vitrado
    Hacker-Attacke
    Datenleck bei Freenet-Tochter Vitrado

    Angreifer haben auf die Daten von rund 67.000 Vitrado-Nutzern zugreifen können. Diese sollten besser ihr Bankkonto im Auge behalten, rät die Freenet-Tochter.

  2. Android: Apps kommen auch ohne Berechtigung an Trackingdaten
    Android
    Apps kommen auch ohne Berechtigung an Trackingdaten

    Das Android-Berechtigungsmodell lässt sich mit Tricks umgehen. Eine Studie fand 1.325 Apps, die auch ohne eine Berechtigung an die entsprechenden Daten gelangen.

  3. 3D-Grafiksuite: Epic spendet 1,2 Millionen US-Dollar an Blender
    3D-Grafiksuite
    Epic spendet 1,2 Millionen US-Dollar an Blender

    Der Spielehersteller Epic Games spendet über drei Jahre insgesamt 1,2 Millionen US-Dollar an die Blender-Foundation. Der Verein zur Unterstützung der freien Grafiksuite verdoppelt damit fast seine Einnahmen.


  1. 16:37

  2. 15:10

  3. 14:45

  4. 14:25

  5. 14:04

  6. 13:09

  7. 12:02

  8. 12:01