Visual Studio Magazine - Guest Opinion - Save the Hobbyist Programmer
Ein schon älterer, aber interessanter Artikel der auf ein wichtiges Problem hinweist: Hobby-Programmierer werden immer mehr ausgeschlossen aus der Erstellung von kleinen Hacks und einfachen Lösungen durch die immer komplexeren Systeminterfaces und ständigen Wechsel von APIs und Programmierwerkzeugen in der Windows Welt. Und das ist nicht nur die Windows Welt, die davon betroffen ist. Linux und OS X leiden teilweise genauso darunter.
Klar, es gibt immer noch kleine Helfer mit einfacher Programmiermöglichkeit. Oder Scriptsprachen, die leicht zu lernen und zu benutzen sind - z.B. Python. Aber das ist nicht wirklich eine Lösung für diese Bastler. Was für Hobby-Bastler früher das omnipräsente Basic war, oder zum Beispiel die - wenn auch kranke - Sprache in DBase, das fehlt heute. Kaum noch eine Programmierumgebung die nicht ohne Objektorientierten Ansatz daher kommt. Kaum noch Lösungsansätze die nicht versuchen gleich eine allgemeine Entwicklungsumgebung für komplette Programme zu sein.
Nette Ausnahmen gibts noch - FileMaker auf dem Mac versucht immer noch den Hobby-Hacker anzusprechen. Aber es stimmt trotzdem: die einfachen Einstiege werden weniger.
Selbst AppleScript ist auf dem Mac mitlerweile dermaßen komplex und überfüllt worden, das es kaum noch einem Seiteneinsteiger möglich ist damit gleich mal loszulegen. Einige Ecken von AppleScript sind selbst für alte Programmierhasen wie mich obskur und kompliziert. Dazu kommt natürlich, das es für die ganzen Scriptsprachen zwar viele tolle Möglichkeiten der Integration von Anwendungen gibt - aber gerade diese Teile ausgesprochen mies dokumentiert sind.
Um beim Beispiel AppleScript zu bleiben: zwar gibt es die Anwendungsdictionaries, in denen die AppleScript-Fähigkeit eines Programms dokumentiert wird, aber nahezu alle dort abgelegten Beschreibungen die ich bisher gelesen habe gingen davon aus, das der Nutzer schon komplettes und weitgehendes Wissen über AppleScript und die AppleScript-Strukturen hat (was sind Objekte in AppleScript, wie arbeitet man mit Containern etc.). Obwohl also diese Dictionaries genau dem Hobby-Programmierer als Startpunkt dienen könnten, werden sie von den Erstellern (und das sind die Profi-Programmierer in den Softwarehäusern) so gestaltet, das oftmals sogar nur sie selber damit was anfangen können.
Ähnlich in der Linux-Welt. TCL war mal die Standardscriptsprache für den einfachen Einstieg mit simpler Struktur, geradezu primitivster Erweiterungsschnittstelle und der Möglichkeit selbst für Nicht-Programmierer schnell zu Lösungen zu kommen. Heute besteht TCL in der Standardauslieferung (die dann netterweise oft Batteries-Included heisst - nur dummerweise fehlt die verständliche Anleitung) schon aus Bergen von Paketen, von denen eine ganze Reihe sich mit Metasprachenaspekten beschäftigen (z.B. incrTCL und den darauf und auf TK aufbauenden Widget-Libraries - herrjeh, allein in diesem kurzen Hinweis auf den Inhalt sind mehr für einen Einsteiger unverständliche Wörter drin als Füllwörter), die ein Einsteiger nie kapieren wird.
Und auf die desolate Situation unter Windows mit dem Scripting-Host und den OLE Automation Schnittstellen (oder wie auch immer die Dinger heute heissen werden) brauche ich garnicht eingehen - wer da einmal einen Versionswechsel einer Anwendung mitgemacht hat und seine komplette Lösung komplett neu schreiben durfte dank des totalen Wechsels des Scripting-Modells von zum Beispiel Access, der weiss wovon ich rede.
Letzten Endes nehmen wir (wir == professionelle Programmierer) damit den Endanwendern ein Stück Freiheit weg - die Freiheit rumzuspielen und ja, auch die Freiheit sich selbst in den Fuss zu schiessen. Und ich denke, das gerade in der Welt der freien Software die Programmierer anfangen sollten hieran wieder mal ein paar Gedanken zu verschwenden. Es ist ja nett, das nahezu jedes grössere Programm irgendeine Scripting-Sprache einbettet. Aber weniger nett ist, das nahezu garkeine dieser Einbettungen eine vernünftige Dokumentation ihrer Möglichkeiten hat und nur primitivste Beispiel sowie Komplettlösungen sehr komplexer Anwendungen als Startpunkt fürs Lernen da sind. Gerade Hobby-Programmierer lernen nun mal am einfachsten durch das Lesen vorhandener Tools. Und ja, auch ich bin da nicht unbedingt ein gutes Beispiel, denn der Python Desktop Server hat zwar eine Reihe von Erweiterbarkeiten, die auch gerade für Endanwender gedacht sind - aber auch ich hab da viel zu wenig Dokumentation geschrieben. Irgendwie schade, denn so werden viele Projekte zu inzestuösen Veranstaltungen, weil die eigentlichen Endanwender aussen vor bleiben. Nein, eine echte Lösung hab ich keine - denn gerade bei freien Projekten ist nunmal die Dokumentationserstellung ein oftmals nerviger und unbeliebter Anteil des Projektes und wird deshalb stiefmütterlich behandelt. Ausserdem sind die meisten Programmierer sowieso nicht in der Lage allgemeinverständliche Dokumentationen zu erstellen. Vielleicht ist das aber auch eine Chance für Projekte, die versuchen die Aktivität in Grossprojekten der Open Source Gemeinschaft auf bisher geringer beteiligt sind. Mir fällt da spontan debian-women ein (da Jutta sich damit derzeit beschäftigt). Denn einer stärkeren Beteiligung von Frauen wäre sicherlich auch Dokumentation und Information die nicht unbedingt einen vollausgebildeten Master-Hacker voraussetzt hilfreich. Schliesslich hat nicht jeder Mensch Lust sein ganzes Leben auf das Lernen von immer neuen APIs und Tools zu verwenden ... Hier gibts den Originalartikel.
