Python contra BlueJ

[guidofranke]

Hallo alle miteinander!

Ich stehe vor einer mittelschweren Entscheidungsfrage:

Ab dem nächsten Schuljahr (2008-09) wollen wir in der SEK II, also am
Gymnasium (GHG-Wismar) die Prgrammiersprache für OOP-Entwicklung
wechseln. Zurzeit arbeiten wir noch ausschließlich mit Delphi (7.0),
müssen uns aber wohl oder Übel für eine andere entscheiden.

BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???

So nun seid Ihr gefragt:

Was soll ich vorbereiten?
Was macht PYTHON (außer seiner unabhängigkeit von SUN) attraktiv, um es
BlueJ vorzuziehen?
Ich muss gestehen, dass ich beide Sprachen nur sehr oberflächlich kenne,
Bücher angeschafft habe (Java lernen mit BlueJ von Barnes/König und OOP
mit Python von Michael Weigland, beide in der 3. Auflage).

Trotzdem bin ich immer noch unentschlossen.
Da ich ab dem 21.7.2008 unsere PC-Anlage umstellen werde, würde ich
diese Entscheidung gern vorher treffen. Alternativ bliebe natürlich,
beide Sprachsysteme vollständig zu implementieren und dann flexibel zu
bleiben. Der Installationsaufwand scheint mir bei BlueJ höher zu sein,
da ja Python mit knapp 13MB sehr klein ausfällt,oder hab ich da nun was
übersehen?

Gibt es für Python auch eine Entwicklungsumgebung unter Windows?
Unsere Schüler tun sich mit der von mir geliebten DOS-Umgebung sehr
schwer. (Was man nicht mit der Maus bedienen kann, ...)

Ich bitte um Eure qualifizierte Entscheidungshilfe.

Guido Franke
FranSoft.de IT-Service

[Wolfgang Fellger]

Post by guidofranke
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.

BlueJ ist eine IDE, Python eine Programmiersprache. Äpfel, Birnen.

Geht es dir um Java vs. Python als Lehrsprache, oder die Verfügbarkeit einer
"besseren" IDE (wobei du hier noch ausführen darfst welche Faktoren dir
wichtig sind)?
Weder Java noch Python entsprechen der "reinen OOP-Lehre", verfolgen aber
recht unterschiedliche Ansätze. Es könnte daher interessant sein, beides
anzusprechen.

Post by guidofranke
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???

Bitte nur ein Satzzeichen.

Post by guidofranke
Gibt es für Python auch eine Entwicklungsumgebung unter Windows?

Das mitgelieferte IDLE zum Beispiel?

[Stefan Behnel]

Post by Wolfgang Fellger

Post by guidofranke
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.

BlueJ ist eine IDE, Python eine Programmiersprache. Äpfel, Birnen.

Eben. Wenn es darum gehen soll, den Umgang mit einer IDE zu lernen, kommen
beide Sprachen in Frage. Auch für Python gibt es gute IDEs, aber die für Java
sind trotzdem nur recht schwer zu schlagen.

Wenn es aber darum geht, Programmierung zu lernen, grundlegende Sprachkonzepte
und vielleicht auch funktionale Programmierung, dann kann ich von Java nur
abraten. Allein die Komplexität wirkt auf Schüler sicherlich eher
abschreckend, und als Lernsprache ist es schon gar nicht zu gebrauchen.
Spätestens wenn es auch darum geht, nicht-außerschulisch-Vorbegabte
anzusprechen, dann ist Python in jedem Fall die bessere Wahl.

Wer einmal Python verstanden hat und damit programmieren kann, kann sicherlich
auch andere Sprachen verstehen und anwenden. Aber mit Java anzufangen ist wie
den Berg rückwärts an der Zahnradbahn vorbei raufzugehen.

Stefan

[Markus Heiser]

Moin Guido,

sorry folgendes ist nicht bös gemeint aber symptomatisch
für den Schul- und Hochschulbetrieb: ihr hattet bisher
Delphi und beim Wechsel der Sprache denkt ihr an die IDE.
Programmieren ist immer noch ein 'Tipp-Abenteuer' und das
sollte einem Schüler auch vermittelt werden.

Jede Sprache hat ihre Stärken und schwäche, die Lehre
gehört in den Mittelpunkt, welche Inhalte sollen vermittelt
werden? Die Wahl der Sprache sollte sich daran orientieren.

Wenn es darum geht ganz allgemein Prg-Konzepte grob zu
vermittel kann eine syntaktisch einfache und dynamisch
typisierende Sprache wie Python eine gute Wahl sein
zumal sie unterschiedliche Konzepte (zumindest im Ansatz)
unterstütz.

Ihr wollt einen einfachen Einstieg für Eure Schüler, in
sofern kann ich es schon verstehen das die Wahl der
Sprache auch schnell mal an der Wahl der IDE fest gemacht
wird.

... du hast es selber schon angedeutet: 'Python' ist verglichen
mit 'Java' recht schlank, das 'zieht sich durch die Sprache
und die Werkzeuge auch so durch'; einen Editor zu starten,
ein paar Zeilen zu tippen und dann zu schauen wie der
Interpreter sich über das eigene Werk beschwert scheint
mir auch nicht schwerer als die Bedienung einer IDE (BlueJ
kenne ich nicht) zu erlernen.

Es gibt auch für Python verschiedenste IDEs, aber Deine
Schüler sollten nicht mit der IDE kämpfen sondern sich
besser auf Sprache und Inhalt konzentrieren, wenn am
Ende Deiner Lehrtätigkeit der Schüler die IDE nicht
von der Sprache trennen kann ist was schief gelaufen ;-)

Ich war bisher nicht im Lehrbetrieb tätig, kann deshalb
auch keinen Hasen aus dem Hut zaubern, aber es gibt ein
sehr nettes Python Projekt, das sich mit einer
plattformunabhängigen GUI auseinandersetzt 'wxPython'

http://www.wxpython.org/

Bitte lass Dich nicht von der, für Jugendliche sicherlich
etwas langweiligen Internetseite abschrecken, lade Dir die
binaries runter

http://www.wxpython.org/download.php#binaries

und installiere auch die Docs und Demo. Am besten machst Du
das erst mal auf einer Plattform die Dir am besten liegt.

In der Demo findest Du unter anderem ....

----
PyCrust An application that provides an interactive
Python shell and also namespace inspectors.

Editra A simple yet powerful programmer's editor.
----

spiel mal ein wenig mit dem PyCrust rum und mach Deine
ersten Python 'Tipp-Erfahrungen. Mit 'Editra' hast Du
gleich noch einen Editor im Paket.

Wenn man dann weiter gehen will und mit Oberflächen
arbeiten möchte kann man sich die wxPython-Demos anschauen
(obwohl ich denke, das lenkt eher vom Inhaltlichen ab).

Mit der Installation von Python plus wxPython hat man eigentlich
alles was man für den 'Einstieg braucht, weitere Vorteil für Deine
Schüler ist die Verfügbarkeit auf allen gängigen Plattformen.

Gleich welche Wahl, immer mit Spass dabei ;-)

-- MArkus --

[Torsten Bronger]

Hallöchen!

[...]
Ich war bisher nicht im Lehrbetrieb tätig, kann deshalb auch
keinen Hasen aus dem Hut zaubern, aber es gibt ein sehr nettes
Python Projekt, das sich mit einer plattformunabhängigen GUI
auseinandersetzt 'wxPython'
http://www.wxpython.org/

Ich hab wxPython wirklich lieb, das Buch steht hier im Regal, aber
wenn auch das *erzeugen* einer GUI in SII angedacht ist, ist Python
in meinen Augen raus. Ich denke, der OP sollte mal genau darlegen,
was so auf dem Lehrplan steht.

Tschö,
Torsten.

[Markus Heiser]

Post by Torsten Bronger
Ich hab wxPython wirklich lieb, das Buch steht hier im Regal, aber
wenn auch das *erzeugen* einer GUI in SII angedacht ist, ist Python

sorry, da konnte man mich falsch verstehen; ich wollte eigentlich nicht
auf die GUI entwicklung abziehlen, ich dachte mir nur das man mit
pyCrust eine shell hat die auch einem anfänger gefällt.

Post by Torsten Bronger
in meinen Augen raus. Ich denke, der OP sollte mal genau darlegen,
was so auf dem Lehrplan steht.

ja, ich glaub den armen guido haben wir und unsere Flame Kollegen ganz
verschreckt, zumindest hört man nichts mehr von ihm;

... guido lebst Du noch ...


-- Markus --

[guidofranke]

Post by Markus Heiser

Post by Torsten Bronger
Ich hab wxPython wirklich lieb, das Buch steht hier im Regal, aber
wenn auch das *erzeugen* einer GUI in SII angedacht ist, ist Python

sorry, da konnte man mich falsch verstehen; ich wollte eigentlich nicht
auf die GUI entwicklung abziehlen, ich dachte mir nur das man mit
pyCrust eine shell hat die auch einem anfänger gefällt.

Post by Torsten Bronger
in meinen Augen raus. Ich denke, der OP sollte mal genau darlegen,
was so auf dem Lehrplan steht.

ja, ich glaub den armen guido haben wir und unsere Flame Kollegen ganz
verschreckt, zumindest hört man nichts mehr von ihm;
... guido lebst Du noch ...
-- Markus --

Sorry, wenn ich tot war. Musste auf die Hochzeit unseres großen (29) und
komme gerade aus der Schule...

[Torsten Bronger]

Hallöchen!

Post by guidofranke
Ab dem nächsten Schuljahr (2008-09) wollen wir in der SEK II, also
am Gymnasium (GHG-Wismar) die Prgrammiersprache für
OOP-Entwicklung wechseln. Zurzeit arbeiten wir noch ausschließlich
mit Delphi (7.0), müssen uns aber wohl oder Übel für eine andere
entscheiden.
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl
gekommen. Viele meiner Kollegen bevorzugen BlueJ einige Wenige
PYTHON!!!???

Ich habe bilang nur mit Delphis IDE gearbeitet und habe mir gerade
dieses BlueJ heruntergeladen. Also als Delphi-Benutzer finde ich
mich in BlueJ überhaupt nicht zurecht. Die Art, dort ein Projekt zu
erstellen und auszuführen ist in meinen Augen höchst ungewöhnlich.
Und in der Lehre ist ungewöhnlich keine gute Eigenschaft.

Auch wenn auf dem Etikett "für Schüler" stehen mag, ist das so
verquer, daß ich das dieser Zielgruppe nicht antun wollte.
Vielleicht haben sich IDEs in den letzten Jahren *sehr* verändet
(ich kenne VS und Eclipse nicht), aber wenn Delphi da immer noch
einigermaßen repräsentativ ist, dann laß die Finger von BlueJ.

Damit sage ich ausdrücklich nichts gegen Java als Sprache für euren
Zweck, nur gegen BlueJ.

Post by guidofranke
[...]
Was soll ich vorbereiten?
Was macht PYTHON (außer seiner unabhängigkeit von SUN) attraktiv,
um es BlueJ vorzuziehen?

Schwer zu sagen. Beides sind ausgereifte, weit verbreitete
Sprachen. Ich kenne Java nur vom Hingucken und von vielen dutzend
Seiten, die ich über diese Sprache gelesen habe.

Mit Python kommt man definitiv schneller in die Füße. Allein die
Boilerplate von Java ist gewiß abschreckend. Bei Python hingegen
fängt man mit print "Hallo" an und arbeitet sich weiter. Das
betrifft zwar nur den Bereich der Miniprogramme, aber so richtig
darüberhinaus kommt man in der Schule ja auch nicht. Python
skaliert quasi besser abwärts. ;-)

Ich halte von Pythons IDLE nicht viel, aber für euren Zweck scheint
es geradezu ideal zu sein. Es bietet genau so viel, wie man
vermitteln kann, und der Schritt von IDLE zu einer der "großen"
IDEs, den dann einzelne Schüler privat, beruflich oder akademisch
machen könnten, erscheint mir ganz natürlich. Im Gegensatz zu BlueJ
als Startpunkt ...

Das einzige kleine Problem, das ich bei Python sehe, ist ihre
hoch-dynamische Natur. Wenn ich heute nochmal zu C++ wechseln muß,
ist das schon ein gewisses Umdenken, und wenn ich noch nie in einer
statischen Sprache gearbeitet hätte, stelle ich mir das schwer vor.
Allerdings sollten das Leute, die das später beruflich machen,
durchaus hinbekommen; außerdem wird man in der Schule kaum mehr
Dynamik machen als Namensbindungen.

Grundsätzlich ist Python "weiter weg vom Metall". Das ist für die
Einführung von Anfängern in jedem Falle ein dicker Pluspunkt. Die
Grundlagen der Hardware bekommen die Anwärter auf ein Info-Studium
noch früh genug beigebracht, bzw. kennen sie schon.

Tschö,
Torsten.

[Sebastian Wiesner]

Post by Torsten Bronger
Grundsätzlich ist Python "weiter weg vom Metall".

Darf man mal fragen, wie du auf diesen Unsinn (imho) kommst?

[Torsten Bronger]

Hallöchen!

Post by Sebastian Wiesner

Post by Torsten Bronger
Grundsätzlich ist Python "weiter weg vom Metall".

Darf man mal fragen, wie du auf diesen Unsinn (imho) kommst?

(Diese Wendung ist nicht von mir.)

In statischen Sprachen hat man mit der Eigenart der real
existierenden (=Metall) Prozessortypen zu tun, daß sie nicht
beliebige Dinge an bestimmten Speicherzellen ablegen können, sondern
daß im Vorfeld genau wissen müssen, was da hinkommt.

Deshalb läßt sich Java durch Kompilation *erheblich* einfacher in
eine Sprache bringen, die der Prozessor nahezu direkt ausführen
kann. Deshalb benutzt man bei Python -- auch auf absehbare Zeit --
eine Zwischenschicht.

Gut, wenn man jemand einen Prozessor für dynamische Sprachen
schnitzt, dann wäre Python wieder nahe am Metall, aber naja ... ;-)

Tschö,
Torsten.

[Sebastian Wiesner]

Post by Torsten Bronger
Hallöchen!

Post by Sebastian Wiesner

Post by Torsten Bronger
Grundsätzlich ist Python "weiter weg vom Metall".

Darf man mal fragen, wie du auf diesen Unsinn (imho) kommst?

(Diese Wendung ist nicht von mir.)
In statischen Sprachen hat man mit der Eigenart der real
existierenden (=Metall) Prozessortypen zu tun, daß sie nicht
beliebige Dinge an bestimmten Speicherzellen ablegen können, sondern
daß im Vorfeld genau wissen müssen, was da hinkommt.
Deshalb läßt sich Java durch Kompilation *erheblich* einfacher in
eine Sprache bringen, die der Prozessor nahezu direkt ausführen
kann. Deshalb benutzt man bei Python -- auch auf absehbare Zeit --
eine Zwischenschicht.

Ja und? Was hat die Kompilierung mit der Hardwarenähe einer Sprache zu tun?
Anders gefragt: Was hilft es, wenn der Compiler Speicher füllen kann, die
Sprache aber keinerlei Möglichkeit bietet, auf diesen zuzugreifen? ;)

Natürlich könnte man jetzt argumentieren, dass man Zeiger als Sprachelement
einführen könnte, nur ... kann man dann ja auch gleich C++ nutzen. Java
zeichnet sich nun mal durch "Hardwareferne" aus, weswegen es auch keine
Zeiger oder ähnliches in der Sprache gibt.

Im Übrigen ist das eh ziemlich akademisch, weil weder Java noch Python C auf
Mikrocontrollern Konkurrenz machen können, und auf größeren
Embedded-Geräten eh vollwertige Betriebssysteme laufen, so dass man gar
nicht mehr in Hardwarenähe programmiert.

[Torsten Bronger]

Hallöchen!

Post by Torsten Bronger

Post by Sebastian Wiesner

Post by Torsten Bronger
Grundsätzlich ist Python "weiter weg vom Metall".

Darf man mal fragen, wie du auf diesen Unsinn (imho) kommst?

(Diese Wendung ist nicht von mir.)
In statischen Sprachen hat man mit der Eigenart der real
existierenden (=Metall) Prozessortypen zu tun, daß sie nicht
beliebige Dinge an bestimmten Speicherzellen ablegen können,
sondern daß im Vorfeld genau wissen müssen, was da hinkommt.
Deshalb läßt sich Java durch Kompilation *erheblich* einfacher in
eine Sprache bringen, die der Prozessor nahezu direkt ausführen
kann. Deshalb benutzt man bei Python -- auch auf absehbare Zeit
-- eine Zwischenschicht.

[...] Anders gefragt: Was hilft es, wenn der Compiler Speicher
füllen kann, die Sprache aber keinerlei Möglichkeit bietet, auf
diesen zuzugreifen? ;)
Natürlich könnte man jetzt argumentieren, dass man Zeiger als
Sprachelement einführen könnte, nur ... kann man dann ja auch
gleich C++ nutzen.

Nix gegen dich, eher gegen mich, aber bis hierhin verstehe ich nur
Bahnhof.

Java zeichnet sich nun mal durch "Hardwareferne" aus, weswegen es
auch keine Zeiger oder ähnliches in der Sprache gibt.

Java ist hardwareferner als C++, dennoch ist man Restriktionen
unterworfen, die dynamisch typisierte Sprachen zugunsten der
besseren Gehirn-Freundlichkeit nicht haben. Java hat diese
Restriktionen, um besser mit dem realen Prozessor zurechtzukommen.

Im Übrigen ist das eh ziemlich akademisch, weil weder Java noch
Python C auf Mikrocontrollern Konkurrenz machen können,

Das ist hier aber nicht das Thema. Es geht um die
Gehirn-Freundlichkeit. Das, was BASIC seinerzeit so erfolgreich
gemacht hat, wird in dynamischen Sprachen weitergedacht, nämlich
einfach überall a=1 schreiben zu dürfen.

Tschö,
Torsten.

[Sebastian Wiesner]

Post by Torsten Bronger
Hallöchen!

Post by Torsten Bronger

Post by Sebastian Wiesner

Post by Torsten Bronger
Grundsätzlich ist Python "weiter weg vom Metall".

Darf man mal fragen, wie du auf diesen Unsinn (imho) kommst?

(Diese Wendung ist nicht von mir.)
In statischen Sprachen hat man mit der Eigenart der real
existierenden (=Metall) Prozessortypen zu tun, daß sie nicht
beliebige Dinge an bestimmten Speicherzellen ablegen können,
sondern daß im Vorfeld genau wissen müssen, was da hinkommt.
Deshalb läßt sich Java durch Kompilation *erheblich* einfacher in
eine Sprache bringen, die der Prozessor nahezu direkt ausführen
kann. Deshalb benutzt man bei Python -- auch auf absehbare Zeit
-- eine Zwischenschicht.

[...] Anders gefragt: Was hilft es, wenn der Compiler Speicher
füllen kann, die Sprache aber keinerlei Möglichkeit bietet, auf
diesen zuzugreifen? ;)
Natürlich könnte man jetzt argumentieren, dass man Zeiger als
Sprachelement einführen könnte, nur ... kann man dann ja auch
gleich C++ nutzen.

Nix gegen dich, eher gegen mich, aber bis hierhin verstehe ich nur
Bahnhof.

Ich bemesse Hardwarenähe nicht an der Art der Kompilierung, sondern an den
Möglichkeiten, die mir eine Sprache zum Zugriff auf die Hardware gibt.

Anders gesagt: Statische Typisierung hilft mir als Programmierer nicht, wenn
ich _hardwarenah_ programmieren möchte, dazu braucht es Sprachfeatures wie
Zeiger. Und diese Sprachfeatures bieten weder Python noch Java.

Ich kann z.B. weder in Java noch in Python Programme schreiben, die auf
Mikroprozessoren ohne Betriebssystem laufen, da beide Sprachen am
Speichermanagement des Betriebssystems hängen.

Post by Torsten Bronger

Im Übrigen ist das eh ziemlich akademisch, weil weder Java noch
Python C auf Mikrocontrollern Konkurrenz machen können,

Das ist hier aber nicht das Thema. Es geht um die
Gehirn-Freundlichkeit. Das, was BASIC seinerzeit so erfolgreich gemacht
hat, wird in dynamischen Sprachen weitergedacht, nämlich einfach überall
a=1 schreiben zu dürfen.

Das Thema war gerade Hardwarenähe. Und ob dynamische Sprachen
tatsächlich "gehirnfreundlicher" sind, sei mal dahingestellt. Für manchen
ist es eingänglicher, Objekte über den Typ anstatt über das Verhalten zu
definieren. Und dank Type Inference funktioniert "a=1" auch in statischen
Sprachen, boo und cobra lesen sich größtenteils wie Python, obwohl beide
zumindest teilweise statisch sind.

[Torsten Bronger]

Hallöchen!

Post by Sebastian Wiesner
[...]
Anders gesagt: Statische Typisierung hilft mir als Programmierer
nicht, wenn ich _hardwarenah_ programmieren möchte, dazu braucht
es Sprachfeatures wie Zeiger. Und diese Sprachfeatures bieten
weder Python noch Java.

Du schüttest dabei das Kind mit dem Bade aus: Du versetzt dich nun
in einen Programmierer, der möglichst hardwarenah programmieren will
und das richtige Tool dafür sucht. Dabei landet man bei C. Aber da
will der OP ja nun gar nicht hin.

Der möchte eine Entscheidung zwischen Sprachen treffen, die ohnehin
schon sehr weit abstrahieren, und dabei geht Python eben noch einen
Schritt weiter als Java. (Es gibt dafür auch einiges auf; das tut
es ja nicht für nichts.)

Post by Sebastian Wiesner
[...]

Post by Torsten Bronger
Das ist hier aber nicht das Thema. Es geht um die
Gehirn-Freundlichkeit. Das, was BASIC seinerzeit so erfolgreich
gemacht hat, wird in dynamischen Sprachen weitergedacht, nämlich
einfach überall a=1 schreiben zu dürfen.

Das Thema war gerade Hardwarenähe. Und ob dynamische Sprachen
tatsächlich "gehirnfreundlicher" sind, sei mal dahingestellt. Für
manchen ist es eingänglicher, Objekte über den Typ anstatt über
das Verhalten zu definieren.

Ich bezweifle allerdings, daß es sich dabei um Anfänger handelt.
Nur meine Einschätzung.

Post by Sebastian Wiesner
Und dank Type Inference funktioniert "a=1" auch in statischen
Sprachen, boo und cobra lesen sich größtenteils wie Python, obwohl
beide zumindest teilweise statisch sind.

Allerdings bekommt man die Annehmlichkeiten von Type Inference auch
nicht umsonst; es verlangt eine Sorgfalt, die ebenso für Anfänger
eher ungeeignet ist.

Ich bleibe dabei: Die dynamischen Sprachen abstrahieren die zugrunde
liegende reale Maschine am gründlichsten, und ich persönlich halte
diese Eigenschaft gerade für die Ausbildung von völligen Neulingen
für sehr interessant.

Tschö,
Torsten.

[Sebastian Wiesner]

Post by Torsten Bronger

Post by Sebastian Wiesner
Anders gesagt: Statische Typisierung hilft mir als Programmierer
nicht, wenn ich _hardwarenah_ programmieren möchte, dazu braucht
es Sprachfeatures wie Zeiger. Und diese Sprachfeatures bieten
weder Python noch Java.

Du schüttest dabei das Kind mit dem Bade aus: Du versetzt dich nun
in einen Programmierer, der möglichst hardwarenah programmieren will
und das richtige Tool dafür sucht. Dabei landet man bei C. Aber da
will der OP ja nun gar nicht hin.

Genau genommen hat der OP nie von Hardware gesprochen, was den Schluss nahe
legt, dass es ihm sowas von egal ist, ob nun Python oder Java näher an der
Hardware ist ...

Post by Torsten Bronger
Der möchte eine Entscheidung zwischen Sprachen treffen, die ohnehin
schon sehr weit abstrahieren, und dabei geht Python eben noch einen
Schritt weiter als Java. (Es gibt dafür auch einiges auf; das tut
es ja nicht für nichts.)

Du machst diesen Unterschied nur an der Typisierung fest, was völlig
realitätsfremd ist. In der Praxis hat die Art der Typisierung keinen
Einfluss darauf, ob man nun mit einer Sprache hardwarenah programmieren
kann. Insofern ist die ganze Diskussion rein akademisch.

Post by Torsten Bronger

Post by Sebastian Wiesner
Und dank Type Inference funktioniert "a=1" auch in statischen
Sprachen, boo und cobra lesen sich größtenteils wie Python, obwohl
beide zumindest teilweise statisch sind.

Allerdings bekommt man die Annehmlichkeiten von Type Inference auch
nicht umsonst; es verlangt eine Sorgfalt, die ebenso für Anfänger
eher ungeeignet ist.

Ein Anfänger wird zwischen einem Stück boo-Code mit Type-Inferenz und dem
entsprechenden Python-Stück eh keinen Unterschied sehen.

F'Up gesetzt, da ziemlich OT

[Torsten Bronger]

Hallöchen!

Post by Sebastian Wiesner
[...]
Genau genommen hat der OP nie von Hardware gesprochen, was den
Schluss nahe legt, dass es ihm sowas von egal ist, ob nun Python
oder Java näher an der Hardware ist ...

Eben.

Post by Sebastian Wiesner

Post by Torsten Bronger
Der möchte eine Entscheidung zwischen Sprachen treffen, die
ohnehin schon sehr weit abstrahieren, und dabei geht Python eben
noch einen Schritt weiter als Java. [...]

Du machst diesen Unterschied nur an der Typisierung fest, was
völlig realitätsfremd ist. In der Praxis hat die Art der
Typisierung keinen Einfluss darauf, ob man nun mit einer Sprache
hardwarenah programmieren kann.

Was auch immer du mit "Einfluß" meinst, aber es besteht eine
deutliche Korrelation zwischen der Art der Typisierung und der
Hardwarenähe.

Post by Sebastian Wiesner
[...]
F'Up gesetzt, da ziemlich OT

Wie bitte??!

Tschö,
Torsten.

[Arne Becker]

Mir sind in meiner Ausbildung bis jetzt C++ in der Berufsschule und
Java im Studium unter bekommen. Wie schon erwähnt kommt es drauf an
was ihr vermitteln wollt. Um nur die Strukturen einer
Programmiersprache (if-else, Schleifen, OOP) zuvermitteln ist Python
besonders ind er SEKII sicher einfacher. Allerdings muss man beachten
das es Python keine so explizite Typenunterscheidung gibt wie in JAVA.
Ich fand es immer ganz sinnvol erstmal zu erklären wie Zahlen und
Buchstaben im PC dargestellt und gespeichert werden. Und da man bei
Java mehr auf die Typen achten muss sollte man das vielleicht als
Lehrsprache nehmen. Python achtet ja eher weniger auf richtige typen
definition

gruß arne

[Marc 'BlackJack' Rintsch]

Post by Arne Becker
Mir sind in meiner Ausbildung bis jetzt C++ in der Berufsschule und
Java im Studium unter bekommen. Wie schon erwähnt kommt es drauf an
was ihr vermitteln wollt. Um nur die Strukturen einer
Programmiersprache (if-else, Schleifen, OOP) zuvermitteln ist Python
besonders ind er SEKII sicher einfacher. Allerdings muss man beachten
das es Python keine so explizite Typenunterscheidung gibt wie in JAVA.
Ich fand es immer ganz sinnvol erstmal zu erklären wie Zahlen und
Buchstaben im PC dargestellt und gespeichert werden. Und da man bei
Java mehr auf die Typen achten muss sollte man das vielleicht als
Lehrsprache nehmen. Python achtet ja eher weniger auf richtige typen
definition

Das ist mir ein wenig zu schwammig formuliert. Auch bei Python muss man
darauf achten kompatible Typen zu verwenden. Nur dass das "kompatibel"
nicht an einem Typnamen festgemacht wird, sondern ob sich das Objekt
entsprechend verhält. Man muss sich also genau so Gedanken darüber machen
wie bei Java. Gilt umgekehrt für Java auch, denn das eine Klasse einen
bestimmten Typnamen und Methoden mit festgelegter Signatur hat, bedeutet
nicht automatisch, dass es sich die Objekte auch korrekt verhalten.

Wie Buchstaben im PC dargestellt werden ist gar nicht so einfach zu
erklären, da selbst langjährige Programmierer, die das Thema scheuen,
Probleme mit dem Zusammenhang Zeichen, Kodierungen, und Bytes haben.

Ciao,
Marc 'BlackJack' Rintsch

[Matthias Bläsing]

Hey,

Post by Torsten Bronger

Post by guidofranke
Ab dem nächsten Schuljahr (2008-09) wollen wir in der SEK II, also am
Gymnasium (GHG-Wismar) die Prgrammiersprache für OOP-Entwicklung
wechseln. Zurzeit arbeiten wir noch ausschließlich mit Delphi (7.0),
müssen uns aber wohl oder Übel für eine andere entscheiden.
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???

Ich habe bilang nur mit Delphis IDE gearbeitet und habe mir gerade
dieses BlueJ heruntergeladen. Also als Delphi-Benutzer finde ich mich
in BlueJ überhaupt nicht zurecht. Die Art, dort ein Projekt zu
erstellen und auszuführen ist in meinen Augen höchst ungewöhnlich. Und
in der Lehre ist ungewöhnlich keine gute Eigenschaft.

Ich weiß ja nicht was ihr als IDE bezeichnet, aber BlueJ ist es IMHO
nicht. Es ist eine Hilfe für das Verständnis und die Visualisierung von
Java Objekten. Die direkte Arbeit mit Objekten, die der User zur Laufzeit
selbst erzeugen kann und auf denen er Methoden aufrufen kann, das ist für
mich der Kern von BlueJ.

Es ist also mehr eine didaktische Umgebung, als eine IDE.

Mfg

Matthias

[Sebastian Wiesner]

Post by guidofranke
Was soll ich vorbereiten?

Das, was du bzw. die Lehrer können. Es hat keinen Sinn, einen
Java-Programmierer Python unterrichtet zu lassen. Was dabei rauskommt,
sieht man am Galileo Openbook, dass eigentlich Java mit Pythonsyntax
beibringt.

Und wenn die Mehrzahl der Lehrer nur Java gut kann, dann sollte Java die
erste Wahl sein, es sei denn, jeder einzelne ist bereit, sich in die
Paradigmen von Python einzuarbeiten. Ich halte Java mit Sicherheit nicht
für eine didaktisch geeignete Sprache zum Unterricht in objektorientierter
Programmiererung, aber lieber eine suboptimale Sprache richtig lehren, als
eine an sich gute Sprache falsch lehren. Davon haben die Schüler dann auch
mehr.

Post by guidofranke
Trotzdem bin ich immer noch unentschlossen.
Da ich ab dem 21.7.2008 unsere PC-Anlage umstellen werde, würde ich
diese Entscheidung gern vorher treffen. Alternativ bliebe natürlich,
beide Sprachsysteme vollständig zu implementieren und dann flexibel zu
bleiben. Der Installationsaufwand scheint mir bei BlueJ höher zu sein,
da ja Python mit knapp 13MB sehr klein ausfällt,oder hab ich da nun was
übersehen?

Ich denke nicht, dass du bei dieser Betrachtung den Installationsaufwand
einbeziehen solltest. Die Installation ist eine einmalige Sache, bei der
Mehraufwand zwar bedauerlich, nicht aber katastrophal ist. Mit der
getroffenen Entscheidung müssen Lehrer und Schüler allerdings auf längere
Zeit leben, falsche Entscheidungen werden dann katastrophal.

Im Übrigen sollte die Installation dank moderner Imaging-Tools auch keine
allzu schwere Aufgabe sein, selbst wenn ein Stück Software mal etwas
komplizierter ist.

Post by guidofranke
Gibt es für Python auch eine Entwicklungsumgebung unter Windows?

eric 4, wing IDE, komodo, etc. IDEs gibt es mehr als genug. Ich persönlich
halte allerdings nichts davon, IDEs als Mittel im Unterricht einzusetzen.
Im Zweifelsfall lernen die Schüler nur, Knöpfchen zu drücken, anstatt sich
um die dahinter liegenden Konzepte Gedanken zu machen.

Für den Anfang ist imho ein Editor, der Syntaxhighlighting und die
Möglichkeit, Programme aus dem Editor heraus zu übersetzen und auszuführen,
bietet, völlig ausreichend. Sinnvolle IDE-Features wie Refactoring oder
Debugging werden im Unterricht wohl eh kaum eingesetzt.

[Torsten Bronger]

Hallöchen!

Post by Sebastian Wiesner
[...]
Und wenn die Mehrzahl der Lehrer nur Java gut kann, dann sollte
Java die erste Wahl sein, es sei denn, jeder einzelne ist bereit,
sich in die Paradigmen von Python einzuarbeiten. Ich halte Java
mit Sicherheit nicht für eine didaktisch geeignete Sprache zum
Unterricht in objektorientierter Programmiererung, aber lieber
eine suboptimale Sprache richtig lehren, als eine an sich gute
Sprache falsch lehren. Davon haben die Schüler dann auch mehr.

Das sehe ich anders. Ich behaupte mal frisch von der Leber weg, daß
ich auf S II-Niveau nahezu jedes Algol/C++-Derivat nach ein paar
Tagen Einarbeitungszeit vermitteln könnte. Du hast völlig recht,
daß Programmiersprachen-Wechsler dazu neigen, schlechte Muster zu
verwenden, aber in meinen Augen tritt das bei den
Spielzeugprogrammen eines Anfängerkurses nicht zutage.

(Wenn das überhaupt eingefleischte Java-Only-Kenner sind; zur Zeit
wissen wir nur, daß sie BlueJ bevorzugen.)

Tschö,
Torsten.

[Marc 'BlackJack' Rintsch]

Post by Torsten Bronger

Post by Sebastian Wiesner
[...]
Und wenn die Mehrzahl der Lehrer nur Java gut kann, dann sollte
Java die erste Wahl sein, es sei denn, jeder einzelne ist bereit,
sich in die Paradigmen von Python einzuarbeiten. Ich halte Java
mit Sicherheit nicht für eine didaktisch geeignete Sprache zum
Unterricht in objektorientierter Programmiererung, aber lieber
eine suboptimale Sprache richtig lehren, als eine an sich gute
Sprache falsch lehren. Davon haben die Schüler dann auch mehr.

Das sehe ich anders. Ich behaupte mal frisch von der Leber weg, daß
ich auf S II-Niveau nahezu jedes Algol/C++-Derivat nach ein paar
Tagen Einarbeitungszeit vermitteln könnte. Du hast völlig recht,
daß Programmiersprachen-Wechsler dazu neigen, schlechte Muster zu
verwenden, aber in meinen Augen tritt das bei den
Spielzeugprogrammen eines Anfängerkurses nicht zutage.

Oh doch! Da werden dann fröhlich Variablen "deklariert", indem am Anfang
erst einmal alle verwendeten Namen an ein Objekt des Typs gebunden werden,
den "die Variable später auch aufnimmt", Listen werden grundsätzlich über
Indexe angesprochen, wenn man Pech hat wird der Index dann auch noch in
einer ``while``-Schleife "per Hand" erhöht, alles wird in Klassen gesteckt,
usw.

Ich würde auch empfehlen die Sprache zu verwenden, mit denen die Lehrer am
glücklichsten sind. Wenn der Lehrer "gegen" statt "mit" der Sprache
programmiert, haben die Schüler da sicher nicht so viel von.

Ansonsten wäre ich natürlich eher für Python, was in einer
Python-Newsgroup wahrscheinlich nicht weiter verwunderlich ist. Aber dazu
müssten die Lehrer auch Ahnung von OOP haben und zum Beispiel vermitteln,
dass es dabei um Objekte geht, die miteinander kommunizieren um ein
Problem zu lösen, das aber nicht heisst, dass man dafür zwingend Klassen
benötigt. Etwas was Java-Leuten erst einmal fremd erscheinen mag.

Ciao,
Marc 'BlackJack' Rintsch

[Torsten Bronger]

Hallöchen!

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger

Post by Sebastian Wiesner
[...]
Und wenn die Mehrzahl der Lehrer nur Java gut kann, dann sollte
Java die erste Wahl sein, es sei denn, jeder einzelne ist
bereit, sich in die Paradigmen von Python einzuarbeiten. Ich
halte Java mit Sicherheit nicht für eine didaktisch geeignete
Sprache zum Unterricht in objektorientierter Programmiererung,
aber lieber eine suboptimale Sprache richtig lehren, als eine an
sich gute Sprache falsch lehren. Davon haben die Schüler dann
auch mehr.

Das sehe ich anders. Ich behaupte mal frisch von der Leber weg,
daß ich auf S II-Niveau nahezu jedes Algol/C++-Derivat nach ein
paar Tagen Einarbeitungszeit vermitteln könnte. Du hast völlig
recht, daß Programmiersprachen-Wechsler dazu neigen, schlechte
Muster zu verwenden, aber in meinen Augen tritt das bei den
Spielzeugprogrammen eines Anfängerkurses nicht zutage.

Oh doch! Da werden dann fröhlich Variablen "deklariert", indem am
Anfang erst einmal alle verwendeten Namen an ein Objekt des Typs
gebunden werden, den "die Variable später auch aufnimmt", Listen
werden grundsätzlich über Indexe angesprochen, wenn man Pech hat
wird der Index dann auch noch in einer ``while``-Schleife "per
Hand" erhöht, alles wird in Klassen gesteckt, usw.

Unter ersterem kann ich mir nichts vorstellen, den Rest finde ich
gut so. Die Leute sollten programmieren lernen, nicht Python. Im
übrigen ist es argumentativ zu leicht, einfach vom Worst Case
auszugehen. Es gibt auch gute Lehrer.

Außerdem kommen auch immer wieder neue Lehrer, was also die ersten
zwei, drei können, ist eh beliebig.

Tschö,
Torsten.

[Sebastian Wiesner]

Post by Torsten Bronger
Hallöchen!

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger

Post by Sebastian Wiesner
[...]
Und wenn die Mehrzahl der Lehrer nur Java gut kann, dann sollte
Java die erste Wahl sein, es sei denn, jeder einzelne ist
bereit, sich in die Paradigmen von Python einzuarbeiten. Ich
halte Java mit Sicherheit nicht für eine didaktisch geeignete
Sprache zum Unterricht in objektorientierter Programmiererung,
aber lieber eine suboptimale Sprache richtig lehren, als eine an
sich gute Sprache falsch lehren. Davon haben die Schüler dann
auch mehr.

Das sehe ich anders. Ich behaupte mal frisch von der Leber weg,
daß ich auf S II-Niveau nahezu jedes Algol/C++-Derivat nach ein
paar Tagen Einarbeitungszeit vermitteln könnte. Du hast völlig
recht, daß Programmiersprachen-Wechsler dazu neigen, schlechte
Muster zu verwenden, aber in meinen Augen tritt das bei den
Spielzeugprogrammen eines Anfängerkurses nicht zutage.

Oh doch! Da werden dann fröhlich Variablen "deklariert", indem am
Anfang erst einmal alle verwendeten Namen an ein Objekt des Typs
gebunden werden, den "die Variable später auch aufnimmt", Listen
werden grundsätzlich über Indexe angesprochen, wenn man Pech hat
wird der Index dann auch noch in einer ``while``-Schleife "per
Hand" erhöht, alles wird in Klassen gesteckt, usw.

Unter ersterem kann ich mir nichts vorstellen, den Rest finde ich
gut so.

class Spam(object):
egg = 0

def __init__(self, egg):
self.egg = egg

Das wäre eine völlig unsinnige Deklaration, die man allerdings sehr oft bei
Leuten sieht, die von Java zu Python kommen, ohne sich tiefer mit Python
beschäftigt zu haben. Die sind es gewohnt, Instanzattribute bei der
Klassendeklaration ebenfalls zu deklarieren, und machen das fröhlich weiter
in Python, obwohl es eigentlich Blödsinn ist.

Post by Torsten Bronger
Die Leute sollten programmieren lernen, nicht Python.

So? Und was ist an einer Index-Schleife nun idiomatischer als an einem
Iterator?

# bad
i = 0
while i < len(spam):
do_something(spam[i])
i += 1

vs.

# ugly
for i in xrange(len(spam)):
do_something(spam[i])

vs.

# good
for egg in spam:
do_something(egg)

Die ersten beiden Formen sind schlicht kein guter Python-Code, und
schlechten Code sollte man gar nicht erst lehren. Im Übrigen sind
indizierte Schleifen keineswegs in irgendeiner Weise "typisch". Im
Gegenteil, die meisten modernen Sprachen bieten bessere Alternativen: C#,
Java, Ruby, Perl, alle haben Iteratoren. Sogar für C++ gibt es in Boost
und Qt4 Implementierungen mit Makros, die unzähligen Funktor-Bibliotheken
nicht mitgezählt.

Sorry, aber wer "for(int i=0; i<length; ++i)" immer noch für die Kür der
(Schleifen-)Programmierung hält, ist irgendwann Anfang dieses Jahrtausends
in der Entwicklung stehen geblieben ...

Post by Torsten Bronger
Außerdem kommen auch immer wieder neue Lehrer, was also die ersten
zwei, drei können, ist eh beliebig.

Ein unwilliger Lehrer kann mehr kaputt machen als zwei gute Lehrer
beibringen können. Wenn man sowas durchzieht, müssen alle ausnahmslos
dahinter stehen, sonst überträgt sich der Unwillen des Lehrer auf die
Schüler ...

[Torsten Bronger]

Hallöchen!

Post by Sebastian Wiesner
[...]
egg = 0
self.egg = egg
Das wäre eine völlig unsinnige Deklaration, die man allerdings
sehr oft bei Leuten sieht, die von Java zu Python kommen, ohne
sich tiefer mit Python beschäftigt zu haben.

Also zum einen spekulieren wir hier fröhlich herum, wie klug die
Lehrer an der Schule des OPs sind, zum anderen kann ich mir weiß
Gott schlimmeren Programmier-Unterricht vorstellen, als den Kleinen
diesen Code vorzusetzen, gelinde gesagt. ;-)

Post by Sebastian Wiesner
[...]

Post by Torsten Bronger
Die Leute sollten programmieren lernen, nicht Python.

So? Und was ist an einer Index-Schleife nun idiomatischer als an
einem Iterator?

Ich habe Iteratoren (allerdings die C++-Version) erst vor ein paar
Jahren verstanden, obwohl ich da schon 10 Jahre Pascal hinter mir
hatte. Einfach einen Zähler hochsetzen geht in jeder Sprache und
ist schnell kapiert.

Allerdings ist das alles für mich ohnehin zu spekulativ, sorry. Wer
wirklich als "alter Hase" sich diese Basics in Python nicht binnen
ein paar Stunden beibringen kann, wird auch als Java-Dozent nichts
taugen.

Tschö,
Torsten.

[Stefan Behnel]

Post by Torsten Bronger

Post by Sebastian Wiesner
[...]
egg = 0
self.egg = egg
Das wäre eine völlig unsinnige Deklaration, die man allerdings
sehr oft bei Leuten sieht, die von Java zu Python kommen, ohne
sich tiefer mit Python beschäftigt zu haben.

Also zum einen spekulieren wir hier fröhlich herum, wie klug die
Lehrer an der Schule des OPs sind, zum anderen kann ich mir weiß
Gott schlimmeren Programmier-Unterricht vorstellen, als den Kleinen
diesen Code vorzusetzen, gelinde gesagt. ;-)

Zumindest, wenn er korrekt erklärt wird. Oben wird "egg" nämlich sowohl als
Klassenattribut gebraucht, als auch als Instanzattribut. Unsinnig ist daran
erstmal gar nichts.

Stefan

[Marc 'BlackJack' Rintsch]

Post by Marc 'BlackJack' Rintsch
Oh doch! Da werden dann fröhlich Variablen "deklariert", indem am
Anfang erst einmal alle verwendeten Namen an ein Objekt des Typs
gebunden werden, den "die Variable später auch aufnimmt", […]

Unter ersterem kann ich mir nichts vorstellen, […]

So etwas hier:

spam = 0
ham = list()
eggs = ""

ham = [str(2**n) for n in xrange(input())]
spam = len(ham)
eggs = ', '.join(ham)

Also wie man das von Pascal, C usw. kennt erst einmal alle Namen
"deklarieren" und den richtigen Typ geben.

Ciao,
Marc 'BlackJack' Rintsch

[Torsten Bronger]

Hallöchen!

Post by Marc 'BlackJack' Rintsch

Post by Marc 'BlackJack' Rintsch
Oh doch! Da werden dann fröhlich Variablen "deklariert", indem
am Anfang erst einmal alle verwendeten Namen an ein Objekt des
Typs gebunden werden, den "die Variable später auch aufnimmt",
[…]

Unter ersterem kann ich mir nichts vorstellen, […]

spam = 0
ham = list()
eggs = ""
ham = [str(2**n) for n in xrange(input())]
spam = len(ham)
eggs = ', '.join(ham)

Okay, dem kann man wirklich keine positive Seite abgewinnen.

Tschö,
Torsten.

[Wolfgang Fellger]

Post by guidofranke
Ich bitte um Eure qualifizierte Entscheidungshilfe.

Ach ja: Und bitte keine Multiposts.

Jetzt haben wir zwei Diskussionen in de.comp.lang.java[1] und hier, die
nachher niemand mehr zusammenbringt.

Informiere dich über Crossposting und Follow-Up.

[guidofranke]

Post by Wolfgang Fellger

Post by guidofranke
Ich bitte um Eure qualifizierte Entscheidungshilfe.

Ach ja: Und bitte keine Multiposts.

Wenn ich diese Anfrage an zwei "gegnerische" Gruppen sende, erwarte ich
auch unterschiedliche Antworten.

Wozu also dieses Geplänkel von Multiposts?
STOP!

[Marc 'BlackJack' Rintsch]

Post by guidofranke

Post by Wolfgang Fellger

Post by guidofranke
Ich bitte um Eure qualifizierte Entscheidungshilfe.

Ach ja: Und bitte keine Multiposts.

Wenn ich diese Anfrage an zwei "gegnerische" Gruppen sende, erwarte ich
auch unterschiedliche Antworten.
Wozu also dieses Geplänkel von Multiposts?
STOP!

Bei einem Crosspost könnten die "gegnerischen" Gruppen aber auch
miteinander kommunizieren.

Ciao,
Marc 'BlackJack' Rintsch

[Jan Ulrich Hasecke]

Die Eignung von Python als Unterrichtssprache ist sicher mehrmals untersucht
worden. Ich hab grad nur einen Link zur Hand.

http://www.stadtgespraeche.com/static/Python_und_Zope_als_Unterrichtswerkzeuge.pdf

Sean Kelly hat einen netten Screencast gemacht. Wichtigste Erkenntnis. Man
braucht in Java umgefähr siebenmal so viele Codezeilen um die gleiche
Funktionalität zu programmieren.

--> Recover from Addiction:
http://seankelly.tv/blog/blogentry.2006-07-04.3319928440

juh

www.zope.de

[Michael Ströder]

Post by Jan Ulrich Hasecke
Sean Kelly hat einen netten Screencast gemacht. Wichtigste Erkenntnis. Man
braucht in Java umgefähr siebenmal so viele Codezeilen um die gleiche
Funktionalität zu programmieren.

Das ist genau das, was ich oft Projektkollegen sage. Python skaliert gut
mit der Komplexität des Problems. Man kann kleine Skripts mit wenigen
Zeilen für kleine Probleme schreiben, aber eben auch größere Projekte
für komplexere Sachen sauber implementieren.

Ciao, Michael.

[Dennis Schulmeister]

Hallo Guido,

Post by guidofranke
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???
Was soll ich vorbereiten?

Ich möchte an dieser Stelle einfach mal aus meiner Sicht die Vor- und
Nachteile beider Sprachen beschreiben, was dir meiner Meinung nach wohl
besser hilft, als die recht oberflächliche Diskussion über Metal. :)

Lines of code:
--------------

Klarer Sieg für Python. Im Gegensatz zu Java erbt es seine Syntax nicht
von C/C++ und ist darauf ausgelegt, mit wenigen Zeilen viel zu
erreichen. Das geht sogar soweit, dass Programmblöcke nicht durch
Trennwörter wie BEGIN und END oder Zeichen wie { und } gekennzeichnet
werden, sondern nur durch ihre Einrückung. Somit wird der Code in Python
sehr kompakt und man bekämpft ein typisches Anfängerproblem gleich an
der Wurzel: Code gewordene Kindergeburtstage, sprich unübersichtliche
Einrückungen.

Zum Vergleich, Java:

public class HelloWorld {
public static void main(String[] sArgs) {
System.out.println("Hello World!");
}
}

Und Python:

print "Hello, World"

Wobei man in Python auch eine Klasse verwenden kann:

class HelloWorld(object):
def main():
print "Hello World"
main = staticmethod(main)

if __name__ == "__main__":
HelloWorld.main()

Das zweite Python-Beispiel wird im Vergleich zum ersten allerdings auch
deinem Ziel gerecht: OOP zu lehren!

Du siehst, egal welche Sprache, wenn du OOP unterrichtest, hast du am
Anfang IMMER einen gewissen Boiler-Plate-Code, den die Schüler nicht
verstehen. Das ist aber nicht tragisch. Den gibt man eben als
Grundgerüst vor und weist darauf hin, dass die Schüler nach Abschluss
der Vorlesung oder des Schuljahres in der Lage sein werden, ihn zu
verstehen. Man kann halt nur einen Fuß vor den anderen setzen.

Typisierung und Paradigmen:
---------------------------

Das wurde im Laufe der hiesigen Diskussion ja bereits angesprochen. In
Python verwendet man eine Variable einfach, wenn man sie braucht. Und es
ist auch kein Problem, einer Variable im Laufe ihres Lebens Werte von
unterschiedlichen Typen zuzuweisen:

fruehstueck = "10:00 Uhr"
fruehstueck = 3
fruehstueck = {
"Uhrzeit": "10:00 Uhr",
"Anzahl": 3
}

Das geht in Java natürlich nicht so einfach. Da gibt es nur statische
Typisierung und der einmal festgelegte Datentyp einer Variable ändert
sich auch nicht.

int iFruehstueck = 3
String strFruehstueck = "10:00 Uhr"

Die dritte Frühstücksvariable in meinem Python-Beispiel ist übrigens ein
Dictionary. Dafür gibt es Java leider keine so elegante Entsprechung.
Wohl aber, kennen beide Sprachen die bereits erwähnten Iteratoren:

In Python:

todo = [
"Aufstehen",
"Anziehen",
"Tisch decken",
"Essen",
"Aufräumen",
"In die Arbeit fahren"
]

for task in todo:
print task

Und in Java:

String[] strTodos = {
"Aufstehen",
"Anziehen",
"Tisch decken",
"Essen",
"Aufräumen",
"In die Arbeit fahren"
};

for (String strTask : strTodos) {
System.out.println(strTask);
}

Insgesamt wirkt der Python-Code etwas eleganter, dennoch würde ich den
Punkt hier an Java vergeben. Warum? In Java wird der Code vor der
Ausführung kompiliert, in Python gibt es diesen Schritt nicht zwingend.
Wenn man aber eine Weile mit Java gearbeitet hat, lernt man schnell,
dass der Compiler ein Freund und kein Feind ist. Noch bevor das Programm
überhaupt ausgeführt werden kann, deckt der Compiler Fehler auf, von
denen Pythons Syntaxprüfung beim Programmstart nur träumen kann.

Das heißt, obwohl UnitTests für beide Sprachen unumgänglich sind, ist es
meiner Meinung nach bereits ein schweres Vergehen, Python-Code
auszuliefern, der nicht durch einen ordentlichen Unit-Test geprüft
wurde. Denn 70% der Compilierfehler in Java sind versteckte
Laufzeitfehler in Python!

Standardbibliothek:
-------------------

Hier können beide Sprachen punkten und es gibt meiner Meinung nach
keinen Sieger. Beide Sprachen liefern sehr umfangreiche Bibliotheken
mit, die vorerst nur wenig Wünsche offen lassen. In beiden Fällen
reichen die Funktionen der Bibliotheken von einfachen Kleinigkeiten bis
zur GUI-Pogrammierung. (Wobei ich persönlich Pythons TkInter nicht so
sehr mag wie Javas Swing. Doch auch von letzterem bin ich nicht so
angetan. Das ist jetzt aber nicht Gegenstand der Diskussion)

Programmeditor und Programmausführung:
--------------------------------------

Für beide Sprachen gibt es gute IDEs, die sowohl unter Windows, als auch
unter den gängigen Unix-Systemen laufen. Java-IDEs neigen hier eher zur
Vollständigkeit (z.B. Eclipse oder NetBeans), was einen Anfänger
mitunter überfordern kann. Insgesamt gilt aber, dass für beide Sprachen
ein beliebiger Texteditor mit Syntax-Highlighting genügt. Leider ist
Microsoft nicht in der Lage, einen solchen Texteditor zu programmieren,
so dass man auf Notepad besser nicht zurückgreifen sollte ...

Für Java gibt es einen kleinen, einfachen Editor namens Joe (Java
Oriented Editing). Der kann nicht viel und läuft nur unter Windows. Ist
aber für Anfänger wohl geeignet.

Python hat dafür einen anderen Vorteil: Seinen interaktiven Interpreter.
So ähnlich wie 8-Bit BASIC in den 80er Jahren kann man Pythons
Interpreter starten, ein bisschen Code eintippen und live verfolgen, was
passiert. Für kleine Spielereien reicht das vollkommen. Größere Sachen
sollte man dann aber doch in Dateien (Modulen) speichern. :)

Eine typische Session könnte zum Beispiel so aussehen:

Python 2.5.2 (r252:60911, May 7 2008, 15:21:12)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Post by guidofranke

todos = [

... "Aufstehen",
... "Zähne putzen",
... "Anziehen",
... "Fühstücken"
... ]
... print task
...
Aufstehen
Zähne putzen
Anziehen
Fühstücken
Fazit:
------

It's up to you. Die letztendliche Entscheidung kann ich dir nicht
abnehmen. Aber ich konnte dir hoffentlich einen kleinen Überblick über
beide Sprachen vermitteln.

Meiner Meinung nach sind beide Sprachen sehr gut geeignet, um Schüler
der Sekundarstufe II damit zu konfrontieren und das Argument, dass Java
hierfür ungeeignet sei, kann ich nicht teilen. Während meines Studiums
haben wir auch Programmieren gelernt. Anhand von Java, ausschließlich.
Was soll ich sagen? Es hat jeder geschafft. Und jeder, der anschließend
mit irgend einer anderen Sprache in Berührung kam, konnte sofort
Transferwissen aufbauen. ("Das ist doch so ähnlich wie in Java").

Vielleicht ist hier Java sogar noch besser geeignet als Python, weil es
dem Programmierer nicht so viele Dinge abnimmt. Das heißt, gerade wenn
man anfängt zu programmieren, muss man erst einmal verstehen, was man
dem Computer eigentlich sagt. In Python kann es passieren, dass der
Computer zwar das Richtige macht, ein Anfänger aber nicht genau weiß,
warum. Das ist aber nur meine persönliche Meinung und soll nicht als
verbindlich angesehen werden.


Mit freundlichen Grüßen,
Dennis Schulmeister
--
Volle Kontaktdaten auf WikiBerd: (http://ncc-1701a.homelinux.net)
Complete contact data on WikiBerd: (http://ncc-1701a.homelinux.net)

http://www.denchris.de - http://www.audiominds.com
http://www.motagator.net/bands/65

<GnuPG KeyIDs: B8382C97, 01AD62DE>



Mit freundlichen Grüßen,
Dennis Schulmeister

[Torsten Bronger]

Hallöchen!

Post by Dennis Schulmeister
[...]
Meiner Meinung nach sind beide Sprachen sehr gut geeignet, um
Schüler der Sekundarstufe II damit zu konfrontieren und das
Argument, dass Java hierfür ungeeignet sei, kann ich nicht
teilen. Während meines Studiums haben wir auch Programmieren
gelernt. Anhand von Java, ausschließlich. Was soll ich sagen? Es
hat jeder geschafft. Und jeder, der anschließend mit irgend einer
anderen Sprache in Berührung kam, konnte sofort Transferwissen
aufbauen. ("Das ist doch so ähnlich wie in Java").

Aber Informatik-Studenten und Gymnasiasten sind doch sehr
unterschiedliche Zielgruppen.

Tschö,
Torsten.

[Dennis Schulmeister]

Moin moin,

Post by Torsten Bronger
[...]
Aber Informatik-Studenten und Gymnasiasten sind doch sehr
unterschiedliche Zielgruppen.

Also, ob das auf unseren Kurs so zutrifft, weiß ich nicht. ;)

Da waren einige Frischlinge dabei, die gerade vom Wirtschaftsgymnasium
abgegangen sind und Webseiten bauen für Informatik hielten. (Überspitzt
ausgedrückt)


Mit freundlichen Grüßen,
Dennis Schulmeister

[Volker Grabsch]

Post by Dennis Schulmeister

Post by Torsten Bronger
[...]
Aber Informatik-Studenten und Gymnasiasten sind doch sehr
unterschiedliche Zielgruppen.

Also, ob das auf unseren Kurs so zutrifft, weiß ich nicht. ;)

Wenn ich mir die Uni ansehe: Auch kein großer Unterschied. ;-)

Post by Dennis Schulmeister
Da waren einige Frischlinge dabei, die gerade vom Wirtschaftsgymnasium
abgegangen sind und Webseiten bauen für Informatik hielten. (Überspitzt
ausgedrückt)

Full ACK. Etwas weniger überspitzt:

Im Informatik-Unterricht waren diejenigen gute Programmierer,
die das auch intensiv in ihrer Freizeit gemacht haben. Beim
Studium ist es nicht anders! Es gibt nur zwei Unterschiede:

* Der Anteil der Freizeit-Programmierer ist höher,
(dank Gruppenarbeit erscheint ihr Anteil noch größer)

* Studenten können größeren Spaghetti-Code schreiben,
bevor sie aufgeben müssen.

SCNR.

Bei uns an der Uni ist man deshalb dazu übergegangen, die
Korrektoren vom Programmcode der Studenten fernzuhalten.
Kein Scherz! Die abgegebenen Programme müssen diverse Test-
Suiten durchlaufen, und es werden einige Metriken gemessen
(Abweichungen vom Coding-Stil, Komplexitäts-Metriken, Anteil
von Kommentaren, etc.) Hinzu kommen Ähnlichkeits-Maße, um
Plagiate automatisiert zu erkennen.

Die Maßnahmen an sich sind gar nicht so schlecht. Aber es
wäre IMHO viel wichtiger, wenn besonders elegante Lösungen
herausgeholt und in der Übung besprochen werden. Oder wenn
besonders gut verständliche Kommentierungen gelobt und gezeigt
werden. Der Punkt beim Programmieren ist ja gerade, dass der
Code _von Menschen_ gelesen und verstanden werden soll. Die
Metriken sind nur Hilfsmittel.

Überspitzt ausgedrückt: Ich frage mich, wann die Kommentare
im Quellcode einer Rechtschreib- und Grammatik-Überprüfung
unterzogen werden.


Gruß,

Volker

[Dennis Schulmeister]

Post by Volker Grabsch
Überspitzt ausgedrückt: Ich frage mich, wann die Kommentare
im Quellcode einer Rechtschreib- und Grammatik-Überprüfung
unterzogen werden.

Eclipse macht das automatisch (Rechtschreibung) und unterstreicht falsch
geschriebene Wörter, so wie man es aus Office ... kennt. Find ich gar
nicht so schlecht.


Mit freundlichen Grüßen,
Dennis Schulmeister

[Volker Grabsch]

Post by Dennis Schulmeister

Post by Volker Grabsch
Überspitzt ausgedrückt: Ich frage mich, wann die Kommentare
im Quellcode einer Rechtschreib- und Grammatik-Überprüfung
unterzogen werden.

Eclipse macht das automatisch (Rechtschreibung) und unterstreicht falsch
geschriebene Wörter, so wie man es aus Office ... kennt. Find ich gar
nicht so schlecht.

Ja, das ist richtig. Das meinte ich aber nicht.

Ich meinte: Wann wird es soweit sein, dass bei der Korrektur neben
den anderen Metriken auch die Rechtschreibung/Grammatik der Kommentare
in die erreichte Punktzahl einfließt? ;-)


Gruß,

Volker

[Stefan Behnel]

Post by Volker Grabsch
Überspitzt ausgedrückt: Ich frage mich, wann die Kommentare
im Quellcode einer Rechtschreib- und Grammatik-Überprüfung
unterzogen werden.

Flyspell?

Stefan

[Marc 'BlackJack' Rintsch]

Post by Dennis Schulmeister
print "Hello World"
main = staticmethod(main)
HelloWorld.main()
Das zweite Python-Beispiel wird im Vergleich zum ersten allerdings auch
deinem Ziel gerecht: OOP zu lehren!

Argh! Wird es in keiner Weise, weil dass da nichts mit OOP zu tun hat.
OOP != alles in eine Klasse stecken. Das ist nichts weiter als eine
Funktion in den Namensraum einer Klasse gesteckt. Das ist nicht OOP,
sondern unnötig umständlich.

Post by Dennis Schulmeister
Du siehst, egal welche Sprache, wenn du OOP unterrichtest, hast du am
Anfang IMMER einen gewissen Boiler-Plate-Code, den die Schüler nicht
verstehen.

Welchen Boilerplate hast Du bei Python bei OOP?

Post by Dennis Schulmeister
Das ist aber nicht tragisch. Den gibt man eben als Grundgerüst vor und
weist darauf hin, dass die Schüler nach Abschluss der Vorlesung oder des
Schuljahres in der Lage sein werden, ihn zu verstehen. Man kann halt nur
einen Fuß vor den anderen setzen.

Aber gerade da kann man bei Python prozedural, funktional, und OOP
einführen, ohne das man erst einmal viel Quelltext präsentieren muss, den
man später erklärt. Man kann das in kleinen Schritten aufbauen und alles
immer sofort erklären.

Post by Dennis Schulmeister
Die dritte Frühstücksvariable in meinem Python-Beispiel ist übrigens ein
Dictionary. Dafür gibt es Java leider keine so elegante Entsprechung.

Es gibt keine literale Darstellung dafür, aber `java.util.Hashtable`
existiert.

Post by Dennis Schulmeister
Insgesamt wirkt der Python-Code etwas eleganter, dennoch würde ich den
Punkt hier an Java vergeben. Warum? In Java wird der Code vor der
Ausführung kompiliert, in Python gibt es diesen Schritt nicht zwingend.
Wenn man aber eine Weile mit Java gearbeitet hat, lernt man schnell,
dass der Compiler ein Freund und kein Feind ist. Noch bevor das Programm
überhaupt ausgeführt werden kann, deckt der Compiler Fehler auf, von
denen Pythons Syntaxprüfung beim Programmstart nur träumen kann.

Das führt in einigen Fällen dazu, dass die Leute bei Java nur den Compiler
glücklich machen, d.h. entweder selbst solange an den Typen rumdrehen bis
es fehlerfrei funktioniert, oder die Autokorrektur der IDE verwenden ohne
sich den Fehler wirklich bewusst zu machen.

Post by Dennis Schulmeister
Das heißt, obwohl UnitTests für beide Sprachen unumgänglich sind, ist es
meiner Meinung nach bereits ein schweres Vergehen, Python-Code
auszuliefern, der nicht durch einen ordentlichen Unit-Test geprüft
wurde. Denn 70% der Compilierfehler in Java sind versteckte
Laufzeitfehler in Python!

Die Zahl bitte mal belegen. Ich habe jedenfalls in Python-Quelltext gar
nicht so viele Typfehler, wie das Verfechter von statisch typisierten
Sprachen immer prophezeien. Und wie Du sagst: Testen muss man sowieso.
Gerade im Lernumfeld sollte ein Lehrer IMHO neben dem Quelltext immer
Testläufe verlangen, oder vielleicht sogar Doctests vorgeben, bzw. die
Schüler vor der Implementierung schreiben lassen, damit man lernt
Quelltext zu schreiben, der die geforderten Kriterien erfüllt.

Für Python gibt's auch statische Prüfwerkzeuge (pylint, pychecker,
pyflakes), die einiges finden können was bei statisch typisierten Sprachen
der Compiler bemerkt. Natürlich nicht alles.

Post by Dennis Schulmeister
Meiner Meinung nach sind beide Sprachen sehr gut geeignet, um Schüler
der Sekundarstufe II damit zu konfrontieren und das Argument, dass Java
hierfür ungeeignet sei, kann ich nicht teilen. Während meines Studiums
haben wir auch Programmieren gelernt. Anhand von Java, ausschließlich.
Was soll ich sagen? Es hat jeder geschafft. Und jeder, der anschließend
mit irgend einer anderen Sprache in Berührung kam, konnte sofort
Transferwissen aufbauen. ("Das ist doch so ähnlich wie in Java").

Das ist ja gerade die Gefahr, die hier einige sehen. Es ist eben nicht
alles so ähnlich wie Java. Java ist ein ziemlich eingeschränkter
Ausschnitt von den Möglichkeiten, wie man etwas mit einer
Programmiersprache ausdrücken kann. Frag mal so einen Jahrgang ob Klassen
für OOP notwendig sind. Oder setz denen Haskell, OCaml, oder Scheme vor.
Wer Java kann, kann in Java programmieren. Ich denke um Programmieren
als allgemeine Disziplin zu können, muss man auch andere Sprachen und vor
allem welche mit anderen Paradigmen gesehen haben.

Post by Dennis Schulmeister
Vielleicht ist hier Java sogar noch besser geeignet als Python, weil es
dem Programmierer nicht so viele Dinge abnimmt. Das heißt, gerade wenn
man anfängt zu programmieren, muss man erst einmal verstehen, was man
dem Computer eigentlich sagt.

Das ist auch ein Standpunkt über den man prima, ohne Ergebnis, streiten
kann. Es gibt Solche die sagen, man muss verstehen was der Rechner macht,
also am besten mit Assembler oder C anfangen, und Solche die sagen es
kommt beim Programmieren auf eine gewisse Art analytisch zu Denken an und
abstrakte Lösungen zu formulieren und deshalb Sprachen wie Haskell den
Vorzug geben. Letzteres ist IMHO wichtiger, denn auch bei Assembler und C
braucht man diese abstrakte Denke, dort dann zusätzlich zu dem technischen
Wissen über Speicher, Zeiger, und interner Darstellung von Werten.

Post by Dennis Schulmeister
In Python kann es passieren, dass der Computer zwar das Richtige macht,
ein Anfänger aber nicht genau weiß, warum.

Das kann Dir in anderen Sprachen auch passieren.

Ciao,
Marc 'BlackJack' Rintsch

[Dennis Schulmeister]

Hallo,

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
print "Hello World"
main = staticmethod(main)
HelloWorld.main()
Das zweite Python-Beispiel wird im Vergleich zum ersten allerdings auch
deinem Ziel gerecht: OOP zu lehren!

Argh! Wird es in keiner Weise, weil dass da nichts mit OOP zu tun hat.
OOP != alles in eine Klasse stecken. Das ist nichts weiter als eine
Funktion in den Namensraum einer Klasse gesteckt. Das ist nicht OOP,
sondern unnötig umständlich.

Natürlich ist das umständlich, es ist aber die Python-Entsprechung für
das oben drüber aufgeführte Java-Beispiel. Übrigens kann man eine (!)
statische Methode in einer (!) Klasse nicht gleich als "alles in eine
Klasse stecken" bezeichnen. ;)

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Du siehst, egal welche Sprache, wenn du OOP unterrichtest, hast du am
Anfang IMMER einen gewissen Boiler-Plate-Code, den die Schüler nicht
verstehen.

Welchen Boilerplate hast Du bei Python bei OOP?

Verglichen mit dem Java-Beispiel, die explizite Zuweisung(!) main =
staticmethod(main) sowie den Python-typischen Abschluss mit if __name__
== "__main__". Die fünf Zeilen Java kann man direkt ausführen, weil die
VM, wenn man ihr eine Klasse vorwirft, immer nach der statischen
main-Methode sucht.

Wie gesagt, es ging nur darum, zwei identische Beispiele zu liefern.
Keines der Beispiele kann als ausgeklügeltes OO-Referenzmodell dienen.

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Die dritte Frühstücksvariable in meinem Python-Beispiel ist übrigens ein
Dictionary. Dafür gibt es Java leider keine so elegante Entsprechung.

Es gibt keine literale Darstellung dafür, aber `java.util.Hashtable`
existiert.

Stimmt, an dieser Stelle finde ich Python generell besser. In Java ist
alles in Klassen und Methoden verpackt und da man auch keine Operatoren
überladen kann, findet man gerne elendig lange Ratenschwänze von
aneinader gehängten Methodenaufrufen, die schwer zu verstehen sind.

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Insgesamt wirkt der Python-Code etwas eleganter, dennoch würde ich den
Punkt hier an Java vergeben. Warum? In Java wird der Code vor der
Ausführung kompiliert, in Python gibt es diesen Schritt nicht zwingend.
Wenn man aber eine Weile mit Java gearbeitet hat, lernt man schnell,
dass der Compiler ein Freund und kein Feind ist. Noch bevor das Programm
überhaupt ausgeführt werden kann, deckt der Compiler Fehler auf, von
denen Pythons Syntaxprüfung beim Programmstart nur träumen kann.

Das führt in einigen Fällen dazu, dass die Leute bei Java nur den Compiler
glücklich machen, d.h. entweder selbst solange an den Typen rumdrehen bis
es fehlerfrei funktioniert, oder die Autokorrektur der IDE verwenden ohne
sich den Fehler wirklich bewusst zu machen.

Das ist natürlich der Extremfall. Aber der Punkt ist, dass der Compiler
(sofern man selbst etwas Intelligenz mitbringt) eine sehr große Hilfe
sein kann.

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Das heißt, obwohl UnitTests für beide Sprachen unumgänglich sind, ist es
meiner Meinung nach bereits ein schweres Vergehen, Python-Code
auszuliefern, der nicht durch einen ordentlichen Unit-Test geprüft
wurde. Denn 70% der Compilierfehler in Java sind versteckte
Laufzeitfehler in Python!

Die Zahl bitte mal belegen.

Die Zahl ist rhetorisch. :)

Post by Marc 'BlackJack' Rintsch
Ich habe jedenfalls in Python-Quelltext gar
nicht so viele Typfehler, wie das Verfechter von statisch typisierten
Sprachen immer prophezeien. Und wie Du sagst: Testen muss man sowieso.
Gerade im Lernumfeld sollte ein Lehrer IMHO neben dem Quelltext immer
Testläufe verlangen, oder vielleicht sogar Doctests vorgeben, bzw. die
Schüler vor der Implementierung schreiben lassen, damit man lernt
Quelltext zu schreiben, der die geforderten Kriterien erfüllt.
Für Python gibt's auch statische Prüfwerkzeuge (pylint, pychecker,
pyflakes), die einiges finden können was bei statisch typisierten Sprachen
der Compiler bemerkt. Natürlich nicht alles.

Das ist natürlich ein gutes Argument und der Einsatz solcher Tools ist
empfehlenswert. Die Frage ist, inwiefern das aber nicht den Rahmen einer
Schulveranstaltung sprengt.

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Meiner Meinung nach sind beide Sprachen sehr gut geeignet, um Schüler
der Sekundarstufe II damit zu konfrontieren und das Argument, dass Java
hierfür ungeeignet sei, kann ich nicht teilen. Während meines Studiums
haben wir auch Programmieren gelernt. Anhand von Java, ausschließlich.
Was soll ich sagen? Es hat jeder geschafft. Und jeder, der anschließend
mit irgend einer anderen Sprache in Berührung kam, konnte sofort
Transferwissen aufbauen. ("Das ist doch so ähnlich wie in Java").

Das ist ja gerade die Gefahr, die hier einige sehen. Es ist eben nicht
alles so ähnlich wie Java. Java ist ein ziemlich eingeschränkter
Ausschnitt von den Möglichkeiten, wie man etwas mit einer
Programmiersprache ausdrücken kann. Frag mal so einen Jahrgang ob Klassen
für OOP notwendig sind. Oder setz denen Haskell, OCaml, oder Scheme vor.
Wer Java kann, kann in Java programmieren. Ich denke um Programmieren
als allgemeine Disziplin zu können, muss man auch andere Sprachen und vor
allem welche mit anderen Paradigmen gesehen haben.

Das ist sicher richtig. Aber man darf nicht vergessen, dass es um
Schulunterricht geht, in dem etwas OOP unterrichtet werden soll. Das
ganze Spektrum der Informatik kann man da in keinster Weise einfangen.
Dafür ist ja dann das Informatik-Studium dar. (Wobei es nicht mal da
richtig gelingt.)

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Vielleicht ist hier Java sogar noch besser geeignet als Python, weil es
dem Programmierer nicht so viele Dinge abnimmt. Das heißt, gerade wenn
man anfängt zu programmieren, muss man erst einmal verstehen, was man
dem Computer eigentlich sagt.

Das ist auch ein Standpunkt über den man prima, ohne Ergebnis, streiten
kann. Es gibt Solche die sagen, man muss verstehen was der Rechner macht,
also am besten mit Assembler oder C anfangen, und Solche die sagen es
kommt beim Programmieren auf eine gewisse Art analytisch zu Denken an und
abstrakte Lösungen zu formulieren und deshalb Sprachen wie Haskell den
Vorzug geben. Letzteres ist IMHO wichtiger, denn auch bei Assembler und C
braucht man diese abstrakte Denke, dort dann zusätzlich zu dem technischen
Wissen über Speicher, Zeiger, und interner Darstellung von Werten.

Bis zu Assembler muss man ja nicht runtergehen. Aber ich bin schon der
Meinung, dass das analytische Denken erst dann funktioniert, wenn man
einigermaßen versteht, wie der Computer das ein oder andere macht. Man
sollte also schon wissen, dass wenn man for ... in ... schreibt, ein
Iterator (oder ein Generator) dahinter steckt und dass man den mit yield
ganz einfach selbst erzeugen kann.

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
In Python kann es passieren, dass der Computer zwar das Richtige macht,
ein Anfänger aber nicht genau weiß, warum.

Das kann Dir in anderen Sprachen auch passieren.

Natürlich. :)



Mit freundlichen Grüßen,
Dennis Schulmeister

[Volker Grabsch]

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
print "Hello World"
main = staticmethod(main)
HelloWorld.main()
Das zweite Python-Beispiel wird im Vergleich zum ersten allerdings auch
deinem Ziel gerecht: OOP zu lehren!

Argh! Wird es in keiner Weise, weil dass da nichts mit OOP zu tun hat.
OOP != alles in eine Klasse stecken. Das ist nichts weiter als eine
Funktion in den Namensraum einer Klasse gesteckt. Das ist nicht OOP,
sondern unnötig umständlich.

Natürlich ist das umständlich, es ist aber die Python-Entsprechung für
das oben drüber aufgeführte Java-Beispiel.

Nein, ist es nicht. Obiger Java-Code ist die einzige Möglichkeit,
ein "Hello World" auszugeben. Die Dummy-Klasse ist ein Workaround
für fehlende Ausdrucksmöglichkeiten in Java.

Solche Workarounds sollte man IMHO nicht übertragen. Das wäre in etwa
so, als würde man folgenden Python-Code

def f(x):
assert isinstance(x, int)
...

übersetzen würde nach:

public f(int x) {
/* Java-Code zum testen, ob x ein Integer ist */
...
}

Wenn man Sprachen sinnvoll vergleichen will, sollte man sie
nicht "Wort für Wort" übersetzen, das macht man bei natürlichen
Sprachen auch nicht.

Stattdessen sollte es darum gehen, die _übliche Realisierung_
der Konzepte in den Sprachen zu vergleichen.

Post by Dennis Schulmeister
Übrigens kann man eine (!)
statische Methode in einer (!) Klasse nicht gleich als "alles in eine
Klasse stecken" bezeichnen. ;)

Doch, weil das Programm nur aus diesem "einen (!)" Befehl besteht. :-)

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Du siehst, egal welche Sprache, wenn du OOP unterrichtest, hast du am
Anfang IMMER einen gewissen Boiler-Plate-Code, den die Schüler nicht
verstehen.

Welchen Boilerplate hast Du bei Python bei OOP?

Verglichen mit dem Java-Beispiel, die explizite Zuweisung(!) main =
staticmethod(main) sowie den Python-typischen Abschluss mit if __name__
== "__main__". Die fünf Zeilen Java kann man direkt ausführen, weil die
VM, wenn man ihr eine Klasse vorwirft, immer nach der statischen
main-Methode sucht.

Damit hast du aber nur die Klassen-Syntax übersetzt.

OOP ist jedoch kein syntaktisches Werkzeug, sondern ein
Programmier-Stil!

Man kann in seinem Program tausende von Klassen definieren, und
dennoch kein bisschen OOP betreiben. Und man kann gutes OOP
praktizieren, selbst wenn die Sprache keine OO-Features mitbringt
(C, Assembler).

Es geht nicht darum, seine Funktionen in Klassen zu gruppieren.
Es geht darum, dass in dem Programm Objekte "leben", deren
Schnittstellen durch ihre Fähigkeiten, nicht ihre Daten, bestimmt
wird. Die Objekte sollten sich gegenseitig benachrichtigen, und
den (modellierten) Objekten der wirklichen Welt möglichst gut
entsprechen.

Obige HelloWorld-Klasse demonstriert genau das, was man in der
OOP eigentlich _nicht_ möchte! Wenn man es in dem Stil schreiben
will, müsste man sich erst einmal überlegen, was die Objekte sind,
und das Beispiel erstmal soweit vergrößern, dass man überhaupt
Objekte darin findet.

Ein Hauptprogramm, das alle benötigten Objekt erzeugt (bzw. lädt),
und ihr Zusammenspiel initiiert, gibt es dann überall. In Java
ist dieses Hauptprogramm eine statische "main"-Methode einer
willkürlichen Klasse. In Python gibt es dafür einen separaten
Ort. Aber mit der Deklaration von Objekten und ihren Fähigkeiten
hat die "main"-Methode von Java nichts am Hut. Es ist viel eher
eine syntaktisch erzwungene Verwirrung von OOP.

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch
Das führt in einigen Fällen dazu, dass die Leute bei Java nur den Compiler
glücklich machen, d.h. entweder selbst solange an den Typen rumdrehen bis
es fehlerfrei funktioniert, oder die Autokorrektur der IDE verwenden ohne
sich den Fehler wirklich bewusst zu machen.

Das ist natürlich der Extremfall. Aber der Punkt ist, dass der Compiler
(sofern man selbst etwas Intelligenz mitbringt) eine sehr große Hilfe
sein kann.

Sprachen wie Haskell und OCaml haben so einen Compiler. Bei C++ und Java
vermisse ich solch einen. SCNR ;-)

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch
Für Python gibt's auch statische Prüfwerkzeuge (pylint, pychecker,
pyflakes), die einiges finden können was bei statisch typisierten Sprachen
der Compiler bemerkt. Natürlich nicht alles.

Das ist natürlich ein gutes Argument und der Einsatz solcher Tools ist
empfehlenswert. Die Frage ist, inwiefern das aber nicht den Rahmen einer
Schulveranstaltung sprengt.

Auch einen Profiler sollte man vielleicht erwähnen. Viel zu viele
Leute nehmen Geschwindigkeit als Argument für oder gegen eine
bestimmte Konstruktion im Code. Stattdessen sollte es um Korrektheit,
Klarheit und Übersichtlichkeit gehen.

Wenn man den Leuten demonstriert, wie sie große Geschwindigkeits-
Gewinne erreichen - und dabei nur Bruchstücke des Programms optimieren
und hässlicher machen, dann ist ne Menge gewonnen. Doch dazu müssen
sie wissen, dass es sowas wie Profiler gibt.

Genau wie inkrementelle Programmierung sollte das am besten schon
in der Schule gelehrt werden. Oder zumindest erwähnt!

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch
Das ist auch ein Standpunkt über den man prima, ohne Ergebnis, streiten
kann. Es gibt Solche die sagen, man muss verstehen was der Rechner macht,
also am besten mit Assembler oder C anfangen, und Solche die sagen es
kommt beim Programmieren auf eine gewisse Art analytisch zu Denken an und
abstrakte Lösungen zu formulieren und deshalb Sprachen wie Haskell den
Vorzug geben. Letzteres ist IMHO wichtiger, denn auch bei Assembler und C
braucht man diese abstrakte Denke, dort dann zusätzlich zu dem technischen
Wissen über Speicher, Zeiger, und interner Darstellung von Werten.

Bis zu Assembler muss man ja nicht runtergehen. Aber ich bin schon der
Meinung, dass das analytische Denken erst dann funktioniert, wenn man
einigermaßen versteht, wie der Computer das ein oder andere macht. Man
sollte also schon wissen, dass wenn man for ... in ... schreibt, ein
Iterator (oder ein Generator) dahinter steckt und dass man den mit yield
ganz einfach selbst erzeugen kann.

Aber genau das ist doch die konzeptuelle Ebene!

Nächst-niedrigere Ebene wäre, wenn man lernt, dass ein Iterator
ein Objekt mit next()-Methode ist. (in anderen Sprachen auch:
next() und hasNext())

Aber wie z.B. ein Methodenaufruf funktioniert, was da in den
Registern und im Stack passiert, das interessiert nichtmal
einen C-Programmierer wirklich. Es ist auch vollkommen egal,
das varriert in den verschiedenen Sprachen sowieso. Deshalb gibt
es ja die Abstraktion "Funktionsaufruf". Und genauso gibt es ein
abstraktes Konzept "Iterator". Die kann man im Detail verstehen.

Aber für die Programmierung genügt es, "for/in" und "yield" zu
kennen. Ein guter Programmierer sollte sogar dafür sorgen, dass
sein Programm unabhängig davon ist, wie for/in und yield im Detail
implementiert sind. Er _nutzt_ sie einfach bestimmungsgemäß, genauso
wie er auch "print" und "+" benutzt.

Saubere Programmierung ist doch gerade das *Akzeptieren* dieser
Abstraktionsschichten, und das Vermeiden sinnloser Durchbrüche
durch diese Schichten. So kann man das Darunterliegende bei Bedarf
ändern kann, und genau das passiert auch ständig.

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
In Python kann es passieren, dass der Computer zwar das Richtige macht,
ein Anfänger aber nicht genau weiß, warum.

Das kann Dir in anderen Sprachen auch passieren.

Natürlich. :)

Bei der heutigen Komplexität der Prozessoren, der C-Compiler, etc.:
Das _passiert_, und zwar immer! Du weißt niemals genau, was innendrin
abläuft. Aber du weiß, was rauskommen soll, wenn du XYZ reinsteckst,
und hast eine ungefähre Vorstellung von dem Zeitverhalten. Und darauf
kommt es an.


Gruß,

Volker

[Sebastian Wiesner]

Post by Volker Grabsch
OOP ist jedoch kein syntaktisches Werkzeug, sondern ein
Programmier-Stil!
Man kann in seinem Program tausende von Klassen definieren, und
dennoch kein bisschen OOP betreiben. Und man kann gutes OOP
praktizieren, selbst wenn die Sprache keine OO-Features mitbringt
(C, Assembler).
Es geht nicht darum, seine Funktionen in Klassen zu gruppieren.
Es geht darum, dass in dem Programm Objekte "leben", deren
Schnittstellen durch ihre Fähigkeiten, nicht ihre Daten, bestimmt
wird. Die Objekte sollten sich gegenseitig benachrichtigen, und
den (modellierten) Objekten der wirklichen Welt möglichst gut
entsprechen.
Obige HelloWorld-Klasse demonstriert genau das, was man in der
OOP eigentlich _nicht_ möchte! Wenn man es in dem Stil schreiben
will, müsste man sich erst einmal überlegen, was die Objekte sind,
und das Beispiel erstmal soweit vergrößern, dass man überhaupt
Objekte darin findet.
Ein Hauptprogramm, das alle benötigten Objekt erzeugt (bzw. lädt),
und ihr Zusammenspiel initiiert, gibt es dann überall. In Java
ist dieses Hauptprogramm eine statische "main"-Methode einer
willkürlichen Klasse. In Python gibt es dafür einen separaten
Ort. Aber mit der Deklaration von Objekten und ihren Fähigkeiten
hat die "main"-Methode von Java nichts am Hut. Es ist viel eher
eine syntaktisch erzwungene Verwirrung von OOP.

Ich würde sogar sagen, dass die erzwungene "Klassen-OOP" von Java dem
Verständnis von OOP eher abträglich ist. Zumindest habe ich die Erfahrung
gemacht, dass unbedarfte Anfänger oft intuitiv erkennen, dass solche
Klassen sinnlos sind und sich deswegen mit dem Verständnis schwer tun.

Eine Sprache, die OOP aus den Zwängen der Klasse "befreit", erlaubt dem
Lehrer dagegen, OOP anhand eines realen, nachvollziehbaren Beispiels
vorzustellen, was imho gerade beim "Erstkontakt" förderlich ist.

[Marc 'BlackJack' Rintsch]

Post by Sebastian Wiesner
Eine Sprache, die OOP aus den Zwängen der Klasse "befreit", erlaubt dem
Lehrer dagegen, OOP anhand eines realen, nachvollziehbaren Beispiels
vorzustellen, was imho gerade beim "Erstkontakt" förderlich ist.

Vor allem kann man auch vergleichende Beispiele bringen. In der Richtung:
Schaut mal, hier haben wir einen Haufen Funktionen, die alle die gleiche
Datenstrukturen als Argumente bekommen und etwas damit machen. Das kann
man jetzt sinnvoll in Klassen zu Objekten zusammen fassen und Programme
damit verständlicher machen. Und dann schiebt man noch Polymorhie
hinterher, wo im Beispiel mit den Funktionen
``if``/``elif``/``else``-Kaskaden verwendet werden, um generische
Funktionen zu schreiben und wie das auf magische Weise verschwindet und
einfacher wird, wenn man Klassen verwendet. So sehen die Schüler den
Mehrwert, den OOP bringt.

Ciao,
Marc 'BlackJack' Rintsch

[Marc 'BlackJack' Rintsch]

Post by Dennis Schulmeister
Hallo,

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
print "Hello World"
main = staticmethod(main)
HelloWorld.main()
Das zweite Python-Beispiel wird im Vergleich zum ersten allerdings auch
deinem Ziel gerecht: OOP zu lehren!

Argh! Wird es in keiner Weise, weil dass da nichts mit OOP zu tun hat.
OOP != alles in eine Klasse stecken. Das ist nichts weiter als eine
Funktion in den Namensraum einer Klasse gesteckt. Das ist nicht OOP,
sondern unnötig umständlich.

Natürlich ist das umständlich, es ist aber die Python-Entsprechung für
das oben drüber aufgeführte Java-Beispiel.

Und? Du hast behauptet das Beispiel würde dem Ziel gerecht OOP zu lehren,
aber weder das Python-Beispiel, noch das entsprechende Java-Beispiel haben
etwas mit OOP zu tun.

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch

Post by Dennis Schulmeister
Du siehst, egal welche Sprache, wenn du OOP unterrichtest, hast du am
Anfang IMMER einen gewissen Boiler-Plate-Code, den die Schüler nicht
verstehen.

Welchen Boilerplate hast Du bei Python bei OOP?

Verglichen mit dem Java-Beispiel, die explizite Zuweisung(!) main =
staticmethod(main) sowie den Python-typischen Abschluss mit if __name__
== "__main__". Die fünf Zeilen Java kann man direkt ausführen, weil die
VM, wenn man ihr eine Klasse vorwirft, immer nach der statischen
main-Methode sucht.

Ich wollte wissen welchen Boilerplate man bei *OOP* in Python hat! Das
Beispiel hat wie gesagt mit OOP nichts zu tun ausser dass es syntaktische
Hilfsmittel die für OOP gedacht sind, sinnlos verwendet. Das ist genauso,
als würde ich sagen hier würde "list comprehension" verwendet:

ham = [spam(x) for x in [parrot]][0]

Syntaktisch ist das zwar eine LC, aber semantisch einfach nur unnötiger
Code.

Post by Dennis Schulmeister

Post by Marc 'BlackJack' Rintsch
Für Python gibt's auch statische Prüfwerkzeuge (pylint, pychecker,
pyflakes), die einiges finden können was bei statisch typisierten Sprachen
der Compiler bemerkt. Natürlich nicht alles.

Das ist natürlich ein gutes Argument und der Einsatz solcher Tools ist
empfehlenswert. Die Frage ist, inwiefern das aber nicht den Rahmen einer
Schulveranstaltung sprengt.

Gar nicht denke ich. Pylint checkt unter anderem auch Metriken und
Programmierstil, und das ist etwas, was IMHO sehr sinnvoll ist und die
Schüler selber machen können. Viele Python-IDEs integrieren solche
Werkzeuge auch, so dass zum Beispiel beim Speichern automatisch ein
Checker über den Quelltext schaut. Einiges davon machen Java IDEs auch.

Ciao,
Marc 'BlackJack' Rintsch

[Torsten Bronger]

Hallöchen!

[...]
[...] Pylint checkt unter anderem auch Metriken und
Programmierstil, und das ist etwas, was IMHO sehr sinnvoll ist und
die Schüler selber machen können.

Aber Pylint hat auch sehr viele "false positives". Und dann muß man
den Schülern erklären, warum das nun so doch gut ist oder nicht so
schlimm ist. Das dürfte sie eher verwirren als ihnen helfen.
Pylint ist daher in meinen Augen ein Werkzeug für Fortgeschrittene.

Tschö
Torsten.

[Marc 'BlackJack' Rintsch]

Post by Torsten Bronger

[...] Pylint checkt unter anderem auch Metriken und
Programmierstil, und das ist etwas, was IMHO sehr sinnvoll ist und
die Schüler selber machen können.

Aber Pylint hat auch sehr viele "false positives".

Bei mir nicht.

Ciao,
Marc 'BlackJack' Rintsch

[Torsten Bronger]

Hallöchen!

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger

[...] Pylint checkt unter anderem auch Metriken und
Programmierstil, und das ist etwas, was IMHO sehr sinnvoll ist
und die Schüler selber machen können.

Aber Pylint hat auch sehr viele "false positives".

Bei mir nicht.

Das ist hier auch nicht relevant.

Tschö,
Torsten.

[Marc 'BlackJack' Rintsch]

Post by Torsten Bronger

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger
Aber Pylint hat auch sehr viele "false positives".

Bei mir nicht.

Das ist hier auch nicht relevant.

Dann ist es Deine Aussage aber auch nicht. Ist ja auch nur ein "Sample".

Ciao,
Marc 'BlackJack' Rintsch

[Torsten Bronger]

Hallöchen!

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger
Aber Pylint hat auch sehr viele "false positives".

Bei mir nicht.

Das ist hier auch nicht relevant.

Dann ist es Deine Aussage aber auch nicht. Ist ja auch nur ein "Sample".

Wenigstens habe ich eine Aussage gemacht. Auf meinen Einwand mit
einem lapidaren "bei mir nicht" zu antworten, bringt uns doch keinen
Schritt weiter. Man weiß ja nicht einmal, ob dich nur die Adverbien
oder die ganze Aussage stört.

Wenn es die Adverbien sind, wäre eine weitere Diskussion so sinnvoll
wie sich über Geschmack zu streiten.

Daß du meine Aussage grundsätzlich in Zweifel ziehst, kann ich mir
kaum vorstellen; Pylint ist ein Score- und Regelbasiertes System,
und sowas hat natürlich prinzipbedingt False Positives. Pylint
selber betreibt einigen Aufwand, um dem Benutzer zu ermöglichen,
damit zurechtzukommen.

Tschö,
Torsten.

[Marc 'BlackJack' Rintsch]

Post by Torsten Bronger

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger

Post by Marc 'BlackJack' Rintsch

Post by Torsten Bronger
Aber Pylint hat auch sehr viele "false positives".

Bei mir nicht.

Das ist hier auch nicht relevant.

Dann ist es Deine Aussage aber auch nicht. Ist ja auch nur ein "Sample".

Wenigstens habe ich eine Aussage gemacht. Auf meinen Einwand mit
einem lapidaren "bei mir nicht" zu antworten, bringt uns doch keinen
Schritt weiter.

Natürlich, es sagt aus, dass die sehr vielen "false positives" nicht bei
jedem auftreten.

Post by Torsten Bronger
Man weiß ja nicht einmal, ob dich nur die Adverbien oder die ganze
Aussage stört.

Die ganze Aussage, die nicht als "Sample" sondern so einfach absolut da
steht.

Post by Torsten Bronger
Wenn es die Adverbien sind, wäre eine weitere Diskussion so sinnvoll wie
sich über Geschmack zu streiten.
Daß du meine Aussage grundsätzlich in Zweifel ziehst, kann ich mir kaum
vorstellen; Pylint ist ein Score- und Regelbasiertes System, und sowas
hat natürlich prinzipbedingt False Positives.

Kommt drauf an, wie sehr man sich an die Regel halten möchte und welche
Regeln man wie konfiguriert hat. Zusätzlich kann man absichtliche
Regelverstösse auch kommentieren und damit vor Pylint "schützen".

Ciao,
Marc 'BlackJack' Rintsch

[Volker Grabsch]

Post by Dennis Schulmeister

Post by guidofranke
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???
Was soll ich vorbereiten?

Ich möchte an dieser Stelle einfach mal aus meiner Sicht die Vor- und
Nachteile beider Sprachen beschreiben, was dir meiner Meinung nach wohl
besser hilft, als die recht oberflächliche Diskussion über Metal. :)

Ja, etwas Tiefgang kann in diesem Thread nicht schaden. :-)

Post by Dennis Schulmeister
Insgesamt wirkt der Python-Code etwas eleganter, dennoch würde ich den
Punkt hier an Java vergeben. Warum? In Java wird der Code vor der
Ausführung kompiliert, in Python gibt es diesen Schritt nicht zwingend.

Du meinst das richtige: statische Typprüfung. Punkt an Java.

Ob die allerdings durch einen Compiler oder einen Interpreter erfolgt
ist irrelevant. Zumal sowohl Python als auch Java eine _Kombination_
aus Compiler und Interpreter verwenden. Dieses "Gemisch" ist in Python
viel entwicklerfreundlicher realisiert als in Java. Punkt an Python.

Post by Dennis Schulmeister
Das heißt, obwohl UnitTests für beide Sprachen unumgänglich sind, ist es
meiner Meinung nach bereits ein schweres Vergehen, Python-Code
auszuliefern, der nicht durch einen ordentlichen Unit-Test geprüft
wurde. Denn 70% der Compilierfehler in Java sind versteckte
Laufzeitfehler in Python!

Hier steht übrigens nach wie vor die Frage im Raum, was effektiver
ist: Befriedigung des Java-Compilers durch mehr Typo-Notationen,
oder Schreiben von mehr Unit-Tests in Python.

Das sollte man aber unter dem allgemeinen Punkt "statische vs.
dynamische Typisierung" betrachten. Diese Diskussion kann man
besser führen, wenn man sie auf dem Niveau "LISP vs. OCaml/Haskell"
führt, statt auf dem Niveau "Python vs. Java".

Post by Dennis Schulmeister
-------------------

Diesen Punkt hast du IMHO zu oberflächlich behandelt, daher
gebe ich nochmal meinen Senf hinzu. Denn ich kenne einige
Programmierer, denen Python als Sprache viel besser gefällt.
Dennoch verwenden sie Java. Warum? Nur wegen der Standard-
bibliotheken, vorallem wegen Swing! Dieser Punkt ist viel
wichtiger, als man zunächst glauben mag.

Dabei geht es gar nicht um die Qualität von Swing, die ich im
Vergleich zu GTK oder Qt übrigens auch nicht so toll finde,
sondern es geht um was anderes. Es geht um die Batterien.
(siehe nächste Absätze)

Post by Dennis Schulmeister
Hier können beide Sprachen punkten und es gibt meiner Meinung nach
keinen Sieger. Beide Sprachen liefern sehr umfangreiche Bibliotheken
mit, die vorerst nur wenig Wünsche offen lassen.

Dennoch gibt es einen großen Unterschied: Die Python-Libraries
kommen i.d.R. direkt aus den bekannten C-Libraries, die Highlevel-
APIs natürlich sind dann in Python geschrieben. Das heißt, man hat
es mit Libraries zu tun, die man auch von C, C++, Perl, PHP und
vielen anderen Sprachen kennt.

Java hingegen hat auch im Lowlevel-Bereich praktisch alles neu
implementiert. Dabei sind die neuen APIs nicht unbedingt besser
designt, sondern einfach nur anders. Einige mögen genau das, andere
nervt das.

Post by Dennis Schulmeister
In beiden Fällen
reichen die Funktionen der Bibliotheken von einfachen Kleinigkeiten bis
zur GUI-Pogrammierung. (Wobei ich persönlich Pythons TkInter nicht so
sehr mag wie Javas Swing. Doch auch von letzterem bin ich nicht so
angetan. Das ist jetzt aber nicht Gegenstand der Diskussion)

Dennoch sollte Python seinen starken Hang zu Tk ablegen. Nicht,
weil Tk zu einfach gestrickt ist, sondern vorallem, weil's rein
optisch potthässlich ist. Diesen Effekt darf man nicht unterschätzen.
Eine GUI-Library mit guter Optik motiviert Entwickler und Anwender
zugleich. Ähnliches gilt übrigens auch für Web-Programmierung, und
sogar für Programmierung im Textmodus (ncurses, slang).

Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries. Aber zu den
"eingebauten Batterien" gehört nach wie vor nur Tk. Unter Linux
wiegesagt kein Problem, aber wer unter Windows programmiert, oder
für Windows ausliefert, der hat hier eine unnötige Hürde.

Und genau das macht Java/Swing interessant: Hier hat man eine
_schicke_ GUI-Library mit viel Funktionalität eingebaut. In Python
ist nur Tk eingebaut, eine _hässliche_ GUI-Lib mit viel zu wenig
Funktionalität. Daher klarer Punkt an Java.

Python sollte sich von Tk lösen und stattdessen GTK oder Qt als
Batterien mitbringen. Besonders ironisch: Für GTK gibt es bereits
eine Highlevel-Bibliothek namens Kiwi, die GUI-Programmierung
nochmals viel angenehmer macht. Eine echte "Geheimwaffe" von
Python, die AFAIK kein echtes Pendant in Java hat.

Kiki ist in meinen Augen der Swing-Killer schlechthin. Nur leider
gehört es in Python nicht zu den Batterien. :-(


Interaktiver Interpreter:
-------------------------

Post by Dennis Schulmeister
Python hat dafür einen anderen Vorteil: Seinen interaktiven Interpreter.
So ähnlich wie 8-Bit BASIC in den 80er Jahren kann man Pythons
Interpreter starten, ein bisschen Code eintippen und live verfolgen, was
passiert. Für kleine Spielereien reicht das vollkommen. Größere Sachen
sollte man dann aber doch in Dateien (Modulen) speichern. :)

Diesem Vorteil habe ich mal eine eigene Überschrift gegönnt. :-)

Java hat auch eine interaktive Shell, BeanShell, aber die ist
nicht mit "ipython" vergleichbar. Das Eben-Mal-Ausprobieren kann
man gar nicht genug betonen, gerade im didaktischen Bereich.

Viele Detail-Fragen kann man einfach durch ausprobieren klären,
und Selbermachen haftet besser im Gedächtnis. Dank Tab-
Vervollständigung kann man mal schnell die richtigen Methoden
erfragen, selbst wenn die erst dynamisch erzeugt wurden.

Und vorallem: Es bewegt sich ständig was. Man sieht immer
kleine Erfolge. Das ist für die "großen Programmierer" mindestens
genauso wichtig wie für Schüler. Es steigert nicht nur die
Motivation, sondern sorgt vorallem auch für weniger Verständnis-
und Konzept-Fehler. Das kann einem kein noch so strenges Typsystem
abnehmen.

In guten Python-IDEs (oder mit zwei XTerms für Vim und IPython ;-))
kann man mal schnell zwischen Interpreter und Quellcode-Datei
wechseln. Im Interpreter probieren, im Quellcode festschreiben.
Und nachdem die Funktion Quellcode steht, kann man sie im Interpreter
wieder direkt nutzen und entweder ausprobieren oder gleich die
nächste Funktion schreiben. Diese Technik der "inkrementellen
Programmierung" sollte man so früh wie möglich lehren!

Die großartige Interaktivität ist ein klarer Pluspunkt für Python.

Auch noch so viele Editor-Features von Eclipse können einen
interaktiven Interpreter einfach nicht schlagen. BTW, das hat
nichts mit statischer Typisierung von Java zu tun. Das sog.
"Toplevel" von OCaml zeigt, dass auch eine extrem strenge,
statisch typisierte Sprache einen Interpreter haben kann.

(Leider fehlt es dem OCaml-Toplevel an vielen benutzerfreundlichen
Features, wie man sie von IPython gewohnt ist. Wäre das Toplevel
besser, würde ich viel mehr in OCaml programmieren. Aber das ist
ein anderes Thema.)


Doc-Tests:
----------

Die interaktiven Sitzungen liefern i.d.R. auch super Anhaltspunkte
für Unit-Tests - und man kann sie größtenteil einfach herüber
kopieren.

Noch besser: Doc-Tests, das sind spezielle Unit-Tests, die man
als Beispiel-Code in seine API-Doc hinein schreibt. Es sind auto-
matisch getestete Beispiele und Unit-Tests zugleich. Und die kann
man sogar *witklich* 1:1 aus der Interpreter-Shell herüber kopieren,
weil genau das die Syntax für Doc-Tests ist.

Vielleicht gibt es das inzwischen auch für Java, doch Doc-Tests
entfalten erst dann ihre wahre Stärke, wenn sie interaktiv entstehen.
Eine der wichtigsten und aufwändigsten Tätigkeiten, das Testen, kann
man mit sehr kleinem Aufwand automatisieren. So, wie es sein sollte.
Daher würde ich auch hier einen Pluspunkt an Python vergeben.


Gruß,

Volker

[Dennis Schulmeister]

Hallo Volker,

Post by Volker Grabsch
Java hingegen hat auch im Lowlevel-Bereich praktisch alles neu
implementiert. Dabei sind die neuen APIs nicht unbedingt besser
designt, sondern einfach nur anders. Einige mögen genau das, andere
nervt das.

Mich nervt das sogar ungemein. Zum Einen integrieren sich
Java-Anwendungen nicht so schön in das (Unix-)System und zum Anderen
führt das schon seit einem guten Jahr dazu, dass ich unter Java und
Linux nicht drucken kann. Weil es die Sun/Java-Entwickler nicht gebacken
bekommen, CUPS richtig anzusprechen.

Post by Volker Grabsch

Post by Dennis Schulmeister
In beiden Fällen
reichen die Funktionen der Bibliotheken von einfachen Kleinigkeiten bis
zur GUI-Pogrammierung. (Wobei ich persönlich Pythons TkInter nicht so
sehr mag wie Javas Swing. Doch auch von letzterem bin ich nicht so
angetan. Das ist jetzt aber nicht Gegenstand der Diskussion)

Dennoch sollte Python seinen starken Hang zu Tk ablegen. Nicht,
weil Tk zu einfach gestrickt ist, sondern vorallem, weil's rein
optisch potthässlich ist. Diesen Effekt darf man nicht unterschätzen.
Eine GUI-Library mit guter Optik motiviert Entwickler und Anwender
zugleich. Ähnliches gilt übrigens auch für Web-Programmierung, und
sogar für Programmierung im Textmodus (ncurses, slang).

Das ist richtig, Tk sieht wirklich nicht sonderlich schön aus. Auf
Windows geht es noch, weil die Widgets ähnlich den nativen
Windows-Widgets aussehen, aber unter Linux (Gnome)? Da bekommt man einen
Schreck.

Post by Volker Grabsch
Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries. Aber zu den
"eingebauten Batterien" gehört nach wie vor nur Tk. Unter Linux
wiegesagt kein Problem, aber wer unter Windows programmiert, oder
für Windows ausliefert, der hat hier eine unnötige Hürde.

Persönlich mag ich GTK sehr, so dass es für mich die GUI-Library
schlecht hin ist. Klar ist aber, dass es hier verschiedene Meinungen
gibt. Man darf allerdings aus Python-Sicht nicht vergessen, dass GTK
unter Windows ebenfalls nicht zum Lieferumfang gehört. Wenn Python pyGTK
(oder gar Kiwi) in seine Standardbibliothek aufnimmt, muss es für die
Windows-Anwender, die ja leider keine Paketverwaltung kennen, auch GTK
ausliefern. Umgekehrt gilt das natürlich auch für Qt.

wxWidgets ist meiner Meinung nach einfach nur pragmatisch. Aber das was
wxWidgets mit GTK macht, grenzt auch schon an Vergewaltigung und sieht
ebenfalls nicht sonderlich anschaulich aus.

Post by Volker Grabsch
Und genau das macht Java/Swing interessant: Hier hat man eine
_schicke_ GUI-Library mit viel Funktionalität eingebaut. In Python
ist nur Tk eingebaut, eine _hässliche_ GUI-Lib mit viel zu wenig
Funktionalität. Daher klarer Punkt an Java.

Naja, wenn du Swing als schick bezeichnen würdest. ;) Zumindest gibt es
ein Paar Möglichkeiten, die Optik zu verbessern.

Post by Volker Grabsch
Python sollte sich von Tk lösen und stattdessen GTK oder Qt als
Batterien mitbringen. Besonders ironisch: Für GTK gibt es bereits
eine Highlevel-Bibliothek namens Kiwi, die GUI-Programmierung
nochmals viel angenehmer macht. Eine echte "Geheimwaffe" von
Python, die AFAIK kein echtes Pendant in Java hat.
Kiki ist in meinen Augen der Swing-Killer schlechthin. Nur leider
gehört es in Python nicht zu den Batterien. :-(

Ich kenne Kiwi noch nicht so lange, aber du hast Recht. Es ist wirklich
eine super Sache.

Post by Volker Grabsch
Java hat auch eine interaktive Shell, BeanShell, aber die ist
nicht mit "ipython" vergleichbar. Das Eben-Mal-Ausprobieren kann
man gar nicht genug betonen, gerade im didaktischen Bereich.

Ist BeanShell nicht in Java selbst programmiert? Also Java in Java?

Post by Volker Grabsch
Viele Detail-Fragen kann man einfach durch ausprobieren klären,
und Selbermachen haftet besser im Gedächtnis.

Vollste Zustimmung.

Post by Volker Grabsch
Noch besser: Doc-Tests, das sind spezielle Unit-Tests, die man
als Beispiel-Code in seine API-Doc hinein schreibt. Es sind auto-
matisch getestete Beispiele und Unit-Tests zugleich. Und die kann
man sogar *witklich* 1:1 aus der Interpreter-Shell herüber kopieren,
weil genau das die Syntax für Doc-Tests ist.

Das ist wahr. Sollte also die Entscheidung zu Gunsten von Python
ausgehen, dann sollten DocStrings und DocTest auf jeden Fall gebührende
Erwähnung im Unterricht finden.


Mit freundlichen Grüßen,
Dennis Schulmeister

[Volker Grabsch]

Post by Dennis Schulmeister

Post by Volker Grabsch
Java hingegen hat auch im Lowlevel-Bereich praktisch alles neu
implementiert. Dabei sind die neuen APIs nicht unbedingt besser
designt, sondern einfach nur anders. Einige mögen genau das, andere
nervt das.

Mich nervt das sogar ungemein.

Seh ich genauso. Aber es gibt auch Leute, die der Meinung sind,
dadurch werde die untere Schicht ordentlich ausgemistet. Aber die
Qualität und Sicherheit der Libraries steigt eben nicht allein
dadurch, dass man sie in Java statt C implementiert. Vorallem,
wenn man bedenkt, wie alt die C-Libs sind und wieviel Debugging-
Arbeit darin steckt.

Uraltem Fortran-Code würde ich mehr vertrauen als einem jungen
Python-Code, obwohl ich genau weiß, dass im Python-Code gewisse
Fehler kategorisch ausgeschlossen sind. (es sei denn, der Python-
Interpreter selbst macht nen Segfaul oder Buffer-Overflow)

Post by Dennis Schulmeister

Post by Volker Grabsch
Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries. Aber zu den
"eingebauten Batterien" gehört nach wie vor nur Tk. Unter Linux
wiegesagt kein Problem, aber wer unter Windows programmiert, oder
für Windows ausliefert, der hat hier eine unnötige Hürde.

Persönlich mag ich GTK sehr, so dass es für mich die GUI-Library
schlecht hin ist.

Geht mir genauso. GTK erschien mir früher zu aufgebläht, zu viele
Schrauben zu drehen. Aber das meiste /will/ man auch drehen, wenn
die GUI ordentlich aussehen und ergonomisch sein soll. wxWidgets ist
z.B. unter Linux ein Wrapper für GTK. Ich fand das cool, eine
einfachere Schnittstelle zu GTK. Aber die Einschränkungen haben
mir überhaupt nicht geschmeckt.

Keine Auswahllisten mit zweizeiligen Einträgen (damit sie nicht
so lang sind). Labels kann man nicht mit dem Eingabefeld zentrieren,
und so weiter. Und das Tabellen-Widget (Grid) ist äußerst unhandlich.
Dann lieber etwas mehr Arbeit mit GTK, aber auch ein entsprechendes
Ergebnis. Dank Glade und Gazpacho sind auch die Details kein Problem.

Und der eigentliche Code? Da habe ich mit Kiwi ein _ordentliches_
vereinfachtes Interface gefunden. Die Programmierung ist sogar noch
einfacher als mit wxWidgets, und trotzdem werde ich nicht in der
Gestaltung und Auswahl der GUI-Komponenten eingeschränkt.

Post by Dennis Schulmeister
Wenn Python pyGTK
(oder gar Kiwi) in seine Standardbibliothek aufnimmt, muss es für die
Windows-Anwender, die ja leider keine Paketverwaltung kennen, auch GTK
ausliefern. Umgekehrt gilt das natürlich auch für Qt.

Ja, und? So fett ist GTK nun auch wieder nicht.

Ob der Python-Windows-Installer nun 11 MB oder 11,5 MB groß
ist, was macht das schon?

(Und bei den Linux-Distris ist es ja ziemlich egal, ob das nun
ein kleines Extrapaket oder Teil des Hauptpakets ist)

Post by Dennis Schulmeister

Post by Volker Grabsch
Und genau das macht Java/Swing interessant: Hier hat man eine
_schicke_ GUI-Library mit viel Funktionalität eingebaut. In Python
ist nur Tk eingebaut, eine _hässliche_ GUI-Lib mit viel zu wenig
Funktionalität. Daher klarer Punkt an Java.

Naja, wenn du Swing als schick bezeichnen würdest. ;) Zumindest gibt es
ein Paar Möglichkeiten, die Optik zu verbessern.

Ich fand damals diesen Metall-Look ziemlich gut. Auf jeden Fall
besser als das damalige Aussehen von Qt und GTK. (obwohl auch
die schon damals besser aussagen als Tk). Inzwischen sind GTK
und Qt wirklich schick geworden, aber Swing deshalb nicht
hässlicher.


Gruß,

Volker

[Hermann Riemann]

Post by Volker Grabsch
Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries.

QT soll ja auch unter windows gehen.

Wenn man GUI über CGI machen will,
ist Python wieder besser.

Post by Volker Grabsch

Post by Dennis Schulmeister
Python hat dafür einen anderen Vorteil: Seinen interaktiven Interpreter.

Wenn jemand eine von java abhängige script-Sprache
haben will, kann diese Person ja groovy nehmen.

Hermann
dessen nächstes größere Projekt
vermutlich ein Mix aus Programmen in 4 Sprachen ist.

[Sebastian Wiesner]

Post by Hermann Riemann

Post by Volker Grabsch
Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries.

QT soll ja auch unter windows gehen.

Seit Qt4 funktioniert das so gut, dass ich mittlerweile mit Python und PyQt4
wunderbar für Windows entwickeln kann (und das sogar größtenteils in der
gewohnten Linux-Entwicklungsumgebung).

Post by Hermann Riemann
Wenn man GUI über CGI machen will,
ist Python wieder besser.

GUI über Common Gateway Interface?

[Volker Grabsch]

Post by Hermann Riemann

Post by Volker Grabsch
Inzwischen hat jede Linux-Distribution Python-Bindings zu GTK, Qt,
wxWidgets und vielen anderen portablen GUI-Libraries.

QT soll ja auch unter windows gehen.

GTK und wxWidgets auch. Ich verstehe nicht, worauf du hinaus willst.

Post by Hermann Riemann
Wenn man GUI über CGI machen will,
ist Python wieder besser.

Stimmt, Webapplikationen sind auch ein wichtiger Punkt. Das hatte
ich vollkommen vergessen. Der WSGI-Standard und die vielen guten
Frameworks sprechen da sehr für Python. Andererseits gibt es auch
für Java ein entsprechendes Framework. Wie gut das ist, kann ich
leider nicht beurteilen.


Gruß,

Volker

[Sebastian Wiesner]

Post by Volker Grabsch
Dabei geht es gar nicht um die Qualität von Swing, die ich im
Vergleich zu GTK oder Qt übrigens auch nicht so toll finde,
sondern es geht um was anderes.

Aus Sicht des Entwicklers ist Swing imho sehr komfortabel und modern.
Zumindest hat es Dinge wie MFC schon lange für Qt gehabt.

Post by Volker Grabsch
Dennoch sollte Python seinen starken Hang zu Tk ablegen. Nicht,
weil Tk zu einfach gestrickt ist, sondern vorallem, weil's rein
optisch potthässlich ist.

Tk 8.5 hat ja jetzt eine Theming Engine, man darf gespannt sein, ob das dem
Look zuträglich ist.

Mich persönlich als Entwickler stört an Tk viel mehr, dass es in seinen
Möglichkeiten arg beschränkt ist, da viele Widgets, die bei anderen
Toolkits längst Standard sind, einfach fehlen. Das fängt schon bei so
einfachen Sachen wie Systray-Icons an.

Post by Volker Grabsch
Python sollte sich von Tk lösen und stattdessen GTK oder Qt als
Batterien mitbringen. Besonders ironisch: Für GTK gibt es bereits
eine Highlevel-Bibliothek namens Kiwi, die GUI-Programmierung
nochmals viel angenehmer macht.

Solange Trolltech/Nokia nichts an der Lizenz ändert, wird Qt in der
Standardbibliothek ein (schöner) Wunschtraum bleiben. Ob die Trolle
angesichts des Profits, den sie mit proprietären Qt-Lizenzen scheffeln,
bereits sind, Qt für lau der PSF zu überlassen, wage ich zu bezweifeln ;)

Aber ein anderes GUI Toolkit hätte Python dringest nötig. Gtk, Wx, völlig
egal, alles ist besser als Tk ;)

[Sebastian Wiesner]

Post by Dennis Schulmeister
---------------------------
Das wurde im Laufe der hiesigen Diskussion ja bereits angesprochen. In
Python verwendet man eine Variable einfach, wenn man sie braucht. Und es
ist auch kein Problem, einer Variable im Laufe ihres Lebens Werte von
fruehstueck = "10:00 Uhr"
fruehstueck = 3
fruehstueck = {
"Uhrzeit": "10:00 Uhr",
"Anzahl": 3
}
Das geht in Java natürlich nicht so einfach. Da gibt es nur statische
Typisierung und der einmal festgelegte Datentyp einer Variable ändert
sich auch nicht.
int iFruehstueck = 3
String strFruehstueck = "10:00 Uhr"
Die dritte Frühstücksvariable in meinem Python-Beispiel ist übrigens ein
Dictionary. Dafür gibt es Java leider keine so elegante Entsprechung.
todo = [
"Aufstehen",
"Anziehen",
"Tisch decken",
"Essen",
"Aufräumen",
"In die Arbeit fahren"
]
print task
String[] strTodos = {
"Aufstehen",
"Anziehen",
"Tisch decken",
"Essen",
"Aufräumen",
"In die Arbeit fahren"
};
for (String strTask : strTodos) {
System.out.println(strTask);
}
Insgesamt wirkt der Python-Code etwas eleganter, dennoch würde ich den
Punkt hier an Java vergeben. Warum? In Java wird der Code vor der
Ausführung kompiliert, in Python gibt es diesen Schritt nicht zwingend.

Auch Python-Code wird kompiliert. Im Allgemeinen bedeuten statische
Typisierung und Typprüfung auf jeden Fall noch lange nicht, dass man vor
Typprüfungen gefeiht ist. Ein schönes Java-Beispiel dazu:

class Test {
public static void main(String args[]) {
StringBuilder buffer = new StringBuilder('H');
buffer.append("ello World!");
System.out.println(buffer);
}
}

Für einen Anfänger kann es verdammt verwirrend sein, dass da nur "ello
World" rauskommt.

[Florian Diesch]

Post by guidofranke
Ab dem nächsten Schuljahr (2008-09) wollen wir in der SEK II, also am
Gymnasium (GHG-Wismar) die Prgrammiersprache für OOP-Entwicklung
wechseln. Zurzeit arbeiten wir noch ausschließlich mit Delphi (7.0),
müssen uns aber wohl oder Übel für eine andere entscheiden.
BlueJ (also JAVA) oder PYTHON 2.5 sind in die engere Wahl gekommen.

Warum? Was genau spricht gegen Delphi?

Post by guidofranke
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???

AFAIK ist BlueJ eher eine IDE für Java, keine eigene Sprache. Den
Schülern den Umgang mit einer speziellen IDE beizubringen halte ich
für wenig hilfreich. Typischerweise liegt das Problem erst einmal
darin, die Konzepte zu verstehen.

Post by guidofranke
Was soll ich vorbereiten?
Was macht PYTHON (außer seiner unabhängigkeit von SUN) attraktiv, um es
BlueJ vorzuziehen?

* In Java benötigt man auch für einfache Programme sehr schnell relativ
viel Code, Python ist da typischerweise einfacher.

* Python erzwingt eine ordentliche Formatierung des Codes (dafür
erzwingt Java einen sauberen Umgang mit Typen, aber das wird wohl
auf dem angestrebten Niveau wenig relevant sein).

Post by guidofranke
Ich muss gestehen, dass ich beide Sprachen nur sehr oberflächlich kenne,
Bücher angeschafft habe (Java lernen mit BlueJ von Barnes/König und OOP
mit Python von Michael Weigland, beide in der 3. Auflage).

IMHO sollten die unterrichtenden Lehrer einigermaßen fundierte
Kenntnisse in der im Unterricht benutzten Sprache haben.

Post by guidofranke
Trotzdem bin ich immer noch unentschlossen.
Da ich ab dem 21.7.2008 unsere PC-Anlage umstellen werde, würde ich
diese Entscheidung gern vorher treffen. Alternativ bliebe natürlich,
beide Sprachsysteme vollständig zu implementieren und dann flexibel zu
bleiben. Der Installationsaufwand scheint mir bei BlueJ höher zu sein,
da ja Python mit knapp 13MB sehr klein ausfällt,oder hab ich da nun was
übersehen?

Der Installationsaufwand sollte das kleinste Problem sein.

Post by guidofranke
Gibt es für Python auch eine Entwicklungsumgebung unter Windows?

Ich kenne Windows nicht, aber für den Anfang würde ich mich auf einen
Editor beschränken, der Syntaxhighlighting und automatische Einrückung
für die angestrebte Sprache beherrscht. Dinge wie eine
Projektverwaltung machden es für die Schüler nur unnötig kompliziert.



Florian

[Stefan Behnel]

Post by Florian Diesch

Post by guidofranke
Gibt es für Python auch eine Entwicklungsumgebung unter Windows?

Ich kenne Windows nicht, aber für den Anfang würde ich mich auf einen
Editor beschränken, der Syntaxhighlighting und automatische Einrückung
für die angestrebte Sprache beherrscht. Dinge wie eine
Projektverwaltung machden es für die Schüler nur unnötig kompliziert.

Das klingt in meinen Ohren realistisch. Für den Anfang ist es sicherlich
besser, mit einem Interpreter herumspielen zu können, als sich vor der
eigentlichen Programmierung erst großartig in eine IDE einarbeiten zu müssen
(gilt für die Lehrer wahrscheinlich genauso wie für die Schüler).

Stefan

[Marc 'BlackJack' Rintsch]

Post by Florian Diesch

Post by guidofranke
Viele meiner Kollegen bevorzugen BlueJ einige Wenige PYTHON!!!???

AFAIK ist BlueJ eher eine IDE für Java, keine eigene Sprache. Den
Schülern den Umgang mit einer speziellen IDE beizubringen halte ich
für wenig hilfreich. Typischerweise liegt das Problem erst einmal
darin, die Konzepte zu verstehen.

BlueJ ist mit dem Ziel angetreten lernenden das OOP Konzept näher zu
bringen. Es versucht so ein bisschen Smalltalk für Arme zu sein, in dem
man "live" Objekte erstellen und verändern kann und sich die zusammenhänge
wohl auch grafisch darstellen lassen kann. Das ist weniger eine IDE, die
man für echten Programme verwenden würde, als vielmehr eine Lernumgebung.
In sofern also schon für Schüler geeignet. Jedenfalls besser als denen
Eclipse mit seinen zigtausend Funktionen und Einstellungsmöglichkeiten
vorzusetzen.

Ciao,
Marc 'BlackJack' Rintsch

[Stefan Scholl]

Meine Schulsprachen: Turbo Pascal und COBOL

Kann nicht verstehen warum das jetzt anders gehandhabt werden
soll. ;-)


Muss mich den anderen Kommentaren anschließen: Python ist sauber,
erlaubt aber trotzdem sehr schnelle Erfolgserlebnisse. Das
dürften die wichtigsten Argumente für Python als Lehrsprache
sein.

:wq

[guidofranke]

Post by Stefan Scholl
Meine Schulsprachen: Turbo Pascal und COBOL
Kann nicht verstehen warum das jetzt anders gehandhabt werden
soll. ;-)
Muss mich den anderen Kommentaren anschließen: Python ist sauber,
erlaubt aber trotzdem sehr schnelle Erfolgserlebnisse. Das
dürften die wichtigsten Argumente für Python als Lehrsprache
sein.
:wq

In meiner Schulzeit bis 1979 gab es keine PC. Selbst ein Taschenrechner
war in der Prüfung verboten.
1980 hab ich dann Maschinencode z80 i8086 erlernt. Später dass (MS)ASM
und BASIC, PASCAL, TurboPascal, SQL, seit 2000 dann Delphi und PROLOG,
PHP, JAVAScript und nun UML. JAVA-PYTHON OOP. Wenn ich mir das ganze so
ansehe, ist allen Sprachen, bis auf PROLOG, eines gemeinsam, die
imperative Struktur: Lineare Folgen, Zyklen, Verzweigungen, Datentypen.

Was dieser "von oben angeordnete" ständige Sprachwechsel soll, ist mir
dabei völlig unverständlich.

Zu meiner Studienzeit (ab 1995 Zusatz-Quali Informatik für Lehrer UNI
HRO) hat man sich beim Thema "Softwaretechnik" einen Dreck um die
Sprachauswahl gekümmert, Pascal 5 hat damals gereicht und bis auf den
OOP-Spaß kann ich auch heute alles Andere damit machen.

Ich habe 28 Jahre lang gut auf Klassen verzichten können, Systemtreiber
für die unterschiedlichste Hardware und 1886-87 fürs Militär Hard- und
Software entwickelt.

Eigentlich wollte ich nur ein ganz kleines pro/contra.
Was ich hier losgebrochen habe tut mir ja fast leid. Ich bin genau
schlau wie vorher.

Wen es speziell interessiert: Das Kerncurricula für die Sekundärstufe 2
am Gymnasium findet ihr hier zum download:

http://www.bildungsserver-mv.de/download/rahmenplaene/kc-informatik-11-12-gym.pdf


Hier ein Auszug für das Thema Softwaretechnik

4.3 Softwareentwicklung
(2 Wochenstunden, 1/2 Schuljahr also max. 32 Stunden)
Anmerkung: ich kenne niemenden, der nach 32 Stunden prgammieren konnte ;-(
Inhalte
● objektorientierte Modellierung (UML-Klassendiagramme)
● Algorithmen und Datenstrukturen
● objektorientierte Programmierung
● Grundlagen systematischer Softwareentwicklung (Software-Life-Cycle)
Hauptfach (4 Wochenstunden)
● deklarative Programmierung (funktional oder logisch)
Kompetenzerwerb im Themenfeld
Im Themenfeld Softwareentwicklung erwerben die Schülerinnen und Schüler
Kenntnisse
über das methodische Vorgehen zur modellhaften Entwicklung von
Softwaresystemen.
Die Darstellung von Algorithmen in graphischer Form und ihre Umsetzung
in ein effizientes
Programm sollen den Schülerinnen und Schülern einen Einblick in eine
wesentliche Phase
der Erstellung von Software vermitteln. Problemlösestrategien werden von
den Schülerinnen
und Schülern selbst angewendet. Die algorithmischen Lösungswege werden
dabei formalisiert,
implementiert und auf Zuverlässigkeit geprüft.
Die Einführung eines weiteren Programmierparadigmas verdeutlicht, dass
für die Lösung
von Problemen verschiedene Sprachkonzepte unterschiedlich gut geeignet sind.
Mensch-Maschine-Schnittstellen werden analysiert und adressatengerecht
berücksichtigt.
Mögliche Kontexte
● Pakete, Interfaces
● Softwareergonomie
● Veränderung in der Arbeitswelt
● Auswirkungen in der Gesellschaft
● Simulation (dynamische Systeme, Automaten)


Übrigens ist das Alles an Informationen, die man uns gibt. Die Zentralen
Abiturprüfungen geben etwas mehr Aufschluss über dass, was gelehrt
werden soll. So etwas "Schwammiges" kann man Schülern doch nicht antun,
oder?

Hier mal eine Beispielarbeit:

http://www.bildung-mv.de/export/sites/lisa/de/abitur2008/Beispielaufgaben_2008_pdf-Format/Informatik.pdf

[Torsten Bronger]

Hallöchen!

[...]
Eigentlich wollte ich nur ein ganz kleines pro/contra. Was ich
hier losgebrochen habe tut mir ja fast leid. Ich bin genau schlau
wie vorher.

Das ist aber nicht ganz fair. Es wurden hier sehr gründliche
Vergleiche angestellt.

Wen es speziell interessiert: Das Kerncurricula für die
http://www.bildungsserver-mv.de/download/rahmenplaene/kc-informatik-11-12-gym.pdf

Das ganze Pro/Contra hast du ja bereits. Meine Empfehlung nach
Lektüre dieses Textes ist: Installiert die
Standard-Python-Distribution und nehmt IDLE. Die Schüler haben
damit alles, was sie brauchen, ohne sie unnötig zu belasten.

Tschö,
Torsten.

P.S.: Ich bin ganz schön entsetzt über diesen Lehrplan. Da wird
teilweise das zweite vor dem ersten Stockwerk gebaut.

[Stefan Behnel]

Post by guidofranke
1980 hab ich dann Maschinencode z80 i8086 erlernt. Später dass (MS)ASM
und BASIC, PASCAL, TurboPascal, SQL, seit 2000 dann Delphi und PROLOG,
PHP, JAVAScript und nun UML. JAVA-PYTHON OOP. Wenn ich mir das ganze so
ansehe, ist allen Sprachen, bis auf PROLOG, eines gemeinsam, die
imperative Struktur: Lineare Folgen, Zyklen, Verzweigungen, Datentypen.

Und du meinst jetzt, da hätte sich seit dem späten 19. Jahrhundert nichts
geändert, als die liebe Ada das Programmieren erfunden hat. (was ich übrigens
im Unterricht sehr erwähnenswert finde).

Post by guidofranke
Was dieser "von oben angeordnete" ständige Sprachwechsel soll, ist mir
dabei völlig unverständlich.

Das hat mit "von oben verordnet" eher wenig zu tun. Konkurrierende Sprachen
gibt es seit Urzeiten. Das heißt aber nicht, dass dabei keine
Weiterentwicklung stattgefunden hat, nicht einmal innerhalb der großen
Sprachfamilien. Es gibt durchaus so etwas wie einfache und schwere Sprachen,
komplizierte und offensichtliche.

Post by guidofranke
Zu meiner Studienzeit (ab 1995 Zusatz-Quali Informatik für Lehrer UNI
HRO) hat man sich beim Thema "Softwaretechnik" einen Dreck um die
Sprachauswahl gekümmert, Pascal 5 hat damals gereicht und bis auf den
OOP-Spaß kann ich auch heute alles Andere damit machen.

Dann hat sich ja doch noch etwas geändert.

Post by guidofranke
Ich habe 28 Jahre lang gut auf Klassen verzichten können, Systemtreiber
für die unterschiedlichste Hardware und 1886-87 fürs Militär Hard- und
Software entwickelt.

Für Systemtreiber würde ich Objektorientierung auch nicht zwingend
voraussetzen. Aber sicherlich eine Frage des Umfangs.

Post by guidofranke
Eigentlich wollte ich nur ein ganz kleines pro/contra.
Was ich hier losgebrochen habe tut mir ja fast leid. Ich bin genau
schlau wie vorher.

Das sind zwei verschiedene Dinge. Aber Argumente gab es sicherlich genug. Wer
lesen kann ist klar im Vorteil.

Ansonsten schonmal hierhin geschaut?

http://www.python.org/community/sigs/current/edu-sig/

Post by guidofranke
Übrigens ist das Alles an Informationen, die man uns gibt. Die Zentralen
Abiturprüfungen geben etwas mehr Aufschluss über dass, was gelehrt
werden soll. So etwas "Schwammiges" kann man Schülern doch nicht antun,
oder?

Zumal die Inhalte für 32 Stunden schon ziemlich umfangreich sind. Mal Hand
aufs Herz - gibt es ein Schulfach, wo die Vorgaben nicht schwammig sind?
Ansonsten wäre das Lehrerleben doch viel zu langweilig...

Stefan

[Michael Ströder]

Post by guidofranke
Wen es speziell interessiert: Das Kerncurricula für die Sekundärstufe 2
http://www.bildungsserver-mv.de/download/rahmenplaene/kc-informatik-11-12-gym.pdf
Hier ein Auszug für das Thema Softwaretechnik
4.3 Softwareentwicklung
(2 Wochenstunden, 1/2 Schuljahr also max. 32 Stunden)
Anmerkung: ich kenne niemenden, der nach 32 Stunden prgammieren konnte ;-(
Inhalte
[..illusorische Auflistung größenwahnsinniger Bildungsbürokraten
gelöscht...]

Guido, ich kann Dein Dilemma verstehen, welches letztlich nix mit der
Programmiersprache zu tun hat. (Habe letztens einer befreundeten
Lehrerin die Grundzüge von UML-basierter Modellierung erklärt, obwohl
ich jetzt auch nicht der ausgewiesene Modellierungskönig bin.)

Das Problem ist meines Erachtens, dass die Schüler Lösungen für Probleme
erlernen sollen, welche sie gar nicht kennen. Und das immer gleich in
der allumfassenden Komplexität. Mir persönlich hat beim Lernen immer
geholfen an konkreten Beispielen zu erkennen, warum der eine Schritt in
der Entwicklung auf den anderen folgte (und was ggf. alter Wein in neuen
Schläuchen ist. ;-) Aber die ganze Historie von Assembler zu UML kann
man in 32 Stunden nicht vermitteln. Das kapieren die
G12-Turbo-Bildungspolitiker aber leider nicht. Ich bin pessimistisch,
was dabei raus kommt.

Ciao, Michael.

[Marek Kubica]

Post by guidofranke
In meiner Schulzeit bis 1979 gab es keine PC. Selbst ein Taschenrechner
war in der Prüfung verboten.
1980 hab ich dann Maschinencode z80 i8086 erlernt. Später dass (MS)ASM
und BASIC, PASCAL, TurboPascal, SQL, seit 2000 dann Delphi und PROLOG,
PHP, JAVAScript und nun UML. JAVA-PYTHON OOP. Wenn ich mir das ganze so
ansehe, ist allen Sprachen, bis auf PROLOG, eines gemeinsam, die
imperative Struktur: Lineare Folgen, Zyklen, Verzweigungen, Datentypen.

Weil das ja auch alles imperative Sprachen sind, bis auf Prolog und SQL.
Du hast dir keine einzige funktionale Sprache angesehen, in denen Dinge
anders aussehen können: etwa ein sehr starker Fokus auf Typen wie bei
Scala oder Haskell, ein Misch aus funktionaler Programmierung und OOP wie
bei OCaml oder der Schwerpunkt bei Metaprogrammierung wie in Lisp. Scheme
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Python hat da den Vorteil gegenüber Java, dass man auch mehr Funktionale
Elemente in der Sprache einsetzen kann wenn man will, bietet im Gegensatz
zu Java mehrere Paradigmen.

grüße,
Marek

[guidofranke]

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt. Wenn dann der Rekursionsausstieg nicht mit
100%er Sicherheit garantiert ist, gibts mit absoluter Sicherheit
Speicherüberläufe, der man nur mit exquisiter Fehlerbehandlungsroutinen
begegnen kann.

Wenn dann so eine unendliche Rekursion auch noch in Echtzeit arbeitet
kannst du nur noch den Stecker ziehen, da sich solche Dinger totlaufen.
M.E. ist Windows nichts weiter als eine solche Rekursion, die Resourcen
frisst ohne sie wirklich zu brauchen; erst mal Speicher reservieren.
Speicher wieder freigeben können dann externe Destruktoren...

Wie liebe ich doch Maschinencode in HEX geschrieben.
Ich freue mich jedes mal, wenn Schüler in Delphi Laufzeitfehler
verursachen und der debugger dann die Inhalte der Register auflistst.
Mann ist das schön, wenn man sieht, wie alles mal begann...

[Marc 'BlackJack' Rintsch]

Post by guidofranke

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

Wenn man eine iterative Schleife durch Rekursion ersetzt wird in einer
funktionalen Sprache genau so viel Kellerspeicher verwendet, wie bei der
Iteration -- nämlich keiner. Sonst könnte man in funktionalen Sprachen
wohl kaum irgend ein sinnvolles Programm mit länger laufenden Schleifen
schreiben. Das Du anscheinend nicht weisst was Endrekursion ist, und das
Compiler, übrigens auch solche für imperative Sprachen, die entsprechend
optimieren, ist für jemanden der Schülern programmieren beibringen will
schon irgendwie bedenklich.

Post by guidofranke
Wie liebe ich doch Maschinencode in HEX geschrieben.
Ich freue mich jedes mal, wenn Schüler in Delphi Laufzeitfehler
verursachen und der debugger dann die Inhalte der Register auflistst.
Mann ist das schön, wenn man sieht, wie alles mal begann...

Früher war alles besser. Also ich freue mich eigentlich immer wenn ich
eine Ausnahme plus Stapelabzug sehe und mir das meistens genug Information
gibt, dass ich nicht auf die Maschinenebene herunter muss. Das mit den
Registern macht nämlich auch nur dann "Spass", wenn der Prozessor nicht
allzuviele davon hat und der Compiler den Quelltext möglichst "dumm"
übersetzt und nicht so optimiert, dass der Zusammenhang zwischen Quelltext
und Assembler nicht mehr so einfach nachvollziehbar ist.

Ciao,
Marc 'BlackJack' Rintsch

[Stefan Behnel]

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna bin ich ein großer Feind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

So ziemlich alle funktionalen Sprachen verwenden statt Schleifen Rekursion.
Und ich kenne trotzdem kaum eine Sprache, die zu so effizientem Maschinencode
führt wie StandardML.

Stefan

[Stefan Behnel]

[und auch hier hätte "Allen antworten" genau das getan, wozu es da ist]

Post by Stefan Behnel

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna bin ich ein großer Feind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

So ziemlich alle funktionalen Sprachen verwenden statt Schleifen Rekursion.
Und ich kenne trotzdem kaum eine Sprache, die zu so effizientem Maschinencode
führt wie StandardML.
Stefan

Das ist ja auch kein Wunder, da ja eine Rekursion im Grunde nichts
weiter ist, als ein CALL auf sich selbst, mit vorhergehendem Push der
Register in den Stack. Nur peinlich, wenn die POP den Keller nicht mehr
leeren, weil der Rekursionsausstieg niemals erreicht wird (Berechnung
von Pi wäre ein tolles Beispiel).

Rekursion in einer Hochsprache zu verwenden bedeutet nicht, dass auch der
Compiler zur Umsetzung Funktionsaufrufe verwenden muss. Hat sich wohl doch
seit der Computerfrühzeit ein bisschen was geändert.

Stefan

Wer schreibt den effektivsten Code, um Pi exakt (ohne Stellenbegrenzung
nach dem Komma) zu berechnen?
Das dürfte doch eine Herausforderung für alle mathematisch angehauchten
Informatiker sein. Nur die Zielbedingungen wären noch zu definieren.
-schnellster Code
-leichtester Code
-sauberster Code
-höchste Genauigkeit (wobei es ja immer nur ein Näherungswert sein kann)
-stabilster Code
und nicht zu vergessen wäre natürlich auch die Testplattform, auf der
die Software laufen soll, natürlich ohne NPU-Unterstützung
sagen wir auf Basis des Befehlssatzes des commodore 64 (eine reine
peek-poke-Maschine, aber für die damalige Zeit aufgrund des geringen
Befehlssatzes sehr schnell)
Bitte diese Aufgabe nicht allzu ernst nehmen. Ich möchte unter euch
keinen Konkurrenzkampf entfachen. ;-)
Das war einfach ein Gedankensprung zum Thema "Rekusive Berechnung"

[Marek Kubica]

Servus,

Post by Stefan Behnel
So ziemlich alle funktionalen Sprachen verwenden statt Schleifen
Rekursion. Und ich kenne trotzdem kaum eine Sprache, die zu so
effizientem Maschinencode führt wie StandardML.

Was nicht zuletzt auch an den aufwendigen Optimierungen liegt die MLTon
mit seiner Whole Program Optimization da anwendet.

Zum Rekursionsthema noch:
Rekursion ist genausogut wie Iteration da sie im Falle der Endrekursion
wieder intern vom Compiler zur Iteration umgebaut wird, wie Marc schon
sagte. Der Vorteil der Rekursion ist also nicht dass die Programme nicht
größer werden können ;) sondern dass man gewissen Dinge schöner und
einfacher auf rekursive Art und Weise lösen kann ohne dass man sich über
Speicher der irgendwann ausgeht Gedanken machen muss.

grüße,
Marek

[Volker Grabsch]

[...] Der Vorteil der Rekursion ist also nicht dass die Programme nicht
größer werden können ;) sondern dass man gewissen Dinge schöner und
einfacher auf rekursive Art und Weise lösen kann ohne dass man sich über
Speicher der irgendwann ausgeht Gedanken machen muss.

Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Eine Tail-Rekursion in eine Interation umzuschreiben ist ne nette
Übung. Genauso wie man auch echte Rekursionen mit selbstgebautem
Stack o.ä. mit Schleifen umformulieren kann. Das eine nette Zusatz-
Aufgabe für die Schüler, die sich im Unterricht langweilen. Aber
das ist nichts, was systematisch vermittelt werden sollte. Programm-
code muss von /Menschen/ gelesen und verstanden werden können.


Gruß,

Volker

[Hermann Riemann]

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen
Assemblertricks verwendet werden.
Ein Compiler hat nicht immer das Anwenderwissenwissen,
und hat auch seine Grenzen.

Hermann
der vermutet,
das compiler immer noch keinen code
zur Laufzeit überschreiben.

[Volker Grabsch]

Post by Hermann Riemann

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen
Assemblertricks verwendet werden.

Naja, erstmal bessere (dafür aber kompliziertere) Algorithmen.
Dann eine Sprache auf niedrigerem Level (z.B. C), und _dann_
erst Assembler, als allerletzten Ausweg, würd ich sagen. :-)

Davon abgesehen: Schon der erste Schritt, gezielte Zeitfresser
zu suchen und durch komplexere Algorithmen zu bändigen, das
dürfte im Unterricht kaum zu bewältigen sein.

Aber der Leuten verfrühte Optimierungen auszureden, und ihnen
den Umgang mit einem Profiler vorzuführen, damit kann man gar
nicht früh genug beginnen!


Gruß,

Volker

[Hermann Riemann]

Post by Volker Grabsch

Post by Hermann Riemann

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen
Assemblertricks verwendet werden.

Naja, erstmal bessere (dafür aber kompliziertere) Algorithmen.

Also ein GOTO-Salat?

Post by Volker Grabsch
Dann eine Sprache auf niedrigerem Level (z.B. C),

Bei Java habe ich kein API zu C gefunden.

Wenn Python (und clisp) C aufrufen
geht das umständlich (und vermutlich mit Einschränkung) über
.so (windows .dll) Dateien.

Python kann (unter SuSE 10.3 allerdings nicht ganau nach Beschreibung)
relativ einfach von C aus aufgerufen werden
( Ich finde dieses API derzeit gut, habe aber noch kaum Praxis)

Post by Volker Grabsch
und _dann_
erst Assembler, als allerletzten Ausweg, würd ich sagen. :-)

Der allerletze Ausweg ist Maschinecode
( in z.B. C über pointer to function)

Post by Volker Grabsch
Davon abgesehen: Schon der erste Schritt, gezielte Zeitfresser
zu suchen und durch komplexere Algorithmen zu bändigen, das
dürfte im Unterricht kaum zu bewältigen sein.

Da ist Python schon geeignet:
In Python werden meiner Kenntnis nach arrays als Listen angesehen
und statt Indexberechnung eine Schleife durchlaufen.

Wenn ich z.B. einen scanner baue,
bei dem ich in einer Liste
für jeden Buchstaben
ein Element mit Inhalt
eine Variable vom Typ eine Klasse zuordne,
so hab eich für den Zugriff
(meist Kleinbuchstaben mit Dezimalwert >100)
ca 500 Zyklen alleine für den loop.
Bei einer schnellen Reaktionszeit möchte ich dafür
nicht mehr als 5 milli Sekunden spendieren.
Es es verbleiben 10 Mikrosekunden.
Mit einer CPU von 2000 Befehlen pro Mikosekunden
und 10 Takte für diesen loop
dürften die Dateien zusammen nicht größer als 2 kB sein.

Post by Volker Grabsch
Aber der Leuten verfrühte Optimierungen auszureden, und ihnen
den Umgang mit einem Profiler vorzuführen, damit kann man gar
nicht früh genug beginnen!

Einen Profiler habe ich nie verwendet.
Dafür habe ich aber schon mehrfache Änderungen
für Optimierungsbedingungen erlebt.
z.B. erst war die Takte pro Befehl wichtig,
nach Einführung von pipeline deren Berücksichtigung.

Hermann
der vermutet, das die CPU-Leistung nicht mehr so schnell
zunimmt wie es in den letzten Jahrzehnten war.

[Stefan Behnel]

Post by Hermann Riemann
Wenn Python (und clisp) C aufrufen
geht das umständlich (und vermutlich mit Einschränkung) über
.so (windows .dll) Dateien.

Das ist ja glatt gelogen.

http://cython.org/

Stefan

[Volker Grabsch]

Post by Hermann Riemann

Post by Volker Grabsch

Post by Hermann Riemann

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen
Assemblertricks verwendet werden.

Naja, erstmal bessere (dafür aber kompliziertere) Algorithmen.

Also ein GOTO-Salat?

Ich habe nichts dergleichen geschrieben.

Davon abgesehen: Auch einfache Algorithmen kann man schlampig
umsetzen ("GOTO-Salat"). Der Einsatz eines komplizierteren
Algorithmus' rechtfertigt selbstverständlich keinen Spaghetti-
Code, im Gegenteil! Je komlizierter das Konzept, umso wichtiger
die übersichtliche Umsetzung.

Post by Hermann Riemann

Post by Volker Grabsch
Dann eine Sprache auf niedrigerem Level (z.B. C),

Bei Java habe ich kein API zu C gefunden.

Es gibt auch in Java Schnittstellen zu C-Libraries.
Schau dir mal JOGL an, damit können Java-Programme auf
OpenGL (eine C-Library) zugreifen.

Konkret in Java gebe ich dir dennoch recht: Da kann
man auch direkt zum JavaVM-Assembler ("Jasmine"?) gehen.

Post by Hermann Riemann
Wenn Python (und clisp) C aufrufen
geht das umständlich (und vermutlich mit Einschränkung) über
.so (windows .dll) Dateien.

Das Anbinden existierender C-Libraries ist in Python
gang und gäbe. Soo schlimm kann das also nicht sein. :-)

Die eleganteste/einfachste Anbindung einer Highlevel-
Sprache an C hat aber immer noch Ocaml. YMMV.

http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

Post by Hermann Riemann

Post by Volker Grabsch
und _dann_
erst Assembler, als allerletzten Ausweg, würd ich sagen. :-)

Der allerletze Ausweg ist Maschinecode
( in z.B. C über pointer to function)

Wieso das denn? Gibt es im Maschinencode irgendwas,
das man nicht genauso (und übersichtlicher) in Assembler
ausdrücken kann?

Assembler ist doch, bis auf ein paar Makros, nichts
weiter als eine menschenlesbare, direkte Repräsentation
des Maschinencodes. Es ist doch keine "andere Sprache"
oder sowas.

Post by Hermann Riemann

Post by Volker Grabsch
Aber der Leuten verfrühte Optimierungen auszureden, und ihnen
den Umgang mit einem Profiler vorzuführen, damit kann man gar
nicht früh genug beginnen!

Einen Profiler habe ich nie verwendet.
Dafür habe ich aber schon mehrfache Änderungen
für Optimierungsbedingungen erlebt.
z.B. erst war die Takte pro Befehl wichtig,
nach Einführung von pipeline deren Berücksichtigung.

Den Profiler interessiert das alles gar nicht. Er
misst einfach die Zeiten und Anzahl der Aufrufe.
Das hilft beim Finden der Flaschenhälse ungemein.
Und man kann im Nachhinein verifizieren, ob man
gut genug optimiert hat.

Auch beim Optimieren selbst ist er eine große Hilfe,
wenn man z.B. mehrere Varianten hat ... und bis man
wirklich gemessen hat, kann man ja nie sicher sein,
welche Variante nun die schnellere ist.


Gruß,

Volker

[Stefan Behnel]

Post by Volker Grabsch

Post by Hermann Riemann
Wenn Python (und clisp) C aufrufen
geht das umständlich (und vermutlich mit Einschränkung) über
.so (windows .dll) Dateien.

Das Anbinden existierender C-Libraries ist in Python
gang und gäbe. Soo schlimm kann das also nicht sein. :-)
Die eleganteste/einfachste Anbindung einer Highlevel-
Sprache an C hat aber immer noch Ocaml. YMMV.
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

Hauptnachteil dabei ist, dass du immer noch C schreiben musst, um C-Code
anzubinden. Selbst, wenn OCaml anscheinend etliche Macros anbietet, um mit
OCaml-Typen umzugehen (inkl. GC), finde ich eine Lösung innerhalb der
Zielsprache (also OCaml oder Python) einfacher zu handhaben. Cython und ctypes
erscheinen mir da wesentlich schöner.

Stefan

[André Malo]

Cython und ctypes erscheinen mir da wesentlich schöner.

Ja, das wundert mich nicht.

nd

[Marc 'BlackJack' Rintsch]

Post by Hermann Riemann

Post by Volker Grabsch
Davon abgesehen: Schon der erste Schritt, gezielte Zeitfresser
zu suchen und durch komplexere Algorithmen zu bändigen, das
dürfte im Unterricht kaum zu bewältigen sein.

In Python werden meiner Kenntnis nach arrays als Listen angesehen
und statt Indexberechnung eine Schleife durchlaufen.

Listenzugriff über Index ist in Python in O(1) Zeit, also direkter
Zugriff. Nix mit Schleife. Da würdest Du also schon an der falschen
Stelle mit Optimierungen herumdoktern.

Post by Hermann Riemann

Post by Volker Grabsch
Aber der Leuten verfrühte Optimierungen auszureden, und ihnen
den Umgang mit einem Profiler vorzuführen, damit kann man gar
nicht früh genug beginnen!

Einen Profiler habe ich nie verwendet.

Und woher weisst Du dann, ob Du an der Stelle optimierst, die den meisten
Geschwindigkeitsgewinn verspricht und ob der nach der Veränderung auch
wirklich eingetreten ist?

Post by Hermann Riemann
z.B. erst war die Takte pro Befehl wichtig,
nach Einführung von pipeline deren Berücksichtigung.

Tja und heute ist eher wichtig, ob man "cache misses" oder gar "page
faults" provoziert, die wesentlich mehr als ein paar Prozessorzyklen
fressen und unter Umständen kann es sogar etwas bringen Daten in
Arrays *nicht* an gerade Adressen aus zu richten, damit nicht alles auf
den gleichen cache lines landet. Auch hier ist Profiling wieder wichtig,
sonst ist das nur stochern im Nebel.

Post by Hermann Riemann
Hermann
der vermutet, das die CPU-Leistung nicht mehr so schnell
zunimmt wie es in den letzten Jahrzehnten war.

Dafür aber die Anzahl der Kerne. Viel Spass beim Aufteilen von
Algorithmen auf mehrere Kerne *in Assembler*. :-)

Ciao,
Marc 'BlackJack' Rintsch

[Sebastian Wiesner]

Post by Hermann Riemann

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen
Assemblertricks verwendet werden.

So? Und du meinst also allen Ernstes, dass dein Assemblercode effizienter
ist als der vom Compiler aus guten C-Code erzeugte?

Händisch geschriebener Assemblercode als Optimierung hat sich angesichts der
heutigen Compiler ein klein wenig überlebt ...

Post by Hermann Riemann
Ein Compiler hat nicht immer das Anwenderwissenwissen,
und hat auch seine Grenzen.

Das Anwenderwissen sollte aber in einen besseren Algorithmus investiert
werden und nicht in den eher sinnlosen Versuch, C besser zu optimieren als
der Compiler.

[Marc 'BlackJack' Rintsch]

Post by Hermann Riemann

Post by Volker Grabsch
Und genau das - Übersichtlichkeit und gute Darstellung - sollte
in der Schule vermittelt werden. Nicht irgendwelche Lowlevel-
Optimierungen, die jeder halbwegs intelligente Compiler heutzutage
automatisch erledigt.

Nicht ganz.
Nach meiner Erfahrung sollte überwiegend übersichtlich programmiert
werden und eventuell an zeitkritischen Stellen Assemblertricks verwendet
werden. Ein Compiler hat nicht immer das Anwenderwissenwissen, und hat
auch seine Grenzen.

Und der Anwender hat nicht immer das Wissen über CPU-Interna und hat auch
seine Grenzen. CPUs setzen teilweise die Befehle intern in einen anderen,
einfacheren Befehlssatz um und ordnen diese Befehle wenn's günstig
erscheint auch noch um. Das Wissen über den Zielprozessor, was der
Prozessorhersteller in seinen C-Compiler steckt, also zum Beispiel Intel,
hat ein normalsterblicher Programmierer in der Regel gar nicht.

Post by Hermann Riemann
Hermann
der vermutet,
das compiler immer noch keinen code
zur Laufzeit überschreiben.

Falls damit Selbstmodifikation gemeint ist -- das war auf'm C64 ganz nett
und nützlich, aber auf Desktop-CPUs stehen da Schreibschutz bei
Codesegmenten und das Invalidieren des Caches dagegen.

Ciao,
Marc 'BlackJack' Rintsch

[Stefan Scholl]

Post by guidofranke

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt. Wenn dann der Rekursionsausstieg nicht mit

Wenn man ungeschickt ist, ja.

Lies mal was über Tail Recursive.

[Volker Grabsch]

Post by guidofranke

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna

Naja, zumindest behauptest du nicht, Kenner der Compilerinterna
zu sein.

Post by guidofranke
bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

Selbst die C-Compiler können Tail-Recursion erkennen - was du im
erzeugten Maschinencode übrigens sehr gut erkennen kannst - dort
wird im Wesentlichen statt "PUSH,PUSH,PUSH,...,CALL" einfach
"MOV,MOV,MOV,...,JMP" gemacht. Die effiziente Behandlung von
Tail-Recursion ist also nicht einmal besonders kompliziert.

Bei Java dürfte das genauso aussehen. Ergo: Kein Stackverbrauch.

Was übrigens tatsächlich ein Nachteil von Python ist: Dort wird
Tail-Recursion leider (noch) nicht erkannt, sodass man dort aus
Effizienzgründen tatsächlich Schleifen bevorzugen muss.

Darüber hinaus vermute ich eine zu einseitige Kenntnis von
Programmierkonzepten (nur imperativ/OO) und empfehle daher
dringends die ernsthafte Beschäftigung mit mindestens einer
der folgenden Sprachen: Ocaml, Haskell, CLISP, Scheme.


Gruß,

Volker

[Hermann Riemann]

Post by Volker Grabsch

Post by guidofranke

Post by Marek Kubica
etwa hat keine Schleifen, dort verwendet man Rekursion etc.

Als Kenner der Prozessorinterna

Naja, zumindest behauptest du nicht, Kenner der Compilerinterna
zu sein.

Post by guidofranke
bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

Selbst die C-Compiler können Tail-Recursion erkennen

Nicht jede Rekursion ist Tail-Recursion.

Post by Volker Grabsch
- was du im
erzeugten Maschinencode übrigens sehr gut erkennen kannst - dort
wird im Wesentlichen statt "PUSH,PUSH,PUSH,...,CALL" einfach
"MOV,MOV,MOV,...,JMP" gemacht.

Mit nahezu gleichen Befehlszeiten (
jeweils ca ein Takt, bei Sprung eventuell mehr)

Post by Volker Grabsch
Die effiziente Behandlung von
Tail-Recursion ist also nicht einmal besonders kompliziert.
Bei Java dürfte das genauso aussehen. Ergo: Kein Stackverbrauch.

Bei Java soll das Problem ja die garbage collection sein.
Ob das heute noch so ist, weiß ich nicht.
Die Aussage, das macht ein thread mit geringerer Priorität,
verhindert nicht höhere CPU-Temperatur und höhere Stromrechnung.

Post by Volker Grabsch
Darüber hinaus vermute ich eine zu einseitige Kenntnis von
Programmierkonzepten (nur imperativ/OO) und empfehle daher
dringends die ernsthafte Beschäftigung mit mindestens einer
der folgenden Sprachen: Ocaml, Haskell, CLISP, Scheme.

Und wie kommuniziere ich mit clisp etc ohne extra Handarbeit?

Beispiel:
Mit java gui wird manuelle io gemacht,
mit Python werden die Text zerlegt und wieder zusammengesetzt,
mit lisp inhaltlich (die tokens) untersucht, aufbereitet.

Hermann
der Letzteres statt mit java mit C und SDL vorhat.

[Volker Grabsch]

Post by Hermann Riemann

Post by Volker Grabsch

Post by guidofranke
bin ich ein großerFeind der Rekursion.
Warum? Ganz einfach, weil jeder Rekursionsaufruf eine unmenge an
Kellerspeicher benutzt.

Selbst die C-Compiler können Tail-Recursion erkennen

Nicht jede Rekursion ist Tail-Recursion.

Irrelevant, da die übrigen Rekursionen sowieso Stack fressen.

Obwohl ... Haskell kann AFAIK noch tiefere Optimierungen
durchführen, um noch weitere Klassen von Rekursionen mit
konstantem Stackverbrauch zu versehen. Aber darum geht
es hier nicht.

Der Punkt ist, dass es egal ist, ob ich eine ungeschickte
Rekursion in eine Iteration oder Tail-Rekursion umformuliere.
Der "Zwang" zur Rekursion führt per se erstmal nicht zu
Performance-Nachteilen, eher im Gegenteil (siehe moderne
Haskell-Compiler).

Insofern ist es wirklich eine Schande, dass Python mit
Tail-Rekursion (noch) nicht ordentlich umgehen kann.
Vielleicht geht's mit Python+Psyco?

Post by Hermann Riemann

Post by Volker Grabsch
- was du im
erzeugten Maschinencode übrigens sehr gut erkennen kannst - dort
wird im Wesentlichen statt "PUSH,PUSH,PUSH,...,CALL" einfach
"MOV,MOV,MOV,...,JMP" gemacht.

Mit nahezu gleichen Befehlszeiten (
jeweils ca ein Takt, bei Sprung eventuell mehr)

Aber ohne Stackverbrauch, und darum ging es ja.

Post by Hermann Riemann

Post by Volker Grabsch
Darüber hinaus vermute ich eine zu einseitige Kenntnis von
Programmierkonzepten (nur imperativ/OO) und empfehle daher
dringends die ernsthafte Beschäftigung mit mindestens einer
der folgenden Sprachen: Ocaml, Haskell, CLISP, Scheme.

Und wie kommuniziere ich mit clisp etc ohne extra Handarbeit?

Gerade CLISP (Common LISP) hat eine extrem große Standard-
Bibliothek, und hocheffiziente Compiler. Im ersten Schritt
würde ich daher empfehlen, die Applikation komplett in CLISP
zu schreiben.

Willst du hingegen LISP wirklich nur für Highlevel-Dinge
einsetzen, dann ist vielleicht Schema interessanter. Das
ist ein sprachlich eleganterer, "schlanker" LISP-Dialekt,
der jedoch relativ wenige Libraries mitbringt.

Post by Hermann Riemann
Mit java gui wird manuelle io gemacht,
mit Python werden die Text zerlegt und wieder zusammengesetzt,
mit lisp inhaltlich (die tokens) untersucht, aufbereitet.

Vielleicht ist GUILE für dich interessant. Das ist eine
Scheme-Implementierung, die direkt darauf ausgelegt ist,
mit C verheiratet zu werden. Damit kannst du ohne Aufwand
deine Basisfunktionen in C schreiben, und die eigentliche
Applikation mit LISP.

Falls dich das interessiert, wirf mal einen Blick in den
Quellcode von Taxbird, da wird genau das getan. (http://www.taxbird.de/)


Gruß,

Volker

[Stefan Scholl]

Post by Volker Grabsch
Gerade CLISP (Common LISP) hat eine extrem große Standard-
Bibliothek, und hocheffiziente Compiler. Im ersten Schritt

Aber nur Bytecode.

[Sebastian Wiesner]

Post by Hermann Riemann
Bei Java soll das Problem ja die garbage collection sein.

FUD.

Post by Hermann Riemann
Die Aussage, das macht ein thread mit geringerer Priorität,
verhindert nicht höhere CPU-Temperatur und höhere Stromrechnung.

Wenn sich schon Javas GC so dramatisch in deiner Stromrechnung
niederschlägt, wie katastrophal müssen dann erst die Kosten von Qt mit
seinem Objektbaum, seinen implicitly shared Objekten und vor allem seinem
Signal-Slot-System sein?

Vielleicht solltest du die Wahl deines Newsreaders überdenken ;)

SCNR

[Hermann Riemann]

Post by Sebastian Wiesner
Wenn sich schon Javas GC so dramatisch in deiner Stromrechnung
niederschlägt, wie katastrophal müssen dann erst die Kosten von Qt mit
seinem Objektbaum, seinen implicitly shared Objekten und vor allem seinem
Signal-Slot-System sein?
Vielleicht solltest du die Wahl deines Newsreaders überdenken ;)

Ich verwende knode und die CPU ist nach top zu 98% idle.

Hermann
der in java, qt, gtk, X das timer-event vermisst,
wie er es von SDL her kennt.

[Matthias Bläsing]

der in java, qt, gtk, X das timer-event vermisst, wie er es von SDL
her kennt.

Ich weiß nicht was das timer-event ist, aber wenn es ist, was ich vermute
ist für gtk gobject.timeoute_add(timeout, callback) dein Freund. Abhängig
vom Return-Code wird der Timeout nach der Ausführung gelöscht oder auch
wieder aufgerufen.

HTH

Matthias

[guidofranke]

So, nun ist gut. Dazu fällt mir spontan ein:

Der Computer hilft uns Probleme zu lösen, die wir ohne den Computer
niemals hätten...

STOPP
Ich nehm BlueJ weils die Mehrheit tut.
Windows ist auch Mist und alle (fast) benutzen es!

[Torsten Bronger]

Hallöchen!

Post by guidofranke
Der Computer hilft uns Probleme zu lösen, die wir ohne den
Computer niemals hätten...
STOPP
Ich nehm BlueJ weils die Mehrheit tut.
Windows ist auch Mist und alle (fast) benutzen es!

Das nächste mal machst du den Gruppenmitgliedern bitte vorher klar,
an wen sie da geraten.

Ich selbst habe hier sicherlich 30 Minuten Hirnschmalz verbrannt, um
mein erstes Follow-Up zu verfassen, und dann nochmal einige Zeit,
die PDFs zu lesen. Andere werden ähnlich viel investiert haben.
Für die Infos hier hättest du bei einer Beraterfirma gut und gerne
ein paar hundert Ocken lassen können.

Du hingegen stehst erstmal gar nicht zur Verfügung (persönliche
Termine hin oder her, die Hochzeit wird ja wohl nicht überraschend
gekommen sein), liest dann nichtmal, was wir schreiben, und am Ende
fällst du deine Entscheidung unter ausrücklichem Ignorierem von dem,
was die Leute hier alles geschrieben haben. Obwohl du selber nach
eigener Aussage kaum Ahnung von beiden Alternativen hast.

Ich kann nur hoffen, daß deine Kollegen ihren Job ernster nehmen.

Tschö,
Torsten.

[Volker Grabsch]

[ Fup2 dsu, falls weiterer Diskussionsbedarf zu dem Thema besteht. ]

Post by Torsten Bronger

Post by guidofranke
Der Computer hilft uns Probleme zu lösen, die wir ohne den
Computer niemals hätten...

Zwei Programmiersysteme durch einfache pro/contra-Listen
zu vergleichen, das wäre für deine Fragestellung viel zu
oberflächlich gewesen. Es wundert mich, dass dir ober-
flächliche Antworten lieber gewesen wären als diese
ausführliche Diskussion.

Aber wie heißt es so schön? Eine Frage im Usenet zu stellen
bedeutet nicht, dass man die Antwort erhält, die man gern
hören möchte.

Nicht alle Antworten hatten eine hohe Qualität, daher
vermute ich, dass du die guten Antworten einfach übersehen
hast. Da hilft nur: Üben, üben, üben. Niemand kommt gleich
auf Anhieb mit dem Medium "Usenet" klar. Medienkompetenz muss
man sich hart erarbeiten.

Ein typischer Fehler ist es z.B., einen Thread nach den
durchschnittlichen Beiträgen zu bewerten, statt nach den
besten Beiträgen. Aber wird ein einzelner guter Beitrag
(und hier gab's sogar mehrere!) dadurch abgewertet, dass
er von schlechteren Postings im Thread umgeben ist?

Post by Torsten Bronger

Post by guidofranke
STOPP
Ich nehm BlueJ weils die Mehrheit tut.
Windows ist auch Mist und alle (fast) benutzen es!

Das nächste mal machst du den Gruppenmitgliedern bitte vorher klar,
an wen sie da geraten.

So ist das nunmal im Usenet. Es gibt keine Garantie, gelesen
zu werden, auch nicht vom ursprünglichen Fragesteller. :-)
Der war mit den vielen Antworten offensichtlich überfordert.

Aber andere Leser der Liste haben sicher ein paar interessante
Infos aus dem Thread mitnehmen können. (z.B. ich :-))

Ich halte es generell für einen Fehler, im Usenet nur für
eine einzige Person zu schreiben. Sicher, der OP als Frage-
steller gibt den entscheidenen Anstoß, aber ein Posting sollte
auch für sich stehend einen gewissen Wert aufweisen. Es sollte
für die ganze Gruppe lesenwert sein. Schließlich wird es der
Allgemeinheit zugänglich gemacht, nicht nur einer einzelnen
Person.

Post by Torsten Bronger
Ich selbst habe hier sicherlich 30 Minuten Hirnschmalz verbrannt, um
mein erstes Follow-Up zu verfassen, und dann nochmal einige Zeit,
die PDFs zu lesen. Andere werden ähnlich viel investiert haben.

Bei mir waren es deutlich mehr als 30 Minuten.

Post by Torsten Bronger
Für die Infos hier hättest du bei einer Beraterfirma gut und gerne
ein paar hundert Ocken lassen können.

Das zählt nicht. Für eine Beraterfirma zahlt man immer viel Geld,
egal wie gut die Infos sind. :-)

Post by Torsten Bronger
Ich kann nur hoffen, daß deine Kollegen ihren Job ernster nehmen.

Ich glaube nicht, dass das etwas mit der beruflichen Qualität
des OP zu tun hat. Jeder ist hin und wieder mal überfordert.


Gruß,

Volker

[Stefan Behnel]

Post by guidofranke
Der Computer hilft uns Probleme zu lösen, die wir ohne den Computer
niemals hätten...

Wenn du jetzt noch erklären könntest, was das mit dieser Diskussion hier zu
tun hat, dann könnte ich vielleicht zu der Erkenntnis gelangen, dass du nicht
gänzlich uninteressiert an deiner eigenen Frage bist.

Stefan

[Marek Kubica]

Post by Stefan Behnel
Wenn du jetzt noch erklären könntest, was das mit dieser Diskussion hier
zu tun hat, dann könnte ich vielleicht zu der Erkenntnis gelangen, dass
du nicht gänzlich uninteressiert an deiner eigenen Frage bist.

Also die Diskussion auf de.comp.lang.java hat auf jeden Fall auch nichts
gebracht was guidofranke hätte überzeugen können - dort wurde sie auch
einfach von ihm beendet weil BlueJ von der Mehrheit genommen wird. Dabei
haben die Leute dort Java gar nicht einmal so sehr gelobt bzw Python gar
nicht so gebasht.

Ich persönlich finde die Entscheidung das zu nehmen was die meisten
nehmen ja ziemlich blöd. Es hat natürlich Sinn, sich für etwas zu
entscheiden was auch Nutzer hat - logisch, denn wenn es gar keine Nutzer
hat, wird es auch nicht sonderlich gut sein. Jedoch heißen Mehrheiten
nichts. Die Mehrheit nutzt auch IE und ich kenne außer verblendeten MS-
Fanboys niemanden der IE gut findet. IMHO reicht es ja wenn es genug User
gibt um einen Support zu garantieren. Und die hat Python definitiv.

grüße,
Marek

[Stefan Behnel]

[Kleiner Tipp: "Allen antworten" hilft]

Post by Stefan Behnel

Post by guidofranke
Der Computer hilft uns Probleme zu lösen, die wir ohne den Computer
niemals hätten...

Wenn du jetzt noch erklären könntest, was das mit dieser Diskussion hier zu
tun hat, dann könnte ich vielleicht zu der Erkenntnis gelangen, dass du nicht
gänzlich uninteressiert an deiner eigenen Frage bist.
Stefan

Ganz einfach: Ich bin in einer Zeit aufgewachsen, als Computer fast
ausschließlich in dem Literatur-Genre Since Fiction auftauchten.
Damals konnte wohl außer Stanislaw Lem und Co. kaum jemand was mit dem
Computer anfangen und wenn ich mir heute meine geliebte Serie Mondbasis
Alpha 1 ansehe , muss ich über die sehr phantastisch anmutenden Lampen
und Schalter lächeln.
Ich hab heute Python und BlueJ samt Suns IDE auf dem Master installiert
und habe noch ca. 50 MB bis zur magischen Speichergrenze der Recover-DVD
behalten, dafür mussten halt andere Microsoft-Komponenten zurückstecken.
Wer braucht schon wirklich Outlook oder Infopath oder Publisher? Sind
mir in den letzten 10 Jahren im Unterricht nicht dienlich gewesen.
Einzig Word, Excel, Powerpoint und Access waren gefragt, zusätzlich noch
Delphi und PROLOG und seit heute Python und BlueJ.
Mal sehen, wann wir als Recover-Medium dann externe HDD einsetzen. VISTA
ist dafür ja ideal geeignet... Ein Klonen der User-PC wird immer
aufwenndiger, immer neue Anwendungen sollen von überall ausführbar sein,
auch ohne anständigen Terminalserver... (40 Fat-Client-PC an 1 Siemens
Server mit 1 Proz (P4) mit 512 MB RAM und 2*34GB SCSI HDD mit
100Mbit-LAN); das ist doch lächerlich...
Dummerweise wollen die veantwortlichen keine Kohle rausrücken. Ihr an
euren Unis habt da leistungsfähige Mainframe-Systeme (SUN-WS mit
Multiproz. und protzigen 32GB RAM...) da ist so was natürlich kein
Problem. Wenn ich hier eine Netzwerkbasierte Office-Installation starte
(820 MB Daten), dann dauert das gut 2 Stunden. Netzwerkauslastung ca.
0,08% bei 100 Mbit... An eine Multi- bzw. Unicast-Installation ist nicht
zu denken. Warum diese Anmerkung? Jedes Byte, das zusätzlich die
Grundinstallation aufbläst, kostet mich unbezahlte Freizeit. Ich bemomme
für die administrativen Aufgaben 1 Stunde pro Woche bezahlt (40
Client-PC, 2 Server und 5 Notebooks). Fällt also irgendetwas aus, kann
ich das im Rahmen dieser Vergütung erledigen... Wer schon einmal einen
jungfreulichen PC zum Master für das Klonen gemacht hat, kennt die
Probleme. Kaum hat man das Image zum Replizieren fertig, kommen neue
Wünsche dazu, also wieder nachinstallieren, neues Image erstellen,
replizieren und ... noch ein ganz wichtiges Programm (Flash-Player) muss
unbedingt drauf, sonst können wir nicht arbeiten ... hier vergeht kein
Tag, ohne dass irgend jemand nichts möchte.
Hauptproblem: Einige dieser "tollen" Programme erfordern Admin-Rechte
auf C:. Da steh ich ja total drauf. Also alle Bibliotheken auf den
Server umgeleitet, denn C: ist nach Eintritt in unsere Domäne
"unantastbar". Wenn dann irgend wer oder -was Zugriff braucht, ist es zu
spät. Dann fängt der Admin wieder von vorn an. Manchmal ist es
einfacher, dem gemeinen USER Admin-Rechte zu geben und alle Probleme
sind gelöst.
Da ja Windows XP läuft und bei jedem neuen User auch neue eigene Dateien
auf C: angelegt werden, Internet-Temp-Verzeichnis ca. 600MB und eigene
Musik bei den Kiddies schnell mehrere GB einnimmt, ist dann ein
Klonensolcher Boliden unmöglich...
Früher hat man einen A4-Hefter genommen, 10 Blätter reingelegt und
fertig war das Schuljahr vorbereitet. Darum ohne PC weniger
Vorbereitungs-Probleme. Programmiert wurde am PAP, später dann Nassi...
Strukturen wurden dabei auch vermittelt.
MfG
GF

[Stefan Scholl]

Post by guidofranke
Ich nehm BlueJ weils die Mehrheit tut.

Noch nie davon gehört. Dachte die Mehrheit benutzt Java? ;-)