Grundsätzliches, Algorithmen

@Cpp_Junky
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.
Er meinte also dass ich mich mehr mit den Algorithmen der Programme beschäftigen sollte da das Potenzial, um zu Schreiben, durchaus da ist und es schade wäre wenn ich nur wegen dessen aufgeben würde.

Vernochan

Algorithmieren?
Das mach ich auch "gerade" in der berufsschule
Hat der bei euch nie sowas wie Struktogramme oder PAPs(Programm Ablauf Plan) erstellt?
Das ist für den Anfang glaube ich eigentlich ganz gut...
Allerdings weiss ich nicht, wie gut man sich sowas mit nem Buch/tut beibringen kann...
Zudem kenne ich auch keine...
Wäre aber vielleicht mal ne Idee Wert.

Cpp_Junky

Mach dir zum Anfang vielleicht ein Paar Notizen. Sowas in der Richtung (EVA Schema hilft )

Eingabe:
    Zahl1, Zahl2
Verarbeitung:
    Zahl3 = Zahl1 + Zahl2
Ausgabe:
    Zeige Zahl3

Dann überlegst du dir, welche Elemente du für jeden Schritt brauchst und fängst an. Als erstes muss natürlich ein Grundgerüst stehen. Bei einer Konsolen-Anwendung schreibst du dir also erstmal die Main Funktion oder überlässt diese Aufgabe meinetwegen auch dem Klassen-Assi (Falls du MS Visual Studio benutzt).

Danke euch .
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.

Wenn dir diese Denke liegt, solltest du einfachere Sachen in Zukunft dann auch im Kopf entwickeln können. Ich betone "können", weil es nicht unbedingt zum optimalsten Ergebniss führt, sich nur kurz darüber Gedanken zu machen und drauf los zu hacken.

Gregor

Cpp_Junky schrieb:

Mach dir zum Anfang vielleicht ein Paar Notizen. Sowas in der Richtung (EVA Schema hilft )

Ja, wirklich? Zeig mal ein "EVA-Schema" für ein Programm, das 10 Zahlen einliest und sortiert wieder ausgibt. Wenn man sowas erstellen kann, dann kann man den Code IMHO auch sofort schreiben. Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.

@Ki: Ok, vielleicht bringt es dich weiter. Es ist ja jeder Mensch anders. Ich glaube aber, dass du dein Problem so nicht wirklich lösen können wirst. ...ich glaube sogar, dass du dein Problem gar nicht lösen können wirst. Was dir fehlt ist IMHO Talent. Sorry, wenn ich dir das so direkt sage. Es mag sein, dass du bezüglich deines Problems kleine Fortschritte machen wirst und das ist auch sehr wahrscheinlich. Ich denke aber nicht, dass aus dir jemals ein guter Programmierer werden wird. Ganz ehrlich: Ich würde dir empfehlen, dir ein anderes Betätigungsfeld zu suchen.

...so, jetzt könnt ihr mich alle fertig machen, weil ich so ne demotivierende Antwort gegeben habe, die alles andere als nett ist. :p

*Gregor fertig mach*

Sorry, es sind leider nicht mehr Smileys erlaubt. Ich hätte gerne alles zugekleistert.

interpreter

Ich kann Gregor nur zustimmen. Gewisse Sachen kann man einfach oder nicht. Ich glaube nicht, dass Van Gogh täglich malen oder Einstein Mathe geübt hat

Cpp_Junky

Gregor schrieb:

Ja, wirklich? Zeig mal ein "EVA-Schema" für ein Programm, das 10 Zahlen einliest und sortiert wieder ausgibt. Wenn man sowas erstellen kann, dann kann man den Code IMHO auch sofort schreiben. Ich glaube nicht, dass einen so ein "EVA-Schema" weiterbringt.
...

Ok, das war jetzt bezogen auf sein kleines Zahlen-Additions Problem. Bei grösseren Sachen ist das natürlich Humbug. Ich würde entweder PAP's schreiben und wenns ins Detail geht dann Pseudo-Code. Letztendlich ist das sowieso alles Gewöhnungssache. Meistens mach ich mir bei komplizierten Sachen ein paar krakelige Notizen, einen PAP, meditiere dann ein bisschen über das Konzept und dann fang ich an zu hacken. Bis jetzt komm ich damit ganz gut klar. Kleinere Sachen kann ich i.d.R sofort ohne Probleme umsetzen.

Artchi

@Gregor! Es mag sein, das einem Menschen das Talent für sowas fehlt, und das Menschen es wirklich niemals schaffen werden. Aber ich bin auch der Meinung, das manchmal einfach nur die Initialzündung oder ein Aha!-Effekt fehlt. Man sollte erstmal auf dieses hin arbeiten.

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!

@Ki! Du brauchst Praxis, Praxis, Praxis...! Und Code lesen hilft einem nicht weiter, man muß es auch praktizieren. Meiner Meinung nach sollte man zu Anfang weniger fremden Code lesen, und später wird man mehr Aha!-Effekte in anderem (besserem) Code haben. Das Posting von Cpp_Junky fand ich sehr gut. Und ich kann bekräftigen, das du dich einfach täglich vor deinen PC setzt (privat meine ich!) versuchst zu coden. Egal ob der Algo schlecht oder gut ist. Wichtig ist, das es funktioniert. "Schön" machen kann man es danach immer noch.

nman

interpreter schrieb:

Ich glaube nicht, dass Van Gogh täglich malen

Nicht täglich, aber lernen musste er es wohl auch irgendwann mal.

oder Einstein Mathe geübt hat

Hm, gerade bei Einstein geht man doch mittlerweile davon aus, dass ihm seine erste Frau Milena Maric bei einigen mathematischen Formulierungen seiner Theorien ganz entscheidend geholfen hat...

groovemaster

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).

Shade Of Mine

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 eingeben

1 zahl ausgeben
und
1 zahl berechnen
wird zu
1 berechnete zahl ausgeben

diese beiden zusammen ergeben dann:
2 zahlen eingeben und daraus eine zahl berechnen und diese ausgeben

schon 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...

Sgt. Nukem

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.

Jester

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

Gregor

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?

Jester

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.

Daniel E.

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.

SirLant

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.