Python Tutorials

Objektorientierte Skriptsprache: (python.org)
Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Python Tutorials

Beitrag von Xin » Mi Apr 22, 2009 8:48 pm

dP. hat geschrieben:
Ich habe auch nie behauptet, dass ich die schwache Typisierung in Python in irgendeiner Form gutheißen würde.
Das halte ich für eine der Stärken von Python.
Ich programmiere jetzt seit 1986. Das sind in August 23 Jahre.
Dabei habe ich auch einige Sprachen gelernt, die schwach typisiert sind.
Das Proggen.org CMS schreibe ich in C++, weil C++ stark typisiert ist und das bei größeren Projekten SEHR hilft, Fehler zu vermeiden.
Python ist eine Rapid-Prototyping-Sprache. Damit kann man sehr schnell, etwas auf die Beine stellen. Aber bitte keine größeren Projekte.
dP. hat geschrieben:Allerdings hätte ich Python jetzt als stark, aber eben nicht statisch typisiert bezeichnet. Zumindest hat jedes Objekt zur jeder Zeit einen genau festgelegten Typ.
Ein Objekt kann zwangsläufig zu jeder Zeit nur genau einen Typ haben. Noch schwächer kann man nicht typisieren.

Die Variablen jedenfalls können auf beliebige Objekte zeigen und der Typ der Variablen ändert sich entsprechend des Typs: Die Variablen sind also schwach typisiert.
Python garantiert mir nicht, dass ich an irgendeiner Stelle einen bestimmten Typ in einer Variablen habe. C++ gibt mir an allen Stellen Garantien.
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.

5auron
Beiträge: 4
Registriert: Mi Apr 29, 2009 9:23 am

Re: Python Tutorials

Beitrag von 5auron » Mi Apr 29, 2009 9:46 am

dP. hat geschrieben:Was dumm ist:

Code: Alles auswählen

a = MyNumber(5)
a + 3 # funktioniert
3 + a # TypeError
Dafür gibt es __radd__.

Xin hat geschrieben:Sicher kann man über Geschmack streiten. Allerdings sollte der Geschmack da zurücktreten, wo Konsistenz gefragt wird. Ich sehe den Zusammenhang zwischen a+b und "operator +" als deutlicher gegeben, als bei __add__. Über __+__ hätte man noch reden können, aber hier werden zusätzliche Schlüsselwörter verbraten, die eigentlich nicht notwendig sind.
Schlüsselwörter werden hier gar nicht verbraten (__add__ ist kein Schlüsselwort sondern eine stinknormale Funktion) im Gegenteil. Für "operator +" müsstest du das Schlüsselwort "operator" einführen und für das und alles andere müsste man Ausnahmen in der Syntax einführen.

Beispielsweise:

Code: Alles auswählen

a.__+__ # Was ist damit jetzt gemeint? gettattr(a, "__+__") oder (a.__) + __ ?
Ein Objekt kann zwangsläufig zu jeder Zeit nur genau einen Typ haben. Noch schwächer kann man nicht typisieren.
Was ist denn deine Definition von „Starker Typisierung“?
Die Variablen jedenfalls können auf beliebige Objekte zeigen und der Typ der Variablen ändert sich entsprechend des Typs: Die Variablen sind also schwach typisiert.
Deswegen nennt man das ja dynamisch typisiert.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Python Tutorials

Beitrag von Xin » Mi Apr 29, 2009 10:31 am

Moin 5auron und willkommen im Forum.
5auron hat geschrieben:Dafür gibt es __radd__.
Stimmt, mein Python Exkurs ist wieder ein paar Tage her und zu einer große Vertiefung kam ich noch nicht.

Wie sieht es mit zwei Klassen aus, die beide __add__ und __radd__ für die jeweils andere implementieren?
Das wird sicherlich nicht gewürfelt, aber es wäre unschön, wenn es zwei unterschiedliche Varianten gibt, die dann nicht zuordbar sind, wenn man nicht die Feinheiten von Python kennt.
5auron hat geschrieben:
Xin hat geschrieben:Sicher kann man über Geschmack streiten. Allerdings sollte der Geschmack da zurücktreten, wo Konsistenz gefragt wird. Ich sehe den Zusammenhang zwischen a+b und "operator +" als deutlicher gegeben, als bei __add__. Über __+__ hätte man noch reden können, aber hier werden zusätzliche Schlüsselwörter verbraten, die eigentlich nicht notwendig sind.
Schlüsselwörter werden hier gar nicht verbraten (__add__ ist kein Schlüsselwort sondern eine stinknormale Funktion) im Gegenteil. Für "operator +" müsstest du das Schlüsselwort "operator" einführen und für das und alles andere müsste man Ausnahmen in der Syntax einführen.

Beispielsweise:

Code: Alles auswählen

a.__+__ # Was ist damit jetzt gemeint? gettattr(a, "__+__") oder (a.__) + __ ?
Den Einwand verstehe ich jetzt nicht. Wo liegt das Problem a.operator +( 4 ) zu schreiben? Ein Operator ist in C++ auch nur eine normale Funktion, aber die Besonderheit, dass sie in Kurzschreibweise möglich ist, ergibt sich aus dem Namen, der mit dem Schlüsselwort 'operator' beginnt.
Das Schlüsselwort operator existiert in C++ ja auch nicht umsonst.
Weiterhin muss ich sagen, dass ich mich nicht verantwortlich fühle, für Dinge die in der Syntax einer Sprache inkonsistent bedacht wurden.
Ich habe allerdings auch nicht so den Trieb Dinge zu retten. Hakt die Sprache, muss ich keine Ausnahmen in der vorhanden Syntax suchen, sondern eine Syntax, die nicht hakt.
5auron hat geschrieben:
Ein Objekt kann zwangsläufig zu jeder Zeit nur genau einen Typ haben. Noch schwächer kann man nicht typisieren.
Was ist denn deine Definition von „Starker Typisierung“?
Der Satz zuvor war schlecht ausgedrückt. Zu jeder Zeit meint eher zu jedem Zeitpunkt: Eine Variable kann nie mehr als einen Typ gleichzeitig haben. Schwache Typisierung bedeutet, dass der Typ sich im Lauf der Zeit ändert. Es besteht also keine Garantie, dass eine Variable am Ende des Algorithmus noch vom gleichen Typ ist wie zu vor. Darüber lässt sich ggfs. noch streiten, ob das so wichtig ist.
Aber dass man zu beginn eines Algorithmus nicht statisch festlegen kann, welche Datentypen für einen Algorithmus legal sind und welche nicht - da wird es dann langsam unschön.
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.

5auron
Beiträge: 4
Registriert: Mi Apr 29, 2009 9:23 am

Re: Python Tutorials

Beitrag von 5auron » Mi Apr 29, 2009 5:55 pm

Xin hat geschrieben:Wie sieht es mit zwei Klassen aus, die beide __add__ und __radd__ für die jeweils andere implementieren?
Das wird sicherlich nicht gewürfelt, aber es wäre unschön, wenn es zwei unterschiedliche Varianten gibt, die dann nicht zuordbar sind, wenn man nicht die Feinheiten von Python kennt.
Es wird immer zuerst versucht die __add__-Methode des linken Operanden auszuführen, dann die __radd__ Methodes des rechten Operanden und dann fliegt ein TypeError. Einzige Ausnahme ist, wenn der Typ des rechtes Operanden eine Subklasse des Typs des linken Operanden ist und dort eine __radd__-Methode implementiert ist, wird zuerst die __radd__-Methode des rechten Operanden ausgeführt. Klar, muss man wissen, aber wer auf die Idee kommt mal eine Methode names __radd__ zu implementieren wird wohl schon die Doku gelesen haben....
Den Einwand verstehe ich jetzt nicht. Wo liegt das Problem a.operator +( 4 ) zu schreiben?
Weil man dann ein zusätzliches Schlüsselwort einführen müsste (was die Sprache nur unnötig kompliziert machen würde). Sonst kann der Interpreter ja nicht wissen ob jetzt (a.operator) + ( 4 ) oder (a.operator +)(4) gemeint ist.
Weiterhin muss ich sagen, dass ich mich nicht verantwortlich fühle, für Dinge die in der Syntax einer Sprache inkonsistent bedacht wurden.
Ich sehe jetzt nicht was daran inkonsistent sein soll.
Schwache Typisierung bedeutet, dass der Typ sich im Lauf der Zeit ändert. Es besteht also keine Garantie, dass eine Variable am Ende des Algorithmus noch vom gleichen Typ ist wie zu vor. Darüber lässt sich ggfs. noch streiten, ob das so wichtig ist.
Der Typ von Variablen (in Python spricht man auch eher von Namen) ändert sich in Python auch nicht von selbst. So lange man nicht selbst an eine Variablen einen neuen Wert zuweist bleibt der gleich.
Aber dass man zu beginn eines Algorithmus nicht statisch festlegen kann, welche Datentypen für einen Algorithmus legal sind und welche nicht - da wird es dann langsam unschön.
Dafür gibt es Dokus und Tests. Aber das ist ein ewiges Streitthema.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Python Tutorials

Beitrag von Xin » Mi Apr 29, 2009 6:30 pm

5auron hat geschrieben:Es wird immer zuerst versucht die __add__-Methode des linken Operanden auszuführen, dann die __radd__ Methodes des rechten Operanden und dann fliegt ein TypeError. Einzige Ausnahme ist, ... Klar, muss man wissen, ...
Für mich als Anwender einiger Klassen ist das uninteressant. Ich erwarte eine einfache Regel, zum Beispiel:

Code: Alles auswählen

resulttype operator +( lefttype & leftdata, righttype & rightdata )
Das wird nicht überladen, weil es ansonsten nicht kompilierbar ist. Wenn's kompiliert, muss ich mir als Anwender keine Sorgen machen. Es gibt also auch keine einzige Ausnahme und kein 'Klar, man muss wissen'.
5auron hat geschrieben:
Xin hat geschrieben:Den Einwand verstehe ich jetzt nicht. Wo liegt das Problem a.operator +( 4 ) zu schreiben?
Weil man dann ein zusätzliches Schlüsselwort einführen müsste (was die Sprache nur unnötig kompliziert machen würde). Sonst kann der Interpreter ja nicht wissen ob jetzt (a.operator) + ( 4 ) oder (a.operator +)(4) gemeint ist.
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.
5auron hat geschrieben:
Weiterhin muss ich sagen, dass ich mich nicht verantwortlich fühle, für Dinge die in der Syntax einer Sprache inkonsistent bedacht wurden.
Ich sehe jetzt nicht was daran inkonsistent sein soll.
Das stimmt. Es ist schwamming und das konsistent, weil es dem Konzept entspricht. Und das meine ich nicht negativ, denn das ist das Konzept von Python.
Ich schreibe aber zu wenig Programme, die in den Anwendungsbereich von Python passen. Deswegen brauche ich Garantien.
5auron hat geschrieben:
Schwache Typisierung bedeutet, dass der Typ sich im Lauf der Zeit ändert. Es besteht also keine Garantie, dass eine Variable am Ende des Algorithmus noch vom gleichen Typ ist wie zu vor. Darüber lässt sich ggfs. noch streiten, ob das so wichtig ist.
Der Typ von Variablen (in Python spricht man auch eher von Namen) ändert sich in Python auch nicht von selbst. So lange man nicht selbst an eine Variablen einen neuen Wert zuweist bleibt der gleich.
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.
Kommt dann noch OOP dazu, verwandelt sich eine schwach typisierte Sprache in eine Monte-Carlo-Maschine. Und wenn's scheppert heißt das nicht unbedingt, dass man gewonnen hat ;-)
5auron hat geschrieben:
Aber dass man zu beginn eines Algorithmus nicht statisch festlegen kann, welche Datentypen für einen Algorithmus legal sind und welche nicht - da wird es dann langsam unschön.
Dafür gibt es Dokus und Tests. Aber das ist ein ewiges Streitthema.
Für mich ist das kein Streitthema.

Weder kann ich als Entwickler alle Dokus auswendig können, noch kann ein Test alle Fälle abdecken. Beides ist ein großer Aufwand, der durch eine statische Typprüfung deutlich verringert und hochgradig automatisiert werden kann. Mein größtes Privatprojekt hat einige Megabyte Quelltext. Auch dokumentiert, ich habe jede Zeile geschrieben - aber ich kann mir nicht jedes Detail merken.

Wenn es nicht möglich ist, diese Form von Fehlern semantisch korrekt auszudrücken, dann kann ich kein Programm erzeugen, das diese Form von Fehlern enthält - oder ich schreibe in den Code demonstrativ einen "reinterpret_cast" rein, was nicht nur optisch eine Beleidigung an gutes Code-Verständnis ist.

Python ist eine interessante Sprache. Es ist eine Rapid-Prototyping-Sprache. Und dafür ist sie sehr gut.

Man kann damit aufwendige Projekte realisieren. Aber das heißt definitiv nicht, dass das eine gute Idee wäre. Für aufwendige Projekte wird man langfristig schneller sein, wenn man eine andere Sprache verwendet. Das Dumme ist... man nimmt halt, was man kennt und schätzt und nicht unbedingt das, was in der Situation sinnvoll ist.
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.

5auron
Beiträge: 4
Registriert: Mi Apr 29, 2009 9:23 am

Re: Python Tutorials

Beitrag von 5auron » Do Apr 30, 2009 11:32 pm

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.
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.
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.
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.

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).

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Python Tutorials

Beitrag von Xin » Fr Mai 01, 2009 10:14 am

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.

5auron
Beiträge: 4
Registriert: Mi Apr 29, 2009 9:23 am

Re: Python Tutorials

Beitrag von 5auron » Fr Mai 01, 2009 11:53 am

Xin hat geschrieben:Für DBC benutzt Du in C das Assert-Makro. An dieser Stelle sei einmal angemerkt, dass C 1972 entwickelt wurde.
Klar gabs das alles schon. Ich kann auch auf while etc. vergessen und nur noch manuell im Programm umherspringen. Ob das jetzt zur Lesbarkeit beiträgt sei mal dahingestellt. Dasselbe gilt auch für DBC, wenn es auf Sprachebene gut umgesetzt ist, dann dient das auch gleichzeitig zur Dokumentation. Das ist dann einfach nur „Syntactic Sugar“ nicht mehr und nicht weniger.
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.
Ja, zu der Zeit hat man mit einer dynamisch typisierten Sprache (Smalltalk) die noch dazu in einer VM interpretiert wurde an der ersten modernen GUI gearbeitet. Seitdem hat sich nicht mehr viel getan, da hast du Recht, leider.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Python Tutorials

Beitrag von Xin » Fr Mai 01, 2009 3:43 pm

5auron hat geschrieben:
Xin hat geschrieben:Für DBC benutzt Du in C das Assert-Makro. An dieser Stelle sei einmal angemerkt, dass C 1972 entwickelt wurde.
Klar gabs das alles schon. Ich kann auch auf while etc. vergessen und nur noch manuell im Programm umherspringen. Ob das jetzt zur Lesbarkeit beiträgt sei mal dahingestellt. Dasselbe gilt auch für DBC, wenn es auf Sprachebene gut umgesetzt ist, dann dient das auch gleichzeitig zur Dokumentation. Das ist dann einfach nur „Syntactic Sugar“ nicht mehr und nicht weniger.
Das würde ich so nicht sagen, da ich es eigentlich sehr gut finde, wenn die Sprachsyntax die Ideen widerspiegeln und so die Disziplin des Programmierers unterstützt. Das ist quasi Typsicherheit in einer anderen Problemstellung.

DBC selbst ist allerdings per Assert und ein wenig Disziplin abbildbar und das erfordert MASSIV weniger Disziplin als Typsicherheit in schwach typisierten Sprachen, da es lediglich auf den Eintritt und den Austritt der Funktion beschränkt ist. Es lässt sich beispielsweise sehr schön und einfach in Interfaces kapseln, die somit ebenso dokumentieren und den eigentlichen Algorithmus dann so durchlaufen lassen.
5auron hat geschrieben:
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.
Ja, zu der Zeit hat man mit einer dynamisch typisierten Sprache (Smalltalk) die noch dazu in einer VM interpretiert wurde an der ersten modernen GUI gearbeitet. Seitdem hat sich nicht mehr viel getan, da hast du Recht, leider.
Heutzutage hat man mehr Rechenleistung.
Asserts finde ich sehr gut, um ein Programm zu testen. Inzwischen ist die Rechenzeit da, um die Tests zum Kunden zu verschieben und ihm das auch noch zu verkaufen: Sie überprüfen bei der Benutzung des Programms, dass wir uns an die Vorgaben gehalten haben. Eine Selbstverständlichkeit als Feature zu verkaufen, das geht nur mit gutem Marketing.
Asserts sollte man nämlich wieder rausnehmen, wenn man das Release rausgibt.
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.

Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

Re: Python Tutorials

Beitrag von fat-lobyte » Fr Mai 01, 2009 8:23 pm

Tag!
<unqualifiziert>Ist es vielleicht möglich, dass sich hier die Anwendungsgebiete von C++ und Python weniger überschneiden als hier beschrieben wird?
C++ ist sehr Stark typisiert, sehr viel wird bereits zur Kompilierzeit überprüft und abgefangen und auch die Performance ist Toll. Aber C++ ist eine solch riesige Sprache, dass man ein Dutzend Informatiker damit erschlagen könnte. Die Syntax ist nicht immer intuitiv und auch die Konzepte sind relativ schwer zu verstehen. Bis man in C++ nutzbaren Code Produziert dauerts ne ganz schöne Weile.
Python hingegen ist eine Skriptsprache. Allein damit ist schon viel gesagt. Damit fallen schon mal viele (alle?) überprüfungen zur Kompilierzeit weg, alles wird in die Laufzeit verlagert, die Performance ist im Eimer.
Aber mal ganz ehrlich: es ist eine Skriptsprache! Was soll ich mir denn anderes davon Erwarten? Wenn ich weiß dass ich ein Megaprojekt habe, das Zeitkritisch ist, dann verwende ich einfach eine andere Sprache. Aber nicht alle Programme sind groß, wichtig und zeitkritisch. Ob ein Programm 0.01 oder 0.5 Sekunden braucht ist für den User egal (schon klar, bei größeren Datenmengen sieht die Sache anders aus. Aber bei kleinen Datenmengen?) Wieso sollte man nicht mal Python verwenden? Die Sprache ist einfach, schnell zu lernen und für den Anfang Produktiv. So quasi für den "afternoon hack".
Ich sehe nicht, wieso man für kleine Skripte unbedingt den Compiler anwerfen und den perfekten C- Code schreiben muss. Das wäre ein absoluter Overkill.

Das sind meine Gedanken dazu... Hoffe es fühlt sich keiner auf den Schlips getreten.
</unqualifiziert>
Haters gonna hate, potatoes gonna potate.

Antworten