Zukunft der Programmierung

[marcel b.]

Hallo,

ich bin mal wieder auf der Suche nach einer interessanten Programmiersprache, um einfach mal auszuprobieren, was es sonst noch so gibt. Ich bin jetzt auf Python gestoßen, da im Moment auch ein "For Kids"-Buch stark beworben wird. Ich halte das zwar nicht für sonderlich gelungen, aber ganz interessant.

Wie auch immer. In mir stieg die Frage hoch, wie es wohl mit den Computern und den Programmen so weiter gehen wird.

Seid ihr auch der Meinung, dass in Zukunft immer mehr Programmen "nur noch" im Browser ablaufen werden und Techniken wie AJAX für Endanwenderprogramme die Oberhand bekommen werden? Sprachen wie Java, C/C++ etc. werden nur von "wenigen" Profis entwickelt um das "Frontend" AJAX oä. zu bedienen? So könnte man von jedem Computer (Job-Workstation, daheim-Computer, unterwegs-Handheld) auf die immer gleichen Dateien zugreifen und damit arbeiten. Bei den aktuellen erscheinenden miniPCs a la eeePC sollte das fast nichts großes mehr sein.

Aber wie sieht das dann mit der Datensicherheit aus? Ist es beispielsweise sicher seine Steuererklärung in einer Online-Anwendung zu machen?

Ich frage einfach deshalb, weil ich Systembetreuer und Informatiklehrer bin und die Probleme sowohl von den Kollegen ("wie geht denn das?", "Früher war alles einfacher", "Kann ich meine ppt für den Unterricht nicht auch von zu Hause auf den Schulserver legen?") als auch von den Schülern kenne, die zum Einen auf das Medium Internet vorbereitet werden sollen und zum Anderen Programmieren etc. (daher Pyhton) lernen sollen.

Wie wird die Zukunft sein? Auf was bereitet ihr euch vor die jeden Tag mit Kunden umgehen müssen? Was erwarten diese?

Es wäre schön ein paar interessante, anregende, kritische, konstruktive Antworten zu bekommen.

marcel

[Marc Reichelt]

Hallo Marcel,

Wie auch immer. In mir stieg die Frage hoch, wie es wohl mit den Computern und den Programmen so weiter gehen wird.

Seid ihr auch der Meinung, dass in Zukunft immer mehr Programmen "nur noch" im Browser ablaufen werden und Techniken wie AJAX für Endanwenderprogramme die Oberhand bekommen werden? Sprachen wie Java, C/C++ etc. werden nur von "wenigen" Profis entwickelt um das "Frontend" AJAX oä. zu bedienen? So könnte man von jedem Computer (Job-Workstation, daheim-Computer, unterwegs-Handheld) auf die immer gleichen Dateien zugreifen und damit arbeiten. Bei den aktuellen erscheinenden miniPCs a la eeePC sollte das fast nichts großes mehr sein.

Jede Programmiersprache belegt normalerweise eine bestimmte Nische auf dem Markt.
Wird die Nische zu klein oder andere Sprachen zu stark, so "stirbt" eine Programmiersprache.
Frei werdende Plätze werden von neuen Programmiersprachen eingenommen.
So war es immer, und so wird es immer sein.

C/C++ und Java werden heute noch von vielen Programmierern benutzt, obwohl sie schon länger totgesagt wurden - sie werden sich noch eine ganze Weile halten, weil neue Konzepte (Boost bei C++, Generics etc. bei Java) Einzug erhalten und die Sprachen (bzw. die Bibliotheken) so auch immer modernisiert werden.

Aber wie sieht das dann mit der Datensicherheit aus? Ist es beispielsweise sicher seine Steuererklärung in einer Online-Anwendung zu machen?

Sicherheit ist kein Zustand, sondern ein Prozess.
Und oft scheitert das Einsetzen von Sicherheit an mangelnder Kenntnis des Anwenders, und nicht ausschließlich unsicherer Programmierung.

Ich frage einfach deshalb, weil ich Systembetreuer und Informatiklehrer bin und die Probleme sowohl von den Kollegen ("wie geht denn das?", "Früher war alles einfacher", "Kann ich meine ppt für den Unterricht nicht auch von zu Hause auf den Schulserver legen?") als auch von den Schülern kenne, die zum Einen auf das Medium Internet vorbereitet werden sollen und zum Anderen Programmieren etc. (daher Pyhton) lernen sollen.

Wie wird die Zukunft sein? Auf was bereitet ihr euch vor die jeden Tag mit Kunden umgehen müssen? Was erwarten diese?

Kunden erwarten von Informatikern insbesondere Flexibilität.
Das Konzept von Programmiersprachen ist ja nicht neu - jede neue Programmiersprache ist mehr oder weniger ähnlich zu denen, die ein Informatiker bisher gelernt hat.

Es wäre schön ein paar interessante, anregende, kritische, konstruktive Antworten zu bekommen.

Ich weiß nicht genau worauf du hinauswillst.
Willst du wissen, welche Programmiersprache in der Zukunft häufiger verwendet werden wird?

IMHO könnte D einen Fortschritt darstellen von C/C++ hin zu einer einfacheren Variante, die sowohl maschinenorientiertes Programmieren (inkl. Pointern) als auch objektorientiertes Programmierung (inkl. Garbage Collector) erlaubt.
Java, Python, PHP, Ruby und überwiegend in der Windows-Welt C# sind zur Zeit "à la mode", C und C++ sind die Klassiker.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Tom]

Hello,

Jede Programmiersprache belegt normalerweise eine bestimmte Nische auf dem Markt.
Wird die Nische zu klein oder andere Sprachen zu stark, so "stirbt" eine Programmiersprache.

Das Überleben oder Wachsen hat aber auch nicht unbedingt mit der Qualität der Sprache zu tun, sondern eventuell nur mit der Marktmacht, mit der sie vorangetrieben wird. In Falle von C hat sich das dann wohl mal irgendwann selbstständig gemacht.

Ich erinnere mich aber noch gut an die Zeiten, in denen die Frage gestellt wurde, ob man lieber das "sichere" Pascal mit seinen Derivaten (Turbo-Pascal, Modula2, Delphi, ...) lernen solle, oder das eigentlich "vollkommen unsichere" C oder C++.

Vergessen worden ist dabei sicherlich auch der Nymbus, den für Andere Unverständliches ausübt. C hat sich mMn deshalb so schnell durchgesetzt, weil es einfach "für Insider" gemacht war und andere Menschen damit leicht auszugrenzen waren.

Das hat sich mit C++, C-Sharp, Java, aber auch Perl und anderen Sprachen keinesfalls verbessert.

Diw optimale Programmiersprache ist mMn noch nicht definiert worden. Vielleicht fehlt aber auch einfach das optimale Prozessorsystem dafür. Ansätze, Java bereits in die Prozessoren "einzubauen", waren ja schon da.

Ein harzliches Glückauf

Tom vom Berg

[Der Martin]

Hallo Marcel,

ich erlaube mir, dein Posting etwas umzukrempeln. ;-)

Ich frage einfach deshalb, weil ich Systembetreuer und Informatiklehrer bin ...

Das erscheint mir nämlich eine wichtige Zusatzinformation zu sein, die ich ganz vorne an stellen wollte.

Seid ihr auch der Meinung, dass in Zukunft immer mehr Programmen "nur noch" im Browser ablaufen werden ...

Nein.

und Techniken wie AJAX für Endanwenderprogramme die Oberhand bekommen werden?

Nein.

Sprachen wie Java, C/C++ etc. werden nur von "wenigen" Profis entwickelt

Das ist ja heute schon so.

Ich sehe da drei Hauptrichtungen, die sich IMHO auch in den nächsten Jahren so behaupten werden.
Da wäre zunächst mal der Embedded-Bereich. Immer mehr Geräte des täglichen Gebrauchs enthalten heutzutage Microprofessoren, um die Fülle an Funktionen zu realisieren. Die müssen natürlich auch programmiert werden, und ich bin überzeugt, dass sich in diesem Bereich sogar Assembler noch auf Jahre behaupten kann.
Am anderen Ende der Komplexitätsskala hätten wir den Bereich der vernetzten und verteilten Anwendungen, wozu ich auch typische Webapplikationen zähle. Die werden wahrscheinlich in einigen Anwendungsgebieten noch zunehmen, aber letztendlich die bisher üblichen, rechner-lokalen Anwendungen nicht ersetzen, höchstens ergänzen.
Und schließlich noch den Bereich der klassischen Desktop-Anwendungen. Hier kann ich mir eine Vermischung mit dem Web vorstellen, letztendlich braucht man aber immer wieder auch "native Applications", die auch auf isolierten Rechnern laufen. Hier denke ich, dass auch noch in einigen Jahren "solide" Programming Skills in C/C++ gefragt sind, aber auch Alternativen wie Java sehe ich hier durchaus als realistische Möglichkeit. Bei Handies und PDAs hat sich Java schon jetzt eine Nische erobert.

Aber wie sieht das dann mit der Datensicherheit aus? Ist es beispielsweise sicher seine Steuererklärung in einer Online-Anwendung zu machen?

Die Datensicherheit ist eine Sache, die man bedenken muss. Natürlich möchte ich nicht all meine Daten in der Weltgeschichte hin- und herschicken.
Aber mindestens genauso wichtig ist mir die Zuverlässigkeit. Das bedeutet für mich aber auch, dass ich so wenig Unwägbarkeiten wie nur möglich in die Hände von anderen legen möchte, von denen ich dann abhängig bin.
Ich lege also Wert darauf, dass jeder Computer zunächst auch für sich allein ohne jegliche Vernetzung grundsätzlich funktioniert und dass die wesentlichen Anwendungen nutzbar sind. Für mich ist daher eine webbasierte Applikation nur für Schnickschnack denkbar, auf den ich auch gut verzichten könnte, wenn's mal nicht funktioniert. Aber alle wichtigen Anwendungen und die notwendigen Daten müssen für mich "lokal" verfügbar sein. "Lokal" heißt dabei nicht zwangsläufig "auf diesem einen Computer", aber zumindest innerhalb des eigenen Netzwerks, das ich unter Kontrolle habe.

So long,
 Martin

[hotti]

[brutal gekürzt...]

hi, ein paar Gedanken,

den Trend zur Webanwendung durfte ich viele Jahre aktiv miterleben und ich denke, dass der weiterhin da ist und auch eine Zukunft hat.

Beispiel Intranet und ein Team von Netzwerkspezialisten.
Da gibt es viel zu Lesen an Dokumenten, Wissen auszutauschen und dieses oder jenes Progrämmchen. Was liegt näher, als den ganzen Kram einheitlich auf einen Webserver abzulegen!

Und weg von der dezentralen Datenhaltung, von wegen, dass Excel-Dateichen mit Netzplanung und dergl. rumgeschickt werden. Das Chaos ist vorprogrammiert.

Sowas geghört einheitlich auf einem Webserver abgelegt: Von Dokumentationen, Know-How, News bis hin zur Seite mit den wichtigsten Telefonnummern. Und natürlich sämtliche Verwaltungstools wie die Datenbank für die Verwaltung verschiedener Netze, der Technik und so manches Tool, z.B. ein Netzkalkulator für Planung und Design.

Jetzt haben wir den Zustand der "Best Practice": Die Kollegen brauchen nur noch einen Browser und können standortübergreifend arbeiten. Zentrale Datenhaltung, one ring to rule them all!

Zentrale Projektverwaltung usw.usw. VPN ermöglicht es, dass auch mal von zuhause aus gearbeitet werden kann. Für Authentifications und Authorizations der Webanwendungen gibt es zentrale Dienste wie LDAP, RADIUS und TACACS. Damit hat der Webmaster den Rücken frei.

Dabei ist die Sprache für interkommunikative Webanwendungen egal. Der eine kommt mit Perl, geht, und der andere macht halt mit PHP weiter....

Zu Ajax und Web 2.0
Das mag ein Hype sein, ist im Grunde genommen jedoch eine Luftnummer. Sofern Firmen-APs nicht soweit geknebelt sind, dass JavaScript ständig eingeschaltet sein muss, platzt die Ajax-Blase in dem Moment, wo der Benutzer JavaScript ausknipst.

Viele Grüße,
Horst Haselhuhn

[Klawischnigg]

Hi there,

Zu Ajax und Web 2.0
Das mag ein Hype sein, ist im Grunde genommen jedoch eine Luftnummer.

Sag das Google.

Sofern Firmen-APs nicht soweit geknebelt sind, dass JavaScript ständig eingeschaltet sein muss, platzt die Ajax-Blase in dem Moment, wo der Benutzer JavaScript ausknipst.

Dann hat er sich halt selbst ausgeknipst. Es geht ja nicht um irgendwelche Spielchen und Mouseover-Effekte sondern die Frage war nach den Techniken, mit der in Zukunft Anwendungen erstellt werden. Und da wird in Zukunft noch wesentlich mehr im Browser laufen. Und das ist eben in den meisten Fällen nur mit Javascript möglich. Wenn JS dann augeschaltet ist, dann funktionierts ebensowenig wie man mit einem ausgeschaltetem Rechner eine Lagerhaltungssoftware etc. bedienen kann.

Daß es natürlich immer auch Anwendungen geben wird, die lokal laufen und die in irgendeiner Sprache erstellt werden müssen versteht sich von selbst. Ich denke, daß da in den vorigen Postings mit Assembler (für bestimmte Spezialgebiete), allen C-Derivaten und Java (fast) alle wichtigen schon genannt wurden...

[at]

Hallo.

Sofern Firmen-APs nicht soweit geknebelt sind, dass JavaScript ständig eingeschaltet sein muss, platzt die Ajax-Blase in dem Moment, wo der Benutzer JavaScript ausknipst.
Dann hat er sich halt selbst ausgeknipst. Es geht ja nicht um irgendwelche Spielchen und Mouseover-Effekte sondern die Frage war nach den Techniken, mit der in Zukunft Anwendungen erstellt werden. Und da wird in Zukunft noch wesentlich mehr im Browser laufen. Und das ist eben in den meisten Fällen nur mit Javascript möglich.

Umso wichtiger ist es, dem Nutzer oder Administrator die Möglichkeit zu geben, im Browser beziehungsweise der interpretierenden Anwendung genau zu bestimmen, welche Anwendung was darf oder welche anderen was nicht dürfen. Ein Zonenmodell reicht da wahrscheinlich nicht mehr aus, und auch eine Auflösung nach Websites kann schon zu grob sein.
MfG, at

[stareagle]

Hallo marcel,

Hallo,

ich erlaube mir ebenfalls mal, die auf die einzelnen Teile in einer etwas anderen Reihenfolge als in deinem Post einzugehen.

Ich frage einfach deshalb, weil ich Systembetreuer und Informatiklehrer

Ich bin Student der Informatik, also einer derjenigen die möglicherweise in paar Jahren einigen Mist verzapfen, den du ausbaden darfst ;-)

Seid ihr auch der Meinung, dass in Zukunft immer mehr Programmen "nur noch" im Browser ablaufen werden und Techniken wie AJAX für Endanwenderprogramme die Oberhand bekommen werden?

Nein. Möglicherweise werden solche Anwendungen die Desktopanwendungen ergänzen, aber nicht ersetzen. Möglich ist aus meiner Sicht aber, das beide auf einen gemeinsamen Datenbestand im Web zugreifen, und man die Daten mit einer komfortablen Oberfläche auf seinem Rechner bearbeiten kann und mit einer weniger komfortablen Webanwendung. Ein Beispiel, das mir spontan einfällt wäre Foxmarks. Das ist zum einen eine Erweiterung für den Firefox, die es erlaubt, seine Bookmarks zu syncen. Andererseits kann man auch mittels einer Weboberfläche auf diese zugreifen, wenn man z.B. an einem öffentlichen Rechner (Internet-Café etc.) sitzt.

Sprachen wie Java, C/C++ etc. werden nur von "wenigen" Profis entwickelt

Du meinst wahrscheinlich "In Sprachen wie C/C++, Java etc. entwickelt werden.

Sprachen selbst werden normalerweise von einer sehr kleinen Gruppe von Experten entwickelt.

ich bin mal wieder auf der Suche nach einer interessanten Programmiersprache, um einfach mal auszuprobieren, was es sonst noch so gibt. Ich bin jetzt auf Python gestoßen,

Welche Sprachen interessant sein oder nicht, ist sehr individuell. Ich persönlich mag Python nicht. Aber das ist Geschmackssache.

Was die Sprachen selbst angeht:

Ich denke, das C (reines pures C) noch lange überleben wird (länger als manche sich das wünschen würden). Zu C als mit Syntax verzuckertem Assembler (Zitat Niklaus Wirth) gibt es imho keine wirkliche Alternative für bestimmte Einsatzzwecke (Programmierung von OS-Kerneln etc.). Auch für Desktopanwendungen ist C nicht unbedingt die schlechtere Wahl.

C++ wird sich auch noch halten, allerdings dürfte C++ seine Komplexität (das C++ fast zu komplex ist gibt sogar der Schöpfer der Sprache Bjarne Stroustrup zu).

Java hat meines Erachtens das Problem, das um die eigentlich das nette Sprache ein mittlerweile unüberschaubarer Zoo von Konzepten entstanden ist (Servlets, Applets, Enterprise Java Beans, Java Persitence API um nur einige zu nennen), die nicht klar von der Sprache selbst abgetrennt sind. Das könnte sich zu einem Problem für die Sprache entwickeln.

Interessant dürfte sein, wie sich die Sprache D entwickelt.

PHP, Ruby und Python werden sich ebenfalls nicht unwichtig sein, insbesondere für die schnelle Entwicklung von Programmen.

Andere Nischen-Sprachen, wie z.B. Ada oder Cobol werden wahrscheinlich genauso wichtig wie heute bleiben.

Für bestimmte Anwendungsfälle werden möglicherweise Konzepte aus den funktionalen Sprachen (Haskell) in andere Sprachen übernommen werden, wie das schon bei Ruby und Python geschehen ist.

Gruß

Stareagle

[Tim Tepaße]

Hallo,

Achtung, Threaddrift

ich bin mal wieder auf der Suche nach einer interessanten Programmiersprache, um einfach mal auszuprobieren, was es sonst noch so gibt. Ich bin jetzt auf Python gestoßen, da im Moment auch ein "For Kids"-Buch stark beworben wird. Ich halte das zwar nicht für sonderlich gelungen, aber ganz interessant.

Ich bin alles andere als ein Pädagoge/Didaktiker aber rein intuitiv mag ich die Idee sehr, im schulischen Informatikunterricht eine moderne multiparadigmale Hochsprache zu verwenden. Pascal zu meinen Zeiten ging mir doch etwas auf den Senkel. Gerade moderne Skriptsprachen und deren starke Klassenbibliotheken und besonders das Ökosystem an vielen Erweiterungen finde ich praktisch für E

Ludger Humbert unterrichtet meines Wissens schon seit Ende der 90er mit Python. Eventuell findest Du in dessen Veröffentlichungen und in dessem Weblog Dinge, die Dir bei der Unterrichtsplanung weiter helfen. Aktuell scheint der sich mit Python auf Nokias S60 zu beschäftigen, um näher an der Lebensrealität der Schüler zu sein. Finde ich spannend.

Auch gut vorstellen könnte ich mir die Programmiersprache Ruby, die in ihrer Objektorientierung schon fast smalltalk'sche Ausmaße hat. In der Ruby-Community sehr populär ist jemand unter dem Alias _why the lucky stiff, der u.a. das Anliegen hat, Ruby spielerisch einzusetzen und damit schnelle Erfolgserlebnisse zu bieten und auch um von den ständigen Fibonacchi-Sequenzen wegzukommen. Sein altes Weblog RedHanded und das neue Weblog hackety.org sind da recht interessant; neuere Projekte wie HacketyHack oder das sehr einfach GUI-Toolkit Shoes finde ich da sehr interessante Entwicklungen. Ich bin aber kein Pädagoge; wüßte also nicht, ob man so etwas in die normalen Unterrichtsrichtlinien integrieren kann. Vielleicht hast Du auch einfach nur Spaß beim Rumklicken & Lesen.

Tim

[marcel b.]

Im Unterricht wird viel auf BlueJ gesetzt, da man dort über das Kontextmenü Objekte erzeugen und seine Attribute und Methoden verändern/aufrufen kann. Was mich persöndlich an Java für den Unterricht stört ist folgendes:

1. public void main.....
      Direkt vom Anfang recht komplex

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

3. Oberflächenprogrammierung
      Eine Oberfläche lässt sich unter Python mit wxWidgets - glaube ich -
      schneller zusammen tippen, als unter Java.

Auf der anderen Seiten wird Java halt überall benutzt und wenn Klassen in der Obestufe gemischt werden und die einen Pyhton und die anderen Java gemacht haben, wird es schwierig. Zudem habe ich Kollegen, die immer noch TurboPascal unterrichten.

Ein schwieriges Thema, das auch wohl von eigenen Vorlieben abhängt. Ich selbst hätte eigentlich gerne folgendes:

1. Oberflächen, die per Drag'n'Drop zusammengestellt werden können.
      (Das hängt ja eigentlich nicht von der Sprache ab, sondern von der
      Entwicklungsumgebung)

2. Betriebssystemunabhängigkeit

3. Einfachheit
      Bei Python kann man raw_input und print benutzen und schon mal loslegen

4. Erzeugen von exe'n für verschiedenen Betriebssysteme
      Das ist für die Schüler sehr wichtig, da so ein eigenes Programm einfach
      sehr befriedigend sein kann.

Java mit Eclipse(?) erfüllt schon recht viel. Dennoch habe ich immer wieder Schüler, die mit so etwas

for (int i = 0;i<10;i++)

völlig überfordert sind. Es sind halt nicht mehr nur die interessierten Schüler die man unterrichtet, sondern alle Schüler einer Klasse.

Was haltet ihr von meinen Überlegungen. Noch weitere Anregungen?

marcel b.

[Otto]

Hi marcel b.,

Deine wünsche werden eigentlich alle von der QT-Bibliothek erfüllt http://trolltech.com

Mit Hilfe des Qt-Designer kannst du die GUI komplett per Drag and Drop zusammen bauen. Qt ist für Linux, Windows und MacOSX verfügbar und lässt sich ohne größere Probleme in Eclipse integrieren. Das Buch C++ GUI Programming with Qt 4 ist super geeignet für den Einstieg. Bis auf das Buch ist alles frei verfügbar. Die Dokumentation ist meines erachten auch sehr gut und bringt viele Beispiele mit.

Haken an der Sache ist jedoch ohne C++ Kenntnisse und OO kommt man nicht weit.

MfG
Otto

[Sympatisant]

Salvete,

im Folgenden gehe ich jetzt mal nur auf Java (primaer in Kombination mit Eclipse) ein.

1. public void main.....
      Direkt vom Anfang recht komplex

Es handelt sich um eine einzige Methode, die naeher erklaert werden muss ;)

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

Es gibt unter Eclipse CodeFormatter, die man beliebig konfigurieren kann.
So ein CodeStyle laesst sich exportieren und auf den jeweiligen Client importieren.
Folglich kann jeder Schueler vor der Abgabe seines Codes den Code formatieren, so
dass er stets die gleiche Struktur aufweist.
Und, ganz nebenbei, eine ordentliche Formatierung ist ein _Muss_, wenn man in
groesseren Teams arbeitet.

3. Oberflächenprogrammierung
      Eine Oberfläche lässt sich unter Python mit wxWidgets - glaube ich -
      schneller zusammen tippen, als unter Java.

Gut, das ist unter Java - ohne intensive Einarbeitung - tatsaechlich nicht ganz
so leicht. Aber einige GuiBuilder bieten hier schon recht angenehme Abhilfe a la
Drag&Drop.
Zum Beispiel das Visual Editor Project: http://www.eclipse.org/vep/WebContent/main.php
Oder, jetzt nicht ganz so homogen, der GuiBuilder von Netbeans: Matisse:
http://www.netbeans.org/features/java/swing.html
Beide sind kostenlos.

1. Oberflächen, die per Drag'n'Drop zusammengestellt werden können.
      (Das hängt ja eigentlich nicht von der Sprache ab, sondern von der
      Entwicklungsumgebung)

s.o.

2. Betriebssystemunabhängigkeit

Da boete sich Java ja geradezu an ;-)

3. Einfachheit
      Bei Python kann man raw_input und print benutzen und schon mal loslegen

System.out.println(); schreibt in die Konsole.

4. Erzeugen von exe'n für verschiedenen Betriebssysteme
      Das ist für die Schüler sehr wichtig, da so ein eigenes Programm einfach
      sehr befriedigend sein kann.

Unter Java wuerdet ihr dann ein jar-File erstellen. Mittels javac laesst sich das dann
auch ueber einen "Doppelklick" ausfuehren.

Java mit Eclipse(?) erfüllt schon recht viel. Dennoch habe ich immer wieder Schüler, die mit so etwas
for (int i = 0; i < 10; i++)

Nun gut, aber Schleifen sind nun mal ein Grundkonzept bei Programmiersprachen.
Ich weiss nicht, ob man den Schuelern einen Gefallen tut, wenn man sie unerwaehnt laesst.

Aber ich merke bereits, solch eine Entscheidung muss gut ueberlegt sein ;-)

MfG,
Sympatisant

[dedlfix]

echo $begrüßung;

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

Zu zeigen, dass Strukturierung bei der Fehlersuche hilft, wäre meiner Meinung nach ein Thema, das Gegenstand des Unterrichts sein sollte. Dass Python die Einrückung erzwingt ist eine Sache, doch ob man damit grundlegend das Strukturieren beibringen kann, wage ich in Zweifel zu ziehen. Auch mit Python kann man miserablen, unüberlegten Code fabrizieren. Als wichtiger sehe ich es an, die Fähigkeit zu vermitteln, ein Problem in Teilprobleme aufzuteilen und diese als solche erkennbar zu notieren inklusive Kommentare, die beschreiben, was mit einer Lösung erreicht werden soll.

Es gibt unter Eclipse CodeFormatter, die man beliebig konfigurieren kann.
So ein CodeStyle laesst sich exportieren und auf den jeweiligen Client importieren.
Folglich kann jeder Schueler vor der Abgabe seines Codes den Code formatieren, so
dass er stets die gleiche Struktur aufweist.

Spaghetti-Code bleibt Spaghetti-Code, egal ob er nun zu Fuß oder automatisch formatiert wurde. Ein Code-Formatter ist nur ein Werkzeug, das einem auch nicht weiterhilft, wenn das Wissen fehlt, wie man das Material bearbeiten muss. Ein CAD-Programm hat sicherlich viele Automatismen, die es einem erleichtern, sein Ziel zu erreichen. Doch wenn einem das Grundlagenwissen zum ordnungsgemäßen und ordentlichen Erstellen der Bauzeichnung fehlt, wird man keine schmucke Villa gebaut bekommen.

Und, ganz nebenbei, eine ordentliche Formatierung ist ein _Muss_, wenn man in
groesseren Teams arbeitet.

Selbst wenn man nur für sich selbst programmiert ist es von Vorteil, wenn man seinen eigenen Code nach einer Zeit, in der der natürliche Vergessensprozess gearbeitet hat, immer noch verstehen kann. Vielleicht sollte man auch mal so etwas üben, indem man z.B. ein vor einiger Zeit erarbeitetes Programm um neue Funktionen erweitern muss.

echo "$verabschiedung $name";

[Sympatisant]

Hallo dedlfix,

Spaghetti-Code bleibt Spaghetti-Code, egal ob er nun zu Fuß oder automatisch formatiert
wurde. Ein Code-Formatter ist nur ein Werkzeug, das einem auch nicht weiterhilft, wenn das
Wissen fehlt, wie man das Material bearbeiten muss.

Vollkommen richtig. Ich hatte das jedoch so verstanden, dass es ihm lediglich um die
spaetere Korrektur seinerseits ging. Aber ich denke, dass man Schuelern durchaus eine
ordentliche Struktur beibringen kann; Zu meiner Zeit war das zumindest so, dass, zB bei
Aufsaetze, bereits Sachen wie Aufbau und Struktur mit in die Benotung eingeflossen
sind. Von daher wird ihnen das m.M.n. nicht all zu fremd erscheinen.

Selbst wenn man nur für sich selbst programmiert ist es von Vorteil, wenn man seinen
eigenen Code nach einer Zeit, in der der natürliche Vergessensprozess gearbeitet hat,
immer noch verstehen kann. Vielleicht sollte man auch mal so etwas üben, indem man z.B.
ein vor einiger Zeit erarbeitetes Programm um neue Funktionen erweitern muss.

Das passiert mir leider viel zu oft ;-)

MfG,
Sympatisant

[Tom]

Hello,

Selbst wenn man nur für sich selbst programmiert ist es von Vorteil, wenn man seinen eigenen Code nach einer Zeit, in der der natürliche Vergessensprozess gearbeitet hat, immer noch verstehen kann. Vielleicht sollte man auch mal so etwas üben, indem man z.B. ein vor einiger Zeit erarbeitetes Programm um neue Funktionen erweitern muss.

Das ist ein sehr interessanter Selbstversuch, den ich neulich mit ca. 13 Jahre altem C-Code vorgenommen habe.

Ich hatte die Programme (alle zum Thema Audio-Kompression) selber in Pascal (und asm) geschrieben, eine Freundin hatte sie in C (und asm) umgesetzt. Anschließend hatten wir eine gemeinsame C-Version (immer noch mit einigen asm-Teilen) mit Kommentaren und Fehlerbehandlung daraus gemacht. Ich habe das alte C-Programm tatsächlich noch zum Laufen gebracht auf einem Linux-Host. Dazu musste ich aber die asm-Routinen wieder gegen die damals wesentlich langsameren C-Routinen ersetzen, weil ich keinen blassen Schimmer davon habe, wie sich die asm-Teile unter Linux formulieren ließen. Es hat sogar geklappt, aber nur wegen der ausführlichen Kommentierung und leicht lesbaren Formatierung.

Jedenfalls habe ich mich daraufhin entschlossen, meine damals widerwillig erworbenen C-Kenntnisse und die Grundlagen von C++ wieder aufzufrischen und zu verbessern...

Grüße aus Syburg

Tom vom Berg

[at]

Hallo.

Dass Python die Einrückung erzwingt ist eine Sache, doch ob man damit grundlegend das Strukturieren beibringen kann, wage ich in Zweifel zu ziehen. Auch mit Python kann man miserablen, unüberlegten Code fabrizieren.

Der Unterschied ist aber der, dass man es bei Python darauf anlegen muss, während es es anderwo einfach passiert.
MfG, at

[Frank (no reg)]

Hi, just my two cents ;)

Was mich persöndlich an Java für den Unterricht stört ist folgendes:

1. public void main.....
      Direkt vom Anfang recht komplex

Also wenn dir das schon komplex erscheint ... wow, wie deklariert man denn in anderen Sprachen Funktionen bzw. Methoden mit und ohne Rückgabewerte?

public function main(vara as string) as string ... end function
oder
private sub main(vara as string)  ... end sub

ist nicht mehr oder weniger komplex ... Python kenn ich nicht. Würd ich subjektiv am Anfang vielleicht auch als "komplex" oder eher und besser ausgedrück anders und gewöhnungsbedürftig empfinden, da ich aus der .net / Java / VBScript Welt komme.

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

Wie, ganz einfach wegfallen. Python hat überhaupt keine Mittel zur Code-Strukturierung. Wie erkennt man dann wo funktionale Blöcke anfangen und aufhören?

3. Oberflächenprogrammierung
      Eine Oberfläche lässt sich unter Python mit wxWidgets - glaube ich -
      schneller zusammen tippen, als unter Java.

Ah, wenigstens noch einer, der seinen Glauben nicht verloren hat. Aber mit dem - glaube ich - ist das Argument als Argument quasi unbrauchbar.

Auf der anderen Seiten wird Java halt überall benutzt und wenn Klassen in der Obestufe gemischt werden und die einen Pyhton und die anderen Java gemacht haben, wird es schwierig. Zudem habe ich Kollegen, die immer noch TurboPascal unterrichten.

Ich kenne partielle Klassen, abstrakte Klassen, aber gemischte Klassen? Unter Python gibts sowas? Wie sieht das aus?

Ein schwieriges Thema, das auch wohl von eigenen Vorlieben abhängt. Ich selbst hätte eigentlich gerne folgendes:

1. Oberflächen, die per Drag'n'Drop zusammengestellt werden können.
      (Das hängt ja eigentlich nicht von der Sprache ab, sondern von der
      Entwicklungsumgebung)

Wo ist da der Lerneffekt? Ist eher ne Frage der Geschicklichkeit bei der Mausbedienung. ;)   Nein, also ich bediene mich auch ab und zu mal der Winforms Designers um zu sehen, wie ein Datagrid an Daten gebunden wird oder wie eine SOAP-WebService Reference umgesetzt wird.

4. Erzeugen von exe'n für verschiedenen Betriebssysteme
      Das ist für die Schüler sehr wichtig, da so ein eigenes Programm einfach
      sehr befriedigend sein kann.

Aha, da bin ich aber gespannt. Das einzige befriedigende Programm, was ich kenne, heisst "Wet Lula". Aber erkläre mal bitte, warum das befriedigend für die Schüler sein soll? Dass sie es nach Hause mitnehmen können und da auch verwenden können?

Dennoch habe ich immer wieder Schüler, die mit so etwas
for (int i = 0;i<10;i++)

völlig überfordert sind.

Wie machst du es in Python, wie in VB, wie in **** ? Ist gibt immer eine Grammatik die man lernen muss, scheissegal, welche Sprache.

Ansonsten ist das reine Gewöhnungssache, man lernt es genauso wie im Französischen die Satzstellung ... oder die Formel für den Radius eines Kreises. Wenn's denn n paar mal genutzt worden ist, hat "man" sich dran gewöhnt. Ausserdem sollen Schüler ja auch was lernen. Wenn alles von selbst ginge und trivial wäre, bräuchten wir keine Bildung. Wenn deine Schüler es nicht verstehen, zeige ihnen Alternativen dazu, mit while oder if und einer sich selbst aufrufenden Funktion.

Es sind halt nicht mehr nur die interessierten Schüler die man unterrichtet, sondern alle Schüler einer Klasse.

Hä? Ah, ja. Jeder hat halt andere Interessen. Das ist ja das bescheuerte am Bildungssystem, man muss erstmal soviel Zeug lernen, was am Ende unnütz ist. Mein Gehörn für Mathe hat ab dem Abi keine Lust mehr gehabt, ich habe dieses Scheiss-Integralrechnen auch nie mals wieder gebraucht. Mathe hätte für mich mit dem Dreisatz, dem des Pythagoras und den binomischen Formeln aufhören können.

Wer für Informatik keinen Trieb hat, für den gibt es vielleicht eher die Künste oder das Philosophische oder von mir aus auch das sadistische Sezieren von noch lebenden Fröschen im Biologieunterricht.

Die Jugend (9 bis 14) kann sich viel zu wenig entfalten, daraus entsteht Desinteresse und Demotivation, welche dann im "Abhängen mit anderen Homies" endet.

Was haltet ihr von meinen Überlegungen. Noch weitere Anregungen?

Ehrlich, ich finde sie etwas einseitig und "Hype"-orientiert. Möchtest du Python zum neuen Evangelium des Informatikunterrichts erklären? Aber dennoch, lehre ihnen Python, lehre ihnen Java, lehre ihnen die Unterschiede dazwischen und lehre ihnen den Self-Gedanken. Biete ihnen Abwechslung, nicht zu viel Tiefe aber auch nicht zu wenig.

Ciao, Frank

[dedlfix]

echo $begrüßung;

public function main(vara as string) as string ... end function
oder
private sub main(vara as string)  ... end sub

ist nicht mehr oder weniger komplex ... Python kenn ich nicht.

private/public/etc. gibt es unter Python nicht.

def functionsname(parametername):

wäre ein einfaches Beispiel. Allerdings wird bei den Parametern zwischen positionierten und Keyword-Parametern unterschieden, da wird es dann syntaktisch ein wenig komplexer, besonders wenn man Catch-All-Parameter hinzufügt.

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

Wie, ganz einfach wegfallen. Python hat überhaupt keine Mittel zur Code-Strukturierung. Wie erkennt man dann wo funktionale Blöcke anfangen und aufhören?

Durch Ein- und Ausrückung. Wenn man sowieso der Übersicht halber ein- und ausrückt kann man auch gleich die Klammern weglassen, die Zugehörigkeit ergibt sich aus den Whitespace-Zeichen.

Auf der anderen Seiten wird Java halt überall benutzt und wenn Klassen in der Obestufe gemischt werden und die einen Pyhton und die anderen Java gemacht haben, wird es schwierig. Zudem habe ich Kollegen, die immer noch TurboPascal unterrichten.

Ich kenne partielle Klassen, abstrakte Klassen, aber gemischte Klassen? Unter Python gibts sowas? Wie sieht das aus?

Schulklassen, keine OOP-Klassen.
Aber auch das wäre unter Python kein Thema, da kann man von mehreren Klassen erben ... :-)

Dennoch habe ich immer wieder Schüler, die mit so etwas
for (int i = 0;i<10;i++)
völlig überfordert sind.

Wie machst du es in Python, [...] ? Ist gibt immer eine Grammatik die man lernen muss, scheissegal, welche Sprache.

Python wurde auf Einfachheit und Übersichtlichkeit getrimmt. (Klappt nicht immer.) Speziell bei for-Schleifen gibt es nur die Möglichkeit über eine Sequenz zu iterieren. Das entspricht eher einem foreach. Möchte man das obige Konstrukt nachbilden, gibt es die Funktion range(), die eine Sequenz liefert und mit Von-, Bis- und Schrittweiten-Parametern versorgt werden kann.

for i in range(10):

wäre das Pendant zur obigen Schleife. In diesem einfachen Fall bekommt range() nur den Bis-Wert übergeben.

Ansonsten ist es ja nicht schwer, Syntax-Beispiele im Netz zu finden, wenn man wirklich daran interessiert ist, die Sprache (in welcher Tiefe auch immer) kennenzulernen.

echo "$verabschiedung $name";

[Tom]

Hello,

ich vertrete die Meinung, dass man im Unterricht als erstes einfache Assemblerprogrammierung auf einem Realmode-System lernen sollte. Das verschafft einem einerseits den technischen Einblick in die Funktionsweise und andererseits eine gewisse Achtung vor allen "vernünftigen" Hochsprachen, sowie ein gewisses Augenmaß für "unsinnige" Hochsprachen.

Außerdem schult es am besten das logische Denkvermögen.

Hochsprachen sollte man mMn immer erst danach anfassen.

Ein harzliches Glückauf

Tom vom Berg

[Christian Seiler]

Hallo Tom,

ich vertrete die Meinung, dass man im Unterricht als erstes einfache Assemblerprogrammierung auf einem Realmode-System lernen sollte. Das verschafft einem einerseits den technischen Einblick in die Funktionsweise und andererseits eine gewisse Achtung vor allen "vernünftigen" Hochsprachen, sowie ein gewisses Augenmaß für "unsinnige" Hochsprachen.

Auf gar keinen Fall! Bloß nicht! In Assembler gibt es keinerlei (!) abstrakten Konstrukte, es gibt (vereinfacht gesagt) nur Sprünge und elementare Rechenoperationen. Da wird das Abstraktionsvermögen überhaupt nicht geschult, wenn man mit Assembler anfängt, schreibt man später garantiert nur Spaghetti-Code der übelsten Sorte.

Und auch der Real-Mode schlägt in die gleiche Kerbe: Kein Memory Management und damit kein virtueller Speicher und damit Speicheradressierung nur über feste Segmente, keine Trennung von Prozessen, etc. Wenn man Leuten erklärt, wie man für Real Mode programmiert, verhindert man auch hier wieder die Möglichkeit, Abstraktion zu lernen.

Und in meinen Augen ist Abstraktion VIEL VIEL wichtiger, als sich mit den Details irgend eines Prozessors rumschlagen zu müssen. Wenn ich prinzipiell weiß, wie ich einen Algorithmus in einer Programmiersprache umsetzen kann, dann kann ich auch eine beliebige andere Programmiersprache lernen und es dort genauso tun. Wenn ich mich dagegen die ganze Zeit nur mit Calling Conventions und Assemblersyntaxkonventionen (sind ja auch nicht einheitlich) rumschlage, lerne ich nicht, wie ich abstrakte Probleme analytisch angehe und sie dann programmiertechnisch umsetze.

Und ich habe kein Problem damit, dass Schüler nicht den effizientesten Code schreiben. Wozu auch? Effizienz ist zwar für das tatsächliche Arbeiten wichtig, aber beim ersten Erlernen der Programmierfertigkeit ist Effizienz erst einmal nicht relevant.

Das ist in meinen Augen das gleiche Spiel wie mit dem unsäglichen "Office-Unterricht" in der Schule: Fast überall wird einem dort beigebracht, wie man Word und Excel konkret als Programm bedient - und wenn sich etwas ändert in einer neueren Version oder die Schüler späpter einmal ein anderes Programm verwenden sollen, sind sie aufgeschmissen.  Wenn man ihnen dagegen beibringen würde, wie man am besten die Fertigkeiten "Textverarbeitung" und "Tabellenkalkulation" erlernt - und dies eben an Hand von z.B. Word und Excel, dann kennen die Schüler die Features von Excel hinterher vielleicht weniger gut, als Schüler, die direkt "Excel gelernt" haben, allerdings kann man sich das noch eher selbst aneignen, wenn man das abstrakte Konzept "Tabellenkalkulation" mal verstanden hat.

Viele Grüße,
Christian

[Der Martin]

Hallo,

ich vertrete die Meinung, dass man im Unterricht als erstes einfache Assemblerprogrammierung auf einem Realmode-System lernen sollte. Das verschafft einem einerseits den technischen Einblick in die Funktionsweise und andererseits eine gewisse Achtung vor allen "vernünftigen" Hochsprachen, sowie ein gewisses Augenmaß für "unsinnige" Hochsprachen.

sehe ich auch so.

Auf gar keinen Fall! Bloß nicht!

Dieses heftige Veto kann ich nun überhaupt nicht nachvollziehen. Ich bin sicher, Tom hat nicht gemeint, dass der Einblick in die Elementarteilchen der EDV die Fähigkeiten zu abstraktem und algorithmischem Denken ersetzen soll, sondern ihr nur eine Basis und ein Gegengewicht geben soll.

In Assembler gibt es keinerlei (!) abstrakten Konstrukte, es gibt (vereinfacht gesagt) nur Sprünge und elementare Rechenoperationen. Da wird das Abstraktionsvermögen überhaupt nicht geschult, ...

Oh doch. Zum Beispiel das Abstraktionsvermögen in dem Sinn, dass man eine bestimmte Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann. Zum Beispiel das Abstraktionsvermögen, sich unter einer Sequenz von Bytes im Speicher eine bestimmte Zahl, einen String, einen Fließkommawert oder gar eine komplexe Struktur vorzustellen.

wenn man mit Assembler anfängt, schreibt man später garantiert nur Spaghetti-Code der übelsten Sorte.

Definitiv nicht - oder wenn doch, dann hat man auch in Assembler das Grundprinzip nicht wirklich verstanden.

Und auch der Real-Mode schlägt in die gleiche Kerbe: Kein Memory Management und damit kein virtueller Speicher und damit Speicheradressierung nur über feste Segmente, keine Trennung von Prozessen, etc. Wenn man Leuten erklärt, wie man für Real Mode programmiert, verhindert man auch hier wieder die Möglichkeit, Abstraktion zu lernen.

Nein. Radfahren lernt man auch am besten ohne Stützräder. Fehlende Sicherheitsvorkehrungen sind IMHO eine der besten Methoden, Disziplin zu lernen: Wenn ich etwas falsch gemacht habe, dann knallt's irgendwo. Wenn der Rechner oder das Betriebssystem komplett abstürzt, ist das für den angehenden Programmierer ein viel eindringlicheres Zeichen, als wenn einfach ein Fenster aufpoppt, in dem ihm das System lapidar mitteilt, dass sein Programm "aufgrund einer unzulässigen Operation beendet wurde". Jedenfalls dann, wenn das Übungssystem nicht gleichzeitig produktiv eingesetzt wird, was wiederum technischer Suizid wäre.

Und in meinen Augen ist Abstraktion VIEL VIEL wichtiger, als sich mit den Details irgend eines Prozessors rumschlagen zu müssen.

Ja, hier stimme ich unbedingt zu. Nur verstehe ich nicht, wie du der Programmierung in Assembler die Notwendigkeit der Abstraktion absprechen kannst. Ich sehe sie hier ebenso deutlich wie in objektorientierten Hochsprachen, sie äußert sich nur ein wenig anders.

Wenn ich prinzipiell weiß, wie ich einen Algorithmus in einer Programmiersprache umsetzen kann, dann kann ich auch eine beliebige andere Programmiersprache lernen und es dort genauso tun.

Genau. Notfalls sogar in Assembler. ;-)

Und ich habe kein Problem damit, dass Schüler nicht den effizientesten Code schreiben. Wozu auch? Effizienz ist zwar für das tatsächliche Arbeiten wichtig, aber beim ersten Erlernen der Programmierfertigkeit ist Effizienz erst einmal nicht relevant.

Das sehe ich auch so. Am Anfang muss erstmal ein solides Verständnis für die Zusammenhänge da sein, bevor ich an Effizienz denken kann.

Das ist in meinen Augen das gleiche Spiel wie mit dem unsäglichen "Office-Unterricht" in der Schule: Fast überall wird einem dort beigebracht, wie man Word und Excel konkret als Programm bedient - und wenn sich etwas ändert in einer neueren Version oder die Schüler späpter einmal ein anderes Programm verwenden sollen, sind sie aufgeschmissen.  Wenn man ihnen dagegen beibringen würde, wie man am besten die Fertigkeiten "Textverarbeitung" und "Tabellenkalkulation" erlernt - und dies eben an Hand von z.B. Word und Excel, dann kennen die Schüler die Features von Excel hinterher vielleicht weniger gut, als Schüler, die direkt "Excel gelernt" haben, allerdings kann man sich das noch eher selbst aneignen, wenn man das abstrakte Konzept "Tabellenkalkulation" mal verstanden hat.

Vollkommen richtig. Diese Art von Spezialkursen halte ich auch für blödsinnig.

So long,
 Martin

[Christian Seiler]

Hallo,

Dieses heftige Veto kann ich nun überhaupt nicht nachvollziehen. Ich bin sicher, Tom hat nicht gemeint, dass der Einblick in die Elementarteilchen der EDV die Fähigkeiten zu abstraktem und algorithmischem Denken ersetzen soll, sondern ihr nur eine Basis und ein Gegengewicht geben soll.

Tom sagte, man sollte mit Assembler auf einem Real-Mode-System _anfangen_ (Du hast es selbst noch einmal zitiert). Und das halte ich für einen sehr, sehr großen Fehler. Dass man - nachdem man die Grundlagen der Programmierung an sich erarbeitet hat - etwas über die x86-Architektur an sich lernt (elementare Datentypen, Endianess, Systemarchitektur, ...) halte ich auch nicht für verkehrt. Aber als Anfang ist es IMHO absolut ungeeignet.

In Assembler gibt es keinerlei (!) abstrakten Konstrukte, es gibt (vereinfacht gesagt) nur Sprünge und elementare Rechenoperationen. Da wird das Abstraktionsvermögen überhaupt nicht geschult, ...

Oh doch. Zum Beispiel das Abstraktionsvermögen in dem Sinn, dass man eine bestimmte Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann. Zum Beispiel das Abstraktionsvermögen, sich unter einer Sequenz von Bytes im Speicher eine bestimmte Zahl, einen String, einen Fließkommawert oder gar eine komplexe Struktur vorzustellen.

Dazu braucht's aber kein Assembler. Das geht auch mit so ziemlich jeder anderen Programmiersprache, sogar mit extrem abstrahierten Sprachen wie PHP (da gibt's halt pack()/unpack(), bei denen man mit Binärdarstellungen rumspielen kann).

Und auch der Real-Mode schlägt in die gleiche Kerbe: Kein Memory Management und damit kein virtueller Speicher und damit Speicheradressierung nur über feste Segmente, keine Trennung von Prozessen, etc. Wenn man Leuten erklärt, wie man für Real Mode programmiert, verhindert man auch hier wieder die Möglichkeit, Abstraktion zu lernen.

Nein. Radfahren lernt man auch am besten ohne Stützräder.

Wieso Stützräder? Bis auf den Embedded-Bereich hat man heutzutage einfach keinen Real Mode mehr, alle Betriebssysteme mit denen man heute auf Desktop/Server/Laptop/...-Rechnern arbeitet, nutzen den Protected Mode. Es gibt sogar Prozessorarchitekturen, die gar keinen Real Mode kennen, sondern gleich virtuellen Speicher etc. haben. Und die meisten Anwendungen werden aus Komplexitäts- und Portabilitätsgründen eben nicht mehr in Assembler geschrieben. Das heißt: Im realen Leben sind diese von Dir so bezeichneten "Stützräder" sowieso schon mit dabei, IMHO passt hier der Vergleich zwischen Fahrrad und Einrad besser. Wieso also Konzepte lernen, mit denen man sich während der Lernphase EXTREM ins Knie schießen kann, im praktischen Leben aber in der Form nicht mehr vorkommen? Dafür schießt man sich mit anderen Dingen ins Knie, die man bei der Lernphase dann lange nicht mehr so gut beigebracht bekommen kann, weil man da viel zu beschäftigt mit den unwichtigen Segment-Adressierungs-Detail-Gedöns ist.

Fehlende Sicherheitsvorkehrungen sind IMHO eine der besten Methoden, Disziplin zu lernen: Wenn ich etwas falsch gemacht habe, dann knallt's irgendwo.

Nein, es reicht völlig aus, das ein Lehrer bei Fehlern einfach streng ist. Das ist dann das "Knallen", das dem Schüler richtig weh tut. Wenn der Computer abstürzt, startet er ihn einfach neu, genauso, wie er eine Meldung einfach wegklickt. Das mag zwar etwas lästig sein, richtig weh tut es dem Schüler aber auch nicht - was vmtl. auch daran liegt, dass Benutzer auf Abstürze konditioniert wurden.

Und in meinen Augen ist Abstraktion VIEL VIEL wichtiger, als sich mit den Details irgend eines Prozessors rumschlagen zu müssen.

Ja, hier stimme ich unbedingt zu. Nur verstehe ich nicht, wie du der Programmierung in Assembler die Notwendigkeit der Abstraktion absprechen kannst.

Ich sage ja nicht, dass man in Assembler nicht abstrahieren kann. Aber um überhaupt erst einmal etwas zum Laufen zu bringen, muss man sich mit Dingen rumschlagen wie "Welche Register bietet der *spezifische* Prozessor an? Welche Calling Conventions verwendet mein *spezifisches* Betriebssystem unter dieser *spezifischen* Architektur? Welche Systemaufrufe unter meinem Betriebssystem gibt es, um Sachen auszugeben?" Und im Real Mode dann noch so Speicheradressierungsscherze. Das sind alles erst einmal Hürden, die überwunden werden müssen, *BEVOR* man in Assembler anfangen kann, von Abstraktion zu reden. In Hochsprachen (objektorientiert oder nicht) hat man dagegen die "lästigen Dinge" schon wegabstrahiert, dass man sich beim Lernen gleich auf die erst einmal relevanten Dinge konzentrieren kann.

Zudem: In Assembler passiert intern viel "Mojo": Irgendwelche Flags werden von Instruktionen gesetzt oder ausgelesen, Register die nicht explizit angegeben werden werden teilweise implizit verwendet etc., was bei typischen Programmiersprachen in der Regel nicht der Fall ist. Wenn jemand programmieren lernt, ist es in meinen Augen sehr wichtig, dass er an einer Zeile ziemlich erkennt, was dort passiert und nicht erst überlegen muss, was der konkrete Befehl noch für "Nebenwirkungen" hat. In einer Sprache, in der man also while (i > 0) { ...; i--; } schreibt, ist ziemlich ersichtlich, was passiert. Wenn ich in Assembler einfach nur ein foo: ... ; LOOP foo habe, dann dürfte es einen Anfänger ziemlich verwirren, über was eigentlich geloopt wird und er müsste nachschlagen, dass das bei x86 eben ecx ist. Und das war nur ein Beispiel, es gibt noch mehr.

[Auf die Gefahr hin, dass ich damit wieder ein Flamewar auf mich ziehe: Dies ist auch der Grund, warum ich Perl auch für Anfängerungeeignet halte, weil dort auch sehr viel durch "funky syntax" passiert, wie zum Beispiel die ganzen $@, $/, ...-Variablen.]

Wenn ich prinzipiell weiß, wie ich einen Algorithmus in einer Programmiersprache umsetzen kann, dann kann ich auch eine beliebige andere Programmiersprache lernen und es dort genauso tun.

Genau. Notfalls sogar in Assembler. ;-)

Natürlich. Aber Assembler ist eine extrem schlechte Programmiersprache, um das Programmieren überhaupt zu lernen.

Wenn man schon einigermaßen gut programmieren kann, dann spricht nichts dagegen, Assembler zu lernen, um die Interna mal kennen zu lernen, das halte ich auch für eine gute Idee (auch wenn ich nicht der Ansicht bin, dass man es machen *muss*). Aber damit anzufangen ist in meinen Augen ein riesengroßer Fehler.

Viele Grüße,
Christian

[Der Martin]

Hallo Christian,

Tom sagte, man sollte mit Assembler auf einem Real-Mode-System _anfangen_ (Du hast es selbst noch einmal zitiert).

ja, das würde ich auch immer noch unterstützen. Aber offensichtlich hast du etwas anderes darunter verstanden als ich - du hast vergessen zu abstrahieren. ;-)

Dass man - nachdem man die Grundlagen der Programmierung an sich erarbeitet hat - etwas über die x86-Architektur an sich lernt (elementare Datentypen, Endianess, Systemarchitektur, ...) halte ich auch nicht für verkehrt.

Ja, einverstanden. Ich meinte das "Anfangen mit Assembler" aber viel allgemeiner und nicht auf eine konkrete Prozessorarchitektur bezogen. Sondern eher als Grundlagenkapitel:
 * Wie funktioniert eine CPU (Prinzip)
 * Wie funktioniert das Zusammenspiel von CPU, Speicher, I/O
 * Welche Arten von Instruktionen gibt es (Beispiele verschiedener CPUs)
 * Wie kann man den Programmfluss strukturieren (Subroutines, Sprünge, Bedingungen)
Diese Grundlagen sollte man dann mit ein paar einfachen(!) Beispielprogrammen festigen und ein bisschen damit rumspielen dürfen. Je nach Neigung des Lehrers auf x86, 68xxx oder 8051-Derivate bezogen. Damit ist das Thema "Assembler als Grundlage", so wie ich es gemeint habe, abgehakt. Ich meinte nicht, dass jeder Programmierer erstmal x86-Assembler bis zur Perfektion lernen solle.
Apropos x86-Assembler: Auf den *wirklich* alten, überschaubaren Systemen (CP/M zum Beispiel) hat man das Theater mit der Speichersegmentierung gar nicht, und selbst bei DOS im Real Mode werden die Segmentregister vom Betriebssystem so günstig mit Defaultwerten belegt, dass man sie als Programmierer erstmal ignorieren kann. Erst wenn man größere Programme schreiben will (oder mit Assembler-Teilen ergänzen), trifft einen das Thema überhaupt.

Zum Beispiel das Abstraktionsvermögen [...] Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann [...] Sequenz von Bytes im Speicher eine bestimmte Zahl, einen String, einen Fließkommawert oder gar eine komplexe Struktur vorzustellen.
Dazu braucht's aber kein Assembler.

Nein, nicht zwangsläufig. Aber bei den meisten Programmiersprachen, seien sie schwach (Javascript, PHP) oder stark typisiert (Pascal, C) drängt sich bei Anfängern immer die Assoziation mit einem bestimmten Datentyp auf. Da wird ein ASCII-Zeichen aus einer Speicherstelle gelesen, die durch eine Variable mit einem bestimmten Typ (z.B. char) referenziert wird, und dann dieses Zeichen in einer printf-Anweisung mit dem Format %u ausgegeben. Und dann kommt die Frage: "Das ist ja jetzt eine Zahl! Wo ist denn das umgewandelt worden?"
Diese Äquivalenz bzw. kontextabhängige Interpretation von Daten kommt meiner Ansicht nach in keiner "höheren" Programmiersprache so anschaulich rüber wie in Assembler.

Nein. Radfahren lernt man auch am besten ohne Stützräder.
Wieso Stützräder? Bis auf den Embedded-Bereich hat man heutzutage einfach keinen Real Mode mehr, ...

Aber gerade dieser Bereich wächst immer noch so rasch, dass man ihn bitte nicht unterschätzen oder für irrelevant halten sollte.

Wieso also Konzepte lernen, mit denen man sich während der Lernphase EXTREM ins Knie schießen kann, im praktischen Leben aber in der Form nicht mehr vorkommen?

Weil sie Grundlagenwissen schaffen, das der angehende Programmierer eben in vielen Bereichen *doch* wieder braucht.

Fehlende Sicherheitsvorkehrungen sind IMHO eine der besten Methoden, Disziplin zu lernen: Wenn ich etwas falsch gemacht habe, dann knallt's irgendwo.
Nein, es reicht völlig aus, das ein Lehrer bei Fehlern einfach streng ist. Das ist dann das "Knallen", das dem Schüler richtig weh tut.

Kommt auf den Lehrer an ... ;-)

Wenn der Computer abstürzt, startet er ihn einfach neu, genauso, wie er eine Meldung einfach wegklickt. Das mag zwar etwas lästig sein, richtig weh tut es dem Schüler aber auch nicht - was vmtl. auch daran liegt, dass Benutzer auf Abstürze konditioniert wurden.

Wurden sie? Zu denen gehöre ich nicht. Für mich hat ein Systemabsturz immer noch etwas Alarmierendes (jedenfalls seit Windows aus den Kinderschuhen rausgewachsen ist).

Ich sage ja nicht, dass man in Assembler nicht abstrahieren kann. Aber um überhaupt erst einmal etwas zum Laufen zu bringen, muss man sich mit Dingen rumschlagen wie "Welche Register bietet der *spezifische* Prozessor an? Welche Calling Conventions verwendet mein *spezifisches* Betriebssystem unter dieser *spezifischen* Architektur? Welche Systemaufrufe unter meinem Betriebssystem gibt es, um Sachen auszugeben?" Und im Real Mode dann noch so Speicheradressierungsscherze.

Das kommt drauf an, wie tief man in das Assembler-Kapitel wirklich einsteigen möchte. Ich dachte, wie gesagt, nie an das Beherrschen aus dem FF (oder dezimal 255), sondern ums Kennenlernen des Prinzips und der allgemeinen Arbeitsweise und Randbedingungen.

Zudem: In Assembler passiert intern viel "Mojo"

Für mich passiert in Javascript, PHP oder C++ viel mehr Voodoo, als du es in Assembler siehst (z.B. Speicherverwaltung, Typecasting). Deswegen mag ich C++ auch nicht so gern und wähle, wenn ich kann, lieber klassisches C.

[Auf die Gefahr hin, dass ich damit wieder ein Flamewar auf mich ziehe: Dies ist auch der Grund, warum ich Perl auch für Anfängerungeeignet halte, weil dort auch sehr viel durch "funky syntax" passiert, wie zum Beispiel die ganzen $@, $/, ...-Variablen.]

Das kann ich nur als Außenseiter kommentieren, aber für mich ist Perl-Quellcode auch ein Buch mit sieben Siegeln, aus dem ich oft nicht einmal erahnen kann, was da passieren soll.

Natürlich. Aber Assembler ist eine extrem schlechte Programmiersprache, um das Programmieren überhaupt zu lernen.

Um die *Grundlagen* zu lernen, meiner Ansicht nach nicht.

Schönen Abend noch,
 Martin

[Christian Seiler]

Hallo Martin,

Ja, einverstanden. Ich meinte das "Anfangen mit Assembler" aber viel allgemeiner und nicht auf eine konkrete Prozessorarchitektur bezogen. Sondern eher als Grundlagenkapitel:
* Wie funktioniert eine CPU (Prinzip)
* Wie funktioniert das Zusammenspiel von CPU, Speicher, I/O
* Welche Arten von Instruktionen gibt es (Beispiele verschiedener CPUs)
* Wie kann man den Programmfluss strukturieren (Subroutines, Sprünge, Bedingungen)
Diese Grundlagen sollte man dann mit ein paar einfachen(!) Beispielprogrammen festigen und ein bisschen damit rumspielen dürfen.

Die ersten beiden Punkte zu erklären, halte ich noch für sinnvoll, die anderen beiden wiederum nicht. Programmflusssteuerung auf Assembler-Ebene ist nichts, was ich Anfängern beibringen will, weil man da außer Funktionsaufrufen wirklich nur Sprünge und nichts weiteres hat.

Zum Beispiel das Abstraktionsvermögen [...] Datenstruktur je nach Kontext ganz unterschiedlich interpretieren kann [...] Sequenz von Bytes im Speicher eine bestimmte Zahl, einen String, einen Fließkommawert oder gar eine komplexe Struktur vorzustellen.
Dazu braucht's aber kein Assembler.
[...]
Diese Äquivalenz bzw. kontextabhängige Interpretation von Daten kommt meiner Ansicht nach in keiner "höheren" Programmiersprache so anschaulich rüber wie in Assembler.

Ich gehöre zu den Leuten, die der Auffassung sind, dass die Abkehr von diesem Paradigma eines der größten Geschenke der Hochsprachen ist. Denn: Es sei denn, ich mache etwas sehr hardwarenahes oder muss meinen Algorithmus auf das letzte Quäntchen Performance / Speicherverbrauch optimieren, interessiert es mich ehrlich gesagt nicht die Bohne, wie das intern im Speicher organisiert ist. Und wenn ich Datentypen umwandele, will ich eher logische Umwandlungen als Uminterpretationen.

Es ist zwar ganz interessant, mal zu sehen, wie Daten tatsächlich im Computer dargestellt werden und ich finde schon, dass das Anfängern gezeigt werden sollte, aber wirklich nützlich sind Uminterpretationen von Daten im Speicher selten. Was soll ich mit einem Float als Integer interpretiert? Das ist irgend eine krumme, bedeutungslose Zahl, nützt mir absolut nichts. Und auch bei einzelnen Zeichen wird es in Zeiten von Unicode immer sinnloser, da irgend etwas direkt uminterpretieren zu wollen, denn nicht mal UTF-16 kann alle Unicode-Zeichen mit einer Einheit (2 Byte) darstellen, für manche braucht es 2 (also 4 Byte), bei denen man dann auf geschickte Weise bestimmte Bits extrahieren muss, um an das Zeichen zu kommen. Ich lege daher beim täglichen Programmieren keinen gesteigerten Wert darauf (auch wenn ich der Auffassung bin, dass man es schonmal gesehen haben sollte, aber das geht wie gesagt eben auch in anderen Sprachen).

Ich glaube, hier kommt einfach ein anderes Paradigma durch: Du willst, wenn Du programmierst, möglichst genau beeinflussen können, was bei der Hardware ankommt. Das ist mir persönlich nicht so wichtig (außer ich will besonders effiziente / zeitkritische Algorithmen schreiben), mir ist es viel wichtiger, in einer Programmiersprache einen Algorithmus ausdrücken zu können und es dann dem Compiler / Interpreter zu überlassen, was er denn tatsächlich daraus macht. Ich finde es zum Beispiel bei Haskell extrem geil, dass man beliebig große Zahlen als Integer-Werte nutzen kann. Wie das intern umgesetzt wird, weiß ich nicht, ist mir auch vollkommen egal, ich kann einfach darauf losrechnen und muss mich nicht um so Blödsinnigkeiten wie Integer Overflows und damit verbundene Probleme kümmern.

Nein. Radfahren lernt man auch am besten ohne Stützräder.
Wieso Stützräder? Bis auf den Embedded-Bereich hat man heutzutage einfach keinen Real Mode mehr, ...

Aber gerade dieser Bereich wächst immer noch so rasch, dass man ihn bitte nicht unterschätzen oder für irrelevant halten sollte.

Schon, aber es wird wohl kaum jemand Embedded-Programmierung lernen, ohne vorher Programmiergrundlagen auf normalen Rechnern zu kennen. Und sich *zusätzliches* Wissen anzueignen für ein bestimmtes Feld ist ja nie ein Problem.

Ich will ja nicht sagen, dass Assembler pauschal schlecht ist, ich finde nur, dass Assembler denkbar ungeeignet für Anfänger ist.

Wieso also Konzepte lernen, mit denen man sich während der Lernphase EXTREM ins Knie schießen kann, im praktischen Leben aber in der Form nicht mehr vorkommen?

Weil sie Grundlagenwissen schaffen, das der angehende Programmierer eben in vielen Bereichen *doch* wieder braucht.

Real Mode und Segmentierung? Habe ich außer für persönliche Spielereien mit Assembler noch NIE für irgend etwas praktisches gebraucht, auch nicht, als ich mit Turbo C damals noch unter DOS programmiert habe...

Assembler kann nützlich sein, wenn man vor einem Debugger sitzt. Das war aber auch das einzige Mal, wo ich Assembler außer für's Rumspielen jemals gebraucht hätte.

Wenn der Computer abstürzt, startet er ihn einfach neu, genauso, wie er eine Meldung einfach wegklickt. Das mag zwar etwas lästig sein, richtig weh tut es dem Schüler aber auch nicht - was vmtl. auch daran liegt, dass Benutzer auf Abstürze konditioniert wurden.

Wurden sie?

Ja. Dass es Leute wie Du oder ich gibt, die einen Absturz ernst nehmen, ist die Ausnahme.

Zudem: In Assembler passiert intern viel "Mojo"

Für mich passiert in Javascript, PHP oder C++ viel mehr Voodoo, als du es in Assembler siehst (z.B. Speicherverwaltung, Typecasting).

Aber dieses Voodoo passiert für Dich nur weil Du aus Sicht eines maschinennahen Programmierers an alle Sachen herangehst (naja ok, bei C++ passiert wirklich viel Voodoo, lassen wir die Sprache mal außen vor ;-)). Aber Javascript und PHP machen aus Sicht der restlichen Welt[tm] eben viel weniger Voodoo, weil man einer Zeile viel leichter ansehen kann, was sie denn tatsächlich tut, als einer Assembler-Zeile. Da steckt zwar intern viel mehr dahinter, aber der Effekt der Zeile auf den umgebenden Programmcode auf dem Niveau der Programmiersprache ist viel geringer, als bei Assembler.

Und automatische Speicherverwaltung inklusive automatischem Garbage Collector ist, wenn es richtig umgesetzt ist, eine Sache, die einem sehr viel Arbeit abnimmt und außerdem mit hoher Wahrscheinlichkeit sogar noch effizienter ist (sic!), als malloc/free bzw. pendants. Hierzu empfehle ich den 24C3-Vortrag Automatic memory management, Video dazu.

Viele Grüße,
Christian

[Der Martin]

Hallo,

* Wie funktioniert eine CPU (Prinzip)
* Wie funktioniert das Zusammenspiel von CPU, Speicher, I/O
* Welche Arten von Instruktionen gibt es (Beispiele verschiedener CPUs)
* Wie kann man den Programmfluss strukturieren (Subroutines, Sprünge, Bedingungen)

Die ersten beiden Punkte zu erklären, halte ich noch für sinnvoll, die anderen beiden wiederum nicht. Programmflusssteuerung auf Assembler-Ebene ist nichts, was ich Anfängern beibringen will, weil man da außer Funktionsaufrufen wirklich nur Sprünge und nichts weiteres hat.

und schon allein diese Erkenntnis ist doch interessant. Aber auch das Wissen, dass es einfache CPUs gibt, die wirklich nur addieren, subtrahieren und Werte hin- und hertransferieren können, und andererseits solche, die mit einem einzigen Befehl eine ganze Matrixmultiplikation machen (z.B. spezielle DSPs), finde ich bemerkenswert. Es zeigt dem Lernenden, dass die Prozessoren extrem unterschiedlich sind und daher Verallgemeinerungen auf dieser Ebene selten richtig.

Es sei denn, ich mache etwas sehr hardwarenahes oder muss meinen Algorithmus auf das letzte Quäntchen Performance / Speicherverbrauch optimieren, interessiert es mich ehrlich gesagt nicht die Bohne, wie das intern im Speicher organisiert ist.

Das, unter anderem, unterscheidet uns. ;-)

Und wenn ich Datentypen umwandele, will ich eher logische Umwandlungen als Uminterpretationen.

Je nachdem. Ich kann mich des Eindrucks nicht erwehren, dass du viel zu sehr auf hochkomplexe, leistungsfähige Systeme und entsprechend entwickelte Programmierkonzepte fixiert bist. Unterschätze nicht die Bedeutung und Verbreitung von kleinen und kleinsten Controllern!

Was soll ich mit einem Float als Integer interpretiert?

Nichts sinnvolles. Aber einen Integerwert, der einmal vorzeichenlos deklariert wurde, an einer anderen Stelle vorzeichenbehaftet zu interpretieren, kann oft lästige Fallunterscheidungen und Offset-Jonglage ersparen.

Und auch bei einzelnen Zeichen wird es in Zeiten von Unicode immer sinnloser, da irgend etwas direkt uminterpretieren zu wollen, denn nicht mal UTF-16 kann alle Unicode-Zeichen mit einer Einheit (2 Byte) darstellen, ...

Das ist einer der Gründe, warum ich Unicode nicht mag.

Ich glaube, hier kommt einfach ein anderes Paradigma durch: Du willst, wenn Du programmierst, möglichst genau beeinflussen können, was bei der Hardware ankommt.

Richtig. Ich bin sozusagen eher der Embedded-Programmierer, der diese Philosophie aber gern auch auf größeren Systemen fortsetzt.

mir ist es viel wichtiger, in einer Programmiersprache einen Algorithmus ausdrücken zu können ...

Das eine schließt doch das andere nicht aus!
Ich finde es unheimlich spannend, für einen PIC eine Divisionsroutine zu schreiben, wenn man weiß, dass man wegen des begrenzten Programmspeichers gerade noch 38 Byte dafür zur Verfügung hat.

Ich finde es zum Beispiel bei Haskell extrem geil, dass man beliebig große Zahlen als Integer-Werte nutzen kann. Wie das intern umgesetzt wird, weiß ich nicht, ist mir auch vollkommen egal, ...

Siehste, das finde ich unbefriedigend - ich "muss" wissen, wie es gemacht ist, will das Prinzip durchschauen, nicht nur anwenden.

Umso mehr wundert mich bei dieser Einstellung ("der daraus resultierende Code ist mir egal"), warum die gleichen Leute dann bei der Erstellung von Webseiten den Code möglichst komplett von Hand schreiben, anstatt auf die ach so bequemen Tools zurückzugreifen.

Weil sie Grundlagenwissen schaffen, das der angehende Programmierer eben in vielen Bereichen *doch* wieder braucht.
Real Mode und Segmentierung?

Nu' klammer dich doch nicht an dieser komischen Real-Mode-Segmentierung als Besonderheit der x86-Architektur fest. Es geht ums Prinzip. Ebenso wie ich bedaure, dass in der Fahrschule heutzutage kaum noch auf die Technik eingegangen wird und im Geographieunterricht in der Schule kein Schwein mehr lernt, welche Bundesländer Deutschland ausmachen und wo welche Flüsse und Gebirge sind (war zu meiner Gymnasialzeit in den 80ern schon so). Die Grundlagen werden in vielen Gebieten immer mehr vernachlässigt. Und das finde ich schade, teils sogar bedenklich.

Aber ich sehe schon, wir haben recht unterschiedliche Vorstellungen von dem, was "richtig" ist - und das ist gut so. :-)

So long,
 Martin

[Tom]

Hello,

Aber ich sehe schon, wir haben recht unterschiedliche Vorstellungen von dem, was "richtig" ist - und das ist gut so. :-)

Solange sich zukünftige Programmier-Schüler diese Diskussion ansehen können und sich anschließend frei entscheiden dürfen, auf welche der beiden beschriebenen Weisen sie sich Fachkenntnisse aneignen wollen, halte ich den Pluralismus auch für äußerst sinnvoll.

Ein harzliches Glückauf

Tom vom Berg

[at]

Hallo.

Solange sich zukünftige Programmier-Schüler diese Diskussion ansehen können und sich anschließend frei entscheiden dürfen, auf welche der beiden beschriebenen Weisen sie sich Fachkenntnisse aneignen wollen, halte ich den Pluralismus auch für äußerst sinnvoll.

Dumm nur, dass das nicht der Fall ist.
MfG, at

[Christian Seiler]

Hallo Martin,

Die ersten beiden Punkte zu erklären, halte ich noch für sinnvoll, die anderen beiden wiederum nicht. Programmflusssteuerung auf Assembler-Ebene ist nichts, was ich Anfängern beibringen will, weil man da außer Funktionsaufrufen wirklich nur Sprünge und nichts weiteres hat.

und schon allein diese Erkenntnis ist doch interessant.

Bezweifle ich ja nicht. Aber ich halte es für falsch, einen Anfänger mit zu viel Detailwissen über einen spezifischen Prozessor zu überhäufen. Sich mit einem Prozessor auseinandersetzen kann man später immer noch, wenn man mal programmieren kann.

Ich kann mich des Eindrucks nicht erwehren, dass du viel zu sehr auf hochkomplexe, leistungsfähige Systeme und entsprechend entwickelte Programmierkonzepte fixiert bist. Unterschätze nicht die Bedeutung und Verbreitung von kleinen und kleinsten Controllern!

Ich glaube eher, Du bist viel zu sehr auf den Embedded-Bereich fixiert. ;-)

Nichts für ungut, aber die Mehrzahl der Menschen, die was mit Programmierung zu tun haben, sind nunmal nicht im Embedded-Bereich angesiedelt. Der ist zwar enorm wichtig in der Anwendung, aber es arbeiten dort trotzdem viel weniger Programmierer, als in anderen Bereichen (Webentwicklung, Business-Software, ...). Und in eben diesen Bereichen spielen die abstrakteren Ideen der theoretischen Informatik eine größere Rolle, als im Embedded-Bereich.

Zudem bin ich der Auffassung, dass jemand, der eine Hochsprache gut programmieren kann und die Konzepte dahinter verstanden hat, sich viel leichter in Lowlevel-Programmierung einarbeiten kann, als umgekehrt. (Was nicht heißt, dass so jemand keine Schwierigkeiten hat, aber ich bin mir sehr sicher, dass jemand, der mit Lowlevel-Kram angefangen hat, sehr viel mehr Schwierigkeiten hat, wenn er dann später was anderes macht.)

Aber einen Integerwert, der einmal vorzeichenlos deklariert wurde, an einer anderen Stelle vorzeichenbehaftet zu interpretieren, kann oft lästige Fallunterscheidungen und Offset-Jonglage ersparen.

Ja, aber dann bist Du wieder am Mikrooptimieren Deines Algorithmus. Ist für Microcontroller natürlich sehr wichtig. Aber der Programmcode wird dadurch auch um einiges schwieriger zu lesen, d.h. dann darf man gleich wieder anfangen, extrem ausführlich zu kommentieren, wenn man in 6 Monaten noch verstehen will, was der Code da genau macht. Zudem: Compiler sind heute schon extrem gut, würde mich nicht wundern, wenn die das teilweise schon selbst hinoptimieren können mit der Integer-Uminterpretations-Geschichte.

Und auch bei einzelnen Zeichen wird es in Zeiten von Unicode immer sinnloser, da irgend etwas direkt uminterpretieren zu wollen, denn nicht mal UTF-16 kann alle Unicode-Zeichen mit einer Einheit (2 Byte) darstellen, ...

Das ist einer der Gründe, warum ich Unicode nicht mag.

Und was willst Du stattdessen nehmen? Es gibt nunmal extrem viele Schriften (engl. "script", nicht "font") auf diesem Planeten, irgendwie muss man die ja organisieren.

Ich glaube, hier kommt einfach ein anderes Paradigma durch: Du willst, wenn Du programmierst, möglichst genau beeinflussen können, was bei der Hardware ankommt.

Richtig. Ich bin sozusagen eher der Embedded-Programmierer, der diese Philosophie aber gern auch auf größeren Systemen fortsetzt.

Und meine Auffassung ist es, dass diese Philosophie bei komplexeren Systemen zu schlechtem Design führt.

mir ist es viel wichtiger, in einer Programmiersprache einen Algorithmus ausdrücken zu können ...

Das eine schließt doch das andere nicht aus!
Ich finde es unheimlich spannend, für einen PIC eine Divisionsroutine zu schreiben, wenn man weiß, dass man wegen des begrenzten Programmspeichers gerade noch 38 Byte dafür zur Verfügung hat.

Spannend ja, keine Frage (ich interessiere mich ja auch für alles mögliche). Aber wenn ich ein größeres Projekt programmiere will ich mir eben keine Gedanken darüber machen müssen, wie eine Division in der Programmiersprache genau funktioniert, ich will sie einfach nutzen können. Ein Algorithmus fängt bei mir dann erst bei sowas wie Quicksort an, alles darunter muss die Programmiersprache für mich erledigen (und selbst für sowas wie Sortieren erwarte ich eigentlich schon vorimplementierte Algorithmen in der Standardbibliothek der Programmiersprache).

Ich finde es zum Beispiel bei Haskell extrem geil, dass man beliebig große Zahlen als Integer-Werte nutzen kann. Wie das intern umgesetzt wird, weiß ich nicht, ist mir auch vollkommen egal, ...

Siehste, das finde ich unbefriedigend - ich "muss" wissen, wie es gemacht ist, will das Prinzip durchschauen, nicht nur anwenden.

Du verstehst mich vielleicht falsch: Ich habe selbst auch eine inhärente Neugierde, wie etwas funktioniert und halte das nicht für falsch. Mich interessieren Algorithmen, mit denen man beliebig große Zahlen effizient darstellen kann, auch. Allerdings ist dieses Interesse meinerseits rein akademischer Natur: Wenn ich dann tatsächlich ein Programm schreibe, das etwas tun soll, dann will ich vor allem, dass das Programm funktioniert - unabhängig von der Frage, wie genau.

Umso mehr wundert mich bei dieser Einstellung ("der daraus resultierende Code ist mir egal"), warum die gleichen Leute dann bei der Erstellung von Webseiten den Code möglichst komplett von Hand schreiben, anstatt auf die ach so bequemen Tools zurückzugreifen.

HTML programmiert man ja auch nicht. ;-)

(Und ich meine das durchaus ernst, da ist IMHO wirklich ein Unterschied.)

Weil sie Grundlagenwissen schaffen, das der angehende Programmierer eben in vielen Bereichen *doch* wieder braucht.
Real Mode und Segmentierung?

Nu' klammer dich doch nicht an dieser komischen Real-Mode-Segmentierung als Besonderheit der x86-Architektur fest.

Hier hast Du mit dem Zitieren was durcheinander gebracht, wenn Du eine ebene höher Schaust, war das mit "Grundlagenwissen" eine Antwort auf die Frage »Wieso also Konzepte lernen, mit denen man sich während der Lernphase EXTREM ins Knie schießen kann, im praktischen Leben aber in der Form nicht mehr vorkommen?« - und die Frage meinerseits bezog sich schon auf Real Mode und Segmentierung. Und wenn Du darauf mit "Grundlagenwissen" antwortest, dann frage ich halt schon mal nach. Aber gut, dass wir uns einig sind, dass Real Mode nicht zu den Dingen gehört, die man als Anfänger wissen muss. ;-)

Es geht ums Prinzip. Ebenso wie ich bedaure, dass in der Fahrschule heutzutage kaum noch auf die Technik eingegangen wird [...weitere Beispiele...]

Achtung, Du vermischst hier ja zwei Dinge. Mir ging es hier um folgendes: Wie lernt man am geschicktesten überhaupt erst einmal das Programmieren, d.h. womit fängt man an? Es ging mir hier nicht um die Frage: Was wäre ein geeignetes Wissen, was man zum Beispiel aus dem Informatikunterricht in der Schule mitnehmen könnte?

Ich bin nunmal der Auffassung, dass man das Lowlevel-Zeug für das Erlernen der Programmierfertigkeit an sich erst einmal weglassen sollte. Das heißt im Umkehrschluss nicht, dass man das gar nicht lernen soll, nur ist es in meinen Augen ein extrem ungeeigneter Startpunkt. Ich könnte mir daher gut vorstellen, dass man in der Schule in Jahr X im Informatikunterricht "Einfache Algorithmen und Datenstrukturen" and Hand einer Hochsprache lernt und dann im Jahr X+1 erst Lowlevel-Kram macht und sich dann zum Beispiel mal auch Assembler oder C-Derivate auf einem µC ansieht - aber halt eben erst, wenn die Schüler schon programmieren können. Aber mit Assembler anzufangen halte ich für einen großen Fehler, es dürfte extrem wenig Schüler geben, die auf diesem Weg richtig Programmieren lernen können.

Viele Grüße,
Christian

[Vinzenz Mai]

Hallo

Es geht ums Prinzip. Ebenso wie ich bedaure, dass in der Fahrschule heutzutage kaum noch auf die Technik eingegangen wird [...weitere Beispiele...]

Achtung, Du vermischst hier ja zwei Dinge. Mir ging es hier um folgendes: Wie lernt man am geschicktesten überhaupt erst einmal das Programmieren, d.h. womit fängt man an? Es ging mir hier nicht um die Frage: Was wäre ein geeignetes Wissen, was man zum Beispiel aus dem Informatikunterricht in der Schule mitnehmen könnte?

[...] Aber mit Assembler anzufangen halte ich für einen großen Fehler, es dürfte extrem wenig Schüler geben, die auf diesem Weg richtig Programmieren lernen können.

insbesondere, wenn ich an eine normale Gymnasialklasse denke mit ca. 60 Schulstunden eines Halbjahres (20 Wochen à 3 Wochenstunden), zu denen vielleicht eine Zeitstunde für Hausaufgaben je Woche dazugerechnet werden darf. Das reicht für eine Einführung ins Programmieren am Beispiel einer Hochsprache meiner Meinung nach gerade aus, jede Stunde Assembler wäre vergeudete Zeit und würde bei mindestens 75% (eher 90%) der Schüler nur zu Frust führen, statt das Thema interessant und spannend aufzubereiten.

Ich halte sowohl trockene Theorie als auch Assembler für den Einstieg denkbar ungeeignet. Das Halbjahr wird weder den Schülern noch dem Lehrer viel Freude bereiten.

Freundliche Grüße

Vinzenz

[Der Martin]

Hi,

[...] Aber mit Assembler anzufangen halte ich für einen großen Fehler, es dürfte extrem wenig Schüler geben, die auf diesem Weg richtig Programmieren lernen können.
insbesondere, wenn ich an eine normale Gymnasialklasse denke mit ca. 60 Schulstunden eines Halbjahres (20 Wochen à 3 Wochenstunden), zu denen vielleicht eine Zeitstunde für Hausaufgaben je Woche dazugerechnet werden darf.

Moment mal: Ich habe nie angenommen, dass es um normalen Schulunterricht geht - es war die Rede von "Programmieren lernen". In welcher Schule werden solche Lehrinhalte vermittelt?

Die wenigen Schüler, mit denen ich gelegentlich plaudere (überwiegend Gymnasium), berichten, dass es zwar einen sogenannten Informatik-Unterricht gibt, die Lehrinhalte sich aber mit sehr oberflächlichen, vor allem rein anwenderbezogenen Themen erschöpfen: Wie bediene ich Windows, was kann ich mit Office machen, wie schreibe ich eine Mailnachricht, wie surfe ich im Internet, was ist das Internet, was wird da geboten. Von "Programmieren lernen" keine Spur.

Deswegen bezog ich mich auf Leute, die sich aus freien Stücken entschieden haben, so etwas zu lernen - sei es in Abendkursen, im Studium oder im Rahmen einer anderen technischen Ausbildung. Oder sogar als Hobby - das war's für mich viele Jahre hauptsächlich.

jede Stunde Assembler wäre vergeudete Zeit und würde bei mindestens 75% (eher 90%) der Schüler nur zu Frust führen, statt das Thema interessant und spannend aufzubereiten.

Wenn wir tatsächlich von Schülern reden, stimme ich zu. Den Eindruck hatte ich aber im restlichen Thread nicht.

Schönen Tag noch,
 Martin

[Christian Seiler]

Hallo Martin,

Moment mal: Ich habe nie angenommen, dass es um normalen Schulunterricht geht - es war die Rede von "Programmieren lernen". In welcher Schule werden solche Lehrinhalte vermittelt?

Naja, ich habe 3 verschiedene Gymansien besucht, an denen zumindest versucht wurde, den Schülern Programmieren beizubringen (im Informatikunterricht). Mit unterschiedlichem Erfolg für die anderen Schüler, das war extrem lehrerabhängig. (Ich klammere mich dabei einfach mal aus, weil ich noch als sehr kleines Kind bereits angefangen habe, mir selbst das Programmieren beizubringen und es in der Schule daher bereits konnte.)

Deswegen bezog ich mich auf Leute, die sich aus freien Stücken entschieden haben, so etwas zu lernen - sei es in Abendkursen, im Studium oder im Rahmen einer anderen technischen Ausbildung. Oder sogar als Hobby

Aber auch diese Situation ändert in meinen Augen nichts an der Frage, womit man am besten anfängt - und das bleibt in meinen Augen immer noch eine Hochsprache. Es gibt natürlich Ausnahmen, zum Beispiel jemanden, der eine Ausbildung zum Embedded-Programmierer macht oder ähnliches. ;-)

Viele Grüße,
Christian

[Tom]

Hello,

[...] Ich klammere mich dabei einfach mal aus, weil ich noch als sehr kleines Kind bereits angefangen habe, mir selbst das Programmieren beizubringen und es in der Schule daher bereits konnte.

*grins* Christian, der Mozart unter den Programmierern ;-)

Aber das bringt mir so einiges in Erinnerung zurück.

Boolsche Algebra am Beispiel von Relaisschaltungen und später DIL-Chips
X1
Fortran
Basic
Algol 60 / 68
??? irgendeine grausame rekursive, deren Namen ich vergessen habe und glücklicherweise nicht lange benutzen musste
dBase               da kam das erste Stutzen
Turbo Pascal
Assembler           da hat es eigentlich erst "Klick" gemacht
RPG
Cobol
C
C++                 (leider nicht ernsthaft, aber das hole ich ja jetzt nach)
usw...

Ich habe die vielen Programmiersprachen, mit denen ich vor dem ernsthaften Assembler-Kontakt gearbeitet habe, alle nicht wirklich verstanden gehabt. Bei dBase habe ichndas erste Mal gestutzt, denn da konnte man "ganz einfach" zusätzliche Module aus anderen Sprachen (hauptsächlich C) eininden. Wie das geht und was dahintersteckt, habe ich dann eben erst durch intensive Assembler-Programmerung verstanden.

Diese Erkenntnis hätte ich sehr viel eher haben können und dann hätte ich vielleicht auch sofort C gelernt...

Ein harzliches Glückauf

Tom vom Berg

[Blaubart]

Tach.

Naja, ich habe 3 verschiedene Gymansien besucht, an denen zumindest versucht wurde, den Schülern Programmieren beizubringen (im Informatikunterricht). Mit unterschiedlichem Erfolg für die anderen Schüler, das war extrem lehrerabhängig. (Ich klammere mich dabei einfach mal aus, weil ich noch als sehr kleines Kind bereits angefangen habe, mir selbst das Programmieren beizubringen und es in der Schule daher bereits konnte.)

Interessante Sache. Wie/womit hast Du den Einstieg gefunden und in welcher Sprache hast Du Deine ersten Gehversuche gemacht?

[Christian Seiler]

Hallo,

(Ich klammere mich dabei einfach mal aus, weil ich noch als sehr kleines Kind bereits angefangen habe, mir selbst das Programmieren beizubringen und es in der Schule daher bereits konnte.)

Interessante Sache. Wie/womit hast Du den Einstieg gefunden und in welcher Sprache hast Du Deine ersten Gehversuche gemacht?

Ich habe damals doch tatsächlich noch mit Visual Basic und QBasic angefangen, das war noch zu Windows 3.1- und DOS 6-Zeiten. Nachdem mir Basic aber ziemlich schnell zu blöd wurde, habe ich mich dann in Richtung Pascal orientiert (erst Turbo Pascal für DOS, dann Delphi für Windows 3.x als die 1.0 veröffentlicht wurde). Bei allem was danach kam, kann ich mich an die Reihenfolge nicht mehr so genau erinnern (C war glaube ich als nächstes dran). Beigebracht habe ich mir alles im Prinzip autodidaktisch durch Lesen von Büchern (damals waren zum beispiel die Handbücher, die mitkamen, noch ihr Geld wert) und hauptsächlich Trial&Error.

Viele Grüße,
Christian

[Blaubart]

Tach.

Ich habe damals doch tatsächlich noch mit Visual Basic und QBasic angefangen, das war noch zu Windows 3.1- und DOS 6-Zeiten. Nachdem mir Basic aber ziemlich schnell zu blöd wurde, habe ich mich dann in Richtung Pascal orientiert.

Also auf einem kleinen Umweg doch genau bei einer der klassischen "Lehrsprachen" gelandet. Mich hätte es allerdings auch nicht gewundert, hier stattdessen etwas von Fortran zu lesen. ;)

Ich habe mich auch schon gefragt, welche Sprachen sich gut für den Einstieg eignen, was man Kindern zumuten kann, ohne daß es gleich zu abgehoben wird, ... Eigentlich geht's ja auch gar nicht darum, einen Pascal/C/VB/sonstwas-Programmierer auszubilden, sondern die Grundlagen zu vermitteln: algorithmisches Denken, Abstraktionsvermögen etc. Die Programmiersprache selber hilft einem dabei in der Regel nicht sonderlich, also sollte man vielleicht für den Einstieg eine auswählen, die einen möglichst wenig dabei stört. Ich finde unter diesem Gesichtspunkt kleine Applikationen, die in einer bewußt beschränkten Skriptsprache programmiert werden können, recht gut geeignet. Irgendein Roboter, den man mit einer Handvoll vorgefertigter Befehle, Schleifen, Verzweigungen durch ein Labyrinth jagen kann oder etwas in der Art.

[Vinzenz Mai]

Hallo Martin,

[...] Aber mit Assembler anzufangen halte ich für einen großen Fehler, es dürfte extrem wenig Schüler geben, die auf diesem Weg richtig Programmieren lernen können.
insbesondere, wenn ich an eine normale Gymnasialklasse denke mit ca. 60 Schulstunden eines Halbjahres (20 Wochen à 3 Wochenstunden), zu denen vielleicht eine Zeitstunde für Hausaufgaben je Woche dazugerechnet werden darf.

Moment mal: Ich habe nie angenommen, dass es um normalen Schulunterricht geht - es war die Rede von "Programmieren lernen". In welcher Schule werden solche Lehrinhalte vermittelt?

ich zitiere Marcel:

Auf der anderen Seiten wird Java halt überall benutzt und wenn Klassen in der Obestufe gemischt werden und die einen Pyhton und die anderen Java gemacht haben, wird es schwierig. Zudem habe ich Kollegen, die immer noch TurboPascal unterrichten.

Aus diesem Absatz leitete ich Schulunterricht am Gymnasium/Gesamtschule in der Mittelstufe ab.

Deswegen bezog ich mich auf Leute, die sich aus freien Stücken entschieden haben, so etwas zu lernen - sei es in Abendkursen, im Studium oder im Rahmen einer anderen technischen Ausbildung.

Auch hier zöge und ziehe ich die Hochsprache vor. Um Programmieren zu lernen, eine Hochsprache. Hab' ich für meinen eigenen Kurs, den ich an der Abendschule halte, auch so konzipiert :-)

Selbstverständlich spricht nichts gegen einen Spezialkurs (Zusatz, keine Pflicht, außer in dem von Christian angesprochenen Fall) in einem x-beliebigen, aber anwendbaren Assembler.

Freundliche Grüße

Vinzenz

[Længlich]

Nginda wunydjangum!

Was mich persöndlich an Java für den Unterricht stört ist folgendes:

1. public void main.....
      Direkt vom Anfang recht komplex

Also wenn dir das schon komplex erscheint ... wow, wie deklariert man denn in anderen Sprachen Funktionen bzw. Methoden mit und ohne Rückgabewerte?

In den meisten Sprachen fängt eine Datei (Script / Ressource / ...) mit etwas schwarzer Magie an, die Anfänger nicht verstehen. Z.B. gehört ja auch der Doctype in HTML zu den Dingen, die man mit als letztes kapiert. Wenn ich einem Anfänger Tips gebe, gebe ich ihm einfach einen Doctype vor, den er in jede neue Datei als erstes reinkopieren soll. Dazu gibt's eine Billig-Erklärung (sinngemäß: Der Browser hat mehrere Darstellungsmodi, und ohne diese Zeile geht er in den falschen); die richtige Erklärung kommt, wenn die Grundlagen geklärt sind.

Analog würde ich es bei Java u.ä. machen: Eine Musterdatei mit einer Klasse und einer main() vorgeben und dazusagen, an welcher Stelle der eigene Code eingefügt werden muß. Schlüsselwörter wie public kann man sowieso nicht erklären, solange die Grundlagen der Objektorientierung noch unbekannt sind, und die kommen ja normalerweise erst nach den Übungen zu Schleifen etc.

2. Klammerung
      Die Fehlersuche bei Schülern ist sehr mühsam, da nich eingerückt wird und
      völlig beliebig geklammert und gelöscht wird. Das würde bei Python
      wegfallen.

Unser Lehrer ist auch immer ausgerastet, wenn nicht ordentlich eingerückt wurde. Damals dachten wir, der übertreibt, inzwischen verstehe ich ihn vollkommen. ;-)

4. Erzeugen von exe'n für verschiedenen Betriebssysteme
      Das ist für die Schüler sehr wichtig, da so ein eigenes Programm einfach
      sehr befriedigend sein kann.

Ja, "exe" muß sein! Andere Sachen, die nur in einer bestimmten Umgebung laufen, fühlen sich für Anfänger einfach nicht wie richtige Programme an.

Dennoch habe ich immer wieder Schüler, die mit so etwas
for (int i = 0;i<10;i++)

völlig überfordert sind.

Wie machst du es in Python, wie in VB, wie in **** ? Ist gibt immer eine Grammatik die man lernen muss, scheissegal, welche Sprache.

Das stimmt schon, aber z.B. die Visual-Basic-Variante

For i = 0 To 9  
    ...  
Next i

ist für Anfänger viel einfacher zu verstehen und zu merken als der Zeichenbandwurm aus der C-Welt.

Ansonsten ist das reine Gewöhnungssache, man lernt es genauso wie im Französischen die Satzstellung ... oder die Formel für den Radius eines Kreises.

Das stimmt, und jede neue Programmiersprache ist leichter zu lernen als die erste, weil man immer irgendwelche Konzepte wiedererkennt. Aber die spannende Frage ist eben, mit welcher man am besten anfängt. Ich bin da selbst unschlüssig. Ich habe autodidaktisch mit Visual Basic angefangen.
Vorteile:

• leicht zu lesen
• wenig schwarze Magie in den Code-Dateien
• einfache englische Funktionsnamen in den Standardbibliotheken, die man auch mal erraten kann (nicht stristr und so'n Zeug)
• macht eine "richtige exe" (auch wenn man inzwischen das .NET-Framework braucht)

Nachteile:

• keine Unterscheidung zwischen Zuweisungs- und Vergleichsoperator (beides =, Mehrfachzuweisungen sind nicht möglich), das sorgt beim Umstieg auf andere Sprachen für Verwirrung
• Befehle werden nur durch Zeilenumbruch beendet, das führt beim Umstieg auf z.B. Java zum notorischen Vergessen des Semikolons
• keine Zeiger (von denen Anfänger zwar sowieso die Finger lassen sollten, die man aber später mal lernen sollte, auch dann, wenn man sie kaum benutzt)
• case-insensitiv, auch dadurch entstehen böse Überraschungen beim Umstieg

Diese Vor- und Nachteile beziehen sich jetzt natürlich nur auf den Einsatz zum Lernen. Bei der Frage, ob VB für ein bestimmtes Projekt geeignet ist, können sie ganz anders liegen.

Viele Grüße vom Længlich

[at]

Hallo.

Nachteile:

Die aufgeführten Nachteile sind allesamt marginal, wenn man den Schülern erklärt, dass es dort Unterschiede gibt, die irgendwann einmal wichtig werden könnten. Wer programmieren kann, lässt sich jedenfalls durch solche Kleinigkeiten nicht ausbremsen.
MfG, at

[ritschmanhard]

Hi marcel!

Wie auch immer. In mir stieg die Frage hoch, wie es wohl mit den Computern und den Programmen so weiter gehen wird.

Das Problem der kommenden Jahre im Bereich der Programmierung sehe ich bei
den Softwarepatenten. Hier könnte es durchaus dazu kommen, dass nur noch "Big Player" Software veröffentlichen können und kleinere Programmierer einfach in die Steinzeit zurück-verklagt werden.
Open source und (L)GPL werden mit etwas Glück an Bedeutung gewinnen und zumindest teilweise das alte Modell der Softwarelizenz aufweichen, so dass das Geld dann im Dienstleistungsbereich (Stichworte: Customizing, Setup, Wartung) verdient wird (vergleiche hierzu:http://www.heise.de/newsticker/Sun-Geld-verdienen-mit-Open-Source--/meldung/110126/from/rss09).

Seid ihr auch der Meinung, dass in Zukunft immer mehr Programmen "nur noch" im Browser ablaufen werden und Techniken wie AJAX für Endanwenderprogramme die Oberhand bekommen werden? Sprachen wie Java, C/C++ etc. werden nur von "wenigen" Profis entwickelt um das "Frontend" AJAX oä. zu bedienen? So könnte man von jedem Computer (Job-Workstation, daheim-Computer, unterwegs-Handheld) auf die immer gleichen Dateien zugreifen und damit arbeiten. Bei den aktuellen erscheinenden miniPCs a la eeePC sollte das fast nichts großes mehr sein.

Hier wird sich das Feld teilen: Während es für Unternehmen aus den verschiedensten Gründen vorteilhaft ist, eine zentrale Server-Client Struktur aufzubauen (als Beispiel nenne ich: zentrales Backup, koordiniertes Entwickeln über Versioning-systeme, Zentrale Wartbarkeit (updates) u.v.a.)
ist es bei Privatanwendern wohl so, dass ein Wunsch nach einem eigenen Computer mit eigener Umgebung bestehen bleibt. Dieser Wunsch resultiert aus menschlichen Denkmustern (diese sind: mein PC = persönliches Besitzen wollen, Bequemlichkeit = keine ungewollte Änderung des Systems von außen u.v.a.).

Aber wie sieht das dann mit der Datensicherheit aus? Ist es beispielsweise sicher seine Steuererklärung in einer Online-Anwendung zu machen?

Hä? Du gibst Daten an den Staat weiter und fragst nach Datensicherheit? Wenn du sie an deine Haustür nageln würdest, würden sicher weniger Leute davon Kenntnis haben.
Problematischer würde ich heutzutage sehen, wie es sich mittlerweile beim Versenden privater Mails verhält (Stichwort: Terrorbekämpfung und Generalverdacht) - und meine Schüler mit PGP in Kontakt bringen.

Wie wird die Zukunft sein? Auf was bereitet ihr euch vor die jeden Tag mit Kunden umgehen müssen? Was erwarten diese?

Kunden werden Flexibilität verlangen - also nicht eine vorhersehbare Programmiersprache, sondern das, was in ihrem Umfeld eingesetzt wurde/wird. Deshalb ist die eigentliche, gelehrte Sprache weniger wichtig. Vielmehr sollte ein Grundverständnis der wichtigen Strukturen (Schleifen, Verzweigungen, das Pointer Prinzip, Objekte und Methoden u.a.) idealerweise vermittelt werden. Die jeweils vom Kunden geforderte Sprache erfordert dann "Einarbeitungszeit".
Auch sollte den Schülern, die tatsächlich in diesem Bereich arbeiten wollen, klar gemacht werden, dass man gerade im Bereich Informatik nie auslernt und immer weiterlernen muß.

Viele Grüße,
Richard