[RalphS]

Eh, klar hat jede Sprache ihre Eigenheiten. Aber, kennt man eine, kennt man trotzdem (mehr oder weniger) alle.

Ich bleib aber dabei: von der GRUNDLAGE her sind P/S eher nebensächlich. Ich stimme zu, daß ein gewisses Verständnis beim Lesen hilft, denke allerdings auch, daß es nicht notwendig ist (wenn man nicht grad absolut auf dem Schlauch steht, aber ich glaub dann sollte man sich wirklich erstmal mit banalem Scripting versuchen und das auf nem lokalen Testbett probieren, um erstmal den AHA-Effekt (Ich hab dem gesagt er soll "Hallo Welt" ausspucken und der macht das wirklich ) zu kriegen.

[XDestroy]

Bin halt anderer Meinung. In der Uni haben wir damals zuerst C gemacht, weil ein Haufen Zeugs in den Büchern mit C-Beispielen erklärt wird. Bleibe dabei, C und die wichtigsten Libs anschauen. Dann versteht sich der Unterbau leichter.

Gruß
XD

[RalphS]

Mh, und wir hatten überhaupt kein C (leider). Dafür irgendwelche 'toten' Sprachen: Modula. Ada. Sowas Aber, man konnte zumindest alles damit machen, und vielleicht wars auch gar nicht SOOO schlecht: wir mußten das ja dann alles später auf "richtige" PS übertragen können.

Für den konkreten Bezug PC<>Programmiersprache... puh. Also ich denk, da ist wirklich Assembler der beste Anfang - wenn man dann die Register hat und ne Idee kriegt, was die wie die und wo die so gut für sind, dann isses auch irgendwann (relativ) trivial zu begreifen, wie sich konkret *die Maschine* programmieren läßt (= Assembler) und dann weitergehend, wie sich höhere Sprachen wie C/C++/etc darauf zurückführen lassen.

Aber, da gibt's sicherlich drei Ansätze mehr als das Computer dafür gibt, und alle werden sicherlich mehr oder weniger zum Ziel führen. Da kommts halt auch darauf an, WAS man denn nun genau wissen will (an dieser Stelle verlassen wir dann aber, IMO, die Grundlagen).

[Kirill]

Späße wie Speicherverwaltung und Referenzübergabe lesen sich wie böhmische Dörfer, sind aber doch extrem wichtige Konzepte. Meiner Erfahrung nach lernt man so was viel besser, wenn man es macht, anstatt nur Theorie.

[RalphS]

Jau, solange man weiß, was man tut.

[Danserg]

@RalphS: Wenn ich dich richtig verstehe, liegt bei dir die Kunst des Programmierens nicht im Verständnis der Programmiersprache (diese sind laut dir alle gleich, nur wiegesagt in einer anderen "Sprache"), sondern in der Anwendung von effizienten Algorithmen? Demnach sollte ein Neuling zunächst eine Sprache lernen (welche ist egal, da leicht in eine andere Sprache transformierbar) und sich dann mit Algorithmen/Lösungsansätze beschäftigen? Gibt es weitere Schritte/Punkte, die einem beim Programmieren weiterhelfen?

[RalphS]

Ganz genau.

Das ist der Unterschied zwischen Programmieren auf der einen und Codieren auf der anderen Seite.


Oberstes Credo: Effizienz. Erfüll das und Du bist schon besser als jeder Coder.

Die genaue Sprache ist Geschmackssache. Interessanter ist da wohl die Art der Sprache - imperativ, prozedural, objektorientiert, andere --- wobei es da natürlich auch wieder Feinheiten gibt (zB ist eine objektorientierte Sprache üblicherweise weniger effizient als die anderen, dafür sind solche Sprachen aber die einfachsten in der Umsetzung).

Von der Herangehensweise ist's letztlich aber immer dasselbe:

- Ich habe ein Problem.
- Wie kriege ich das so effizient wie möglich gelöst?

Darüber hinaus würde ich die Finger von Threads lassen. Aber das ist nur meine Meinung, damit steh ich heutzutage (leider) etwas alleine da.

Warum, ist aber schnell gesagt: die Verwendung von Threads macht den Code absolut undurchschaubar, man weiß oft nicht, wie eigentlich grad die (momentane) Situation aussieht, und große Teile des Codes gehen dafür drauf, die Zustände innerhalb der Threads zu erfahren, abzugleichen und dergleichen mehr.

Mit Threads kann man sich dann befassen, wenn man ausreichend tief in der Materie steckt... wenn man dann noch will.

[Danserg]

Kannst du neben "Introduction to Algorithms" noch weitere Lektüre empfehlen?