Mauz: Programmieren lernen

Abend,

wer kann mir Tipps geben wie ich richtig Programmieren lernen kann?
Damit meine ich nicht, was Kontrollstrukturen, Arrays, Datentypen usw. sind, dieses Wissen besitze ich bereits, ich kann mein Wissen leider nur bedingt anwenden. Ich weiß einfach nicht so wirklich wie ich am besten an so ein Programm ran gehen muss. Ich habe mir im Netz mehrere Tutorials durchgelesen, besitze mehrere Bücher(C/C++/PHP ...), sprich theoretisches Wissen hab ich viel, nur für die Praxis reichts kein Meter!

MfG
Mauz

  1. Hi Mauz,

    wer kann mir Tipps geben wie ich richtig Programmieren lernen kann?

    Meiner bescheidenen Erfahrung nach lernt man am besten bei konkreten Projekten.

    Viele Grüße
    Mathias Bigge

    1. Hallo Mathias Bigge

      Meiner bescheidenen Erfahrung nach lernt man am besten bei konkreten Projekten.

      genau das ist mein Problem, wenn ich vor so einem Projekt stehe, weiß ich oft nicht wie ich es meistern soll. Manchmal hab ich das Gefühl ich bin vielleicht zu dumm dazu, gibt es nicht sowas wie psychologische Eignungstests für Informatiker? Echt, ich bin wirklich am verzeifeln.

      1. Hallo Mauz,

        psychologische Eignungstests für Informatiker? Echt, ich bin wirklich am verzeifeln.

        Naja, die psychischen Belastungen für Informatiker sind ja nun nicht gerade übderdurchschnittlich hoch. Aber einen Eignungstest gibt es z.B. hier: http://www.pms.ifi.lmu.de/eignungstest/

        Man muss nun aber nicht unbedingt Informatik studieren um ein halbwegs brauchbares Programm schreiben zu können. Überleg Dir einfach eine kleinere Aufgabe, die die lösen möchtest und leg los. Wenn Du dabei irgendwie nicht weiter kommst, kannst Du ja hier fragen.
        Natürlich gibt es auch jede Menge Bücher zum Entwurf zu von Programmen oder Algorithmen. Aber erst mal ist es sicher besser, einfach etwas Erfahrung zu sammeln.

        Grüße

        Daniel

      2. Meiner bescheidenen Erfahrung nach lernt man am besten bei konkreten Projekten.

        genau das ist mein Problem, wenn ich vor so einem Projekt stehe, weiß ich oft nicht wie ich es meistern soll. Manchmal hab ich das Gefühl ich bin vielleicht zu dumm dazu.

        Ach nöö...kaum! Wo klemmts denn? Wollen deine Programme einfach nicht laufen, weil der Compiler dauernd Fehler meldet oder einfach 'nix passiert'? Oder funktioniert nix so, wie du es gerne möchtest? Oder hast du keinen blassen Schimmer, wie du überhaupt beginnen solltest? Wenn die ersten beiden Fragen zutreffen, so rate ich dir: Versuche, den Fehler so genau wie möglich einzukreisen, indem du herausfindest, was denn bereits _korrekt_ funktioniert. Im Zweifelsfall wird man dir hier sicherlich auch gerne helfen! Beantwortest du die dritte Frage mit 'ja', so hast du sicher ein bisschen ein grösseres Problem - dir fehlt das grundlegende Wissen, wie sowas überhaupt geht. Dann rate ich dir: Fange mit kleinen Projekten an und steigere dich dann langsam. Es muss nicht gleich eine Windows-API-Anwendung oder ein CMS sein. Auch ein Tischtennis oder ein Gästebuch können einen Anfänger noch überfordern, das ist absolut normal.
        Häufig ist auch das Problem, dass man zwar die Sprache beherrscht, nicht aber unentbehrliche Hilfsbibliotheken. Was will man schon mit C anfangen, wenn man nichts Grafisches darstellen kann, keine Dateien verwenden kann, ... Oder was nützt einem PHP, ohne auf die nötigen GET-Variabeln zugreifen zu können?
        Ich schlage dir vor, du startest ein kleines Projekt und man kann dann im Forum darüber diskutieren, wie sowas am besten geschieht. Sicher auch für die 'Fachleute' interessant.
        Ideen:
        (PHP)

        • HTML-Formular eingeben und nach einfachen Kriterien auswerten (GET-Variabeln)
        • einfaches Gästebuch/Blog (Dateien oder SQL/GET- oder POST-Variabeln)
        • einfacher Counter (Dateien oder SQL)
          (C)
        • Berechnungsprogramm für...Primzahlen, lineare Gleichungen mit mehreren Unbekannten, Flächen/Volumen von Körpern, ...
        • grafische Darstellung von Objekten im Windows-API
        • Ping-Pong, Snake, ...

        Achja - vielleicht solltest du dir mal die Programmiersprache Java ansehen. Dort hast du nämlich kaum Probleme, die nötigen Bibliotheken zu finden. Sie sind meistens auch sehr einfach zu handhaben (im Vergleich z.B. zu C). Aussagen, wonach Java Spielzeugsprache sind, sind absoluter Quatsch. (Man hört sowas manchmal...)

        Gruss

        Michael

      3. Hallo Mauz,

        genau das ist mein Problem, wenn ich vor so einem Projekt stehe, weiß ich oft nicht wie ich es meistern soll. Manchmal hab ich das Gefühl ich bin vielleicht zu dumm dazu, gibt es nicht sowas wie psychologische Eignungstests für Informatiker? Echt, ich bin wirklich am verzeifeln.

        oh je, mache dir nicht allzu viele Sorgen. Vor diesem Problem stehen sehr viele Entwickler und Systemprogrammierer zu Begin ihrer "Laufbahn". Ich kann mich noch gut daran erinnern - sind ja auch nur knapp sieben Jahre her bis jetzt -, da war ich genauso verzweifelt! Damals hatte ich mit kleineren Aufgaben angefangen wie zum Beispiel interaktive C-Progrämmchen mit Abfragen über die Kommandozeile und richtig oder falsch Antwort... Damit ich überhaupt erstmal einen Peil bekam, habe ich mir einfach ein paar Sourcen meiner Kollegen angesehen, die schon seit jahrzehnten nichts anderes machen. Dabei kommt viel rum, auch wenn das Verständnis für viele Abläufe erst mit der Zeit wächst.

        Ich erinnere mich sogar noch sehr gut daran... nach ca. einem Jahr hatte ich mir eine kleine voll automatisierte Systemumgebung in KSH geschrieben und war davon wirklich begeistert - worüber der Eine oder Andere echte Proggi vor Schreck wohl die Hände über dem Kopf zusammen geschlagen hätte :) - und es dauerte kein weiteres Jahr, da habe ich die komplette Umgebung neu geschrieben - was wohl in den darauf folgenden Jahren öfters passierte -, weil ich in dieser Zeit wieder soviel neue Erfahrungen gesammelt hatte, dass ich selbst entdeckte, wie schlecht meine Skripte geschrieben waren oder es für viele Bereiche bessere Lösungen gab. Aber darauf kommt es zu Begin erstmal nicht an! Die Programme zum Laufen zu bringen, auch wenn der Sourcecode aus 1000 Zeilen besteht - was man allerdings schon mit 300 Zeilen genauso gut hätte erledigen können -, dass ist wichtig. Die Erkenntnis, dass man vieles besser schreiben kann, kommt erst mit der Zeit und selbst der absolute Profi kann immer wieder was dazu lernen.

        Greez,
        opi

        --
        Für Syntaxfehler bitte ich um Entschuldigung!
      4. Hi,

        Meiner bescheidenen Erfahrung nach lernt man am besten bei konkreten Projekten.
        genau das ist mein Problem, wenn ich vor so einem Projekt stehe, weiß ich oft nicht wie ich es meistern soll. Manchmal hab ich das Gefühl ich bin vielleicht zu dumm dazu, gibt es nicht sowas wie psychologische Eignungstests für Informatiker? Echt, ich bin wirklich am verzeifeln.

        Divide et impera! Teile und herrsche!

        Zerlege das Projekt in viele kleine Teile, und löse jeden Teil für sich.

        Und: je größer das Projekt, desto größer wird normalerweise das Verhältnis zwischen Planung und Code-Schreiberei.

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        Schreinerei Waechter
        Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
        1. Hallo Andreas,

          Divide et impera! Teile und herrsche!

          Zerlege das Projekt in viele kleine Teile, und löse jeden Teil für sich.

          Und: je größer das Projekt, desto größer wird normalerweise das Verhältnis zwischen Planung und Code-Schreiberei.

          Umgekehrt wird aber auch ein Schuh draus. Da Mauz doch das grundlegende Wissen, was "was Kontrollstrukturen, Arrays, Datentypen usw." betrifft hat, sollte er sich Aufgaben stellen, die er mit seinem bestehenden Wissen bereits lösen kann. Die größeren Module, die er sich dabei erarbeitet, kann er dann zu immer noch größeren zusammenfügen.

          Also ich sehe immer zu, dass ich mich mit den selbstgestellten Aufgaben nicht überfordere, und dass ich einen tatsächlichen Nutzen aus der Lösung ziehe. Für mich ist da auch Sinnenfreude wichtig, deshalb fahr ich so auf die Themen Musik und Animation ab.

          Wenn ich mir ohne jeden Bezug zur Praxis aus einem Lehrwerk einen Algorithmus reinziehe, wie ich das Kleinste gemeinsame Vielfache zweier Zahlen ermiteln kann, bringt mir das nichts und es bleibt dann auch nichts hängen. Wenn ich aber sehe, dass ich das brauche, um ein Spiel zu programmieren, lerne ich das in Null-Komma-Nichts.

          Aber es gibt natürlich unterschiedliche Lernertypen, die sich selbst mit Unterschiedlichem belohnen würden. Manche kommen bei der Erlangung ihrer Ziele auch besser mit deduktiven, andere mit induktiven Methoden zurecht.

          Gruß Gernot

          1. Hello,

            Umgekehrt wird aber auch ein Schuh draus. Da Mauz doch das grundlegende Wissen, was "was Kontrollstrukturen, Arrays, Datentypen usw." betrifft hat, sollte er sich Aufgaben stellen, die er mit seinem bestehenden Wissen bereits lösen kann. Die größeren Module, die er sich dabei erarbeitet, kann er dann zu immer noch größeren zusammenfügen.

            Diese Technik nennt man dann auch "von unten hoch", oder?
            Man kann aber auch "von oben nach unten" arbeiten.
            Und welche Methoden gibts sonst noch so?

            http://www.iam.unibe.ch/~scg/Archive/OSG/Kapp89aPrototyping.pdf
            http://www.hadels.com/programmit/software-engineering.html
            http://www1.iwr.uni-heidelberg.de/~Michael.Winckler/VWA/Skripte/se_skript_2004.pdf

            Harzliche Grüße aus http://www.annerschbarrich.de

            Tom

            --
            Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
            Nur selber lernen macht schlau
            1. Hallo,

              Diese Technik nennt man dann auch "von unten hoch", oder?

              Ja, ich habe damals im Studium auch gelernt, dass man grundsätzlich zwei Methoden unterscheidet, ein Projekt zu implementieren, nämlich "top-down" und "bottom-up".

              Im Lauf der Jahre ist mir aber aufgefallen, dass meine eigene Methode keinem dieser beiden Modelle entspricht. Ich bezeichne sie gern als "inside-out". Damit meine ich nicht, dass ich das Innerste nach außen kehre, sondern dass ich "innen" mit einem Grundgerüst anfange, das erstmal nur ganz grob abstrahiert ist, aber bereits die wesentliche Struktur des Gesamtprojekts widerspiegelt. Dann fange ich erst an, die einzelnen Module im Detail auszuarbeiten, zu testen und dann in das Skelett einzuflechten. Und zwar ungeachtet der Modul-Hierarchie in einer Reihenfolge, die möglichst schnell in sich geschlossene, funktionierende Teilbereiche ergibt.

              Bei der bottom-up-Methode arbeitet man dagegen anfangs sehr lange mit einzelnen Fragmenten, die dem Unbedarften nichts sagen. Es entsteht also für den Außenstehenden ziemlich lange der Eindruck, dass es keinen Fortschritt gäbe.

              Ähnlich ist es mit der top-down-Methode, wenn man sie wirklich konsequent anwendet. Auch hier ergibt sich erst dann etwas Funktionierendes, wenn man endlich anfängt, die Low-Level-Elemente zu realisieren - also erst gegen Ende der "Evolution".

              Und genau da sehe ich den Vorteil der inside-out-Methode: Man hat sehr schnell etwas, mit dem man sich und anderen (Kunde, Chef) zeigen kann, wie das fertige Produkt mal aussehen soll. Es gibt zwar anfangs eine Menge kleine Baustellen und Provisorien, aber man sieht sehr bald die Gesamtstruktur, und die meisten können sich damit am besten ein Bild über das fertige Produkt machen.

              So long,

              Martin

  2. Hello,

    die wichtigsten Werkzeuge zum Programmieren sind meiner Meinung nach immer noch

    - Haufen Schmierpapier
      - Guter Bleistift
      - Radiergummi

    und dann vielleicht eine große Wand, auf der man sich Teilergebnisse auf kleinen Kärtchen oder Zettelchen anpinnen kann um sie miteinander in Zusammenhang zu bringen.

    Speziell der Dialogprogrammierung kann man so gut zu Leibe rücken.
    Erstmal alles aufmalen, was später irgendwie sichtbar werden soll und dann das "Dahinter" designen. Das Coden selbst kommt ganz zum Schluss und ist eigentlich nur noch reine Mechanik.

    Harzliche Grüße aus http://www.annerschbarrich.de

    Tom

    --
    Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
    Nur selber lernen macht schlau
  3. Moin,

    »»Ich weiß einfach nicht so wirklich wie ich am besten an so ein Programm ran gehen muss.»»

    zwar weiß ich nicht genau, welche Sprache Du programmierst, aber ich gehe mal von objektorientierten aus.

    Da erstellst Du am besten Ablauf-Diagramme:

    Wenn dieses..... dann folgt entweder 1., 2., 3., etc.  usw. so entsteht eine Art Baumdiagramm, das die gesamte Funktion des Programmes erfasst. Dieses Baumdiagramm ist dann erstmal nicht Programmiersprachen gebunden, sondern ein reiner Algorithmus.

    Für diese Baumdiagramme gibt es auch ganz spezielle Symbol-Verwendungen, so dass diese Diagramme nicht nur für dich, sondern auch für andere Entwickler verständlich sind.

    Leider fällt mir im Moment der Begriff für diese Diagramme nicht ein. Vielleicht kann jemand weiterhelfen. Es gibt auch Programme, mit denen sich derartige Diagramme relativ leicht erstellen lassen.

    moe.

    1. hi!

      Leider fällt mir im Moment der Begriff für diese Diagramme nicht ein.

      UML?

      bye, Frank!

      --
      Never argue with an idiot. He will lower you to his level and then
      beat you with experience.
    2. Hallo,

      Leider fällt mir im Moment der Begriff für diese Diagramme nicht ein.

      Gibt es einen?
      Ich kenne die Dinger als Flowcharts. Aber ob das der Begriff ist, den du meinst?

      Ciao,

      Martin

      1. Hello,

        Leider fällt mir im Moment der Begriff für diese Diagramme nicht ein.

        PAP = Programm Ablauf Plan.

        Es gab auch mal eine Zeit, da habe sich die Deutschen noch nicht dafür geschämt, eigene Fachausdrücke zu schaffen und sie dann anschließend sogar zu benutzen. Und das ist jetzt keinesfalls nationalaistisch gemeint! Selbstvertrauen und Selbstwertgefühl sind aber im Moment bei uns Mangelware.

        Harzliche Grüße aus http://www.annerschbarrich.de

        Tom

        --
        Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
        Nur selber lernen macht schlau
    3. Hallo FlamingMoe,

      Leider fällt mir im Moment der Begriff für diese Diagramme nicht ein. Vielleicht kann jemand weiterhelfen.

      Diese Diagramme heisen AFAIK Flussdiagramme.

      Gruß
      Alexander Brock

      --
      SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:? ss:| de:> js:( ch:| sh:( mo:} zu:}
      http://againsttcpa.com