Grundsätzliches, Algorithmen
-
Ki schrieb:
Werd ich wohl wirklich mit Aufschreiben oder -,zeichnen machen müssen.
Aber wird sich das im Laufe der Praxis ändern? Also ich schätze schon dass sich das EVA-Prinzip irgendwann weitestgehend automatisieren wird oder gibt es tatsächlich erfahrene Programmierer die das permanent auf die Weise machen müssen weil sies anders nicht checken würden?
Für etwaige weitere Tipps bin ich natürlich äusserst dankbar.Also ich mach mir vorher immer erst Notizen, egal ob jetzt mit Bleistift und Papier oder mit einem Word-Dokument. In seriösen Firmen ist sowas grundsätzlich erforderlich, da du dann selten der einzige bist, der an einem Projekt arbeitet. Und eine gute Dokumentation der verschiedenen Projektphasen ist dann unumgänglich. Machst du sowas nicht, dann endet das im bekannten Trial'n'Error Verfahren und sowas ist im Normalfall der Tod (Projekt oder Firma, was auch immer).
-
Ki schrieb:
Nein, wie gesagt, das Problem ist dahingehend dass ich nicht weis wie ich zum benötigten Ergebnis komme.
Als einfaches Beispiel: Ich brauche z.b ein Programm wo ich Zahlen eingebe und die anschliessend addiert ausgegeben werden (wie gesagt, nur als Beispiel). Ist eine simple Angelegenheit die ich trotzdem auf die Schnelle nicht hinkriege. Einfach aus dem Grund weil ich nicht weis wie oder mit was ich zu Schreiben beginnen soll bzw. welche Funktionen oder Bedingungen etc. ich benötige.
Wenn der Code vom Trainer gezeigt wird ist er für mich eindeutig klar und verständlich.So geht es meiner Freundin auch (ich versuche seit geraumer zeit ihr programmieren beizubringen (allerdings VB und nicht C++, sie hält programme ohne GUI nämlich nicht für 'richtige' programme ;))).
Die Idee mit der wir gut fahren ist:
Ein Problem in Teilprobleme zu zerlegen.Nehmen wir dein Beispiel:
Problem Nr 1:
1 Zahl eingeben.wir schreiben also ein Programm wo man eine Zahl eingeben kann
#include <iostream.h> int main() { int zahl; cin>>zahl; }fertig.
uU auch noch in 2 schritte teilen:
- programm erstellen das eine zahl hat
#include <iostream.h> int main() { int zahl; }- zahl vom user eingeben lassen
als nächstes das ganze mit 2 zahlen.
nun schreiben wir ein anderes programm:
es soll eine zahl ausgeben:#include <iostream.h> int main() { cout<<7; }nun wollen wir ein anderes programm schreiben, dass eine zahl berechnet:
#include <iostream.h> int main() { int zahl=3+4; }nach dem verbinden haben wir:
#include <iostream.h> int main() { int zahl=3+4; cout<<zahl; }und unser 1. programm ist:
#include <iostream.h> int main() { int zahl1; int zahl2; cin>>zahl1; cin>>zahl2; }wir müssen diese beiden programme nur noch miteinander verbinden:
#include <iostream.h> int main() { int zahl1; int zahl2; cin>>zahl1; cin>>zahl2; int zahl=zahl1+zahl2; cout<<zahl; }und fertig

mag blöd klingen und aussehen - aber so kann man jedes problem in minimale teilprobleme zerlegen und wird nicht von der komplexität abgeschreckt.
denn
2 zahlen eingeben und addiert wieder ausgeben
ist wesentlich komplexer als:
1 zahl eingeben
und
1 zahl eingeben
wird zu
2 zahlen eingeben1 zahl ausgeben
und
1 zahl berechnen
wird zu
1 berechnete zahl ausgebendiese beiden zusammen ergeben dann:
2 zahlen eingeben und daraus eine zahl berechnen und diese ausgebenschon haben wir es geschafft und nur recht einfache sachen gemacht.
Im prinzip ist das die selbe herangehensweise an 'echte' Probleme - man teil sie in kleinere probleme auf und am ende fügt man sie zusammen.
das schöne daran: wenn etwas nicht klappt sieht man sofort wo der fehler war - weil man nicht das gesamte programm als fehlerhaft einstufen muss, sondern nur den kleinen schritt an dem man gerade arbeitet.
nun kann man sich recht einfach hilfe holen ohne eine komplettlösung zu bekommen

bei meiner freundin hilft es normalerweise wenn ich ihr die richtigen fragen stelle - und so ihr denken in die richtige richtung lenke

das problem mit diagrammen ist IMHO, dass man bereits wissen muss, was man tut/tun will. Sie bringen also nichts wenn man keine ahnung hat wo man anfangen soll. Bei dem 'in Teilprobleme zerlegen' ansatz, kann man auch in der Mitte anfangen - weil es ja egal ist in welcher Reihenfolge man die Teilprobleme löst...
-
Artchi schrieb:
Ich weiß noch, als ich C++ gelernt habe (habe vorher Assembler ohne Ende programmiert), und ich absolut nicht kapiert habe, was OO sein soll. Aber an einem bestimmten Tag, gab es bei mir den Aha!-Effekt. Das ist einer der Momente in meinem Leben, an die ich mich wie gestern erinnern kann. Und verdammt nochmal, ich habe OO-Talent! Heute löse ich alle Aufgaben im Beruf mit Links!
Das kenne ich.

Ähnliches hatte ich mit Zeigern in einem C++ für Dummies Buch oder so...
OOP & Co. lernt man nicht indem man ein Buch liest.
-
Gregor schrieb:
Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.
Das denke ich schon. Wenn Du Dir das einmal aufschreibst, dann hast Du zumindest mal genau fixiert, was Du als kriegst und was Du haben möchtest. Das ist der erste Schritt zu einer guten Problembeschreibung. Und eine solche ist doch in den allermeisten Fällen schon mindestens die halbe Lösung.
Es gibt nunmal einfach Probleme, die man nicht auf einen Schlag in seinen Kopf reinbekommt weil sie zu umfangreich sind. Da ist es wirklich nützlich sich ein paar Notizen zu machen.
Gregor: Kannst Du mal nen Algorithmus implementieren der einen 8x8 Rubik's Cube löst? Nicht auf die Schnelle? Vielleicht fehlt Dir dann das Talent! - Vielleicht aber auch nicht und Du müßtest Dich damit erstmal genauer auseinandersetzen. Und das geht mit Stift und Papier prima.
Gerade wenn man mit Programmieren anfängt ist es wirklich schwierig den Blick auf das Wesentliche zu richten. Man kann ja als Mensch so ca. 7 Sachen gleichzeitig im Kopf haben, dann ist fertig. Wenn man von diesen 7 Sachen jetzt aber schon 4-5 für syntaktische Probleme reserviert hat... dann wird's halt eng und man muß irgendwo was auslagern.
MfG Jester
-
Jester schrieb:
Kannst Du mal nen Algorithmus implementieren der einen 8x8 Rubik's Cube löst?
Oh, hör blos auf und guck dir eher mal an, womit Ki hier schon Probleme hat. Er weiß nicht, wie er an die Aufgabe herangehen sollte 2 Zahlen zu addieren. Aus meiner Sicht ist das hier kein Problem der Komplexität oder des Begreifens des Problems, sondern ein Problem, das in seiner Denkweise liegt. Er hat es einfach nicht drauf, ein Problem bzw. eine diesbezügliche Lösung in einer Programmiersprache zu formulieren. Ich sehe nicht, wie sich sowas so einfach verbessern sollte. Vor allem sehe ich nicht den Sinn darin, die Lösung des Problems in etwas Programmiersprachen-ähnlichem zu formulieren, wie es hier vorgeschlagen wurde. Damit wird er doch genau die gleichen Probleme haben, weil es letztendlich nur eine andere Notation ist.
Ehrlich gesagt habe ich auch noch nie jemanden gesehen, der sich solche "Pläne" vor dem Programmieren erstellt. Wenn man sich schriftliche Notizen macht, dann sind das doch in aller Regel ganz informelle Skizzen, die die Problemlösung oder das Problem vielleicht grafisch oder so darstellen. Es handelt sich nicht um eine Notation der Lösung, die man "mit nem Program gleich in Sourcecode umwandeln könnte". Welche Vorteile sollte soetwas gegenüber "Code direkt schreiben" haben?
-
Jo, ich mach auch immer nur informelle Beschreibungen. Aber genau das muß man auch üben. Sehe genauso keinen Sinn darin was Programmiersprachen-Ähnliches zu verwenden. Aber ein Gegeben-Gesucht-Schema hilft einem doch oftmals schon auf die Sprünge.
Zumeist ist es doch wirklich schon die halbe Lösung genau zu wissen was man haben möchte. Zumindest ist das meine Erfahrung.
-
Gregor schrieb:
Oh, hör blos auf und guck dir eher mal an, womit Ki hier schon Probleme hat. Er weiß nicht, wie er an die Aufgabe herangehen sollte 2 Zahlen zu addieren. Aus meiner Sicht ist das hier kein Problem der Komplexität oder des Begreifens des Problems, sondern ein Problem, das in seiner Denkweise liegt. Er hat es einfach nicht drauf, ein Problem bzw. eine diesbezügliche Lösung in einer Programmiersprache zu formulieren.
Man sollte nicht zu hart mit denen sein, die zum ersten mal eine Programmmiersprache sehen, besonders, weil hier auch Leute mitschreiben und lesen, die deutlich unter 18 Jahre alt sind (mal unabhängig, was der OP ist). Ich glaube nicht, daß Du solchen recht tust, indem Du gleich aus der Ferne deren Leistungen aburteilst und jede Motivation im Keim erstickst.
-
Das Programmieren ist das Lösen von Problemen und das musst du lernen das umsetzen in irgendeine Sprache ist ein kleiner Teil (welcher natürlich auch über die Performance entscheiden kann).
Könntest du eine Aufgabe wie dein Beispiel in Deutschen Sätzen lösen? Also eine Beschreibung was du nacheinander tust.
-
Hey wow, danke für die riesen Resonanz!
Also ich denke durchaus dass das mit dem EVA-Prinzip mal ganz gut funktionieren kann, zumindest jedenfalls jetzt am Anfang. Und ich denke auch dass mit der steigenden Praxis des Programmierens das Grundkonzept kommen wird (ich habe vielleicht vergessen zu erwähnen dass sich meine Programmiererfahrung gerade mal auf 2 Monate begrenzen).
Und an diejenigen die denken dass das Talent fehlt möchte ich sagen, Mozart hatte unbestritten Talent. Aber dennoch musste er sehr viel lernen.
Danke nochmal allen.
-
Ja, ich denke schon. Stellt sich nur die Frage wie lange ich dafür brauchen würde ;-).
-
Kopf hoch Ki.
Ich habe vor 7 Jahren im Alter von 55 mit C++ angefangen und konnte gerade mal
den PC einschalten.
Du must nur logisch nachdenken dann klappt es auch.
-
Shade Of Mine schrieb:
So geht es meiner Freundin auch (ich versuche seit geraumer zeit ihr programmieren beizubringen (allerdings VB und nicht C++, sie hält programme ohne GUI nämlich nicht für 'richtige' programme )).
Nerds unter sich. *schauder
-
NormalerMensch schrieb:
Nerds unter sich. *schauder
Ach, Blödsinn; wenn man viel mit jemandem zu tun hat der programmiert, dann ist es doch ganz normal, zumindest ansatzweise verstehen zu wollen, was da ungefähr vorgeht.
Wenn meiner Freundin irgendein Programm abstürzt, dann kann ich sie auch nie mit einem einfachen "Naja, geht halt nicht." abspeisen sondern muss genau erklären was da jetzt gerade schiefgelaufen ist; selbst wenn sie sich sonst nicht sonderlich für Computer interessiert.
(Obwohl ich ihr vor kurzem KTurtle gezeigt habe.
)
-
Ich finde Frauen, die programmieren etc schrecklich und unerotisch. Hätte keinen Bock nach der Arbeit nach Hause zu kommen und dann wieder über EDV Mist zu reden...
-
Ki schrieb:
Wie kann ich mich näher mit dem Algorithmus eines Programms befassen um künftig auch selber einfacher Code schreiben zu können?
du hast das gleiche problem wie die vielen in matematik, die zwar die formeln ausrechnen können, aber von der textaufgabe nicht auf irgend eine gescheite formel kommen.
und es gibt keinen königsweg zur formel.kein buch und keine methode hat die macht. weder struktogramme noch uml, noch eva können einen deut daran ändern, daß man einen plan braucht. aber da die informatik noch relativ jung ist, ist hier noch viel wildwuchs und scharlatanerie. ich gehe deswegen lieber zur mathematik, wo seit 2k jahren bekannt ist, daß es kein fertiges schema zur lösung aller probleme gibt.
was du brauchst, ist einer, der dich bei der hand nimmt und dir den geist für alltägliche probleme öffnet. mit täglichen wanderungen duch die stadt und diskussionen über alles, was man sieht. davon 2 oder 3 jahre, dann sollte das mit dem rechner kein problem mehr sein.
-
Das Problem mit der Mathematik kenne ich nur zu gut, wenn ich mein Matheheft bei mir habe ist es kein Problem was auszurechnen, aber in der Arbeit versage ich total, denn da kann ich nirgends nachschauen

-
SirLant schrieb:
Das Problem mit der Mathematik kenne ich nur zu gut, wenn ich mein Matheheft bei mir habe ist es kein Problem was auszurechnen, aber in der Arbeit versage ich total, denn da kann ich nirgends nachschauen

schau mal auf http://volkard.de/matheprob.html nach.
-
@volkard: lol

-
volkard schrieb:
SirLant schrieb:
Das Problem mit der Mathematik kenne ich nur zu gut, wenn ich mein Matheheft bei mir habe ist es kein Problem was auszurechnen, aber in der Arbeit versage ich total, denn da kann ich nirgends nachschauen

schau mal auf http://volkard.de/matheprob.html nach.
Mist. Genau das wollte ich auch gerade schreiben

-
Würde ich, aber da hat mein Lehrer was dagegen