[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