die Frage ist, wo grenzt man "programmieren" (als handwerkliche Tätigkeit) von Softwaredesign und Architekturfragen ab.
Auf die frühzeitig die Antwort zu erarbeiten ist, ja. Weil es entscheidend ist, ob ich Architekt oder Bauingenieur werden will. Als Software-Architekt muss ich natürlich solide Kenntnisse über die Materialien und Werkzeuge des Programmierens haben, aber ich muss nicht wissen (und schon gar nicht aus dem FF), wie alles handwerklich umzusetzen ist. Als Programmierer wiederum muss mich das große Ganze nicht so interessieren sondern die (je nach Schwerpunkt) optimale Implementation.
Interessant, das als kurzen Abstecher, finde ich übrigens die Frage der Programmiersprache. Architekten sind diesbezüglich oft ignorant und oberflächlich, während Programmierer dazu neigen, alles mit "ihrer Sprache" machen zu wollen. Genau das - und die wirre Annahme, Programmierer könnten natürlich auch Architektur - dürfte aber eine der wesentlichsten Quellen für Probleme sein.
Da wird zum Beispiel großzügig ignoriert, dass C, ein absolut wunderbares Werkzeug für Arbeiten nah an der Hardware, zugleich eine zuverlässige Quelle für Probleme und übrigens auch krasse Ineffizienz bei vielem anderen ist. Andererseits meinen Ada-Leute allen Ernstes, man könne mit Ada (zumal moderneren Versionen, z.B. 2005) auch nah an der Hardware arbeiten; und das obwohl Ada von Anfang an sogar eine recht brauchbare und bequeme Schnittstelle zu C bietet. Oder man denke an die Horden von java-Jüngern, die, grob gesagt, noch nicht mal den raison d'etre und die Limits ihres Spielzeugs begriffen haben.
Ein anderes Problem liegt in der Untugend, ohne Verstand als allgemeingültig nachzuplappern und zu propagieren, was man gestern bei Google oder fatzebuk als hype-Weisheit aufgeschnappt hat. Beispiel: Ein guter Programmierer kann etliche Sprachen (impliziert: brauchbar gut) und wählt für ein Projekt die am besten geeignete aus. Papperlapp! Die Realität sieht anders aus, sehr anders. Und das wird noch erheblich verstärkt durch tool-hype und vorhandene "Produktionsstraßen" in größeren Firmen.
Dabei wird auch übersehen, was ich persönlich geradezu als Reife-Merkmal bei Studenten sehe: Ein(ig)e Sprachen rundweg abzulehnen oder gar zu hassen - und zwar konsistent und wohl begründet.
Im Endergebnis würde ich heute folgende Grundregeln im Sinne einer guten Grundausrüstung mit auf den Weg geben:
- C. Nicht perfekt, nicht mal unbedingt gut, aber verdammt gut genug, um Sourcen lesen und lokal verstehen zu können.
- Eine streng und statisch typisierte imperative (optional und bevorzugt (aber *nicht* nur) OO) Sprache. Diese gut durchkauen und verdauen und üben und das bis zum Ende, bis zu einem guten Reifegrad.
- Eine funktionale Sprache. Darf auch eine nicht ganz reine sein, Ocaml z.B. Muss man einfach mal gesehen und ausprobiert und konzeptionell geistig durchdrungen haben.
- Python. Als Alltagswerkzeug. Als Werkzeug zum Schaffen von kleineren oder momentan gebrauchten Werkzeugen. Aber auch aus Zen Gründen.
- FreePascal. Vielleicht bis hinten, bis zur Expertise, aber allemal bis zu "kann ich ordentlich und brauchbar effizient nutzen". Kann auch Punkt 2 ersetzen.
@ninti
Schau dir mal deine Fragen an. Und dann leg deine Ausführungen zu Themen, in denen du noch Schüler und Theoretiker bist daneben. Ich traue dir zu, meine Anmerkung von gestern dann zu verstehen.