Kann die Kenntnis von C dem Code, den Sie in höheren Sprachen schreiben, tatsächlich schaden?

Lesezeit: 10 Minuten

Die Frage scheint erledigt, sogar zu Tode geprügelt. Kluge Leute haben gesagt intelligente Dinge zum Thema. Um ein wirklich guter Programmierer zu werden, muss man C kennen.

Oder tust du?

Ich wurde diese Woche zweimal erleuchtet. Der erste machte mir klar, dass meine Annahmen nicht weiter gehen als mein Wissen dahinter, und angesichts der Komplexität der Software, die auf meinem Computer läuft, ist das fast nicht existent. Aber was es wirklich nach Hause trieb, war dieser Slashdot-Kommentar:

Das Endergebnis ist, dass ich die vielen naiven Wege bemerke, auf denen traditionelle C-“Bare-Metal”-Programmierer davon ausgehen, dass höhere Programmiersprachen implementiert werden. Sie treffen schlechte “Optimierungs”-Entscheidungen in Projekten, die sie beeinflussen, weil sie keine Ahnung haben, wie ein Compiler funktioniert oder wie unterschiedlich ein gutes Laufzeitsystem von dem naiven Makro-Assembler-Modell sein kann, das sie verstehen.

Dann traf es mich: C ist gerecht noch eine Abstraktion, wie alle anderen. Eben die CPU selbst ist nur eine Abstraktion! Ich habe es nur nie brechen sehen, weil ich nicht die Werkzeuge habe, um es zu messen.

Ich bin verwirrt. Wurde mein Geist unwiederbringlich verstümmelt, wie Dijkstra über BASIC gesagt hat? Lebe ich in einem ständigen Zustand vorzeitiger Optimierung? Gibt es Hoffnung für mich, jetzt wo ich erkannt habe, dass ich von nichts weiß? Gibt es überhaupt etwas zu wissen? Und warum ist es so faszinierend, dass alles, was ich in den letzten fünf Jahren geschrieben habe, grundlegend falsch gewesen sein könnte?

Um es zusammenzufassen: Ist es sinnvoll, mehr zu wissen, als die API-Dokumentation mir sagt?

EDIT: CW gemacht. Das bedeutet natürlich auch, dass Sie jetzt besser als wir Beispiele für die Interpreter-/Laufzeitoptimierung posten müssen 🙂

  • Nein kann es nicht. Du bist in Ordnung. Mehr zu wissen tut gut. Hör auf dir Sorgen zu machen. 🙂 Die C-Programmierer in diesem Kommentar sind wahrscheinlich diejenigen, die sich nie darum gekümmert haben richtig mehr über die Hochsprachen erfahren, in die sie migriert sind. Wenn Sie die Sprache wechseln, bemühen Sie sich, in der API zu lernen, wie es funktioniert und unter der Decke (wenn möglich). Dann hast du nie Ärger.

    – FrustriertMitFormularDesigner

    21. Mai 2010 um 13:45 Uhr


  • “Die einzig wahre Weisheit liegt darin, zu wissen, dass man nichts weiß.” -Sokrates

    – RMorrisey

    21. Mai 2010 um 13:59 Uhr


  • Bitte seien Sie vorsichtig, wenn Sie die Arbeit und das Wissen anderer Leute so schnell abtun. Das ganze Problem ist, dass wir es nicht wissen können allesund wie man damit umgeht.

    – György Andrasek

    21. Mai 2010 um 14:01 Uhr


  • Die großen Sprach-Shootout-Benchmarks. Wie viele von diesen wunderbaren “gute Laufzeitsysteme” [sic] dass dieser Troll erwähnt, C in der Praxis regelmäßig zu schlagen? Wie viele nähern sich C um einen Faktor von beispielsweise 25 % an? Wie viele waren das? Null. Tolle Sprachschießerei. Benchmark: alle, Sprachen: alle. Iss diesen Slashdot-Troll: shootout.alioth.debian.org/u32q/… Aber denken Sie daran: Sie sind “kompliziertes High-Level-Zeug, das Low-Level-C-Programmierer nicht verstehen können”. Sie können es vielleicht nicht verstehen, aber sie können sich sicher die Scheiße aus dem Hintern prügeln 😉

    – SyntaxT3rr0r

    21. Mai 2010 um 14:13 Uhr


  • Einige von uns kümmern sich mehr um den Verlust von Daten als um ein paar Millisekunden an Leistung, kurz bevor wir alle unsere Daten verlieren.

    – Warren P

    21. Mai 2010 um 16:00 Uhr

Weder die Kenntnis von C noch die Kenntnis der Implementierungsdetails auf niedrigerer Ebene schaden Ihnen – an sich. Was Sie verletzen kann und wird, ist, wenn Sie konsequent in Bezug auf die Details auf niedriger Ebene denken und arbeiten, selbst wenn dies unangemessen ist.

Das alte Sprichwort lautete: „Echte Programmierer können FORTRAN hineinschreiben irgendein Sprache.” Wenn Sie dasselbe mit C tun, ist es keine Verbesserung. Wenn Sie Lisp schreiben, schreiben Sie Lisp. Wenn Sie Python schreiben, schreiben Sie Python. Was für C angemessen und vernünftig ist, ist nicht für beide (oder einer von vielen anderen).

Ein guter Programmierer muss in der Lage sein, auf vielen verschiedenen Abstraktionsebenen zu denken und (was noch wichtiger ist) die Abstraktionsebene zu erkennen und anzuwenden, die für die jeweilige Aufgabe geeignet ist.

Die Kenntnis der Abstraktionsebene von C schadet nicht. Unkenntnis von Alternativen kann (und wird).

  • Ich denke, das ist die Falle der Überoptimierung. Machen Sie sich keine Sorgen darüber, wie effizient jede Methode ist. Legen Sie immer Wert darauf, die prägnanteste, intuitivste und lesbarste Implementierung als ersten Schnitt zu schreiben. Messen und finden Sie Leistungsengpässe. Kommen Sie zurück und verstümmeln Sie diesen Engpasscode, bis Sie Ergebnisse erhalten. aber lassen Sie den Rest Ihres Codes intakt.

    – RMorrisey

    21. Mai 2010 um 14:09 Uhr


  • Tatsächlich sollte der erste Instinkt, wenn Sie einen Engpass finden, nicht darin bestehen, ihn zu zerfleischen, anstatt darüber nachzudenken, wie Sie den High-Level-Algorithmus ändern können, um den Engpass vollständig zu vermeiden. Wenn Sie auf langsamen Code stoßen, denken Sie nicht „wie kann ich ihn schneller machen“, denken Sie „wie kann ich die Ausführung vermeiden“.

    – Ameisen Aasma

    21. Mai 2010 um 14:41 Uhr

  • Echte Programmierer können FORTRAN in jeder Sprache schreiben :-). Nach der gesehenen C-Funktion, die im KR-Argumentstil geschrieben wurde, weil Fortran es so macht void function(variable) { int *variable;...} Ich bin fest davon überzeugt, dass sie das nicht tun sollten

    – Irgendein Korn

    21. Mai 2010 um 16:23 Uhr

  • @aaa, in K&R gehen Argumenterklärungen Vor die öffnende Klammer. Man könnte genauso gut sagen, dass Funktionsdefinitionen im ANSI-C-Stil alte CS-Absolventen zu schreiben versuchen Paskal. Nur dass letzteres wohl richtig ist. :p

    Benutzer14554

    27. Mai 2010 um 23:25 Uhr


Wissen schadet nicht. je. Diejenigen, die schlechten Code in einer höheren Sprache geschrieben haben, sind, weil sie die höhere Sprache nicht richtig beherrschen, schlechte Entwickler.

  • Ich würde es so sagen: “Was Sie NICHT WISSEN, kann Sie verletzen”. Was Sie wissen, kann Ihnen nur helfen.

    – Warren P

    21. Mai 2010 um 15:54 Uhr

  • Offensichtlich haben Sie HG Wells Time Machine nicht gelesen. “Er dachte nur freudlos an den Fortschritt der Menschheit und sah in dem wachsenden Haufen der Zivilisation nur einen törichten Haufen, der unweigerlich auf seine Schöpfer zurückfallen und sie am Ende zerstören musste.” Mehr Wissen ist immer gut – bis es nicht mehr so ​​ist.

    – Eloff

    21. Mai 2010 um 18:39 Uhr

  • @Eloff, Wissen ist nicht schlecht, dumme Leute mit Wissen sind gefährlich! 🙂

    – Arkaitz Jimenez

    21. Mai 2010 um 19:46 Uhr

  • Und kluge Leute mit Wissen sind noch gefährlicher. Wissen ist nicht von Natur aus gut oder schlecht, aber selbst das grundlegendste Wissen (wie Feuer) kann bei Missbrauch brennen. Fortgeschritteneres Wissen neigt dazu, schlechter zu brennen – wie das Wissen über das Spalten und Verschmelzen von Atomen. Um auf das eigentliche Thema zurückzukommen, C-Kenntnisse sind weder gut noch schlecht, können aber definitiv von dummen und klugen Leuten gleichermaßen missbraucht werden.

    – Eloff

    21. Mai 2010 um 20:39 Uhr

Für einen schlechten Entwickler kann jede Art von Wissen gefährlich sein.

Für einen guten Entwickler ist jede Art von Wissen von Vorteil.

Die Verwendung von Sprachen – natürlich (gesprochen) oder künstlich (Programmierung) – erfordert, dass sich der Geist auf eine bestimmte Weise anpasst. Jede Sprache hat ihre eigene Grammatik, ihr eigenes Vokabular (APIs) usw. Wenn Sie hauptsächlich Java-Programmierer sind und zu Ruby wechseln, werden Sie zumindest den Denkmustern eines Java-Programmierers folgen, wenn nicht sogar schreiben, was im Grunde Java-Code ist Rubin. Es erfordert ein wenig Mühe und Übung, bis Sie sich in der neuen Umgebung (Ruby-Grammatik, Ruby-APIs) wohlfühlen und mit dem Schreiben beginnen Rubin Code.

Der Prozess ist also völlig normal und jede nachteilige Wirkung früherer Muster ist sehr kurzlebig. Und was noch wichtiger ist: Jede Sprache, die Sie lernen, erweitert Ihren Horizont und erleichtert das Erlernen der nächsten. Geniesse die Reise. :]

Beim Programmieren geht es nicht um Programmiersprachen. Es geht darum, Probleme zu lösen. Das Werkzeug Zur Lösung der Probleme werden zufälligerweise Programmiersprachen verwendet. Sie schreiben keinen Code, um Code zu schreiben, Sie schreiben Code, um ihn auszuführen und das Problem zu lösen.

Je besser Sie Ihre Werkzeuge kennen, desto besser und schneller können Sie die Probleme lösen. Aber während Sie ernsthafte Probleme haben werden, wenn Sie versuchen, eine Schraube mit einem Hammer physisch in Holz zu treiben, hat Software eine nette Eigenschaft: Es gibt absurd viele verschiedene Lösungen für ein bestimmtes Problem.

Es ist also durchaus möglich, einen Hammer zu schreiben, der in einem solchen Winkel auf eine Schraube schlägt, dass die Schraube dem Holz sagt, dass er ein Loch in sich selbst bohren soll, damit die Schraube hineinpasst. Dann kann man ihn hinter einem Knopf verstecken, der Benutzer tut es nicht. Sie müssen nicht einmal wissen, was ein Hammer eigentlich ist.

Obwohl es nicht die effizienteste Lösung ist, ist es dennoch eine gültige und funktionierende Lösung. Wenn Sie mit dem von Ihnen verwendeten Tool besser werden, werden Sie endlich entdecken, wie Sie einen Schraubendreher schreiben können, wenn die API keinen bereitstellt.

Je mehr Tools Sie kennen und je mehr Möglichkeiten Sie kennen, um ein Problem zu lösen, desto mehr Auswahlmöglichkeiten haben Sie und desto besser werden Ihre Entscheidungen über die zu verwendende Lösung sein. Wählen Sie das richtige Werkzeug für den Job. Aber wie könnten Sie, wenn Sie die Werkzeuge und die möglichen Lösungen nicht kennen?

Um die Kommentare anderer zu erweitern … Obwohl ich nicht sicher bin, ob ich an die http://en.wikipedia.org/wiki/Whorfian_hypothesis”>Whorfian Hypothesis glaube, wenn es um natürliche Sprachen geht, ist sie ziemlich eindeutig wahr, wenn es darum geht zum Programmieren. Die Sprachen, die Sie beherrschen, wirken sich darauf aus, wie Sie ein Problem lösen. Zwei Beispiele:

1) Von einem Professor, den ich vor vielen, vielen Jahren hatte: Er versuchte herauszufinden, ob es Duplikate in seiner Reihe von Saiten gab. Das war in den 70er Jahren, also schrieb er das in FORTRAN. Seine Brute-Force-n^2-Implementierung dauerte viel zu lange. Also sprach er mit einem Freund. Sein Freund kannte PL1 (ich glaube, es war, vielleicht war es APL), das einen Sort-Operator hat. In dieser Sprache lernt man also, Dinge zu sortieren, und wie nützlich das sein kann, weil es einfach ist. Der Freund hat sich zuerst die offensichtliche Sortierung ausgedacht und sich dann den Algorithmus für benachbarte Elemente angesehen. Viel schneller, und meinem FORTRAN-Schreibprofessor wäre es nicht in den Sinn gekommen, obwohl es in FORTRAN perfekt umsetzbar war.

2) Als ich in der Graduiertenschule war, hatte ich einen Physikstudenten als Mitbewohner. Er ging zum MIT und belegte nur einen Programmierkurs, der natürlich bei Scheme war. Eines Tages kam ich in sein Büro und er sagte: “Hey, Brian, kannst du dir diesen Code ansehen und mir sagen, ob er funktionieren sollte?” Es war eine Sortierroutine. Ich warf einen Blick darauf und sagte, es könne unmöglich funktionieren, weil es eindeutig Bubblesort sei, und doch habe es nur eine Schleife (und nein, es war nicht die eine verrückte Schleife, mit der man Bubblesort schreiben kann, wenn man krank ist und verdrehte). Also, das habe ich gesagt. Er antwortete: “Oh, aber es hat unten einen rekursiven Aufruf!” Es wäre mir nie in den Sinn gekommen, einen rekursiven Bubblesort zu schreiben. Aber was noch wichtiger ist, es wäre ihm nie in den Sinn gekommen, eine nicht-rekursive Funktion zu schreiben!

Der Punkt ist, dass die Sprachen, die Sie beherrschen, zu einem großen Teil die Art des Codes bestimmen, den Sie schreiben werden. Je mehr Sprachen Sie kennen, desto mehr Tools haben Sie, und mehr Tools sind nie schlecht, solange Sie wissen, wann Sie jede von ihnen verwenden müssen …

Um ein wirklich guter Programmierer zu werden, muss man C kennen.

Ich stimme dem zu.

Aber ich stimme auch zu, dass Sie ein wirklich guter Programmierer sein müssen haben zu wirklich wissen wie man Code in einer anderen Sprache schreibt (nicht wie man C-Code in einer anderen Sprache schreibt).

1388290cookie-checkKann die Kenntnis von C dem Code, den Sie in höheren Sprachen schreiben, tatsächlich schaden?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy