[linux-l] RS-232 oder USB lesen mit (Schauder...) Java Os-unabhaengig
Volker Grabsch
vog at notjusthosting.com
Fr Sep 23 21:42:18 CEST 2005
On Thu, Sep 22, 2005 at 10:37:25AM +0200, Axel Weiß wrote:
> Volker Grabsch schrieb:
> > 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.
>
> Volker, der Unterschied der beiden Fehlerklassen ist unabhängig vom
> Vorhandensein eines Compilers. Fehler, die sich durch eine (statische)
> Analyse des Programms finden lassen (Fehler zur Compilierungs-Zeit),
> sollten bitteschön auch gefunden werden, bevor ein Programm zur
> Ausführung kommt. Fehler, die sich so nicht finden lassen (Fehler zur
> Laufzeit), sind also von Laufzeit-Zuständen des Systems abhängig (und
> schonmal prinzipiell schwerer zu finden).
Da ist was dran. Und genau deshalb klingt Ocaml für mich auch so reizvoll.
Aber was Python angeht, ist es schier undenkbar. Nehmen wir z.B. das hier:
def hello(person):
print "Hello", person.name, "!"
class Person:
pass # nichts
Da kann man folgendes machen:
p = Person()
hello(p)
Das ist offenbar ein Fehler, weil "p" als Instanz von "Person" keine
Attribut "name" hat. Und jetzt:
p = Person()
p.__dict__['name'] = "Hans" # Das geht!
hello(p)
Nun funktioniert alles. Selbst wenn der Compiler also feststellen
könnte, dass "hello" das Attribut "name" von seinem Parameter verlangt,
und dass "Person" dieses Attribut nicht bieten kann, müsste er den
String-Parameter 'name' noch verstehen, und wenn man diesen zur Laufzeit
erst zusammenbaut, hat der Compiler keine Chance mehr.
Macht man hingegen das hier:
p = Person()
p.name = "Hans" # Das geht!
hello(p)
... könnte man schon vom Compiler erwarten, dass er darüber Buch führt,
Welche Attribute "p" hat.
Die Frage ist also eher grundsätzlicher Natur: Wieviel kann man bei
einer Sprache voraussagen, wenn sie dynamisch typisiert ist? Und da
wird in Python vielleicht zu wenig getan, aber es gibt zwei Sachen,
die dennoch für Python sprechend
1) gibt es ein Compiler-Projekt für Python, wo eben diese Sorte von
Vorhersagen irgendwie ermöglicht werden. Will man den nutzen, darf
man natürlich nicht mehr die ganz krassen Python-Features nutzen,
aber du braucht man eh selten. Den Namen des Projektes weiß ich
leider nicht mehr.
2) gibt es prinzipiell nur die Sorge, ob bestimmte Methoden verfügbar
sind, wenn sie aufgerufen werden. Selbst wenn man nur ganz einfache
(aber vollständige) Testsuites hat, fällt das auf. Zwar erst
zur Laufzeit, und nicht schon zur Compile-Zeit, aber immer noch
in der Testing-Phase, also lange bevor der Code auch nur irgendwie
ernsthaft gestartet wird. Und die Fehlersuche ist damit genauso
schnell, als würde es vom Compiler gefunden werden ... naja,
vielleicht ein paar Mikrosekunden später ...
Richtig tiefliegende Fehler findet man natürlich nicht, aber ich
wüsste andererseits auch kein Beispiel für so einen Fehler, der
nicht schon beim Programmieren ins Auge fallen würde.
Ohne Testsuites ist Python aber ein ziemliches Wagnis, das stimmt. :-(
> Wenn schon kein Compilierungs-Schritt da ist, sollte wenigstens eine
> statische Analyse stattfinden, um den Programmierer zu unterstützen.
Was bedeutet das? Kannst du das mal an einem Beispiel erläutern?
Viele Grüße,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Mehr Informationen über die Mailingliste linux-l