Ich kann nicht programmieren....

elise

ich glaube, man lernt durch die finger UND durch den kopf.

wobei ich denke, dass der/die threadersteller/in nicht "programmieren" lernt, sondern (1. semester informatik) algorithmen und datenstrukturen mit irgendeiner programmiersprache umgesetzt.
da hilft manchmal dann auch malen (listen)
spielen (sortieralgorithmen lassen sich hervorragend mit skatkarten animieren)
planen (algorithmen mal umgangssprachlich formulieren, (oder wegen mir struktogrammähnlich, wers mag) und erst dann in eine sprache überführen
...

lernen ist vielschichtig.

wie gesagt, ich denke, er/sie wird im ersten semester die grundlagen hören.
aber wer weiß, was manche unis da bauen...

TravisG schrieb:

Ich weiß nicht wieso hier jeder darauf kommt, dass man Programmieren nur durch Üben lernt.

weil es so ist. die wenigsten menschen können programmieren, nur weil sie ein paar bücher darüber gelesen haben.

TravisG schrieb:

Beispiel c++:
std::cout<<"Hello World!"<<std::endl;
Bei den ersten Tutorials oder ganz am Anfang beim ersten kompilierten C++ Projekt reicht es, auf Gedankenebene... sagen wir mal 5 zu bleiben und zu verstehen, dass std::cout Zeichen auf der Konsole ausgibt und diese Zeichen per "<<" übergeben werden.
Wenn du dich allerdings näher mit C++ beschäftigen willst und die Sprache verstehen willst, dann musst du zuerst runter auf Gedankenebene 4,3 oder 2...

leider wird wird von diesem 'hinabsteigen' meistens abgeraten, um nicht in bodenlose abgründe zu stürzen. das finde ich doof. ich persönlich bin auch mehr für den blick hinter die kulissen.

Machine schrieb:

tja, hättest du wohl mal zu den vorlesungen gehen sollen, oder dir notizen machen sollen, oder mal zuhören sollen.
kauf dir n buch über die sprache die du lernen willst und lies es!

Unsinn... Das Programmieren, bzw. umsetzung von Aufgaben OO Vorstellung und impelemtation in Algorithmen lern man nicht in den vorlesungen. Dazu komm üben , üben, üben...

Ein Kind kann auch nicht plötzlich laufen, wenn man es dem Kind zeigt wie laufen ausieht. Es muss üben,üben, üben...

BaldWochende schrieb:

Ein Kind kann auch nicht plötzlich laufen, wenn man es dem Kind zeigt wie laufen ausieht. Es muss üben,üben, üben...

Der Vergleich hinkt, bzw stolpert, wie das Kind wenn es noch nicht so gut laufen kann.

Ich vereinfache mein Posting nur noch etwas.

Wissen aneignen -> Wissen verstehen -> "Wissen üben" ->
Wissen aneignen -> Wissen nicht verstehen -> Trotzdem üben ->

TravisG schrieb:

Wissen aneignen -> Wissen nicht verstehen -> Trotzdem üben ->

nene, so muss das aussehen:
aneignen -> nix verstehen -> üben -> verstehen ->

rüdiger

TravisG schrieb:

Ich weiß nicht wieso hier jeder darauf kommt, dass man Programmieren nur durch Üben lernt. Ich denke noch fälscher geht es nicht.

Natürlich lernt man durch Üben und nicht (nur) durch das lesen von Büchern und Tutorials. Beim üben stößt du nämlich auf konkrete Probleme und musst diese lösen. Und hier lernt man oft erst den Sinn, von vielen Dingen, die einem in den Büchern beigebracht werden.

Programmieren ist nun einmal hauptsächlich ein Handwerk und keine Wissenschaft (Die Wissenschaft dazu ist die Informatik). Und einem Tischler würde ich auch empfehlen zu tischlern und nicht Bücher über die Konstruktion eines Hammers zu lesen...

<edit>Mein Beitrag klingt vielleicht ein bisschen zu Theorie feindlich. Natürlich muss man auch Theorie lesen. Aber imho kann man die wirklich nur begreifen, wenn man das gelesene anwendet.</edit>

Du studierst Informatik und bist noch nicht auf die Idee gekommen Zuhause was für dich zu programmieren. Bist du sicher, dass das das richtige Studium für dich ist? Gibts Jobs für Studienabgänger die noch nie was größeres programmiert haben?

Apollon

Klar. Schau dir doch die WInfe an.

Xantus

Natürlich muss man programmieren "üben". Beispielsweise reicht es nicht, zu wissen, dass eine (einfach verkettete) Liste verkettet ist und jedes Element einen Zeiger auf das folgende Element hat, sowie Methoden zum Hinzufügen, Löschen, Einfügen, Suchen bereit stellt. Man sollte sie auch implementieren können. Und wenn man das noch nie gemacht hat, wirds auch schwer, eine Struktur wie

struct ListItem {
    int value;
    struct ListItem *next;
};

zu schreiben, geschweige denn die Funktionen mit korrekter Speicherfreigabe zu implementieren - wenn man nur weiß was es ist, aber nicht wie es in Codeform aussieht (aussehen kann).

http://www.ibash.de/zitat_7616.html

TravisG schrieb:

BaldWochende schrieb:

Ein Kind kann auch nicht plötzlich laufen, wenn man es dem Kind zeigt wie laufen ausieht. Es muss üben,üben, üben...

Der Vergleich hinkt, bzw stolpert, wie das Kind wenn es noch nicht so gut laufen kann.

Ich vereinfache mein Posting nur noch etwas.

Wissen aneignen -> Wissen verstehen -> "Wissen üben" ->
Wissen aneignen -> Wissen nicht verstehen -> Trotzdem üben ->

Dem kann ich so nicht ganz zustimmen, machmal gibt es durchaus Situationen wo man ein Programmstück nicht sofort versteht (ich meine klar jeder könnte Codezeile für Codezeile durchgehen und sagen was dort ausgeführt wird, aber der Sinn dahinter ist ja das Entscheidende), aber wenn man den Code dann einfach einmal abtippt und sich anschließend darüber Gedanken macht und damit beschäftigt, etwas experimentiert und man im Debugger verfolgt was dort genau passiert so hilft das beim Verständnis durchaus.
Und dieser Prozess zählt - für mich - auch zum Üben dazu. Einfach abtippen hat nur einen Auswendig-Lern-Effekt der ist anfangs natürlich auch nicht schlecht damit man mal etwas hinbekommt ohne alle zwei Minuten erstmal die Doku wälzen zu müssen, aber wirkliche Einsicht erhält man nur, wenn man mit dem Code auch etwas spielt und experimentiert.

@Threadersteller, ich rate dir dazu mal die ganzen (einfachen) Datenstrukturen zu Implementieren und ein paar Standardalgorithmen die auf diesen Arbeiten.
Das Designen von Programmen lernt man erst über die Jahre hinweg so etwas kommt nicht von heute auf Morgen. Aber das einfache Runterprogrammieren kann man sich recht schnell aneignen und mit der Zeit wird man immer besser
Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen
Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.

guenni81

Also, nach den Grundlagen lernen geh ich immer den Weg ein Projekt zu realisieren. Das Projekt ist bei mir am Anfang immer klein und der Umfang wächst dann von Projekt zu Projekt. Damit habe ich bis jetzt gute lern Erfahrungen gemacht. Kann aber durchaus sein das mir das ganze einfach leichter fällt, da ich schon zu Turbo Pascal 7 Zeiten angefangen habe zu programmieren.
Aber mal ehrlich, wieso fängst du jetzt so spät in deinem Studium erst an zu programmieren? Normalerweise merkt man doch schon irgendwann das einem das programmieren schwer fällt und setzt sich zuhause hin und "übt".

BorisDieKlinge

Manache glauben sogar, dass sie ne Programmieren klausur schafen, wenn man ihnen den Quellcode der letzten Klausr erkärt!?

Neulich kam einer an mit ner Übungsaufgabe Objekorientierung Polymorphy etc. Da meinte er ich solle ihm nur den Code erklären also was die Klassen machen und wie sie zusammen aggieren, und er können es dann programmieren:)
Die meinsten denken wenn sie einmal den Code erklärt bekommen und ihn auch verstehen, können sie sowas selber Programmieren (naja vll. gibts ja ausnahmen)

Tippgeber schrieb:

Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.

andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.

-fricky- schrieb:

Tippgeber schrieb:

Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.

andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.

Naja darüber kann man wohl streiten

-fricky- schrieb:

Tippgeber schrieb:

Übrigens: die ein Programmierer ist nur so talentiert wie weit seine Debug-Talente reichen...Wer gut im Debuggen ist hat es einfach leichter und das ist das Problem von vielen Anfängern: sie haben einen Fehler, aber können ihn unmöglich finden, da sie keine Ahnung haben was ein Debugger ist und wie man diesen einsetzt.

andererseits macht ein guter programmierer selten fehler, die man mit einem debugger suchen muss.

Wie sucht man dann die fehler von guten programmieren?

milka

Gregor schrieb:

Aber mich würde mal interessieren, was das für eine Prüfung ist, bei der man mehr als Kleinkram programmieren muss. Was muss man da so programmieren? Und wieviel Zeit hast Du noch bis zum letzten Versuch?

Das problem beim prüfung ist- man muss auf einem stückchen papier programmieren-und da kannst du nicht testen ob es läuft und wenn nicht - was falsch sein kann.Jedes mal sind die aufgaben unterschiedlich-mal prekursive funktion schreiben, mal eine programm mit 1000 zeigern vorgegeben ist, und da muss man rausfinden was am ende rauskommt.Ich habe noch ca halbes jahr zeit

meh, das klingt vll. doof, aber ich habe bis jetzt noch nie einen debugger gebraucht und kann mir auch nicht vorstellen den jemals zu brauchen. probleme die mit dem debugger gelöst werden können schienen mir in der vergangenheit und jetzt einfach viel zu trivial als dass ich tatsächlich den debugger angeworfen hätte. klar, wenn man nen 500 zeilen spaghetti-code hat, kann ich mir schon vorstellen dass ein debugger hilft, aber sowas kommt mir beim programmieren egtl nie vor.

ich bemühe mich drum programmabschnitte möglichst gut zu kapseln und klein zu halten, da ist mein gehirn dem debugger ebenbürtig.

wobei... vor 2 jahren als ich angefangen hab mich etwas intensiver mit c++ zu beschäftigen, benutze ich den um rauszufinden in welcher codezeile der code abstürzt. für mehr aber dann auch nicht.

Shade Of Mine

TravisG schrieb:

meh, das klingt vll. doof, aber ich habe bis jetzt noch nie einen debugger gebraucht und kann mir auch nicht vorstellen den jemals zu brauchen. probleme die mit dem debugger gelöst werden können schienen mir in der vergangenheit und jetzt einfach viel zu trivial als dass ich tatsächlich den debugger angeworfen hätte.

Man macht Fehler beim programmieren - das ist einfach so. irgendwo springt der code in den falschen branche, irgendwo hat man einen spezialfall uebersehen, etc.

natuerlich kann man die sachen auch ohne debugger finden, aber wir wollen doch nicht zu debug-printfs zurueck fallen, oder?

alleine das problem wenn das programm abstuertzt - wo ist es abgeschmiert? oder man faengt eine exception die sagt, da war ein null zeiger der da nie haette sein duerfen - wie findet man sowas? meistens ist der fehler in der tat trivial, aber wie findet man am schnellsten die stelle im code? mit dem debugger rein, kontext ansehen und man hat schonmal einen guten ansatz.

oder wie findest du so einen fehler?

zB logikfehler. entweder man macht debug ausgaben oder man verwendet einen debugger. den code zu analysieren kostet enorm viel zeit und wenn man pech hat, analysiert man die falsche stelle. debugger sparen da soviel zeit...

Shade Of Mine schrieb:

oder wie findest du so einen fehler?

Fehler, die das Programm abstürzen lassen (zugriffe out of range oder auf unreferenzierte zeiger und sowas) kommen einfach nicht mehr vor. Und wenn, dann weiss ich sofort von welcher Stelle es kommt, da ich einzelne Teile des Programms programmiere und danach einzeln Teste bis sie wirklich perfekt (für den Zweck den sie erfüllen) sind.

Shade Of Mine schrieb:

zB logikfehler.

Wie schon erwähnt bearbeite ich einzelne Ausschnitte genau und gehe Logikfehler wesentlich schneller im Kopf durch als mit dem Debugger. In der Regel ist es so, dass mir der Debugger nur den Fehler zeigen würde, den ich ohnehin kenne. Zur Lösung führt mich da keiner.