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 🙂
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).
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.
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).
13882900cookie-checkKann die Kenntnis von C dem Code, den Sie in höheren Sprachen schreiben, tatsächlich schaden?yes
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