1. #1
    U-Labs Elite
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    617
    Thanked 334 Times in 191 Posts

    Standard Typisierung von C# und Python

    Laut Wikipedia gehört Python zu den Sprachen mit einer "recht starken Typisierung". Das hat mich verwundert. Bisher habe ich zwar noch nicht in Python entwickelt, dafür aber in PHP. Und PHP hat ja bekannterweise eine sehr schwache, wenn nicht gar als katastrophal zu bezeichnende Typisierung. Ich hielt Python in der Hinsicht mit PHP vergleichbar, da ich in Python-Code bisher noch nie Datentypen gesehen habe, sondern nur Variablen ohne Typisierung wie in PHP. Es scheint, als wird hier noch mal unterschieden zwischen Implizierter und explizierter Typisierung. Implizite Typisierung scheint das zu sein, was PHP macht: Den Typ völlig eigenständig zu erkennen. Daher kann man den Typ einer Variable auch beliebig ändern wie
    PHP-Code:
    $foo 1;
    $foo 'Test';
    $foo = array(1,2,3);
    // ... 
    Das war bisher für mich das ausschlaggebende Argument. Denn so kann ich ja einer Funktion, die z.B. einen Array erwartet, jede anderen Typ übergeben. Das schlägt dann irgendwann fehl, was zu schwer auffindbaren Fehlern führen kann. Nun gibt es aber auch noch die explizite Typisierung: Der Programmierer gibt hier an, um welchen Typ es sich handelt. In stark typisierten Sprachen wie C# scheint beides vorhanden zu sein:

    string name = "Test";
    // Funktioniert nicht, da es sich um einen String handelt
    name = 4;

    Sehe ich es richtig, dass es in Python zwar keine explizite Typisierung gibt, aber dafür eine implizierte? Oder mit anderen Worten: Der Typ einer Variable wird zwar nicht ausdrücklich angegeben wie in C#. Python erkennt allerdings den Typ anhand der ersten Zuweisung und lässt es damit nicht zu, dass ich eine Variable als Zahl deklariere, und später einen String in die gleiche Variable schreibe? Damit wäre Python in meinen Augen zwar immer noch fehleranfällig, aber nicht ganz so schlimm wie PHP. In PHP kann man ja wie oben schon beschrieben alles machen, mit entsprechendem Chaos als mögliche Folge.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  2. The Following User Says Thank You to DotNet For This Useful Post:

    Negok (12.06.2017)

  3. #2
    U-Labs Routinier
    Avatar von Nuebel
    Registriert seit
    23.11.2013
    Beiträge
    439
    Thanked 355 Times in 231 Posts

    Standard AW: Typisierung von C# und Python

    Ich kenne eigentlich nur statische und dynamische Typisierung. Bei der statischen wird der Typ zur Übersetzungszeit bestimmt, bei der dynamischen zur Laufzeit. Die Definitionen für "starke" oder "schwache" Typisierung geht in verschiedenen Literaturen ziemlich weit auseinander. Hier sind gängige Definitionen aus Wikipedia:
    • Nichtvorhandensein irgendwelcher Konvertierungsmethoden und keine Möglichkeit, das Typsystem auf irgendeine Weise zu umgehen
    • Nur explizite Konvertierungen möglich
    • Typüberprüfung zur Übersetzungs- statt zur Laufzeit (statische Typisierung vs. dynamische Typisierung)
    • Implizite Konvertierungen nur zwischen ähnlichen Typen (zum Beispiel zwei unterschiedlichen Ganzzahl-Typen, siehe auch Zuweisungskompatibilität)
    • Generelle Unterscheidung zwischen Typen (z. B. hat Tcl keine verschiedenen Typen)

    In Python haben Variablen keinen Typ, sondern nur die Objekte, die sie referenzieren. Ähnlich wie in PHP kann einer Variable in Python also auch alles mögliche in beliebiger Reihenfolge zugewiesen werden. Da sie aber keine Variablen im engeren Sinne sind, sondern Objektreferenzen, kann zur Laufzeit geprüft werden, ob das Objekt entsprechende Attribute und Methoden bereitstellt (zum Beispiel zum casten in einen anderen Objekttyp). Dieses Konzept heißt Duck-Typing und ist für objektorientierte Skriptsprachen ziemlich üblich.
    Code:
    # Gueltige Python-Zuweisung
    a = 42
    a ist hier kein nativer Datentyp "Integer", sondern ein Objekt der Klasse "int". Rechenoperationen wie +, -, * und / sind hier auch keine Operatoren, sondern Methoden(, die auch in eigenen Klassen definiert werden können, sodass zum Beispiel '+' auch für eigene Objekte zulässig ist).
    Code:
    # Gueltiger Pythoncode
    a = 42
    if type(a) is int:
        a * 2              # 84
    a = "bla"
    if type(a) is str:
        a * 2              # "blabla"
    Die Typabfrage ist nicht der "python way". Das wird allenfalls beim Debuggen gemacht. Wie in Skriptsprachen üblich, wird alles bisschen lockerer gesehen und nichts "DAU-freundlich" programmiert. Man vertraut auf die korrekte Nutzung der Schnittstellen. Man sollte nicht vergessen, wofür Skriptsprachen gedacht sind: für kleine Problemchen wozu die Shell nicht mehr ausreicht, zur schnellen Entwicklung von Prototypen, zum Beweis der Machbarkeit.
    Geändert von Nuebel (10.06.2017 um 17:42 Uhr)

  4. The Following 2 Users Say Thank You to Nuebel For This Useful Post:

    DotNet (12.06.2017), Kingqwertz (11.06.2017)

  5. #3
    U-Labs Elite
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    617
    Thanked 334 Times in 191 Posts

    Standard AW: Typisierung von C# und Python

    Das Problem sehe ich darin, dass gerade PHP und Python bei weitem nicht mehr nur als "Skriptsprache" für kleine Projekte genutzt werden. Hauptsächlich liegt dies an der Backend-Verwendung in Webanwendungen. Gerade PHP ist ja zum Quasi-Standard für dynamische Webseiten geworden, und hat in seinem Bereich eine ähnlich hohe Verbreitung wie Windows auf Desktop-Computern. Beide Sprachen wurden zur Realisierung großer Webanwendungen genutzt, die weit über kleine Problemchen hinaus gehen.

    Diese dynamische Typisierung sehe ich skeptisch. Klar kann ich von einem Entwickler erwarten, dass Schnittstellen korrekt genutzt werden. Aber auch die sind nur Menschen und machen mal ganz stupide Fehler. Etwa einen String an Funktionen übergeben, die einen Array erwarten. Das geht so lange gut, bis bestimmte Array-Operationen auf den String durchgeführt werden. Selbst das führt in PHP nicht mal zwingend zu einer Exception bzw. einem fatalen Fehler, sondern lediglich einer Warnung, sodass das Programm weiter läuft. Dadurch kommt es zu "Schrott-Daten", und die Fehlersuche kann auch etwas Haarsträubend werden. Vor allem, wenn die Funktion intern andere Funktionen aufruft oder ähnliches. Ganz lustig wird es, wenn sich der Typ unter bestimmten Bedingungen ändert. Z.B. eine Abfrage, die aus einer String-Variable einen Array erzeugt, sei es nur aus Versehen.

    In meinen Augen sind das vermeidbare Fehler, die unnötig Zeit und Nerven kosten. C# ist mir daher viel lieber, weil ich da spätestens zur Compilerzeit einen fatalen Fehler erhalte. Mit Visual Studio sogar bereits zur Entwicklungszeit. Bei der Meldung, dass z.B. die Typen "String" und "List<String>" nicht kompatibel sind, ist dann sofort klar, dass ich mich bei den Parametern vertan habe. Hinsichtlich der Typen scheint Python ja dann doch nicht besser zu sein wie PHP, sondern es eher sehr ähnlich zu handhaben. Gerade mit der Verbreitung finde ich das schade.

    Beim Raspberry ist Python ja DIE Sprache schlechthin, wofür man wohl am meisten Dokumentationen und Tools findet. Für Kleinigkeiten ist das alles nicht so kritisch, da stimme ich dir zu. Aber nun arbeite ich an einem Projekt, dass größer wird. Schnell werden aus ein paar hundert Zeilen Code einige mehr, und ich komme in eine Situation, bei der diese dynamische Typisierung problematischer wird. Wenn ich die Funktion z.B. Mangels Library nicht in Sprachen mit statischer Typisierung wie C# oder Java umsetzen kann, müsste ich eine Brücke bauen (z.B. Python Server mit C# Client). Das ist natürlich technisch nicht so schön, verursacht mehr Arbeit und die Python-Lösung verschwindet dadurch auch nicht komplett, sondern reduziert sich lediglich. Bei einer Website/Anwendung die keine Plattform voraussetzt könnte man wenigstens konsistent auf PHP/Python verzichten, und stattdessen eine stark typisierte Alternative nutzen, als saubere Alternative.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  6. #4
    U-Labs Routinier
    Avatar von Nuebel
    Registriert seit
    23.11.2013
    Beiträge
    439
    Thanked 355 Times in 231 Posts

    Standard AW: Typisierung von C# und Python

    Zitat Zitat von DotNet
    Das Problem sehe ich darin, dass gerade PHP und Python bei weitem nicht mehr nur als "Skriptsprache" für kleine Projekte genutzt werden.
    Ja, das stimmt. Weil sie zu meist interpretierte Sprachen sind, bieten die meisten eine interaktive REPL (Read-Eval-Print-Loop) an, was die Entwicklung - vor allem wenn die IDE die REPL integrieren kann - sehr schnell und spaßig machen kann. Auch kann man das Programm, während es ausgeführt wird, verändern und das Ergebnis dieser Veränderung ist sofort sichtbar bzw. wird sofort übernommen, ohne den Interpreter zu beenden und neuzustarten.
    Schau dir z.B mal Clojure-Entwicklung mit der IDE Light Table an. Das macht richtig Spaß, so zu entwickeln.

    Zusätzlich zu der Typüberprüfung aus meinem ersten Beitrag bieten die meisten dynamisch typisierten Sprachen auch "assert"/"require"-Funktionen an, die als Argument einen booleschen Ausdruck erwarten. Ist dieser Ausdruck false, bricht die Ausführung des Programms ab, aber auch nur im Debug-Modus. Oder ganz klassisch: man schreibt im Kommentar, was für Argumente die Funktion/Methode erwartet.

Ähnliche Themen

  1. Python, Literaturempfehlungen zum Einstieg?
    Von Equilibrum im Forum Andere
    Antworten: 2
    Letzter Beitrag: 13.06.2017, 16:39
  2. Antworten: 4
    Letzter Beitrag: 27.11.2014, 22:36
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150