Delphi lernen, wie vorgehen

[Medium]

An und für sich klingt das nach einer löblichen Vergehensweise, nur hat sie, wie du merkst, auch ein großes Problem: So ein Menschgehirn ist stark abhängig von der Anwendung neuem Wissens, um sich dieses auch wirklich zu verinnerlichen. Jeder etwas erfahrener Programmierer würde dir, zumindest im Affekt, zu deiner Lernidee applaudieren, funktionieren wird das in der Praxis aber leider doch eher selten.

Ich habe mit Delphi auch "quasi" angefangen. Heisst: Ich hatte mit QBASIC als Kind schon einiges gemacht, wirklich verstehen was ich tat war aber nicht drin. Es funktionierte "irgendwie", und das fühlte sich prima an. Dann ganz kurz ein Gastspiel von Turbo Pascal, dann Delphi. Die ersten Jahre waren wirklich einfaches Zusammenklicken von Komponenten, und geflissentliches Ignorieren aller guten Paradigmen der Entwicklung - oftmals auch einfach mangels Wissen um diese, und privat nicht vorhandenem Internet. (Kann sich das heute noch wer vorstellen? Ich sicherlich nicht.)
Erst nach Ende meiner Schulzeit fing bei mir so wirklich das Programmieren nach "erprobten" Vorgehensweisen an, die Sorte, wo man sich noch vor dem Schreiben etlicher Zeilen Code ernsthafte Gedanken um die Dinge gemacht hat, die man erreichen will, und welche Türen man sich noch offen halten mag. Zu diesem Zeitpunkt war ich allerdings schon gut mit der Delphi IDE vertraut, und auch weitestgehend mit der Sprache Pascal. Erst ab dann hat sich alles hauptsächlich um die Konzepte gedreht.
Ich will nicht sagen, dass es falsch wäre diese "Meta"-Disziplinen anfangs ausser Acht zu lassen - bei vielem genügt es aber gerade am Anfang, sie einfach nur schon ein mal gehört zu haben. Die Menge an Programmen, die ich gebaut habe, ohne - nach heutiger Sicht - zu wissen, was ich tat, ist erschreckend . Aber es waren eben diese, die dazu führten, dass ich beim "ernst werden" nicht mehr viel über Kleinigkeiten der Sprache oder die Menüstruktur von Delphi nachdenken musste.

Was ich sagen will: Es ist einfach unerlässlich sich kleine Ziele zu suchen, die man minuziös versucht umzusetzen. Das kann in Einzelfällen auch Wochen dauern, aber eben dieser Biss zahlt sich nachher dadurch aus, dass man mit den ganz zugrunde liegenden Dingen nachher per Du ist, und sich um Konzepte und Strategien kümmern kann, ohne sich in Semantik zu verlieren. Keine Frage, das werden Programme sein, die man nach ein paar Jahren lieber peinlich berührt verschweigen will, aber die sind so wichtig! Der erste Taschenrechner, das erste "Spiel" aus 10000 TImage-Komponenten, der erste Sound den man mit 20 Jahre alten und lang abgekündigten API Funktionen abspielt, die ersten kaputt geschriebenen Dateien, weil Streams gegenüber "file of ..." so unnötig kompliziert erscheinen, der erste Thread, mit dem man fröhlich auf die GUI zugreift und Bekanntschaft mit den unerklärlichsten Zugriffsverletzungen macht... alles Dinge, für die man in Foren so gerne gerüffelt wird, die aber doch einfach Erfahrungen sind, die wie ich finde fest zum Lernprozess gehören. Einfach mal sich trauen ein Programm zu bauen. Irgendwas.

Bei meinen ersten QBASIC Gehversuchen war ich überglücklich, dass 10 Zeilen "**********" im DOS erschienen. Viel später kam ein "DOS-Emulator", der einfach nur so tat, als würde gerade das BIOS das RAM durchtesten (ja, ich war davon überzeugt, dass JEDER PC 4096kB davon hatte ), und nachher nach Kommandozeile aussah, intern aber auch nur alles ans DOS weiterreichte. Dann irgendwann der 256-Farben Mode - WOOHOO! (Co)Sinus-Funktion gefunden -> Lissajous Firugen! (Ich wusste bis nach meinem Studium nicht, dass sie so hießen. Sie waren einfach hübsch und farbig.) Als Krönung irgendwann ein über Monate gebauter, grafisch völlig übler, Space Invaders Klon, der so grottig programmiert war wie nur möglich. Aber es war ein spielbares Spiel! (Zumindest auf einem 386DX40, alles drüber wurde unspielbar schnell.) Aus heutiger Sicht alles diletantisch und völlig naiv gemacht, aber es waren kleine Ziele mit Erfolgen, die letztlich dazu geführt haben, dass das Handwerk an und für sich zu eben diesem werden konnte: Einem "Handwerk". Wirklich "entwickeln" kam erst etliche Jahre später.

Gerade Delphi macht einem die kleinschrittigen Erfolge relativ einfach. Nutze sie! Schreibe kleine unwichtige Programme voller Fehler, und völlig an jedem Ideal vorbei! Zerpflücke Google bei Problemen, sie werden halbstündlich dabei auftreten. Lasse dir in Foren hunderte Zeilen überheblich klingender "guter Ratschläge" entgegenschmettern - die Kunst ist es, die paar guten nüchternen Infos daraus zu extrahieren, den Rest doof zu finden, und dennoch ans Ziel zu kommen. So wie du klingst, wirst du aber auf weit mehr freundliche und hilfsbereite Leute treffen als die "ich will mal eben"- und "ich brauch für Schule und zwar morgen früh"-Faulpelze, die man hier und auch woanders so prominent wahrnimmt (weil sie einem zuweilen echt das Blut zum kochen bringen vermögen).

Probrammieren ist einfach wie so vieles. Man muss voll Krarracho gegen die Mauern rennen um zu erkennen, dass es sie gibt. Dann kann man sich nach und nach an deren Überwindung begeben, egal ob alleine mit Dokus und Suchen, oder durch Fragen bei anderen. Aber man muss los laufen, nur Theorie bis zum Master-Grade kann keiner so wirklich. Und selbst wenn: Es ginge viel zu viel Praxiserfahrung und erlernter Pragmatismus dabei auf der Strecke.

Zur Ausgangsfrage "Delphi lernen, wie vorgehen": Button auf das Formular, Doppelklick drauf, zwischen "begin" und "end" ein ShowMessage(Was'n hier los'n!?); schreiben, F9 drücken, Fehlermeldung kassieren, googlen, fragen, Doku lesen: Bumms -> Du wirst ab jetzt wissen, was Strings und Datentypen generell sind, wie und warum sie sich unterscheiden, und dass ShowMessage() eine Funktion ist, die einen Parameter eines bestimmten Typs braucht. Die Vorgehensweise lässt sich praktisch beliebig durchziehen, sie nennt sich "einfach mal machen"

[Bbommel]

Medium und andere haben mit ihren Antworten ja jetzt eigentlich fast alles gesagt, was es zu sagen gibt.

Eins möchte ich aber noch mal unterstreichen: bis heute hilft es mir beim Erlernen neuer Sprachen und auch von für mich neuen Konzepten innerhalb der Sprache immer, diese an einer konkreten Aufgabe auszuprobieren. Und das ist vielleicht erst mal das schwierigste: überlege dir irgendein kleines Tool, dass du schreiben willst. Das darf gerne auch etwas sein, das es schon längst gibt - der tausendste Taschenrechner, der millionste Vokabeltrainer - vielleicht gibt es aber ja auch wirklich etwas, was du brauchen kannst und das es noch nicht gibt. Nur nicht zu komplex anfangen.

An diesem Tool kannst du dich dann austoben und du hast ein Ziel, wo du hin möchtest und dann kannst du auch gezielt bestimmte Dinge im Buch noch einmal nachlesen und ausprobieren. Wichtig ist es dann, dass du bei dem, was du entwickeln willst, dir erst mal auch kleine Teilaufgaben überlegst.

Beispiel Taschenrechner: Bevor das Ding rechnet, bastelst du in einem Fenster vielleicht erst mal etwas zusammen, das wir ein Taschenrechner aussieht, also die ganzen Knöpfe und eine Anzeige. Dann würdest du vielleicht dafür sorgen wollen, dass, wenn man auf die "1" klickt, diese dann auch in der Anzeige erscheint. Und so weiter, bis es dann immer komplexer wird.

Viel Spaß auf jeden Fall beim Einstieg ins Programmieren!

[DeddyH]

Zitat von Medium:

..., und dass ShowMessage() eine Funktion ist, die einen Parameter eines bestimmten Typs braucht.

ShowMessage() ist eine Prozedur

[Furtbichler]

Nun ja. Eine 'procedure' schon und keine 'function', aber sie ist/hat eine Funktion.

[Medium]

Grummel. Guckt auf die Uhrzeit meines Beitrages, da ist so ein Pätzerchen erlaubt

[baumina]

Schöner Beitrag Medium, man findet sich darin selbst wieder!

Also ich habe Datenverarbeitungskauffrau gelernt (den Beruf gibt's so schon nimmer). Mein Lehrer für Cobol-Programmierung hat sich sein Wissen jeweils mittels Buch kurz vor der Stunde angeeignet. Man konnte ihn also niemals fragen was erst 3 Seiten später stand, also der Unterricht war komplett untauglich.

Bei meinem Chef habe ich "Smart" gelernt. Das war sowas wie Office und VBA, die Programmiersprache war auf deutsch! Durch anfängliches Zusehen habe ich sehr viel gelernt. Auch heute schaue ich Programmierern gerne über die Schulter, denn jeder hat einen anderen Stil und eine andere Denkweise an ein Problem ran zu gehen.

Ja, man muss sich einfach irgendwann einmal trauen irgendwas zu programmieren, auch wenn es anderen dabei die Haare zu Berge stehen lässt. Von heute auf morgen kann man nicht alles wissen, nein, man kann NIE alles wissen, man kann sich nur immer weiter entwickeln.

Auf jeden Fall wünsche ich dir viel Spaß dabei, denn ich programmiere seit über 25 Jahren richtig gerne, auch wenn ich in der Zeit das Rad mindestens schon 100 mal neu erfunden habe, es sieht doch jedesmal ein wenig anders und schöner aus.

[Codehunter]

Wenn ich so zurückdenke wie bei mir das alles mal angefangen hat... 1991, mein erster eigener Computer - natürlich ein Amiga 500. Aufgebaut war er in 20 Minuten und eigentlich idiotensicher. Betriebssystem-Diskette rein und fasziniert zugeschaut, wie sich die Sache so auf dem Fernseher aufbaut. Im Handbuch stand etwas von einer Extras-Diskette, die kam dann auch gleich rein. Und ratet mal, was dort als Icon erschien. Amiga BASIC. Kein Witz: Das allererste Programm das ich auf meinem allerersten Computer per Maus gestartet habe war eine Entwicklungsumgebung. Und die war auch noch von Microsoft. Geschadet hats trotzdem nicht

Ganz ehrlich, das Handbuch zu Amiga BASIC war eines der besten das mir jemals unter kam. Für jedes einzelne Keyword und jede Funktion dieser Sprache gab es mindestens eine volle Buchseite Beschreibung. Die praktischen Beispiele waren stark grafikorientiert und so lernte ich gleich mal den Umgang mit Pixeln und Koordinaten. Diese Erfahrungen, nun schon 22 Jahre alt, helfen mir heute noch bei der Entwicklung grafischer Komponenten.

Mein Masterplan damals auf Amiga BASIC war es, einen Nadeldrucker anzusteuern. Die Standard-Epson-ESC-Sequenzen standen ja auch im Amiga-Handbuch. Ich hab damals nicht eher locker gelassen bis ich den Drucker zum Drucken von Grafik nutzen konnte - mangels Druckertreibern die im OS integriert sind damals ein Horror. Dann schrieb ich ein kleines Malprogramm, sehr primitiv gehalten. Mit der Maus einen Cursor bewegen und bei gedrückter Maustaste eine weiße Linie zeichnen. Meine gestalterischen Fähigkeiten waren damals schon sehr bescheiden und sind heute auch nicht viel besser ^^ Jedenfalls sollte diese handgemalte Grafik zu Papier gebracht werden und das gelang mir irgendwann auch (glaub nach 3 Jahren oder so).

Am Anfang ist es ganz normal, dass man praktisch nach jeder neuen Zeile Code die man schreibt, das Programm einmal laufen lässt um zu sehen was passiert. Das ist zwar nicht sehr effektiv, hilft aber ungemein beim Lernen. Mit der Zeit werden die Codeabschnitte immer länger die man am Stück schreiben kann. Man weiß einfach irgendwann wie alles zusammenhängt. Heute schreibe ich gelegentlich 1000 Zeilen am Stück bevor ich überhaupt was habe das ich testen kann. Wenn dann beim ersten Compilerdurchlauf keine Errors auftreten, weil ich irgendwo ein schließendes END vergessen oder statt einem ";" ein ":" getippt habe, dann sind das so die kleinen Glücksmomente - kommen aber höchst selten vor. Was aber nicht heißt dass der Code beim ersten Versuch auch gleich das tut was er soll.

Tatsache ist, mit einem halbwegs aktuellen Delphi, das ohne Adminrechte unter Win 7 läuft (tut IMHO schon D7) kann man eigentlich nichts kaputt machen. Darum kann man als Anfänger einfach drauflos coden, Fehler machen, daraus lernen und am Ende was nettes erschaffen. Als Anfänger sollte man froh sein, dass man nicht unter Erfolgsdruck steht und sich mit Nonsens befassen kann. Dann macht Programmieren noch richtig Spaß. Wenn man später Programme schreibt für Businessanwendungen, kann die Arbeit sehr nüchtern und trocken sein. Darum werf ich auch heute noch manchmal kleine Opensource-Projekte in die Welt, einfach um zu sehen was andere davon halten und vorallem um mal was vollkommen anderes zu machen als im Alltag. Schade nur, dass so selten Zeit dafür ist.

[BMI]

hatte neulich mal das Problem unter Win 7, daß bei Delphi 7 PE der Debugger (Anzeige der Variableninhalte bei MouseOver über den Variablen beim Durchsteppen/Haltepunkt keine Hints anzeigte.) Probleme machte.
Hatte das schonmal jemand?

[Paul13]

Wow.

Vielen Dank für die ganzen ausführlichen Antworten!
Jetzt bin ich noch mehr motiviert .


Grüße Paul