python vs java

[gerold]

Dynamische Typisierung setzt eigentlich voraus, dass man das Prinzip der Typisierung überhaupt erstmal realisiert und das geht sicherlich besser, wenn man explizit festhalten muss, was für ein Typ an einer bestimmten Stelle erwartet wird.

Hallo dst!

Ich bin nicht deiner Meinung. Ich komme von Visual Basic und wie du vielleicht weißt, muss man dort auch jede Variable vorher mit ``dim <Variable> as <Variabletyp>`` dimensionieren bzw. zur Verfügung stellen. "Variant" mal ausgenommen. Aber wer in VB 6 viel "Variant" verwendet, kann zusehen, wie das Programm langsamer wird...

Als ich Python lernte, wollte ich alles mit irgendeinem Typ fixieren. Dann wollte ich wie mit "dim" alle Variablen, die ich benutze vorher fixieren. Mein Gedanke war, wenn ich die Variablenamen später falsch schreibe, dann können unerklärliche Fehler auftauchen. Wenn ich einer Variable einen falschen Typ zuweise, dann können später Fehler auftauchen.

Also habe ich mich am Anfang sehr schwer auf die Art von Python einstellen können. Es hat mir also absolut NICHTS gebracht, dass ich vorher von einer Sprache gekommen bin, in der nichts ohne fixe Typisierung geht.

Kein Vorteil durch die jahrelange Praxis mit Programmiersprachen, die eine fixe Typisierung erzwingen!

Was ist mit den Schreibfehlern bei Variablenamen? Die gibt es nicht. Ich hatte noch nie einen Fehler im Programm, der auf eine falsch geschriebene Variable zurück zu führen ist. Warum nicht? Ich verwende eine spitzenmäßige IDE --> WingIDE. Allein schon die automatische Codevervollständigung von WingIDE verhindert solche Fehler. Es fällt schon während dem Schreiben von Code auf, wenn eine Variable verwendet wird, die noch nicht zugewiesen wurde. Wenn ich zehn Zeilen vorher die Variable "hallo" definiert habe und ich schreibe "halo", dann reagiert die IDE anders als wenn ich wieder "hallo" hin schreibe. Es gibt also eine optische Unterscheidung -- schon beim Schreiben des Codes. Codevervollständigung sei Dank.

Ich muss mich jedes Mal dazu zwingen, Änderungen an alten VB 6 Programmen zu programmieren. Alles ist umständlicher. Für Probleme, die ich mit Python und wxPython in ein paar Stunden fertig habe, verbrate ich mit VB oft noch Tage.

Einziger Grund, weshalb man Python keinen Anfängern beibringen sollte: "Wer Python kennt, will mit nichts Anderem mehr programmieren." Jemandem Java nach Python beizubringen ist eine schwere Aufgabe. Es wird nicht viele Schüler geben, die darin einen Sinn sehen. Jede Java-Seite wird mit Python-Zeilen verglichen werden.

mfg
Gerold

[dst]

Das kann aber, gerade für Einsteiger, ein großer Unterschied sein. Hast verschiedene
Objekte, bei denen sich ein Teil der Methodennamen überschneidet, kann es sein,
dass ein Script 99% der Zeit ohne Exceptions abläuft, möglicherweise hin und wieder
ein unerwartetes Ergebnis entsteht, möglicherweise aber nicht mal das.

Ich denke, ich spreche hier für jeden Python-Programmierer, wenn ich sage: Das ist FUD, verbreitet von "static typing"-Anhängern.

Theoretisch ist das natürlich möglich, in der Praxis mir zumindest jedoch nie bewusst passiert.

Was dagegen hin und wieder passiert, sind Tippfehler bei Attributnamen oder lokalen Variablen, und genau da hilft pylint.

Sowas ist selbst für einen erfahrenen Programmierer nicht immer leicht zu entdecken.

Wenn es denn vorkäme.

Also ich habe es schon mehrmals miterlebt (soweit ich mich erinnere aber noch nicht selbst produziert ) und zwar genau nach dem Prinzip.

Code: Alles auswählen

sub foo(bar):
    if bar.pruefe_irgendwas():
		bar.normalerweise()
	else
		bar.selten()

Es wird ein Objekt übergeben, dieses hat zwar die Benötigten Methoden (die "selten" evtl. auch nicht, was die ganze Sache einfacher macht, aber auch ärgerlich ist, wenn das Programm in seltenen Fällen abstürzt), die haben aber nicht ganz das erwartete Ergebnis.
Bei größeren Geschichten werden dann schon mal mehrere Stunden in Ablaufverfolgungen gesteckt.
Aber ich halte dynamische Typisierung gar nicht für schlechter als statische, obwohl ich z.B. Type-Hinting in einer dynamisch getypten Sprache für eine nette Idee halte. Dadurch können nämlich wiederum einige Codezeilen gespart werden. Bei Python würde das aber wohl eher nicht ins Konzept passen.

Aber darum ging es mir eigentlich weniger. Dynamische Typisierung setzt eigentlich
voraus, dass man das Prinzip der Typisierung überhaupt erstmal realisiert und
das geht sicherlich besser, wenn man explizit festhalten muss, was für ein Typ
an einer bestimmten Stelle erwartet wird.

Dass man das Prinzip von Datentypen kapieren muss, ist klar, nur kann ich nicht verstehen, wie Typdeklarationen dabei helfen sollen. Wenn ich schreibe ``x = 1``, sehe ich genauso deutlich, dass hier ein Integer vorliegt.

Klar, beim kleinen "Hello World!" oder 1x1. Wenn nur noch mit Namen, Referenzen oder wie immer es in der jeweiligen Sprache gearbeitet wird, nützt das überhaupt nichts.

Ich möchte Python damit nicht schlecht machen, oder Java preisen. Ich bin
aber der Ansicht, dass Python als Lernsprache kaum Vorteile, dafür aber einige
Nachteile, bietet und zwar sehr ähnlichen Gründen, warum ich es als Blödsinn
empfinde, irgendjemandem PHP als Einsteigersprache zu empfehlen (was ja
immer wieder gern gemacht wird).

Da sind wir uns ja einig

Das ist ja immerhin eine Basis


Edit: Um das nochmal klar zu sagen: Ich will dynamisch typisierte Sprachen gar nicht verdammen (sonst würde ich mich wohl kaum mit Python beschäftigen ), ich bin nur der Ansicht, dass sich das Typkonzept mit einer statisch typisierten Sprache besser verdeutlichen lässt.
Ich habe mittlerweilige einige Leute beim Einstieg in die Programmierung begleitet (jaja, klingt irgendwie bescheuert - habe keine Lust mir eine neue Formulierung auszudenken ) und dabei beobachtet, dass das OOP-Denken dadurch wesentlich leichter fällt.
Erfahrene Programmierer haben das ohnehin im Kopf, wissen was sie tun und (so sollte es jedenfalls sein ) warum sie es tun. Einsteiger sind eine ganze Weile nahezu völlig planlos, selbst wenn sie schon vorzeigbare Ergebnisse erzielen.
Gerolds Erfahrungen kann ich überhaupt nicht teilen. Ich bin mit dynamisch typisierten Sprachen angefangen (okay, meine ersten Programmiererfahrungen habe ich mit C64-Basic gemacht, aber das zähle ich nicht), nämlich mit Perl und einigen anderen.
Die Konfrontation mit Java hat mich das definitiv zu einem besseren Programmierer gemacht.
Python soweit zu verinnerlichen, dass ich mein erstes (kleineres) Python-Programm für den produktiven Einsatz schreiben konnte hat mich trotz meiner Begeisterung für Java keine 30 Minuten gekostet.

Ein guter Python-Programmierer bin ich deswegen natürlich trotzdem noch lange nicht, das kommt nur mit der Erfahrung (und bislang kann ich Python eigentlich nur für kleinere Insellösungen einsetzen, was ich sehr schade finde).
Die Erfahrung ist es aber, auf die es bei jeder Sprache ankommt. Ein erfahrender PHP-Programmierer kann trotz der mangelhaften Sprache gute Programme schreiben. Ein unerfahrener Python-Programmierer kann trotz der relativen Einfachheit viel Müll programmieren.

[BlackJack]

Man kann auch in Java Müll produzieren und die statische Typisierung zwingt nicht unbedingt zum Nachdenken über Typen. Ich habe bei Java-Anfängern auch schon gesehen, dass einfach die Vorschläge der IDE eingesetzt wurden oder solange rumprobiert wurde bis der Compiler nicht mehr meckerte, ohne das sich wirklich *Gedanken* gemacht wurden.

Da muss man sich bei Python vielleicht sogar mehr Gedanken über Typen machen, weil einem das die IDE und der Compiler nicht abnehmen. Jedes Objekt hat einen Typ und wenn man das nicht beachtet, fällt einem das auf die Füsse. Eben zur Laufzeit und nicht zur Übersetzungszeit.

Da kommt jetzt das Argument, dass diese Fehler nur auffallen, wenn man den entsprechenden Code auch ausführt. Wenn das passiert, hat man bei den Tests geschlampt. Tests gehören heute bei nicht-trivialen Quelltexten zum guten Ton. Das sollte man auch Anfängern beibringen. "Typprüfung" ist auch nur ein Teil den Tests abdecken, weshalb sie in statisch typisierten Sprachen nicht einfach weggelassen werden dürfen. Die statische Typisierung verhindert nämlich nicht, dass in Quelltext, der nur in 0,1% der Fälle durchlaufen wird, logische oder semantische Fehler stecken, die im Gegensatz zu Typfehlern vielleicht gar keine Ausnahmen auslösen, sondern einfach nur still und leise falsche Ergebnisse produzieren. Das ist etwas was auch in statisch typisierten Sprachen erst nach dem 10000 Programmlauf auffallen kann. Obwohl es vielleicht schon 100 mal vorher auftrat, und man schon eine ganze Weile kaputte oder verfälschte Daten auf der Platte hat und damit vielleicht sogar weitergearbeitet und eine Menge Folgefehler produziert hat.

Ich finde Python ist eine bessere Sprache zum lernen als Java. Man kann mit Python mehr lernen, weil mehr Programmierkonzepte möglich sind. Es hat eine sehr einfache und übersichtliche Syntax, die nicht vom wesentlichen ablenkt. Das fängt mit dem viel zitierten "Hello World"-Vergleich zwischen Python und Java an. Man muss bei Python nicht sagen, dass dieser ganze Boilerplate-Quelltext drumherum erst später erklärt wird.

Ein weiteres Plus ist der Interpreter. Man kann Code "live" ausprobieren und damit herumspielen. Dabei kann man eine Menge lernen und wenn man Zweifel hat, seine Theorien über das Verhalten von Funktionen und Objekten direkt überprüfen. Und man kann auch jederzeit mit `type()` nachschauen welchen Typ man vor der Nase hat. Wobei sich natürlich noch die Frage stellt ob der Typ wirklich so wichtig ist, schliesslich zählt das Verhalten des Objekts mehr.

Man kann in Python mit Funktionen anfangen, prozedural und funktional programmieren und dann zu Klassen übergehen. Generische Funktionen wie `map()` und `filter()` sind in Java nicht machbar. Da stehen leider die "checked exceptions" im Wege. Python ist in gewissem Sinne "objektorientierter" als Java. In Python ist alles ein Objekt, inklusive Funktionen und Klassen. Und mit Generatoren kann man das Konzept von "lazy evaluation" mit relativ wenig syntaktischem Aufwand zeigen. "Closures" sind auch ganz witzig.

Bei Deinen Beobachtungen schreibst Du, dass das "OOP-Denken dadurch [Typkonzept] wesentlich leichter fällt." Leichter als was? Hast Du direkte Vergleiche zu Python, in ausreichender Zahl?

Was ist OOP-Denken? Ich habe jedenfalls die Erfahrung gemacht, dass Leute die Java gelernt haben, unter OOP einerseits nur das verstehen was Java kann. Andererseits aber zu OOP Sachen dazuzählen die nicht zwingend zu OOP gehören. OOP braucht minimal Objekte, Kommunikation zwischen diesen Objekten und Vererbung. Was nicht zwingend dazugehört sind Klassen, Interfaces, dass die Kommunikation auf synchrone Prozeduraufrufe beschränkt ist und Zugriffsschutz. Kapselung und Zugriffsschutz werden von Java-Adepten auch gerne als Synonym aufgefasst, dabei sind das unabhängige Konzepte.

Was das lernen von Algorithmen angeht, abstrahiert Python weiter von der Maschine als Java. Oft kann man den Kernalgorithmus aus dem Lehrbuch nahezu 1:1 in Python-Quelltext übersetzen. Es gibt ja auch den Spruch "Python ist ausführbarer Pseudocode". Man kann bei der Formulierung einer Problemlösung näher am Problem bleiben und muss sich nicht so sehr auf die Ebene der Maschine herunter bewegen. Was hat man davon den Pseudocode aus dem Buch nochmal als Python vorliegen zu haben? Man kann ihn ausprobieren, variieren und im Interpreter inspizieren. Erfahrbar machen.

[rolgal_reloaded]

Mit input() und raw_input() kann man gut demonstrieren wie wichtig es ist sich über den Datentyp Gedanken zu machen bzw. die Unterschiede an sich gut demonstrieren.

Sie konnten dann eigentlich selber schon ganz gut erkennen, wo wir echte Zahlen brauchen, die der Benutzter eingeben soll und wo wir eigentliche nur das Zeichen davon brauchen - z. Bsp. Auswahl in einem Menü.

Freilich setze ich mittelfristig dann nur auf raw_input() und wir wandeln den Typ entsprechend um.

Aber das ist so eine Sache, das ist eine gute Gelegenheit mal was los zu werden.

Auch hier im Fourm habe ich schon des öftereren einen Tipp für Anfänger wie diesen gelesen: Nimm niemals input() .....nur raw_input() und wandel den Typ entsprechend um,

Ahja, aber wenn der/die Gute keine Ahnung hat was der Unterschied zwischen 5 und "5" ist, ist dieser Vorschlag Nonsens.

LG

rolgal_reloaded

[Leonidas]

Wenn Du eine Scriptsprache als Alternative vorstellen möchtest, würde ich dir eher zu ActionScript 2 raten. Diese bringt die objektorientierte Art von Java mit der Objektbasierten Weise von JavaScript (die ja durchaus Ähnlichkeiten mit Python hat) zusammen. Natürlich ist man etwas eingeschränkter was die Anwendungsfälle angeht, da ActionScript (bzw. Flash) in erster Linie auf das Browserplugin ausgelegt ist, aber für Übungsaufgaben dürfte sich da doch einiges finden lassen.

Die Objektorientierte Weise von JavaScript ist definitiv aus dem Punkt aus interessant, weil sie eben nicht Python oder Java ähnelt. Sie funktioniert Prototypenbasiert, womit sich zu beschätigen sicher auch keine schlechte Idee ist. Aber damit anfangen?

Als freie IDE kann ich FlashDevelop empfehlen. Das ist rein auf ActionScript ausgelegt (bietet daher keine grafische Oberfläche für Zeitleisten, Tweens und den ganzen Schnickschnack), bringt einen Compiler mit und ist ansonsten recht schlank und einfach zu installieren. Basiert allerdings auf .NET und ist daher Windows-Only (naja, vielleicht gibt es auch einen Mono-Port, weiß ich aber nicht).

Du empfiehst eine freie IDE füür eine unfreie Skriptsprache, deren Interpreter proprietär ist, deren Entwicklungsmodell ebenso proprietär ist? Davon abgesehen gibt es Flash nur für eine geringe Anzahl von Platformen und die Unterstützung für andere Platformen ist bisweisen sehr schwach - man beachte wie lange es gedauert hat, bis ein halbwegs aktuelle Flashplayer für Linux verfügbar war.

Wenn schon etwas JavaScript-ähnliches dann besser JavaScript selbst. JavaScript hat auch so seine Nachteile, aber im meinen Augen überwiegen die Vorteile gegenüber ActionScript.

[lunar]

Ein weiteres Plus ist der Interpreter. Man kann Code "live" ausprobieren und damit herumspielen. Dabei kann man eine Menge lernen und wenn man Zweifel hat, seine Theorien über das Verhalten von Funktionen und Objekten direkt überprüfen.

Das zumindest geht auch mit Java, wenn auch nicht ohne externe Software. Man braucht nur Beanshell. Allerdings fügt dieser Interpreter noch ein paar "Goodies" hinzu, weil Java als interaktive Sprache sonst arg anstrengend wäre. Trotzdem läuft nahezu jeder Java Code auch unter Beanshell. Ob das bei Java allerdings Spaß macht, ist eine andere Frage...

Generische Funktionen wie `map()` und `filter()` sind in Java nicht machbar. Da stehen leider die "checked exceptions" im Wege.

Mit den Generics aus Java 5 sollte sowas doch auch in Java möglich sein, oder?

Bei Deinen Beobachtungen schreibst Du, dass das "OOP-Denken dadurch [Typkonzept] wesentlich leichter fällt." Leichter als was? Hast Du direkte Vergleiche zu Python, in ausreichender Zahl?

Imho fällt objektorientiertes Denken in Python leichter, weil Java sehr viele Ausnahmen macht. So sind Methoden keine Objekte, und jeder Basistyp ist ebenfalls kein Objekt.

[BlackJack]

So etwas wie `map()` scheitert zum einen daran, dass Methoden keine Objekte sind, die man übergeben kann und das es "checked exceptions" gibt. Man müsste so einer Funktion/Methode also grundsätzlich ein ``throws Exception`` mit auf den Weg geben. Das fügt sich einfach nicht harmonisch in die Sprache ein.

[lunar]

So etwas wie `map()` scheitert zum einen daran, dass Methoden keine Objekte sind, die man übergeben kann und das es "checked exceptions" gibt. Man müsste so einer Funktion/Methode also grundsätzlich ein ``throws Exception`` mit auf den Weg geben. Das fügt sich einfach nicht harmonisch in die Sprache ein.

Theoretisch (und nur das) könnte man das doch über Reflection erledigen: Übergeben wird das Object, und der aufzurufende Methodenname als String. Dann müsste man doch über Reflection die Methode aufrufen können, oder?

Das es sich nicht harmonisch in die Sprache einfügt, ist klar... aber mir geht es jetzt eher um die theoretische Machbarkeit.

[BlackJack]

Ja über Reflection kann man das sicher lösen. Aber den Namen von Funktionen als Zeichenkette übergeben? Das ist ja wie bei PHP. Igitt.

[lunar]

Ja über Reflection kann man das sicher lösen. Aber den Namen von Funktionen als Zeichenkette übergeben? Das ist ja wie bei PHP. Igitt.

Ja, so kann man Java's statische Typisierung auch ad absurdum führen...