ubuntuusers.de

Erst als ich den "schwer zu verstehendem Kleinkram" wußte, habe ich auch den Rest verstanden. Ansonsten mogelt man sich IMHO mit Halbwissen durch, was man nur scheinbar verstanden hat. Das merke ich auch bei Kollegen, die nur Delphi können, wenn da manche Sachen nicht funktionieren, wird es halt irgendwie anders gemacht, bis es geht. Kochrezepte und Erfahrungswerte ersetzen echtes Wissen um die Dinge, die da "wirklich" abgehen. Ich habe auch in Delphi-Code Fehler beseitigt, die IMHO mit C++-Wissen gar nicht erst begangen worden wären.

Ein Beispiel: Das Ergebnis des Ausdruckes PChar( string1 + string2 ) wird sich in einer Variable gemerkt und etwas später im Quelltext verwendet. Es steht zwar im Delphi-Handbuch drin, daß das böse ist, die genaue Erklärung bleibt aber aus. Für jemanden, der in C++ fit ist, ist es hingegen völlig offensichtlich, daß und warum das böse ist.

Java finde ich persönlich (neben Delphi) ein abschreckendes Beispiel, da wird sich so krampfhaft vor den Pointern gedrückt, daß ich es ohne Hintergrundwissen nur verwirrend und unlogisch finde. "a = b" legt entweder eine Kopie an, oder eben auch nicht, je nach Typ von a und b. Das ist in C bzw. C++ nicht so, da wird immer eine Kopie getätigt, und wenn a und b Zeiger sind, dann wird logischerweise (und transparent!) nur eine Kopie des Zeigers angelegt.

Und mir ist bisher noch keiner begegnet, der C/C++ konnte und anschließend mit Java oder C# Probleme hatte, in der anderen Richtung aber sehr wohl.

Ich denke also, daß man das nicht verallgemeinern kann. Der eine braucht halt Basiswissen, um "höhere" Sprachen sicher zu bewältigen, für einen anderen mag das Basiswissen abschreckend und unwichtig sein. In Java ist es z.B. nicht einfach wie in C/C++, sich selber in den Fuß zu schießen. Ob das nun gut ist oder nicht, halte ich für diskussionswürdig, denn bei jedem Schuß in den Fuß lernt man IMHO auch dazu.

Ich hab doch gescrieben, dass es Leute gibt, die das Prinzip "Lernen durch Schmerzen" bevorzugen. Und ja, so einige Schüsse in den Fuß wird und muss es immer geben. Ich hab da aber gerne weniger von. Ich habe mir nach einigen Schüssen in den Fuss angewöhnt, erst die Struktur eines Programmes zu schreiben. Die Implementierung an sich finde ich dann immer nervig, da muss man sich ja mehr oder weniger mit der Realität und "echter" Programmierung, Werten und Zeigern und solchem Zeug wirklich befassen. 😉

Und ja, zuviel Fachwissen schadet manchmal, aber nicht immer.

Ok, wenn Du das so siehst. Ich lese aus Deinem Beitrag nichts heraus, was Hochsprachen auszeichnet, sondern nur "Kleinkram" (Zeiger!), den man für das Verständnis von Konzepten und höheren Datenstrukturen nicht benötigt. Insofern sehe ich da keinen Zusammenhang, was Dir (oder besser irgend jemanden) das Verständnis von Zeigern bringt in Bezug auf das Verstehen von oben genannten Dingen.

Wenn in einem Handbuch Dinge nur mangelhaft erklärt werden, helfen einem ggf. manchmal Erfahrungen mit anderen Sprachen - das muss aber nicht so sein! Zudem ist das Einschätzen der Qualität von Dokumentation auch vom Leser und seiner Qualifikation abhängig.

Python setzt mit seiner Referenz-Implementierung bspw. auf C - allerdings habe ich als ehemaliger C-Programmierer da noch nicht einen Vorteil draus ziehen können bzw. müssen 😉

Natürlich lernt niemand exakt gleich und auch die Interessen und Vorbildungen sind andere; dennoch erlaube ich mir mal zu verallgemeinern, dass Verständnis eher vom großen Zusammenhang zum Detail hin geht, als andersherum. Und deshalb hat ein hohes Abstraktionsniveau imho Vorteile, dieses Gesamtbild darzustellen. Ich würde einem Programmieranfänger daher immer zu einer möglichst hoch abstrahierenden Sprache raten, wie z.B. JavaScript o.ä. selbst wenn er danach Hardware nah programmieren möchte. In der Schule fängt man ja auch nicht beim Atom an 😉

Lysander schrieb:

Insofern sehe ich da keinen Zusammenhang, was Dir (oder besser irgend jemanden) das Verständnis von Zeigern bringt in Bezug auf das Verstehen von oben genannten Dingen.

Da gebe ich dir zwar prinzipiell recht, aber in der Praxis sehe ich das schon differenzierter. Nehmen wir z.B. mal das Buch "The Java Tutorial" von Sun, da wird lediglich in zwei Absätzen erklärt, daß es einen Unterschied zwischen "Primitive Data Type" und "Reference Data Type" gibt. Richtig erklärt wird das IMHO nicht, nur ein Teil der Auswirkungen. Kommt es aber zu weiteren Auswirkungen (wie z.B. bei "objekt1 = objekt2" und anschließendem Schreibzugriff auf "objekt1"), die in dem gesamten Buch nicht vorkommen(!), steht man staunend da. (Andere Bücher haben da recht abenteuerliche Abschnitte zu dem Thema.)

Wenn man jedoch Zeiger kennt, und weiß, daß "Reference Data Type" nichts anderes ist, als ein Zeiger, der vom Compiler bei Bedarf automatisch dereferenziert wird, beginnt man sich IMHO vom Halb-Schwebezustand zu lösen und steht stattdessen mit beiden Beinen fest auf dem Boden. (Vielleicht gibt es ja auch ein Java-Buch, was das richtig gut erklärt, und es ist mir noch nicht begegnet. In C/C++ können sich die Bücher aber gar nicht davor drücken, dank der besonderen Notation der Zeiger/Referenzen mit * bzw. &. BTW: Das Kapitel(!) "Pointers" halte ich im K&R für äußerst gelungen.)

Natürlich lernt niemand exakt gleich und auch die Interessen und Vorbildungen sind andere; dennoch erlaube ich mir mal zu verallgemeinern, dass Verständnis eher vom großen Zusammenhang zum Detail hin geht, als andersherum.

Bei Mathematik wird im Schulunterricht beim Detail angefangen. Java ohne C(++)-Kenntnisse ist für mich ein wenig wie "Mathematik für BWLer". Da wird das Thema "Ableitungen" durchgenommen, und die Schüler müssen x verschiedene Muster anzuwenden lernen (mit x = ca. 20, wenn ich mich richtig erinnere). Damit können sie dann zwar erfolgreich ableiten, haben es aber nicht richtig verstanden. Wenn man dann einem BWLer erklärt, was "Ableitung" eigentlich ist, und daß es nur drei Regeln gibt, dann gibt es zwei Möglichkeiten: Entweder sie haben anschließend keinerlei Probleme mehr mit dem Thema (und sind froh, von den x auswendig zu lernenden Mustern abgekommen zu sein), oder sie verstehen erst recht Bahnhof.

Und deshalb hat ein hohes Abstraktionsniveau imho Vorteile, dieses Gesamtbild darzustellen.

Ja, aber in der Praxis kommt man um den Kleinkram IMHO nicht herum, und man muß sich mit konkreten Schnittstellen, Bibliotheken, DLLs oder was auch immer herumärgern.

In der Schule fängt man ja auch nicht beim Atom an 😉

Gutes Beispiel. Chemie würde ich nicht allzulange ohne Wissen über Atomphysik studieren wollen 😉

Und was das Anfangen mit JavaScript angeht, wenn man später Kernelmodule programmieren will: Ich habe in meinem Leben schon zu viel grausamen C-Code von Leuten, die von Java/Delphi kommen, debuggen müssen. Wenn man also vorhat, auch mal in C zu programmieren, kann ich nur dazu raten, sich (wenn überhaupt) nur so kurz wie möglich vor dem Lernen von C zu drücken, sprich: so schnell wie möglich weg mit den Stützrädern! 😉

Ok, wenn Du das so siehst. Ich lese aus Deinem Beitrag nichts heraus, was Hochsprachen auszeichnet, sondern nur "Kleinkram" (Zeiger!), den man für das Verständnis von Konzepten und höheren Datenstrukturen nicht benötigt. Insofern sehe ich da keinen Zusammenhang, was Dir (oder besser irgend jemanden) das Verständnis von Zeigern bringt in Bezug auf das Verstehen von oben genannten Dingen.

Da gebe ich dir zwar prinzipiell recht, aber in der Praxis sehe ich das schon differenzierter.

Hmm, also ich gebe da Lysander nichtmal ansatzweise recht.

Wie Lysander ja selber schon sagte sind Referenzen und Zeiger Technisch so ziemlich das gleiche. Hat man das Konzept in C verstanden, hat man es auch in jeder anderen Sprache verstanden. Ich hatte auch zuerst C gelernt und als ich mit Perl anfing musste ich zum Thema Referenzen absolut gar nix mehr Lernen. Ich wuste sofort wofür man es benötigt und was es macht.

Und das Wissen benötigst du auch woanders. Gerade bei Sprachen die auch soetwas wie "Call By Reference" machen was soweit ich weiß bei Python durchgängig so ist bringt es einen enormen Vorteil wenn man weiß was das überhaupt genau bedeutet.

Und das es kleinkram sein sollte soll ja wohl ein Witz sein?

Wird nicht bei komplexen Datenstrukturen benötigt? Wie bildest du dann Zirkuläre Strukturen ab? Eine Liste von Personen die sich gegenseitig Referenzieren, Zum Beispiel "Papa/Mama" und "Kind" beziehung? Bei der übergabe an Funktionen ist es wichtig eben Call By Reference, damit man weiß das hier nicht mit einer Kopie gearbeitet wird sondern mit dem Original. Auch wenn die Sprache eine dereferenzierung implizit macht muss man verstehen was das Konzeot dahinter ist.

Dann kommen Themen wie Zeiger auf Funktionen. Also das ganze Thema rund um Callbacks was man damit machen kann und wofür es wichtig ist.

Also das Thema Zeiger sehe ich als einer der wichtigsten Konzepte überhaupt. Hat man dies nicht verstanden hat man erst recht keine Hochsprache verstanden. Da man diese Konzepte hier genauso ausführlich nutzt, wahrscheinlich sogar intensiver als in anderen Sprachen.

Hello World schrieb:

xinuzle schrieb:

Ich will irgendwie nun mal einen höhere Programmiersprache können, bzw. sie verstehen..

C ist aber keine höhere Programmiersprache, sondern eine Low-Level-Sprache (und nicht einmal eine besonders gute). Daher solltest Du Dir genau überlegen, ob es jetzt wirklich C sein soll. Alternativen gibt es viele, z. B. Python, Ocaml, C# und weitere.

C=sowas von Hochsprache

Der Rest den Du geschrieben hast ist Meinung.

Grüße

GT

Sid Burn schrieb:

Hmm, also ich gebe da Lysander nichtmal ansatzweise recht.

Wer hätte das gedacht? 😎

Ok, ich bin da gedanklich zu stark in Richtung Zeigerarithmetik abgedriftet. Nimmt man Zeiger als Synonym für Verweis und call by reference (in Python übrigens nicht unbedingt) und will damit generell das Konzept erklären, ist das mit Sicherheit wichtig und relevant. Allerdings bleibe ich dabei, dass man für das Verständnis davon keine technischen Zeiger auf C-Ebene benötigt!

Vielleicht könnt ihr euch darauf einigen, dass man sowohl Top-Down als auch Bottom-Up lernen kann? Wichtig ist nur, dass man sich weiterentwickelt.

Natürlich kann man erst Atome lernen, dann Moleküle, dann Organische Chemie, dann z.B. Biochemie, Anatomie, Psychologie, Philosophie. Man kann auch von der anderen Seite kommen.

GrandTheft schrieb:

C=sowas von Hochsprache

Eine Sprache, die manuelles Speichermanagement erfordert, ist nach heutigen Maßstäben keine Hochsprache.

Der Rest den Du geschrieben hast ist Meinung.

Dass es dutzende Alternativen zu C gibt, ist nicht einfach meine Meinung, sondern ein Fakt.

vinho schrieb:

Vielleicht könnt ihr euch darauf einigen, dass man sowohl Top-Down als auch Bottom-Up lernen kann? Wichtig ist nur, dass man sich weiterentwickelt. Natürlich kann man erst Atome lernen, dann Moleküle, dann Organische Chemie, dann z.B. Biochemie, Anatomie, Psychologie, Philosophie. Man kann auch von der anderen Seite kommen.

Darum geht es doch gar nicht. Es geht nicht darum ob Top-Down oder Bottom-Up Lernen. Okay, bei Aussagen man sollte erst Python anstatt C Lernen zielt die aussage schon auf die Lernrichtung. Ich halte so eine Aussage aber für dämlich da jeder anders lernt. Zuletzt ging es aber generell darum ob man *überhaupt* dadrunter liegendes Wissen haben muss/sollte, und nicht in welcher Reihenfolge man es lernt.

Und ich sehe keinerlei Nachteile mehr Wissen zu haben und die unteren Schichten zu kennen. Eigentlich kann man Sachen nur besser verstehen lernen. Manch einer sagt halt das es besser wäre jeder würde alle Schichten kennen und nicht nur die höheren. Und das manche die nur die höheren Schichten kennen das Konzept noch nicht begriffen haben. Ursache dafür dann wegen fehlender erklärung, weil die Sprache diese Konzepte "versteckt" vor dem Nutzer oder welchen Begründungen auch immer.

Was nun "richtig" oder "falsch" ist kann ich nicht bewerten. Und das mag wohl bei jedem anderen Menschen anders sein, wodurch es auch kein "richtig" oder "falsch" gibt. Ich kann nur für mich Sprechen und sagen das das Wissen rund um C mir geholfen hatte Perl zu lernen. Bzw. ich vieles gar nicht mehr Lernen brauchte da ich es schon kannte. Ob das umgekehrt genauso gewesen wäre kann ich nicht sagen. Ich kann mein Gehirn nicht mehr löschen und es ausprobieren.

Wer hätte das gedacht?

Nun, anscheind hatte ich ja recht. Wiedersprochen hast du mir ja nicht, eher bestätigt. 😉

Allerdings bleibe ich dabei, dass man für das Verständnis davon keine technischen Zeiger auf C-Ebene benötigt!

Siehe oben. Das mag wohl Abhängig von der Person sein. Relativ oft gibt es aber Leute die Meinen Sie hätten es verstanden und Lernen dann später erneuert und verstehen Sachen dann besser.

Als ich mit C++ und OOP angefangen habe dachte ich auch OOP verstanden zu haben. Tolle "Schablonen" von denen eine "Instanz" erstellt wird. Zwar war das alles irgendwie etwas nebelig, zumindest für mich aber vom Prinzip her dachte ich es verstanden zu haben. Als ich dann später Perl gelernt habe und mich dort mit OOP beschäftigt habe und etlichen Bücher dazu gelesen hatte ist mir das OOP Konzept sehr viel deutlicher geworden und würde sagen erst da habe ich es verstanden.

Genau zu diesem Thema gab es nämlich auch erst Letztens eine Diskusion um C und GTK+ und ob es OOP wäre. Hello World Demonstrierte ja warum C weniger OOP ist als in C++ mit gtkmm, und jemand anderes sagte ebenfalls das man OOP erst recht genauer versteht wenn man C nutzt. Dem kann ich mir auch anschließen.

OOP kann ich auch komplett durch ein Closure und Funktionen nachbilden. Oder auch durch eine Datenstrukturen und Funktionen. Oder besser gesagt. Zeiger auf Datenstrukturen und das herumreichen von Zeigern auf diese. Und wenn Funktionen diese bearbeiten.

Ist alles wie gesagt eine Wissens Sache. Gibt genug leute die Java, C# oder sonst etwas gelernt haben und meinen in C wäre keine OOP Möglich. Das sind auch in der Regel immer die größten Schreihälse die genau sagen können was richtig oder falsch ist. Oder was andere Sprachen können die sie nichtmal selber gelernt haben.

Sid Burn schrieb:

Genau zu diesem Thema gab es nämlich auch erst Letztens eine Diskusion um C und GTK+ und ob es OOP wäre. Hello World Demonstrierte ja warum C weniger OOP ist als in C++ mit gtkmm,

Ich habe nichts derartiges gesagt. Im Gegenteil, ich habe explizit betont, dass es vom Grad der Objektorientierung her keinen Unterschied zwischen gtk und gtkmm gibt.

Hello World schrieb:

Sid Burn schrieb:

Genau zu diesem Thema gab es nämlich auch erst Letztens eine Diskusion um C und GTK+ und ob es OOP wäre. Hello World Demonstrierte ja warum C weniger OOP ist als in C++ mit gtkmm,

Ich habe nichts derartiges gesagt. Im Gegenteil, ich habe explizit betont, dass es vom Grad der Objektorientierung her keinen Unterschied zwischen gtk und gtkmm gibt.

Ups, da fehlt ein "nicht" im Satz.

"Hello World Demonstrierte ja warum C nicht weniger OOP ist als C++ mit gtkmm"

Also wollte eigentlisch schon genau das Gegenteil sagen, ich denke das ist aber auch hoffentlich beim rest genauso rüber gekommen. Korregieren und Editieren kann ich aber leider nicht mehr. Ubuntuusers.de verbietet es sachen zu korregieren.

Auch wenn das hier der Ausgangspunkt für die Meta-Diskussion war, würde ich doch gerne noch einmal festhalten, dass der OP mit seiner eigenen Lernstrategie augenscheinlich überfordert ist ☺

Bei anderen Menschen mag das anders aussehen, hier jedoch würde ich ganz klar von C abraten und zu einer höher abstrahierenden Sprache raten.

Sid Burn schrieb:

Ist alles wie gesagt eine Wissens Sache. Gibt genug leute die Java, C# oder sonst etwas gelernt haben und meinen in C wäre keine OOP Möglich. Das sind auch in der Regel immer die größten Schreihälse die genau sagen können was richtig oder falsch ist. Oder was andere Sprachen können die sie nichtmal selber gelernt haben.

Na, solche Leute nehmen wir hier aber eh nicht ernst ☺ Zudem gibt es das durchaus auch andersherum, speziell bei der korrekten Verwendung von eingebauten Datentypen habe ich da schon viel abschreckendes erlebt - Arrays sind in Java eben nur selten eine gute Wahl 😉