shapeshifta schrieb am 12. Juni 2008 08:45
> > 1) Wo ist für .NET das TCK ("Technology Compatibility Kit") - i.e.
> > die für alle verbindliche und allgemein bekannte Testsuite...
>
> Hm, gibt es sowas nicht?
Ich habe noch nichts davon gehört. Ich bin sicher, daß MS so seine
Tests hat, weil man ja eigentlich nicht mehr ohne Tests entwickelt.
Aber für jede "Java Technology" MUSS es aus Prinzip ein TCK geben,
und sein Zweck ist, allen Implementers eine "aktive" Richtschnur zu
geben: ein Dokument als von Menschen lesbarer Text, das den
"Standard" beschreibt, ist schön und gut, aber weder führt es sich
auf Knopfdruck selbst aus (wie eine Suite) und beantwortet damit die
Kompatibilitätsfrage direkt, noch enthält es i.a. Klarstellungen für
alles, was man auch anders interpretieren könnte (und wird).
Beim Erstellen von Testcases wird man hingegen zu klarer Definition
gezwungen: ein Proband besteht dann den Test oder eben nicht, aber es
gibt keinen Interpretationsspielraum! Das verbleibende Problem ist
dann einfach der Abdeckungsgrad. Erstellt jeder Implementor nach
seinem Gutdünken seine eigenen Tests (andhand dessen, was er aus dem
Dokument herausliest), so hat am Ende jeder eine andere Suite, und
"Kompatibilität" bedeutet jedesmal etwas anderes. Baut man eine
allgemein verbindliche Suite auf, so hat jeder dieselben
Validierungsbedingungen, die Testabdeckung wird für alle auf den
bestmöglichen Stand gebracht ohne diesbezügliche Anstrengungen
unnötig zu duplizieren, und wenn zwei Produkte sich verchieden
Verhalten, ist dieses Verhalten entweder explizit als unspezifiziert
bezeichnet, oder die Suite muß erweitert werden, sobald dieser Fall
erkannt wird: damit er kein "Streitfall" bleibt.
> Es heißt doch immer, das man MS in Bezug auf die
> Entwicklungsumgebungen so schnell nichts vormachen kann,
> sprich das die immer sehr ausgereift sind.
Das, was als IDE für eine Sprache und Laufzeitumgebung verkauft wird,
damit wir damit Programme FÜR diese Umgebung entwickeln können, kann
sehr brauchbar sein, ist aber etwas ganz anderes als die Testsuite,
die die Standardisierung der Laufzeitumgebung für Implementierungen
durch Dritte aktiv (i.e. als Validator) unsterstützt. In Punkto
Standardisierung ist Microsofts Ruf wesentlich schlechter als in
Punkto IDEs/Compiler/Toolkits, und imho zu Recht. Microsoft hat, um
Kritiker zu besänftigen, einen abgegrenzten Subset von .NET (der aber
afaik in der Library-Doku zu Toolkit/IDE nicht klar abgegrenzt ist!)
per ECMA und dann sogar ISO "standardisieren" lassen. Sun hat nach
einigem hin und her darauf verzichtet und klargemacht, daß die
allgemeine (und verbindliche!) Validierbarkeit durch die TCKs viel
wichtiger und nützlicher ist.
Am Beispiel .NET: in einem offiziellen Dokument kann man z.B.
nachlesen, daß Methode m1 in Klasse K als Bestandteil z.B. der CLR
"genormt" ist, Methode m2 in K jedoch "Microsoft privat gehört"..
d.h. das steht zwar so nicht im Dokument, aber wenn m2 dort nicht
auftaucht, sollte man sich auf m2 nicht stützen, wenn man auf z.B.
Mono oder Rotor lauffähig sein will: es gehört offenbar nicht zu
einem genormten Teil von .NET. Ungeachtet dessen kann m2 bei einem
MS-Produkt wie dem Toolkit oder Visual Studio dokumentiert sein (auch
wenn dort nicht steht, daß es nicht zum ISO [oder ECMA] Teil gehört);
es kann vom Mono-Team sogar nachgebildet worden sein, da die über den
ISO-spezifizierten Teil hinaus "kompatibel" sein wollten. Doch bei
ständig neu auftauchenden Bestandteilen wie WPF, WF usw. müssen die
auch mal einen Schlußstrich ziehen. Die Kompatibilität ist bei .NET
also ein recht unscharfer Begriff, Überraschungen und
Meinungsverschiedenheiten "vorprogrammiert", und eine allgemein
verbindliche Testsuite, die das behebt, indem sie für eine
Zertifizierung bestanden werden MUSS, ist mir so nicht bekannt.
Ich habe hier schon öfter danach gefragt, ebenso, ob Mono
mittlerweile doch die für Enterprise Projekte nicht unwichtige Code
Access Security (afaik nicht in jenen ISO/ECMA "Standards" enthalten)
mittlerweile implementiert hat; auf beides habe ich im Forum hier nie
eine Antwort bekommen. Aber dafür wurde hier oft genug im Brustton
der Überzeugung getönt, .NET liefe - als Mono - auch auf Linux "sehr
kompatibel" und sei deshalb "plattformunabhängig" - Sun spricht bei
Java nur von "Plattformneutralität", da ja alles "abhängig"
implementiert werden muß, aber eben auch kann, weil Javas Architektur
mit ihrem "gemeinsamer Nenner"-Ansatz "neutral", also anpassungsfähig
genug ist (ich frage mich, wieso die angeblich bessere - sicher
engere - Integration von .NET in Windows das Ding nicht als
"Windows-zentrisch" [oder wie immer man es auf Deutsch sagen soll]
markiert, wieso das immer noch nicht nur neutral sondern sogar
"plattformunabhängig" sein soll [und wieso ich oft genug beschimnpft
worden bin, wenn ich das anzweifelte] ;)
Zm anderen:
> > 2) Wo ist der Community Prozeß für die Weiterentwicklung von .NET
> > (oder wenigstens für die ISO-genormten Bestandteile)?...
>
> Ich denke, Du sprichst hier über den Grundgedanken von Open Source
> oder zumindest über die Entwicklung durch mehrere Parteien.
Der Community Prozeß wurde von Sun lange vor der Freigabe
irgendwelchen Quellcodes unter einer offenen Lizenz ins Leben
gerufen. Ich sehe daher diese Prinzipien völig unabhängig vom Open
Source Gedanken. Es geht ja dort auch nicht um Quellcode sondern um
die Frage, welche neuen Funktionalitäten man sich als Erweiterung
wünscht, um die Plattformen für das, was einem wichtig ist,
tragfähiger zu machen.
Daß Sun längst nicht mehr alleine bestimmt, wo's lang geht, liegt
nicht an einem Druck durch die zunehmend erstarkende Open Source
Bewegung (damals noch längst nicht so stark wie heute!) sondern
daran, daß die Plattform für die Industrie gemacht ist, und dort
tummeln sich Firmen, die mitreden wollen (und sollen) und die
teilweise am Markt bedeutender sind als Sun: IBM ist beispielsweise
ein richtiges Schwergewicht, neben dem auch Sun klein wirkt.
Seine techniche Kompetenz und die Urheberschaft an Java haben Sun
zwar eine starke Position verschafft, aber sie können unmöglich für
die nahezu gesamte IT-Industrie relevante Standards über die Köpfe
von IBM und Konsorten hinweg bestimmen. Das Schöne daran ist also,
daß offenbar auch Leute konsensfähig sind, die nicht direkt Open
Source Idealisten sind (Sun hat schon früher viel unter z.B. CDDL
offengelegt, aber primär sind sie eine Aktiengesellschaft, die
verdienen muß).
> > 1) Wo ist für .NET das TCK ("Technology Compatibility Kit") - i.e.
> > die für alle verbindliche und allgemein bekannte Testsuite...
>
> Hm, gibt es sowas nicht?
Ich habe noch nichts davon gehört. Ich bin sicher, daß MS so seine
Tests hat, weil man ja eigentlich nicht mehr ohne Tests entwickelt.
Aber für jede "Java Technology" MUSS es aus Prinzip ein TCK geben,
und sein Zweck ist, allen Implementers eine "aktive" Richtschnur zu
geben: ein Dokument als von Menschen lesbarer Text, das den
"Standard" beschreibt, ist schön und gut, aber weder führt es sich
auf Knopfdruck selbst aus (wie eine Suite) und beantwortet damit die
Kompatibilitätsfrage direkt, noch enthält es i.a. Klarstellungen für
alles, was man auch anders interpretieren könnte (und wird).
Beim Erstellen von Testcases wird man hingegen zu klarer Definition
gezwungen: ein Proband besteht dann den Test oder eben nicht, aber es
gibt keinen Interpretationsspielraum! Das verbleibende Problem ist
dann einfach der Abdeckungsgrad. Erstellt jeder Implementor nach
seinem Gutdünken seine eigenen Tests (andhand dessen, was er aus dem
Dokument herausliest), so hat am Ende jeder eine andere Suite, und
"Kompatibilität" bedeutet jedesmal etwas anderes. Baut man eine
allgemein verbindliche Suite auf, so hat jeder dieselben
Validierungsbedingungen, die Testabdeckung wird für alle auf den
bestmöglichen Stand gebracht ohne diesbezügliche Anstrengungen
unnötig zu duplizieren, und wenn zwei Produkte sich verchieden
Verhalten, ist dieses Verhalten entweder explizit als unspezifiziert
bezeichnet, oder die Suite muß erweitert werden, sobald dieser Fall
erkannt wird: damit er kein "Streitfall" bleibt.
> Es heißt doch immer, das man MS in Bezug auf die
> Entwicklungsumgebungen so schnell nichts vormachen kann,
> sprich das die immer sehr ausgereift sind.
Das, was als IDE für eine Sprache und Laufzeitumgebung verkauft wird,
damit wir damit Programme FÜR diese Umgebung entwickeln können, kann
sehr brauchbar sein, ist aber etwas ganz anderes als die Testsuite,
die die Standardisierung der Laufzeitumgebung für Implementierungen
durch Dritte aktiv (i.e. als Validator) unsterstützt. In Punkto
Standardisierung ist Microsofts Ruf wesentlich schlechter als in
Punkto IDEs/Compiler/Toolkits, und imho zu Recht. Microsoft hat, um
Kritiker zu besänftigen, einen abgegrenzten Subset von .NET (der aber
afaik in der Library-Doku zu Toolkit/IDE nicht klar abgegrenzt ist!)
per ECMA und dann sogar ISO "standardisieren" lassen. Sun hat nach
einigem hin und her darauf verzichtet und klargemacht, daß die
allgemeine (und verbindliche!) Validierbarkeit durch die TCKs viel
wichtiger und nützlicher ist.
Am Beispiel .NET: in einem offiziellen Dokument kann man z.B.
nachlesen, daß Methode m1 in Klasse K als Bestandteil z.B. der CLR
"genormt" ist, Methode m2 in K jedoch "Microsoft privat gehört"..
d.h. das steht zwar so nicht im Dokument, aber wenn m2 dort nicht
auftaucht, sollte man sich auf m2 nicht stützen, wenn man auf z.B.
Mono oder Rotor lauffähig sein will: es gehört offenbar nicht zu
einem genormten Teil von .NET. Ungeachtet dessen kann m2 bei einem
MS-Produkt wie dem Toolkit oder Visual Studio dokumentiert sein (auch
wenn dort nicht steht, daß es nicht zum ISO [oder ECMA] Teil gehört);
es kann vom Mono-Team sogar nachgebildet worden sein, da die über den
ISO-spezifizierten Teil hinaus "kompatibel" sein wollten. Doch bei
ständig neu auftauchenden Bestandteilen wie WPF, WF usw. müssen die
auch mal einen Schlußstrich ziehen. Die Kompatibilität ist bei .NET
also ein recht unscharfer Begriff, Überraschungen und
Meinungsverschiedenheiten "vorprogrammiert", und eine allgemein
verbindliche Testsuite, die das behebt, indem sie für eine
Zertifizierung bestanden werden MUSS, ist mir so nicht bekannt.
Ich habe hier schon öfter danach gefragt, ebenso, ob Mono
mittlerweile doch die für Enterprise Projekte nicht unwichtige Code
Access Security (afaik nicht in jenen ISO/ECMA "Standards" enthalten)
mittlerweile implementiert hat; auf beides habe ich im Forum hier nie
eine Antwort bekommen. Aber dafür wurde hier oft genug im Brustton
der Überzeugung getönt, .NET liefe - als Mono - auch auf Linux "sehr
kompatibel" und sei deshalb "plattformunabhängig" - Sun spricht bei
Java nur von "Plattformneutralität", da ja alles "abhängig"
implementiert werden muß, aber eben auch kann, weil Javas Architektur
mit ihrem "gemeinsamer Nenner"-Ansatz "neutral", also anpassungsfähig
genug ist (ich frage mich, wieso die angeblich bessere - sicher
engere - Integration von .NET in Windows das Ding nicht als
"Windows-zentrisch" [oder wie immer man es auf Deutsch sagen soll]
markiert, wieso das immer noch nicht nur neutral sondern sogar
"plattformunabhängig" sein soll [und wieso ich oft genug beschimnpft
worden bin, wenn ich das anzweifelte] ;)
Zm anderen:
> > 2) Wo ist der Community Prozeß für die Weiterentwicklung von .NET
> > (oder wenigstens für die ISO-genormten Bestandteile)?...
>
> Ich denke, Du sprichst hier über den Grundgedanken von Open Source
> oder zumindest über die Entwicklung durch mehrere Parteien.
Der Community Prozeß wurde von Sun lange vor der Freigabe
irgendwelchen Quellcodes unter einer offenen Lizenz ins Leben
gerufen. Ich sehe daher diese Prinzipien völig unabhängig vom Open
Source Gedanken. Es geht ja dort auch nicht um Quellcode sondern um
die Frage, welche neuen Funktionalitäten man sich als Erweiterung
wünscht, um die Plattformen für das, was einem wichtig ist,
tragfähiger zu machen.
Daß Sun längst nicht mehr alleine bestimmt, wo's lang geht, liegt
nicht an einem Druck durch die zunehmend erstarkende Open Source
Bewegung (damals noch längst nicht so stark wie heute!) sondern
daran, daß die Plattform für die Industrie gemacht ist, und dort
tummeln sich Firmen, die mitreden wollen (und sollen) und die
teilweise am Markt bedeutender sind als Sun: IBM ist beispielsweise
ein richtiges Schwergewicht, neben dem auch Sun klein wirkt.
Seine techniche Kompetenz und die Urheberschaft an Java haben Sun
zwar eine starke Position verschafft, aber sie können unmöglich für
die nahezu gesamte IT-Industrie relevante Standards über die Köpfe
von IBM und Konsorten hinweg bestimmen. Das Schöne daran ist also,
daß offenbar auch Leute konsensfähig sind, die nicht direkt Open
Source Idealisten sind (Sun hat schon früher viel unter z.B. CDDL
offengelegt, aber primär sind sie eine Aktiengesellschaft, die
verdienen muß).