Die Flagge des Marasek

Dekostreifen

English

Aktuell Texte Der Comic Impressum Kalender Suche PHP-Klassen Container-Wizard main.s21

Kategorien

Buch
Computer
Computerspiele
Film
Geschichte
Gesellschaft
Idee
Kunst
Natur
Persönlich
Politik
Programmieren
Religion & Philosophie
Weblog
Weltpolitik
Weltsicht
{{login}}

Gelernt vs. beigebracht

Permalink
Vorheriger: KöstlichNächster: Früher war alles besser (1982)
Eingeordnet in: Programmieren, Weltsicht

In Are you a code monkey? geht Tony Marston auf die Frage ein, ob man beim Programmieren selbstständig denken kann oder hauptsächlich das nachahmt, wozu man mal dressiert wurde. Es ist ein lesenswerter Aufsatz; ich werde ihn im Hinterkopf behalten, wenn das nächste Mal wieder jemand mit Begriffen um sich wirft, die er mal gelernt hat.

Ein Punkt ist besonders interessant, weil sich darin meine eigene Erfahrung widerspiegelt: hat man etwas gelernt oder hat man es beigebracht bekommen?

Ich habe mir von den ersten Zeilen <html> bis hin zu diesem System alles selbst beigebracht. Natürlich habe ich Dokumentationen und Tutorials gelesen, aber es gab keinen Lehrmeister ausser mir selbst.
Ich habe die gefährliche Eigenschaft, ungeduldig zu sein und jedes Fitzelchen Wissen sofort zur Anwendung bringen zu wollen. Kaum hatte ich das PHP-Buch so weit wie bis zur Erläuterung des include-Statements gelesen, stand meine erste PHP-Seite: ich habe einfach die HTML-Dateien in PHP umbenannt und in jede Seite <? include("navigation.inc"); ?> anstelle der Navigation geschrieben.
Wenige Seiten später las ich dann von der Parameterübergabe per GET. Die nächste Version bestand also aus einer Seite mit include($_GET...); - ja, genau so, diese Lektion kam erst später. Ich arbeitete mich unter Fluchen in die Funktionsweise von mod_rewrite ein und fand es sehr fies, dass in den Dokumentationen jeder von "Regulären Ausdrücken" sprach, als wenn "Reguläre Ausdrücke" ein alltäglicher Begriff wie "Bügeleisen" wäre. Mit dem anwachsen meiner Linux-Kenntnisse erkannte ich, dass Regex so alltäglich ist wie ein Bügeleisen.
Damit war ich erst mal zufrieden. Ich wollte aber irgendwann mehr - ich denke, die lustigen Sprüche neben dem Counter, die per Zufall angezeigt werden sollten - also erlernte ich den Umgang mit Dateien, Arrays und Schleifen.
Mit der Zeit merkte ich, dass ich vieles wiederholte und oft C&P verwendete - gab es dazu nicht Funktionen? Also Funktionen.
In den grösseren Projekten merkte ich dann, dass ich immer wieder Werte von der einen Funktion an die andere übergeben oder mit globalen Variablen arbeiten musste. Gibt es dazu nicht Klassen, ist das nicht das, wo sich mehrere Funktionen Variablen teilen? Meine ersten Klassen entstanden, die letztlich kaum mehr waren als gruppierte Funktionen. Ich begann, bestimmte Programmbestandteile wirklich als Objekte aufzufassen und wie ein Werkstück zu bearbeiten. Daraus entstanden wirklich mächtige Klassen, ein Framework, dass es mir ermöglichte, in relativ kurzer Zeit komplexe Datenbankanwendungen aus dem Boden zu stampfen. Mein Weg im Bereich Datenbanken war etwas schneller - dort hatte ich mit Altlasten an Datenbanken zu tun, die schlecht normalisiert und nichtssagende Benennungen hatten. Meine daraus resultierende Frustration feuerte mich an, bessere Standards zu entwickeln.

Ich hatte diese Klassen, aber meine Schnittstellen waren mangelhaft. Vieles von dem, was ich programmierte, nahm irgendwelche Arrays an und gab ebensowelche zurück - man kann mit Fug und Recht behaupten, dass ich einen, äh, etwas perversen Hang zu assoziativen Arrays hatte. Zudem manipulierte ich regelmässig und ungeniert direkt die Klassenvariablen von aussen. Wehe mir, wenn ich die Klassen oder die Arrays veränderte! Der Begriff "Kapselung von Daten" traf mich wie ein Vorschlaghammer. Seither sind alle Klassenvariablen private oder protected und werden über Methoden angesprochen; und anstelle von Arrays gibt es Objekte.

Letzteren Zustand hätte ich schneller erreichen können, in dem ich entsprechende Vorlesungen und Kurse besucht hätte - aber dann hätte ich nur das wie und nicht das warum, nur das Ziel und nicht den Weg gekannt. Dadurch, dass ich die Zwischenschritte von "imperativer Programmierung" bis hin zu OOP kenne, weiss ich, was mir OOP erspart. Aber auch, dass sauberes OOP einen höheren Anfangsaufwand hat, der sich nicht immer lohnt. Manchmal kann es eben doch angebracht sein, die Regel zu brechen.

Genau das ist dann das Problem vieler Programmierer, die gleich mit hochentwickelten Sprachen und Konzepten eingestiegen sind: sie kennen nichts anderes.

Dies ist vielleicht ein generelles Problem der heutigen Zeit, dass das Wissen um die Herkunft verlorengeht. Ich war auf der Waldorfschule und wurde von Freunden ausgelacht, dass bei uns Schüler einen Rasen mit der Sense gemäht haben. Nur muss man keine 100 Jahre zurückgehen und man findet genau das. Das Bewusstsein darum, in einer Kette von Entwicklungen zu stehen, dass vor dem Sprint eben erst das Krabbeln, und vor dem Handy die Telegraphenleitung steht, ist kaum mehr vorhanden. Das ist sehr gefährlich.

Insofern kann ich nur jedem raten, seine eigenen Erfahrungen zu machen. Lernen, Fehler machen, hinfallen, aufstehen und den Fehler vermeiden. Und sich nie von irgendwelchen Schwätzern in Foren verunsichern lassen, aber auch immer die Bereitschaft behalten, was neues zu lernen - entweder, um es zu übernehmen oder um sich dann bewusst dagegen zu entscheiden.

Kommentieren

Bitte beachten: Kommentare sind nicht sofort sichtbar, sondern werden erst nach einer kurzen Prüfung freigegeben, sofern keine rechtliche Beanstandung vorliegt.
Rechtlich bedenkliche Inhalte werden entweder entschärft oder nicht veröffentlicht.

* Titel  
* Nickname  
* Kommentar