5auron hat geschrieben:Xin hat geschrieben:Für mich als Anwender einiger Klassen ist das uninteressant. Ich erwarte eine einfache Regel, zum Beispiel:
Dir als Anwender kann das auch egal sein, der Autor muss dafür Sorge tragen dass sich seine Klasse sinnvoll verhält.
Als Entwickler bin ich Anwender von Klassen.
Und richtig, mein Job als Entwickler ist, dass sich meine Software sinnvoll verhält.
Es fällt mir wesentlich einfacher, dafür zu garantieren, dass meine Software sich sinnvoll verhält, wenn die Sprache mir Garantieen gibt.
Ich bin nicht nur für die Qualität meiner Software verantwortlich, ich bin auch direkt (ich bekomme einen auf den Deckel) wie in indirekt (mein Chef bekommt einen auf den Deckel und möchte mein Gehalt nicht erhöhen) verantwortlich. Ich verdiene mein Geld als Software-Entwickler. Für mich zahlt sich die Qualität einer Sprache in Zeit und Geld aus.
5auron hat geschrieben:Für mich sind das Schwachstellen in der Sprache, da ein Objekt im Prinzip nur ein formbarer Attribut-Container ist, die weder klarstellen, ob sie Datenwert oder Funktion sind. Ich will Garantien von meiner Sprache.
Weil die Unterscheidung in Python wenig sinnvoll ist, Funktionen sind Datenwerte.
Das sind sie in C auch, aber trotzdem kann man Signaturen von Funktionen und Datentypen von Variablen unterscheiden.
Und die Garantie ist unabhängig von der Sprache sinnvoll.
Schwach typisierte Sprachen resultieren in meinen Augen aus einem einfachen Grund: Die semantische Prüfung muss im Interpreter implementiert werden, das ist aufwendig. Also lässt man es weg. Anfänger fragen nicht nach semantischen Prüfungen, die probieren aus. Die meisten Entwickler werden nie professionell. Eine Masse von semiprofessionellen Entwicklern, die nie eine Software geschrieben hat, die 100000 Zeilen überschritt, steht im Internet einer extrem geringeren Anzahl von qualifizierten Entwicklern gegenüber (und ein Diplom reicht in meinen Augen nicht für eine Qualifikation, ich meine Erfahrung, deutlich > 100000 Zeilen Projekte).
Kurz: Fresst Scheiße - Millionen Fliegen können nicht irren.
Ich finde Python selbst nicht schlecht. Ich habe vor ein Python-Tutorial für proggen.org aufzubauen. Aber ich finde Python auch nicht gut genug, als dass ich es als 'gut' bezeichnen würde.
5auron hat geschrieben:Natürlich... das ist ja auch alles ganz nett, nur wenn ich eine Variable V mit Typ X an unbekannten Code rausgebe, zum Beispiel durch einen Funktionsaufrufm, dann weiß ich nicht, ob wenn ich danach auf V zugreife, immernoch etwas vom Typ X habe.
Es gibt in Python keine C++-Referenzen, dementsprechend kann die Funktion auch nicht V einen neuen Wert zuweisen.
Ich übergebe Variable einer Klasse. Der Zeiger wird kopiert - nicht die Klasse. Der Inhalt der Klasse verändert sich, inkl. der Datentypen.
In C++ kann ich garantieren, dass sich der Zustand der Klasse von den Datentypen nicht verändert.
Wenn es sein muss, garantiere ich sogar, dass sich der Zustand der Werte ebenfalls nicht ändert. In Java gibt es da Software für, die Warnungen ausspricht, damit man das von hand kontrolliieren kann.
In C++ das Schlüsselwort 'const' und damit eine Garantie, dass da nix verändert wird.
5auron hat geschrieben:Weder kann ich als Entwickler alle Dokus auswendig können, noch kann ein Test alle Fälle abdecken.
Natürlich nicht, aber Typfehler sind wirklich nicht ansatzweise das Problem zu dem du es machst. Die Fallen i.d.R. sofort auf.
Erstens ist "i.d.R." unschön, wenn die Regel an einer wichtigen Stelle nicht auftritt und beim Kunden zur Ausnahme wird.
Zweitens ist "i.d.R." geht's gut für einen Professionellen keine akzeptable Alternative für 'es gibt eine Garantier'.
5auron hat geschrieben:Ich verstehe natürlich, dass das auch eine Hilfe ist und bin dem Prinzipiell noch nichtmal abgeneigt.
An der Stelle sei einmal angemerkt, dass die C# wohl demnächst Design By Contract Unterstützung erhalten wird. Das ist auch eine Sache, die ich mir bei Python gut vorstellen könnte (da das eh zur Laufzeit erfolgen muss, könnte man sich da sogar selbst was basteln dass das erledigen kann).
Für DBC benutzt Du in C das Assert-Makro. An dieser Stelle sei einmal angemerkt, dass C 1972 entwickelt wurde.
Wenn Du was cooles in der Informatik lernen willst, dann rate ich Dir das anzusehen, was man so vor 30-40 Jahren gemacht hat, als Computer mehr Beschränkungen in RAM und CPU-Leistung aufwiesen und die Informatik noch nicht mit Marketingbegriffen verseucht war.
Mein Lieblingsbeispiel ist, dass man in der Zeit einen Algorithmus gefunden hat, welcher ein Wörterbuch einer Rechtschreibkontrolle mit 80000 Worten in die 65536 Bytes Speicher damaliger Computer packte. Asserts in "Design By Contract" umzubenennen und auf Bertrand Meyer und Eiffel (1985) zurückzuführen ist schon etwas vermessen, zumal Eiffel nie sonderlich erfolgreich wurde.
In der Informatik ist in den letzten 50 Jahren nur wenig dazu gekommen. Die meisten Highlights, die in den letzten Jahren rausgekommen sind, sind Marketing-Begriffe für Dinge, die es schon seit Jahrzehnten gibt.
Für mich ist das ärgerlich: Ich muss jetzt gucken, was "Design By Contract" bedeutet, um festzustellen, dass es das ist, was man vor 30 Jahren 'Assert' nannte.
In meiner Sprache gibt es ebenfalls Vor- und Nachbedingungen. Die Idee ist ja auch nicht schlecht. Aber ich wäre nie auf die Idee gekommen, das als "Design By Contract" zu verkaufen.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.