Grundsätzliches Problem im Verständnis beim Entwickeln von Lösungsstrategien

Mechanics

WizardsApprentice schrieb:

Mich würde es brennend interessieren zu erfahren, wie das bei euch so war, als ihr angefangen habt, Programmieren zu lernen. Ging es euch genauso wie mir ? Was kann ich machen, um mein Gespür für Problemlösungen zu schärfen/trainieren ?

Meine Lösungen waren anfangs (und zwar ziemlich lange) sehr plump. Ich hatte auch keine guten Bücher und kein Internet. Aber mir hat das was ich selber programmiert habe sehr viel Spass gemacht und ich wollte immer um jeden Preis vorankommen.
Später dann mit dem Studium und der Arbeit angefangen und dann hat mich nicht mehr das "Programmieren", sondern eher Softwaredesign und -architekturen interessiert. Das mit Algorithmen kommt teilweise durch Erfahrung und im Studium lernt man so ein bisschen die richtige Denkweise. Man hat aber unterschiedlich viel mit sowas zu tun. Was Algorithmen angeht bin ich nicht ansatzweise so gut wie z.B. volkard, ihm macht es anscheinend viel mehr Spass als mir. Die Frage ist, ob du nicht versuchst, die falschen Probleme zu lösen. Man muss keine Sortieralgorithmen erfinden So oft kommt das im Alltag nicht vor. Ich halte meinen jetzigen Job für anspruchsvoller, als das meiste was Entwickler so tun (wenn man davon ausgeht, dass die meisten Webentwicklung und "Java" machen). Und ich muss auch nicht ständig Divide & Conquer anwenden. Eher Nummerik, Constraint Solver, Paper lesen, bewerten, implementieren. Wenn man da etwas Erfahrung hat, kann man sowas dann nachvollziehen und evtl. auf die eigene Problemstellung anpassen, selber draufkommen ist nochmal was ganz anderes.
Willst du Entwickler werden oder ein richtiger Informatiker? Wenn du Informatiker werden willst, solltest du halt studieren. Ansonsten sind das nicht unbedingt alltägliche Probleme.

Mechanics schrieb:

Meine Lösungen waren anfangs (und zwar ziemlich lange) sehr plump. Ich hatte auch keine guten Bücher und kein Internet. Aber mir hat das was ich selber programmiert habe sehr viel Spass gemacht und ich wollte immer um jeden Preis vorankommen.

Zunächst einmal vielen Dank für deine Antwort! Irgendwie beruhigt mich dein Beitrag. Deine Einstellung teile ich voll und ganz, trotz dieser kleinen Zweifel hin und wieder, aber ich habe nie aufgegeben und freue mich immer über neue, fortschreitende Ergebnisse.

Mechanics schrieb:

Die Frage ist, ob du nicht versuchst, die falschen Probleme zu lösen.

Jetzt, wo du das sagst... Womöglich könnte es so sein. Das Problem bei mir ist, dass ich immer versuche, möglichst "alles", was in Lehrbüchern und Co. steht, krampfhaft zu begreifen, ich will im Prinzip immer alles auf Anhieb verstehen, weil ich Bedenken habe, dass sich fatale Wissenslücken bilden, die sich dann später in komplexeren Anwendungen rächen - aber das direkte Verständnis gelingt nicht immer, wahrscheinlich nehmen die Dinge ihre Zeit. Vielleicht sollte ich mich wirklich etwas konservativer auf mein jetziges Lehrbuch konzentrieren und Seite für Seite diszipliniert durcharbeiten.

Mechanics schrieb:

Willst du Entwickler werden oder ein richtiger Informatiker? Wenn du Informatiker werden willst, solltest du halt studieren. Ansonsten sind das nicht unbedingt alltägliche Probleme.

Ich studiere Chemie im Master, das allgemeine Interesse an der Programmierung hat sich bei mir etwas später aus dem Unterbewusstsein heraus gezeigt Im ersten Semester hatten wir damals im Fach Informatik neben HTML und CSS ein paar wenige Grundlagen in der Programmierung mit Visual Basic gelernt, da man uns sagte, wir könnten das später im Beruf immer gebrauchen (kann ich mir sogar gut vorstellen, ein Vorteil ist es), z.B. um kleine individuelle Auswertprogramme zu erstellen (ich bezweifle jedoch, dass das mit >diesen< Grundlagen möglich wäre).
Ich wollte dann im Verlaufe des Studiums aber aus persönlichem Interesse etwas tiefer in diese Materie einsteigen und habe mich so für C++ als erste Programmiersprache entschieden, angefangen mit einem Lehrbuch von der Serie "Jetzt lerne ich..." .

Jedenfalls bringe ich mir das Programmieren bei Gelegenheit selber bei, einfach aus technikaffinen Gründen, Neugierde sowie Spaß und natürlich um selber mal kleine hilfreiche Programme zu entwickeln. Und hier wären wir bei dem Punkt: Ich hätte mal den Reiz, etwas Anspruchsvolleres zu programmieren als z.B. nur switch-case-Taschenrechner oder Rechner für Kreisflächeninhalte ... aber mir fehlen einfach die passenden Ideen bzw. für komplexere Dinge werde ich mich wahrscheinlich mit meinen fortgeschrittenen Einstiegskenntnissen unwohl fühlen und mich verdrücken. Ich weiß nicht ob es daran liegt, dass ich in C++ einfach noch zu unerfahren bin und nebenbei zu große Erwartungen habe.

Wie hast du/ wie habt ihr das Programmieren richtig erlernt, eher strikt nach Lehrbuch oder so "kreuz und quer" ?

WizardsApprentice schrieb:

Lange Rede, kurzer Sinn - mein Problem ist... Um es mal allgemein auszudrücken, ich habe teilweise Schwierigkeiten, meine "Gedankenansätze" in Code zu formulieren.

Programmiersprachen dienen dazu, deine Gedanken in einer für den Computer verständlichen Form zu strukturieren. Du musst also die dahinterstehende Materie - wie Quicksort - begreifen und dir dann überlegen, welche Möglichkeiten deine Programmiersprache bietet, um deine Gedanken dem Computer zu vermitteln.

WizardsApprentice schrieb:

Das Problem bei mir ist, dass ich immer versuche, möglichst "alles", was in Lehrbüchern und Co. steht, krampfhaft zu begreifen, ich will im Prinzip immer alles auf Anhieb verstehen, weil ich Bedenken habe, dass sich fatale Wissenslücken bilden, die sich dann später in komplexeren Anwendungen rächen - aber das direkte Verständnis gelingt nicht immer, wahrscheinlich nehmen die Dinge ihre Zeit. Vielleicht sollte ich mich wirklich etwas konservativer auf mein jetziges Lehrbuch konzentrieren und Seite für Seite diszipliniert durcharbeiten.

Die graue Theorie aus den Lehrbüchern hilft dir nicht weiter, sofern du sie nicht anwenden kannst. Du musst üben, üben, üben. Mit deinen Kenntnissen lässt sich bereits jedes Programm umsetzten! Scheinbar hat es bei dir aber noch nicht Klick gemacht. Üben, üben, üben! (Bzw. weshalb denkst du, dass du mit deinem Wissen etwas nicht umsetzen kannst?)

WizardsApprentice schrieb:

Ich hätte mal den Reiz, etwas Anspruchsvolleres zu programmieren als z.B. nur switch-case-Taschenrechner oder Rechner für Kreisflächeninhalte ... aber mir fehlen einfach die passenden Ideen bzw. für komplexere Dinge werde ich mich wahrscheinlich mit meinen fortgeschrittenen Einstiegskenntnissen unwohl fühlen und mich verdrücken. Ich weiß nicht ob es daran liegt, dass ich in C++ einfach noch zu unerfahren bin und nebenbei zu große Erwartungen habe.

Ideen findest du im deinem Alltag. Eventuell gibt es ja in deinem Chemie-Studium ein interessantes Problem, das du automatisieren könntest?

Kann es sein, dass dich der Umfang von C++ ein wenig einschüchtert? ("den Wald vor lauter Bäumen nicht mehr sehen"?) In den Naturwissenschaften verwenden einige Python. Die Sprache ist simpel, übersichtlich und es gibt eine Fülle an vorgefertigten Bibliotheken (auch im Naturwissenschaftlichen Bereich). (Fast noch wichtiger: Es gibt viele gute Bücher für jeden Kenntnisstand. Teilweise sogar frei (legal) verfügbar. Und Tools wie IPython Notebook sind auch sehr hilfreich.) Du könntest damit deine ersten Erfahrungen mit der Programmierung sammeln. Sobald du genug Erfahrung hast, sollte dir der Umstieg auf eine andere Sprache, wie C++, nicht allzu schwer fallen, wenn du das dann überhaupt noch willst.

PS: Google doch mal nach Python chemistry. Da findest du sogar Vorträge zu dem Thema.

Und ein Nachtrag: ich kenne dein Problem (jede Seite lernen) nur allzu gut. Ich verbeisse mich auch gerne in einer Materie und will sie voll und ganz begreifen. Das Problem hier ist, dass (ich kenne das konkrete Buch nicht) sich die Bücher ja nicht mit dem Programmieren beschäftigen, sondern mit einer Programmiersprache. Und das Ergebnis siehst du ja: die weisst um Sprachfeatures Bescheid, dir fehlt aber das Wissen wie du sie in der Praxis einsetzt.
Du könntest dich auch mit Büchern beschäftigen, die das Programmieren an sich erläutern. Einige Klassiker wären dazu frei im Internet verfügbar. Aber learning by doing wäre wohl effizienter… .

Jester

Ein anderer Punkt ist der, dass das was Du nennst womit Du Schwierigkeiten hast, eben gerade nicht der klassische Stoff von Programmierbüchern sind. Ich weiß noch, dass mich der Taschenrechner von Stroustrup auch erstmal verwirrt hat und ich mich fragte wie man darauf kommt. Der Knackpunkt ist, dass das eigentlich in erster Linie nicht nur Programmierkenntnisse erfordert, sondern das ganze in sich zusammenfällt wenn Du weißt was eine kontextfreie Grammatik ist, und Du weißt wie man sowas aufstellt und parst. Dafür musst Du Dir was über formale Sprachen anschauen, das ist alles kein Hexenwerk, aber man kann nicht erwarten es von einem Beispiel aus zu verstehen, das zudem nur die Implementierung zeigt und nicht wirklich den Entwurf der Grammatik und das Überführen in Lexer+Parser. Ähnlich ist es bei Quicksort. Sowas zu erfinden ist Algorithmenentwurf, und dafür gibt es eine Reihe von Techniken, zum Beispiel divide&conquer. Wenn man sich damit auskennt und weiß wie man sowas analysiert (etwa mittels Rekurrenzen), dann hat man auch eine gute Chance sowas zu finden. Wenn nicht, dann halt nicht. Und wiederum ist das eher Thema von anderen Fachbüchern als reinen Programmier(sprachen)büchern.

Man kann das alles lernen, aber ggf. musst Du Dir halt noch andere Quellen dazu suchen und nicht erwarten alles aus einem Buch zu lernen, das eigentlich hauptsächlich die Programmiersprache vermitteln soll.

tntnet

Es gibt Leute, die versuchen, C++ zu lernen, indem sie wie wild auf der Tastatur herum klimpern bis der Compiler das versteht. Das geht so nicht.

Du bist genau von der anderen Seite, der ein Buch nach dem anderen liest und hofft, dadurch die Erleuchtung zu finden. Auch das geht nicht.

Und wie so oft im Leben ist es der goldene Mittelweg. Solide Theorie und Kenntnis über die Syntax und Möglichkeiten erlangt man durch Bücher. Dann braucht man nicht so lange zu probieren, bis es geht. Aber die Kunst des Programmierens lernt man durch die Praxis. Also einfach mal machen.

Ich glaube, Du bist so weit, dass Du einfach mehr programmieren solltest. Haue in die Tasten und versuche mal, das gelernte theoretische Wissen zu verwenden.

Und wie Du sagst ist Programmieren tatsächlich ein sehr kreativer Vorgang. Und wie das bei vielen kreativen Prozessen so ist, hat der eine mehr und der andere weniger Zugang dazu. Aber auch wenn man weniger davon hat, kann man durchaus sehr viel erreichen, wenn man nur will.

muemmel

Hi WizardsApprentice,

was Du an Problemen aufzählst hat weniger mit der Programmiersprache als mit der Problemlösung an sich zu tun. Früher wurden die entsprechenden Berufe ja noch in Problemanalytiker und Programmierer unterteilt. Und die Problemanalytiker waren kaum die besten Coder, teilweise konnten sie nicht mal die Programmiersprache. Selbst von den Entwicklern von Unix und C kannte wohl nur einer den Assemblercode der PDP11.
Und was Dein Beispiel des Quicksort betrifft, jetzt wo es ihn gibt, finden wir es alle brillant und logisch wie es funktioniert. Aber ich bin mir zum Beispiel nicht sicher, ob es hier imm Forum einer drauf hätte, den ohne Grundlagen zu erfinden. Das mit links und rechts sind ja nur technische Schnärzchen. Aber man muss erst mal darauf kommen, mit dem stufenweise herunterteilen. Der simple Gedanke es so zu machen war der Ausgangspunkt. Der Rest war folgerichtig. Aber Quicksorts zu erfinden ist heute nicht mehr Aufgabe des einzelnen Softwareentwicklers. Diese Grundroutinen sind einfach da, und wir benutzen sie. Unsere Aufgabe sind nicht mehr programmiertechnische Leckerbissen, sondern gut nutzbare effiziente und gut wartbare Lösungen für die jeweilige Aufgabe.
Das Problem bei uns heutezutage ist, dass wir den Wald vor Bäumen nicht mehr sehen. Manchmal lohnt es einfach, mal Kindern beim Spielen zuzusehen. Die machen vieles viel intuitiver.

Wir machen Heute den Fehler, dass wir zu wenig abstrahieren und gleich zu sehr in Einzelheiten denken.
Beispiel: Wir wollen irgend eine Matrix eingeben, irgend was damit rechnen und sie anschließend wieder ausgeben. Und schon geikeln uns irgend welche konkreten Programmiersprachenbefehle im Kopf rum, die da noch gar nichts zu suchen haben, anstatt uns erst mal darüber Gedanken zu machen, was die Aufgabe eigentlich besagt. Fürs erste ist es nämlich völlig egal, ob man die Werte mit dem Quicksort oder Shellsort sortiert. Auf der Ebene gibt es einfach nur 3 (in Worten drei) Aufgaben:
1. Eingeben
2. Berechnen
3. Ausgeben.
Die nächste Stufe könnte dann zum Beispiel das eingeben sein.
1. Spaltenzahl erfassen
2. Zeilenzahl erfassen
3. Werte eingeben.
Und erst wenn's ans Werte eingeben geht sind Gedanken über das wie anzustellen. Aber auch erst mal wieder auf sehr abstrakter Ebene.
Dieses abstrakte Denken, muss man sich aber erst angewöhnen, und es beizubehalten ist auch eine Frage einer gewissen Disziplin beim denken.
Beispiel: wenn Du an einen Tisch denkst, was fällt dir dann dabei ein? 4 Beine? Und wie ist das bei einem Wandklapptisch? Ein Tisch ist einfach nur eine ebene Fläche/Platte, die irgendwie in einer bestimmten Höhe angemacht ist. Und so ist es mit allem. Sobald man beim Tisch an die 4 Beine denkt, hat man schon eine Schere im Kopf, die alles andere wegschneidet, noch bevor es in Erwägung gezogen wurde.
Es kommt also darauf an wie beim Schiffsrat oder 'ner Ideenkonferenz (modern Brainstorming) Einfälle und Realisierbarkeitsbetrachtungen erst mal zu trennen. Wenn man eine Aufgabe hat, dann sozusagen eine Ideenkonferenz mit sich selber durchführen.
Versuch einfach mal, eine bestimmte Aufgabe in 3-5 große Teilaufgaben zu zerlegen. Schreib es einfach als Pseudoquelltext auf, und gib den Teilaufgaben aber bereits sinnvoll strukturierte Namen. Achte aber darauf, dass Du dabei auf einer einheitlichen Ebene bleibst. Also um beim vorherigen Beispiel zu bleiben, nicht schon bei der Aufteilung auf Eingeben, Berechnen und Ausgeben darüber nachdenken ob es sich um reelle oder komplexe Zahlen handelt.
Danach jede dieser Teilaufgaben wieder in ihre 3-5 Hauptbestandteile zerlegen. Wenn's mal mehr werden ist's auch nicht so schlimm.
Irgendwann kommst Du dann ganz zwangsläufig bei den Elementaren Funktionen an, und dann machst Du einfach aus allem Quelltext und das Problem ist gelöst.

Ich selber hab das in der Konsequenz bisher auch nur einmal so diszipliniert durchgezogen. Damals musste in kürzester zeit ein Programm zur Berechnung von bearbeitungszeiten auf konventionellen (von Hand bedienten) Drehmaschinen erstellt werden. Das ganze fand in C bzw. ansatzweise C++ statt. Ich hatte damals lediglich eine alte Version von Borland Turbo-C++.
Für den Dialog mit dem Nutzer standen mir im Prinzip nur die dri Grundfunktionen Getch (Zeichen unsichtbar von der Tastatur holen) GotoXY (Bildschirmkursor positionieren) und TextOut (Ein oder mehrere Zeichen an der bestehenden Position auf dem bildschirm ausgeben) zur Verfügung. Es sollten aber durchaus moderne Editfelder für Text, Ganzzahen und Kommazahlen mit entsprechender Editiermöglichkeit einschließlich Taschenrechnerfunktion zur Verfügung stehen. Und natürlich Auswahlmenüs, ...
Also erst mal zum einen die Grundelemente fpür den Dialog bauen, also von unten her die Grundelemente bereitstellen, diese aber dann auch wieder von oben her entwickeln.
Und im Hauptteil von oben her das ganze komplette Programm als eine Sammlung von lauter Zetteln mit jeweils ein paar Zeilen Pseudoquelltext entwerfen, bis hinunter zu den einzelnen Eingabemsken und dem Zugriff auf die Grundelemente.
Und nach dem das fertig war, nur noch, wieder von oben her, aus dem gesamten Pseudoquelltext echten Quelltext machen. Am Ende ist dann mit minimalstem Aufwand ein ordentlich funktionierendes und auch recht kompfortabel zu bedienendes Programm rausgekommen. Der weg von der Aufgabenstellung hat dabei zwangsläufig zu einem fertigen Programm geführt. Es war aber immer an jedem Punkt auch die Denkdisziplin mit der Konzentration auf das augenblicklich wesentliche nötig.

Was die verschiedenen Bücher betrifft, ich sehe da im wesentlichen zwei als lesenswichtig an. Zum anderen den Ritchie (Die C-Programmiersprache), weil der auf verständliche Weise dahin führt, wie man aus einfachsten Anweisungen komplexe Aufgaben löst. Und das andere ist Die Buchreihe von Scott Meyers (Effektiv C++ Programmieren, Mehr effektiv C++ Programmieren...). Diese Bücher veremitteln ebennicht nur Programmiersprachenkenntnisse, sondern eine Anschauung, wie man sich den Dingen nähern kann.
Sicher ist für alle C++-Programmierer auch der Stroustupp Pflichtlektüre, denn wenn man schon mit einem Werkezug (Programmiersprache) arbeitet, sollte man etwas verstehen, was der Entwickler sich dabei gedacht hat.
Und ein bisschen mit DesignPattern sollte man sich auch beschäftigt haben.
Aber das wichtigte ist, nicht die Programmiersprache selbst ist das Ziel, sondern die zu lösende Aufgabe. Bei einer kleinen Programmiersprache wie C oder auch Fortran IV war es unumgänglich, alle Elemente zu beherrschen, aber bei einer so großen Sprache wie C++ gibt es immer mehrere Wege zum Ziel und es ist nicht zwingend erforderlich alle zu kennen. Aber ma muss alles das was man verwendet ausreichend perfekt kennen, und daran denken, dass bis auf ein paar wenige laufzeitkritische Stellen in den meisten Programmen Effizeienz der Abarbeitung die zweite Rolle spielt.
Viel wichtiger ist die Effizienz der Erstellung. Also im Zweifel die nicht so performante Lösung wählen, die man aber selber richtig verstanden hat und überblickt. Wenn man Realist ist, wird man einsehen, dass bei vielen für einen speziellen Einsatzzweck geschriebenen Programmen die Zeit die der Programmierer damit verbracht hat wesentlich größer ist als die, die der Nutzer damit verbringt. Bei meiner damaligen Abschlussarbeit habe ich noch nach jeder neuen Funtkion geguckt, wieviel die Exe damit gröäßer geworden ist und gegebenenfalls den Algo geändert wenns zu viel gekostet hat. Heute ist mir das (fast) völlig egal.
Damals habe ich im Rahmen meines INformatik-Zusatzstudiums beim Übertragen einer Grafik-Bibliothek aus einem Buch von Fortran nach C noch versucht Vorzeichenänderungen und Vorzeichentest bei Gleitkommazahlen durch Bitoperationen zu ersetzen. Mein damaliger 386SX war einfach zu langsam, und da ich damals arbeitslos war, war mir ein anderer zu teuer. Würde ich heute nicht mehr so machen. Falls es dem Anwender zu langsqam geht muss er eben aufrüsten. Meine Arbeitszeit ist einfach teuerer. Trotzdem hab e ich noch einen alten Laptop mit Windows-XP da stehen, der gerade mal 64 MByte Hauptspeicher hat. Und Programme, die ich für die Landwirte zum Rausgeben mache, die teste ich eben auch darauf, weil das ist das Maximum was ich voraussetzen kann.
Es kommt eben immer auf das jeweilige Ziel an.

Gruß Mümmel

Gregor

WizardsApprentice schrieb:

Ich studiere Chemie im Master

[...]

Und hier wären wir bei dem Punkt: Ich hätte mal den Reiz, etwas Anspruchsvolleres zu programmieren als z.B. nur switch-case-Taschenrechner oder Rechner für Kreisflächeninhalte ... aber mir fehlen einfach die passenden Ideen bzw. für komplexere Dinge werde ich mich wahrscheinlich mit meinen fortgeschrittenen Einstiegskenntnissen unwohl fühlen und mich verdrücken.

Hier ist eine riesige Herausforderung fuer Dich: Schreibe ein Programm, das Hartree-Fock Rechnungen oder weitergehende quantenchemische Methoden realisiert.

Mechanics

WizardsApprentice schrieb:

Im ersten Semester hatten wir damals im Fach Informatik neben HTML und CSS ein paar wenige Grundlagen in der Programmierung mit Visual Basic gelernt

Das hat jetzt eigentlich sehr wenig mit Informatik zu tun, Quick Sort und Algorithmen aber schon. Und wie andere schon geschrieben, muss und kann bei weitem nicht jeder Quick Sort erfinden, also musst du hier erstmal schauen, dass du nicht zu viel gleichzeitig versuchst.

WizardsApprentice schrieb:

Ich hätte mal den Reiz, etwas Anspruchsvolleres zu programmieren als z.B. nur switch-case-Taschenrechner oder Rechner für Kreisflächeninhalte ... aber mir fehlen einfach die passenden Ideen bzw. für komplexere Dinge werde ich mich wahrscheinlich mit meinen fortgeschrittenen Einstiegskenntnissen unwohl fühlen und mich verdrücken.

Mich haben Programme interessiert, die ich gesehen/gekannt habe. Ich hab mal bei jemandem Illustrator gesehen und wollte auch sowas machen. Ich konnte kaum programmieren, hab aber gleich angefangen, die einzelnen Funktionen umzusetzen, und das hat funktioniert. Weil man vieles tatsächlich auf die Reihe bekommt. z.B. Text an einer Kurve ausrichten. Wenn man in den Dokus des Frameworks (VCL damals und hauptsächlich die Offline Hilfe, Internet hatte ich nur in der Schule) stöbert, dann findet man was, wie man einzelne Zeichen zeichnen kann. Aber ich glaub, man konnte sie nicht rotieren. Also doch rumrecherchieren und dann das drunterliegende Framework finden, also GDI und dann findet man irgendwan raus, wie man den Text gedreht ausgeben könnte. Den Rest kann man austüfteln, also die Positionen und die Winkel der einzelnen Buchstaben ausrechnen, um den Text entlang der Kurve zu platzieren. Oder irgendwelche Effekte, wie Objekte zufällig übers Bild verteilen. Oder alle im Dokument verwendeten Fonts sammeln und mit in die Datei abspeichern oder die Namen speichern und dann beim Öffnen des Dokuments installieren oder ähnliche Fonts finden. Man kann sehr vieles austüfteln, wenns einem Spass macht, auch wenn man praktisch nichts von Informatik und Algorithmen versteht.
Später hab ich dann mehr von Informatik verstanden und mich haben dann andere Sachen interessiert, z.B. Datenbanken, und wie man Query Parser und Optimizer schreiben könnte. Aber im Endeffekt musste ich nie suchen, ich hatte immer viel mehr Ideen, was ich machen könnte, als ich freie Zeit hatte.

WizardsApprentice schrieb:

...

Sowas wie Quicksort und Topdown-Parser entwickelt keine Sau von sich aus. Man lernt sowas z.B. im Studium und wendet das Zeug dann an.

tntnet schrieb:

Es gibt Leute, die versuchen, C++ zu lernen, indem sie wie wild auf der Tastatur herum klimpern bis der Compiler das versteht. Das geht so nicht.

Du bist genau von der anderen Seite, der ein Buch nach dem anderen liest und hofft, dadurch die Erleuchtung zu finden. Auch das geht nicht.

Und wie so oft im Leben ist es der goldene Mittelweg. Solide Theorie und Kenntnis über die Syntax und Möglichkeiten erlangt man durch Bücher. Dann braucht man nicht so lange zu probieren, bis es geht. Aber die Kunst des Programmierens lernt man durch die Praxis. Also einfach mal machen.

Ich glaube, Du bist so weit, dass Du einfach mehr programmieren solltest. Haue in die Tasten und versuche mal, das gelernte theoretische Wissen zu verwenden.

Und wie Du sagst ist Programmieren tatsächlich ein sehr kreativer Vorgang. Und wie das bei vielen kreativen Prozessen so ist, hat der eine mehr und der andere weniger Zugang dazu. Aber auch wenn man weniger davon hat, kann man durchaus sehr viel erreichen, wenn man nur will.

Ist doch Quatsch. Ich halte es für sehr wahrscheinlich, dass die meisten Leute von sich aus nicht auf einen Quicksort gekommen werden - also jetzt ohne theoretischen Background und nur durch Übung/Praxis. Für die komplizierten Algorithmen die wir alle so täglich anwenden, gilt das erst recht - da steckt teilweise sehr viel Theorie drin.

Für Alltagsprobleme gilt das aber sicherlich nicht (z.B. fast alles was ich auf der Arbeit mache). Da reicht die Erfahrung + ein ordentlicher Programmierstil und die damit verbundenen Tugenden.