![[HaBo]](/styles/default/logoklein.png){kind=small}
Computeranfänger bevorzugen die Shell
- Themenstarter bad_alloc
- Beginndatum
bitmuncher
Senior-Nerd
Ich finde, dass dieser Artikel zum Teil seine Gültigkeit verloren hat. Sicherlich mag die Shell als Lernmittel immer noch recht brauchbar sein, aber die Zeiten, in denen man auf GUIs verzichten kann, sind mittlerweile fast vorbei. Ein Entwickler, der ohne IDE arbeitet, ist zumeist weniger effektiv in seiner Arbeit als einer, der die gleichen Skills hat, aber eine IDE zur Source-Verwaltung nutzt. Genauso sieht es auch in der Administration von Rechnern aus. Mittlerweile gibt es für viele Zwecke ausgefeilte GUIs, die einem jede Menge Befehls-Getippe ersparen und die Gefahr von Tippfehlern in Konfigurationen u.ä. minimieren. Gerade für Programmierer kommt dann noch hinzu, dass sie viele Konzepte der GUIs ohne diese garnicht oder nur ansatzweise verstehen könnten. Und genau das fehlt mir in diesem Artikel... der Hinweis darauf, dass GUIs immer mehr ein unverzichtbares Mittel sind und dass es ein typischer Fehler von Entwicklern ist in "Konsolen-Strukturen" zu denken, wodurch die Möglichkeiten der GUIs nicht ausgenutzt werden. Mir ist das auch erst kürzlich bewusst geworden, als ich die Oberfläche von MacOSX näher kennenlernte. Der Benutzer muss da z.B. garnicht mehr wissen wo eine Datei liegt. Es spielt zumeist sogar nichtmal eine Rolle welches Format sie hat, da Programm-Zuordnungen effektiv genutzt werden und der Zugriff auf Datenverzeichnisse soweit abstrahiert wurde, dass der genaue Ort des Verzeichnisses garkeine Rolle mehr spielt.
Die Shell sehe ich daher mittlerweile nur noch als ein gutes Mittel um den Umgang mit Automatisierung bei Computern zu erlernen. Den Umgang mit Computern lernt man damit aber heutzutage nicht mehr vollständig. Man lernt quasi "nur" die tieferen Ebenen kennen und dass ist normalweise das, was vor dem Benutzer verborgen bleiben sollte. Computer sind schliesslich Werkzeuge und bei einer Kreissäge lerne ich schliesslich auch nicht erstmal, wie es in ihrem inneren aussieht, bevor ich sie benutzen kann. Für (System)Spezialisten wird die Shell sicherlich weiterhin als Lern- und Arbeitsmittel vorerst unverzichtbar bleiben, aber den Umgang mit Computern erlernt man damit nicht mehr.
Das passende Zitat dazu:
User zum Admin: Kannst du mir beibringen, wie ich einen Computer benutze?
Admin zum User: Nein, ich benutze Computer nicht, ich repariere sie und richte sie ein.
Oder anders gesagt: Während Admins noch mit ihrem Computer das "Frage-Antwort-Spiel" spielen, weiss der Otto-Normal-User zumeist nichtmal, welche Fragen er dem Computer stellen soll.
Die Shell sehe ich daher mittlerweile nur noch als ein gutes Mittel um den Umgang mit Automatisierung bei Computern zu erlernen. Den Umgang mit Computern lernt man damit aber heutzutage nicht mehr vollständig. Man lernt quasi "nur" die tieferen Ebenen kennen und dass ist normalweise das, was vor dem Benutzer verborgen bleiben sollte. Computer sind schliesslich Werkzeuge und bei einer Kreissäge lerne ich schliesslich auch nicht erstmal, wie es in ihrem inneren aussieht, bevor ich sie benutzen kann. Für (System)Spezialisten wird die Shell sicherlich weiterhin als Lern- und Arbeitsmittel vorerst unverzichtbar bleiben, aber den Umgang mit Computern erlernt man damit nicht mehr.
Das passende Zitat dazu:
User zum Admin: Kannst du mir beibringen, wie ich einen Computer benutze?
Admin zum User: Nein, ich benutze Computer nicht, ich repariere sie und richte sie ein.
Oder anders gesagt: Während Admins noch mit ihrem Computer das "Frage-Antwort-Spiel" spielen, weiss der Otto-Normal-User zumeist nichtmal, welche Fragen er dem Computer stellen soll.
Das wage ich mal zumindest im Bezug auf Lisp anzuzweifeln: Mit Emacs und SLIME hat man eine gute IDE im Textmodus. Aber bei anderen Sprachen, wie C++ hat eine IDE wie Visual Studio ganz klar die Nase vorn.
Warum soll dem User etwas verborgen bleiben? Wenn er z.B das Konzept der Befehlseingabe auf der Shell versteht, wird er auch besser mit GUIs umgehen können, da die Konzepte ja ähnlich sind, nur die Bedienung nicht. Der Autor des Artikels wollte ja absoluten Neulingen die Grundlagen des Computers zeigen, wofür die Shell ja wirklich besser ist. Die Anwendung ist ganz was anderes, wie du schon sagst.
Zum Beispiel der Kreissäge: Es ist zwar gut sie benutzen zu können, aber spätestens wenn du das Sägeblatt oder eine Sicherung austauschen musst wird es Zeit sich genauer mit der Maschine auseinanderzusetzen.
Leider ja. Da fordert der Artikel ja eine Starthilfe auf, die die wichtigsten Kommandos auflistet. HELP von der CMD wäre dar ein gutes Beispiel für.
bitmuncher
Senior-Nerd
Das Problem ist meiner Meinung nach ja gerade, dass bei den meisten Systemen die Konzepte von GUI und Konsole ähnlich sind. Würde man diese "Grenze" endlich mal durchbrechen, würden GUIs völlig neue Möglichkeiten bieten. Entwickler sind aber zumeist zu sehr auf das "Konsolen-Denken" eingeschossen, weil sie es eben so gelernt haben.
Und wenn ich mal ein Sägeblatt austauschen will, muss ich auch nur wissen, welchen Knopf ich drücken muss, damit ich es rausnehmen kann. Wie die Aufhängung des Blattes funktioniert und wie diese mit dem Motor verbunden ist, spielt dann keine Rolle mehr. Das ist ein Punkt, den man eher in die Entwicklung von Software einfliessen lassen sollte. Unter Linux, *BSD oder Windows muss ich z.B. wissen mit welchen Tools ich meine Hardware auf Fehler prüfen kann. Bei einem Mac muss ich nur wissen, wie ich den Test starten kann bzw. welchen Knopf ich beim Starten drücken muss.
Es ist daher eher ein Fehler der GUIs, dass sie sich an der Konsole orientieren und nicht unbedingt ein Indiz dafür, dass eine Konsole notwendig ist.
Dass es schwierig ist daraus auszubrechen, will ich aber nicht abstreiten. Als Programmierer schreibt man nunmal Bibliotheken, deren Funktionalität man meist mit kleinen Konsolen-Tools testet und genau diese Denkweise bei der Entwicklung der Testtools, wird dann auch auf die GUI-Entwicklung angewendet. Dadurch wird die Bedienung der Software für Laien zumeist nicht mehr sonderlich intuitiv. Wie intuitive GUIs aussehen können, kennen die Entwickler aber eigentlich aus ihrem Leben, wenn sie schon jemals versucht haben jemandem den Umgang mit einem System zu erklären. Da werden dann Beispiele angebracht wie z.B.: "Ein Ordner ist wie ein Behälter und Dateien sind Objekte, die man in diesen Behälter reinlegen kann." Anstatt dies aber grafisch umzusetzen, bilden die Entwickler Ordner-Strukturen in Bäumen ab. Der User öffnet also nicht einen Behälter, er "geht in einen Ordner". Und dazu lassen sich etliche weitere Beispiele finden.
Die Frage für mich ist daher eher: Wie sinnvoll ist es tatsächlich, Leuten, die später GUIs entwickeln, das Konsolen-Denken einzutrichtern? Damit geht eine Menge Potential verloren.
Und wenn ich mal ein Sägeblatt austauschen will, muss ich auch nur wissen, welchen Knopf ich drücken muss, damit ich es rausnehmen kann. Wie die Aufhängung des Blattes funktioniert und wie diese mit dem Motor verbunden ist, spielt dann keine Rolle mehr. Das ist ein Punkt, den man eher in die Entwicklung von Software einfliessen lassen sollte. Unter Linux, *BSD oder Windows muss ich z.B. wissen mit welchen Tools ich meine Hardware auf Fehler prüfen kann. Bei einem Mac muss ich nur wissen, wie ich den Test starten kann bzw. welchen Knopf ich beim Starten drücken muss.
Es ist daher eher ein Fehler der GUIs, dass sie sich an der Konsole orientieren und nicht unbedingt ein Indiz dafür, dass eine Konsole notwendig ist.
Dass es schwierig ist daraus auszubrechen, will ich aber nicht abstreiten. Als Programmierer schreibt man nunmal Bibliotheken, deren Funktionalität man meist mit kleinen Konsolen-Tools testet und genau diese Denkweise bei der Entwicklung der Testtools, wird dann auch auf die GUI-Entwicklung angewendet. Dadurch wird die Bedienung der Software für Laien zumeist nicht mehr sonderlich intuitiv. Wie intuitive GUIs aussehen können, kennen die Entwickler aber eigentlich aus ihrem Leben, wenn sie schon jemals versucht haben jemandem den Umgang mit einem System zu erklären. Da werden dann Beispiele angebracht wie z.B.: "Ein Ordner ist wie ein Behälter und Dateien sind Objekte, die man in diesen Behälter reinlegen kann." Anstatt dies aber grafisch umzusetzen, bilden die Entwickler Ordner-Strukturen in Bäumen ab. Der User öffnet also nicht einen Behälter, er "geht in einen Ordner". Und dazu lassen sich etliche weitere Beispiele finden.
Die Frage für mich ist daher eher: Wie sinnvoll ist es tatsächlich, Leuten, die später GUIs entwickeln, das Konsolen-Denken einzutrichtern? Damit geht eine Menge Potential verloren.
Wie kann ein GUI aus der Konsolenwelt ausbrechen? Unter unixoiden Systemen z.B. ist die grafische Oberfläche ja nur eine Abstraktionsebene für die Konsole. GUIs geben ja nicht das """wahre Wesen""" eines Computers wieder: Er verwandelt einen Input über eine Verrechnung im Prozessor in einen Output. Auf einer Konsole ist das alles in einer für ihn lesbaren Form abgelaufen, kommt jedoch die GUI ins spiel, so muss umständlich übersetzt werden. Die GUI ist also nur der Versuch des Menschen die Bedienung zu vereinfachen und dabei stülpt er der Konsole eben bunte Buttons über. dadurch entfremden wir den Rechner von seinem Grundprinzip.
Man müsste schon die Rechner von Grund auf zu einer grafische Oberfläche hin entwickeln.
Es ist sehr sinnvoll, da einem einfach viel erspart bleibt: Wenn ich ein Programm schreiben will, dass Daten filtert reicht eine Textoberfläche, die die Daten einliest und ausgibt. Eine GUI drumherum fände ich zu diesem Zweck unnötig, wenn man da 50% der Zeit dran baut, bis sie gut bedienbar ist.
Außerdem sollten sich Anfänger auf basischen konzentrieren können, ohne dauernd über die grafische zu stolpern. Imho ist es wichtiger grundlegende Dateioperationen zu verstehen, als irgendwelche .NET Abstraktionen, die nur auf einer Plattform laufen, während die grundlegenden Konzepte beschränkt auf alle übertragbar sind.
bitmuncher
Senior-Nerd
Auch unixoide Systeme müssen ihre GUI nicht an der Konsole ausrichten. Bei Mac liegt z.B. auch ein Unix zugrunde. Die haben zwar das Prinzip der Ordner auch noch nicht ausgeblendet, aber wo sich Ordner oder Dateien befinden und mit welchen Programmen ich diese ansprechen muss, musste ich bisher nur auf der Konsole wissen. In der GUI muss man sich dank Spotlight darüber keine Gedanken mehr machen. Die Konsole wurde sogar soweit abstrahiert, dass ich ein Programm einfach via Drag&Drop in das Terminalfenster packe und hinterher die Datei, mit der das Programm arbeiten soll und schon werden die Pfadangaben automatisch eingefügt. Windows hat dieses Konzept ja auch bereits aufgenommen mit seiner Suchfunktion. Und selbst für Linux gibt es z.B. 3D-Dateimanager, die das Prinzip der Ordner vollständig verbergen und diese als Behälter darstellen. Entsprechende Bibliotheken können die Entwicklung dafür fast genauso einfach machen wie ncurses- oder termcap-basierte Ausgaben auf der Konsole. Diverse Indexing-Tools versuchen bereits die Lücken von Spotlight&Co. zu schliessen, aber sie sind einfach noch nicht ausreichend in die GUIs integriert und die Oberflächen ansich sind immernoch sehr inkonsistent. Neue Konzepte wie der Java-3D-Desktop (lg3d) versagten ja bisher nicht am User-Zuspruch sondern an mangelnder Weiterentwicklung.
Ich bin jedenfalls der Meinung, dass dieses unixoide Denken nicht der Weisheit letzter Schluss ist und dass ein Umdenken dafür sorgen könnte, dass sowohl die Arbeit mit der Konsole für Profis als auch die Arbeit mit der GUI für Laien einfacher und effektiver wird. Der Profi kann tatsächlich kaum auf ein Terminal verzichten, solange sich die Systeme darunter nicht ändern. Dem Laien können anständige GUIs aber eine Menge Arbeit abnehmen und auch für Profis können sie die Arbeit zumindest vereinfachen. Dafür müsste man aber mal weg vom Altbewährten und neue Ansätze konsequenter verfolgen, als es bisher der Fall war. Das wiederum ist (leider) teuer und da sehe ich auch eher den Grund, dass es bisher nicht gemacht wurde, als darin, dass es halt nicht anders geht.
Ich bin jedenfalls der Meinung, dass dieses unixoide Denken nicht der Weisheit letzter Schluss ist und dass ein Umdenken dafür sorgen könnte, dass sowohl die Arbeit mit der Konsole für Profis als auch die Arbeit mit der GUI für Laien einfacher und effektiver wird. Der Profi kann tatsächlich kaum auf ein Terminal verzichten, solange sich die Systeme darunter nicht ändern. Dem Laien können anständige GUIs aber eine Menge Arbeit abnehmen und auch für Profis können sie die Arbeit zumindest vereinfachen. Dafür müsste man aber mal weg vom Altbewährten und neue Ansätze konsequenter verfolgen, als es bisher der Fall war. Das wiederum ist (leider) teuer und da sehe ich auch eher den Grund, dass es bisher nicht gemacht wurde, als darin, dass es halt nicht anders geht.
Der Artikel betrifft wohl auch wirklich nur Endbenutzer. Und ein Endbenutzer MUSS heute nicht mehr wissen,
wie ein Computer arbeitet. Mein kleiner Neffe von 11 Jahren kann sein Windows Vista besser bedienen als ich.
Das ist fuer seine Zwecke auch optimal. Aber "auskennen" tut er sich mit Computern nicht. Genausowenig wie die allermeisten der normalen User: Sie kennen sich mit Computern _nicht_ aus. Sie bedienen sie lediglich.
Und das verstehen von Computern wird heutzutage immer weniger noetig- fuer einen Enduser. Fuer "uns" Techniker und Admins wird es lediglich komplizierter. Es muss immer die Leute geben die den teilweise echten (komfortablen) schrott managen muessen.
Ich als Admin zumindest kann auf Konsole nicht verzichten. Weder bei BSD- noch bei Windows. Dafuer ist das Konsolenscripting viel zu wichtig. Und manche Configs (IIS, EXchange) sind viel zu komplex, um sie in GUIs zu stopfen.
wie ein Computer arbeitet. Mein kleiner Neffe von 11 Jahren kann sein Windows Vista besser bedienen als ich.
Das ist fuer seine Zwecke auch optimal. Aber "auskennen" tut er sich mit Computern nicht. Genausowenig wie die allermeisten der normalen User: Sie kennen sich mit Computern _nicht_ aus. Sie bedienen sie lediglich.
Und das verstehen von Computern wird heutzutage immer weniger noetig- fuer einen Enduser. Fuer "uns" Techniker und Admins wird es lediglich komplizierter. Es muss immer die Leute geben die den teilweise echten (komfortablen) schrott managen muessen.
Ich als Admin zumindest kann auf Konsole nicht verzichten. Weder bei BSD- noch bei Windows. Dafuer ist das Konsolenscripting viel zu wichtig. Und manche Configs (IIS, EXchange) sind viel zu komplex, um sie in GUIs zu stopfen.