[linux-l] RS-232 oder USB lesen mit (Schauder...) Java Os-unabhaengig

Volker Grabsch vog at notjusthosting.com
Mi Sep 21 15:19:52 CEST 2005


On Tue, Sep 20, 2005 at 02:14:07AM +0200, Oliver Bandel wrote:
> Soweit ich das seh', hanfdhabt Python Datentypen ziemlich lax.
> Was ziemlich schade ist.

Da das in eine altbekannte Diskussion über statische vs. dynamische
Typisierung ausartet, will ich einfach nur mal die Python-Sicht
entgegen stellen, die übrigens für Smalltalk, Objective-C und alle
anderen dynamisch typisierten Sprachen genauso gilt.

Welches der beiden Konzepte nun insgesamt besser ist, das ist sicher
mehr eine Geschmacksfrage. Von der statischen Typisierung her ist Java
sehr primitiv und kein guter Vergleichsparnert. C++ kann schon mehr
(dank der Templates, und Operator-Überladung), aber nach dem, was du
schilderst, scheint OCaml dieses Konzept tatsächlich am besten
umzusetzen.

> Als ich von Perl nach OCaml wechselte, fand ich so einen
> Compiler, der mir wegen der Typprüfung immer auf die Finger haut, ziemlich
> nervig.
> Aber mittlerweile will ich das nicht mehr missen!
> Das hilft so oft, Fehler schon sehr früh ausfindig zu machen.

In Python lautet die Philosophie, dass das "Compilieren" im
Entwicklungs-Zyklus nicht direkt vorkommen sollte. Daher compiliert
Python auch im Hintergrund, und legt das Compilat automatisch ab
(*.pyc-Dateien), damit es später wiederverwendet werden kann. Natürlich
kann man Python trotzdem explizit anweisen, nur zu compilieren. Dadurch
werden alle Vorteile und Compilern und Interpretern vereint, und der
Programmierer muss sich noch nichtmal extra darum kümmern.

Der normale Entwicklungs-Zyklus sieht etwa so aus:

Schreiben - Compilieren - Starten (Testen)
 - Ändern - Compilieren - Testen -
 - Ändern - Compilieren - Testen -
 - Ändern - Compilieren - Testen -
...

Wird der Compilierungs-Schritt weggelassen, ist das eine erhebliche
Erleichterung. Dann heißt es nämlich nur noch "Andern - Testen - Ändern
- Testen".

Von daher ist die Begrifflichkeit "schon beim Compilieren" nichts-
sagend, wenn man erst gar nicht compilieren braucht.

Abgesehen davon vereinigt eine gute IDE sowieso die beieden Schritte
"Compilieren & Starten" auf Knopfdruck. Und das machst du ja sicher
auch, oder?

> Und das ist eine absolute Arbeitserleichterung.
> Verkürzt die Debugging-Zeiten radikal. :)

Wieso? Wenn du nach dem Compilieren sowieso das Programm startest,
kann es dir doch egal sein, wenn es erst beim Starten den Fehler
ausgibt. Die Unterscheidung von "Fehlern zur Compilierungs-Zeit"
und "Fehlern zur Laufzeit" macht keinen Sinn, wenn es keinen
umständlichen extra Compilierungs-Schritt gibt.

> Code, der compiliert werden kann, ist schon deshalb recht solide.
> Man kann nicht einfach irgendwas zusammen bauen und zur Laufzeit kracht's.
> Fehlerhafter Code fällt dann schon auf, bevor er laufen könnte.

Okay, lass uns bitte von diesen Begriffen wegkommen, da sie keinen
Vergleich zwischen Python und OCaml ermöglichen. Wenn das Programm
beim Starten mit einem Fehler abbricht, ist das genauso gut, als
wenn es beim Compilieren abbricht, weil man beides sowieso
hintereinander macht.

Kommen wir nun zu einem "echten" Unterschied, den du wahrscheinlich
meinst: Es kann sein, dass zur Laufzeit nur in besimmten Situationen
Typfehler auftauchen, die du bei einem Ocaml-Programm gleich zu anfang
bemerkst, aber in Python erst beim gründlichen Austesten.

Dies ist zwar tatsächlich ein Problem, aber kein allzu großes: Wenn
du sauber programmieren willst, also dein Ziel stabiler Code ist
(davon reden wir ja die ganze Zeit), dann wirst du ohnehin alles
gründlich austesten müssen. Dann wirst du sowieso inkrementell
Programmieren: Immer nur kleine Sachen ändern, und gleich austesten.
Sobald es plötzlich einen Fehler gibt, kannst du seine Ursache sehr
schnell eingrenzen auf die Stelle, die du eben geändert hast. 100
Zeilen Code umschreiben, und dann erst zu testen, ist kompletter
Wahnsinn und viel zu riskant.

Aber was bedeutet "testen"? Testen heißt ja nicht bloß "Syntax-Check"
oder "Compilieren". Nein, gerade die inhaltlichen Sachen wollen getestet
werden. Logikfehler, Denkfehler, Designfehler sind nämlich das wirkliche
Problem, dem zu zuleibe rücken musst. Man sollte also sowieso ein
Testprogramm schreiben (Unit-Tests sind eine große Hilfe), wo man all
seine Objekte und Funktionen mit gewissen Eingaben belegt und die
Ausgaben überprüft. Ab und zu die Tests erweitern, und schon sammelt
sich mit der Zeit ordentlich was an. Statt die Tests ständig manuell
zu machen, verbringst du diese Zeit, um einen weiteren Test hinzuzufügen,
und jagst dann jedes Mal einfach das gesamte Testprogramm durch, geht
ja fix, und 100 Tests automatisch zu machen ist schneller als auch nur
ein einziger manueller Test. Nur das Schreiben eines Testfalls dauert
etwas länger ... aber höchstens doppelt so lange wie das manuelle
Testen. Von daher zahlt sich das ganze - zeitmäßig - sehr schnell wieder
aus. Vorallem jeder Bug, der jemals aufgefallen ist, muss unbedingt zu
einem Testfall werden, damit zu sichergehen kannst, dass sich ein Fehler
niemals wiederholen wird. So gesehen sind Bugreports erstklassige extern
entwickelte Testfälle.

Wenn man Testfälle aber sowieso benutzt, weil man ja sowieso Laufzeit-
Tests braucht, dann wird beim Starten des Test-Programmes sowieo alles
aufgerufen und alles abgearbeitet, was du programmiert hast.  Und dabei
fallen Typfehler (d.h. bei Python: Aufrufen von nicht existierenden
Methoden) automatisch mit auf.

Wenn du also sowieso inhaltliche Tests machst, hast du automatisch
auch Typ-Tests. Und im "Ändern - Testen - Ändern - ..."-Zyklus
werden dir Typfehler entsprechend auch "sofort" angezeigt, weil
du ja nach jeder Änderung automatisch deine Testsuite drüberjagst.
(bzw. in Ocaml: Ändern - Compilieren - Testsuite rüberjagen)

Wenn dir Ocaml hingegen irgendwelche Sachen durch die Typisierung
unnötig schwer macht (ganz so dynamisch wie Python kann es ja kaum
sein, oder?), und du nur dann eine Gegenleistung kriegst, wenn du
auf inhaltliche Tests, also Laufzeit-Tests, "bequemerweise"
verzichtest, dann ist das IMHO ein schlechter Deal.

Wenn dir Ocaml ein sicheres Gefühl bei deinem Programm verleiht,
ohne dass du Testfälle geschrieben hast, dann ist das eine trügerische
Sicherheit und sehr gefährlich. Stabile Software braucht
in jedem Fall automatisierte Laufzeit-Tests! Das wird sich später
100fach wieder auszahlen, wenn du Bugs produzierst, die sich nur
in seltenen Anwendungsfällen auswirken. Denn wenn du immer per Hand
testest, wirst du niemals bei jedem Start 'zig verschiedene Sachen
überprüfen. Hast du ne Testsuite, so kannst du nach jeden kleinen
Änderung alle Tests drüberlaufen lassen, die dir bis dahin jemals
eingefallen sind. Egal, wie belanglos sie erscheinen, sie werden
einfach jedes Mal mitgemacht. Und *diese* Testsuite ist die wahre
Qualitätssicherung. Und das ist etwas, was dir sowieso kein Compiler
abnehmen kann.


Aber wiegesagt, das ist die "pythonische Sicht", und diese Argumentation
ist in Bezug auf C++ oder Java sehr viel stärker als in Bezug auf
Ocaml, weil du z.B. in Java sehr viel Zeit mit dem Eintippen von
Typ-Bezeichnern und Casts verbringst, was in Ocaml ja scheinbar
nicht der Fall ist.

Ich weiß nicht, ob eine statisch typisierte Sprache jemals so flexibel
sein kann wie z.B. Ruby oder Python. Da müsste ich mir mal Ocaml
genauer anschauen. Selbiges würde ich dir in Bezug auf Python aber
ebenfalls empfehlen.


> > Aber das würde ich dir einfach mal empfehlen: Lerne Python,
> > das ist nicht weiter wild, und sollte nicht allzu lange dauern.
> Naja, wenn ich mal die Muße habe ;-)

> > Zumal
> > Python weit genug verbretiet ist, sodass du damit in absehbarer
> > wahrscheinlich sowieso zu tun haben wirst.
> Das ist natürlich eine Überlegung wert.

> > Wenn du das getan hast, würde
> > mich deine Meinung zum Vergleich von OCaml und Python sehr interessieren
> > ... nicht wegen der Einarbeitungszeit, sondern ob sich diese
> > Einarbeitungszeit danach auch auszahlt.
> Da ich OCaml schon kann, wird sich Python nur dann auszahlen, wenn
> jemand dafür bezahlt, daß ich das benutze.
> Ansonsten lohnt es nicht.

Achso? Nur für Geld würde sich das lohnen? Also, das wäre für mich der
letzte Grund für so eine Entscheidung. Es sei denn natürlich, ich werde
direkt nach Arbeitsstunden bezahlt. ;-)

Aber was wäre, wenn du mit Python schneller zum Ergebnis kommst, also
es dir Enticklungs - *Zeit* erpart. Würde es sich dann nicht auszahlen?

Das weiß ich natürlich nicht. Aber abgesehen von eventuellen Vorteilen
bei der Typisierung ist OCaml ja ziemlich festgefahren auf funktionale
Konzepte. In Bereich Software-Design hättest du in Python wesentlich
bessere Karten, IMHO.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l