Bedeutet "untypisiert" in der akademischen CS-Welt auch "dynamisch typisiert"?

Question

Ich lese eine Folie, die besagt, dass "JavaScript ist untypisiert". Dies widersprach, was ich dachte, wahr zu sein, so dass ich begann zu graben, um zu versuchen und mehr zu erfahren.

Jede Antwort auf Ist JavaScript eine untypisierte Sprache? sagt, dass JavaScript pas untypisiert und bot Beispiele für verschiedene Formen der statischen, dynamischen, starken und schwachen Typisierung, mit denen ich vertraut und zufrieden bin das war also nicht der richtige Weg.

Also habe ich Brendan Eich, den Erfinder von JavaScript, gefragt, und er hat gesagt: "Das ist eine gute Idee:

akademische typen verwenden "untypisiert" im sinne von "keine statischen typen". sie sind klug genug zu erkennen, dass werte typen haben (duh!). kontext ist wichtig.

Verwenden akademisch orientierte Informatiker "untypisiert" als Synonym für "dynamisch typisiert" (und ist das gültig?), oder steckt da etwas Tieferes dahinter, das ich übersehe? Ich stimme Brendan zu, dass der Kontext wichtig ist, aber ich würde mich freuen, wenn Sie mir Erklärungen geben könnten, denn meine aktuellen Bücher spielen bei diesem Thema nicht mit.

Ich möchte das festnageln, um mein Verständnis zu verbessern und weil selbst Wikipedia nicht auf diese alternative Verwendung verweist (die ich jedenfalls finden kann). Ich möchte es mir nicht mit der Verwendung des Begriffs verderben oder die Verwendung des Begriffs in Zukunft in Frage stellen, wenn ich falsch liege :-)

(Ich habe auch gesehen, wie ein Top-Smalltalker sagte, dass Smalltalk auch "untypisiert" ist, es ist also kein Einzelfall, was mich auf diese Suche gebracht hat! :-))

Answer 1

Es stimmt zwar, dass die meisten CS-Forscher, die über Typen schreiben, im Wesentlichen nur Sprachen mit syntaktisch ableitbaren Typen als typisierte Sprachen betrachten, aber es gibt viel mehr von uns, die dynamisch/latent typisierte Sprachen verwenden, die an dieser Verwendung Anstoß nehmen.

Ich bin der Meinung, dass es 3 Arten [SIC] von Sprachen gibt:

Untyped - nur der Operator bestimmt die Interpretation des Wertes - und es funktioniert im Allgemeinen mit allem. Beispiele: Assembler, BCPL

Statisch typisiert - Ausdrücke/Variablen sind mit Typen verknüpft, und dieser Typ bestimmt die Interpretation/Gültigkeit des Operators zur Kompilierzeit. Beispiele: C, Java, C++, ML, Haskell

Dynamisch typisiert - Werte sind mit Typen verknüpft, und dieser Typ bestimmt die Interpretation/Gültigkeit des Operators zur Laufzeit. Beispiele: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

Meines Wissens sind alle dynamisch typisierten Sprachen typsicher, d.h. nur gültige Operatoren können auf Werten operieren. Das gilt jedoch nicht für statisch typisierte Sprachen. Je nach der Leistungsfähigkeit des verwendeten Typsystems werden einige Operatoren nur zur Laufzeit oder gar nicht überprüft. Die meisten statisch typisierten Sprachen behandeln beispielsweise den Überlauf ganzer Zahlen nicht richtig (die Addition von zwei positiven ganzen Zahlen kann eine negative ganze Zahl ergeben), und Verweise auf Arrays, die außerhalb des zulässigen Bereichs liegen, werden entweder überhaupt nicht (C, C++) oder nur zur Laufzeit geprüft. Darüber hinaus sind einige Typsysteme so schwach, dass für eine sinnvolle Programmierung Escape Hatches (Casts in C und Familie) erforderlich sind, um den Kompilierzeittyp von Ausdrücken zu ändern.

All dies führt zu absurden Behauptungen wie der, dass C++ sicherer als Python ist, weil es (statisch typisiert) ist, während die Wahrheit ist, dass Python von Haus aus sicher ist, während man sich mit C++ ein Bein ausreißen kann.

Answer 2

Bei dieser Frage geht es um Semantik

Wenn ich Ihnen diese Daten gebe: 12 Welcher Art ist sie? Das können Sie nicht mit Sicherheit wissen. Es könnte ein Integer sein - es könnte ein Float sein - es könnte ein String sein. In diesem Sinne handelt es sich um "untypisierte" Daten.

Wenn ich Ihnen eine imaginäre Sprache an die Hand gebe, mit der Sie Operatoren wie "addieren", "subtrahieren" und "verketten" auf diese Daten und ein beliebiges anderes Stück Daten anwenden können, ist der "Typ" (für meine imaginäre Sprache) ziemlich irrelevant (Beispiel: vielleicht add(12, a) ergibt 109 das ist 12 plus den Ascii-Wert von a ).

Lassen Sie uns kurz über C sprechen. Mit C können Sie so ziemlich alles tun, was Sie mit beliebigen Daten machen wollen. Wenn Sie eine Funktion verwenden, die zwei uint s - Sie können jede beliebige Form verwenden und übergeben - und die Werte werden einfach als uint s. In diesem Sinne ist C "untypisiert" (wenn man es auf diese Weise behandelt).

Aber - und damit komme ich zu Brendans Punkt - wenn ich Ihnen sagen würde: "Mein Alter ist 12 " - dann 12 hat einen Typ - zumindest wissen wir, dass er numerisch ist. Mit Kontext alles hat einen Typ - unabhängig von der Sprache.

Deshalb habe ich eingangs gesagt, dass Ihre Frage eine Frage der Semantik ist. Was ist die Bedeutung von "untypisiert"? Ich denke, Brendan hat den Nagel auf den Kopf getroffen, als er sagte "keine statischen Typen" - denn das ist alles, was es möglicherweise bedeuten kann. Der Mensch klassifiziert die Dinge von Natur aus in Typen. Wir wissen intuitiv, dass es einen grundlegenden Unterschied zwischen einem Auto und einem Affen gibt - ohne dass uns jemals beigebracht wurde, diese Unterscheidung zu treffen.

Um auf mein Beispiel vom Anfang zurückzukommen - eine Sprache, die sich "nicht um Typen kümmert" (per se), mag es erlauben, ein "Alter" und einen "Namen" zu "addieren", ohne einen Syntaxfehler zu produzieren... aber das bedeutet nicht, dass es eine logisch einwandfreie Operation ist.

Mit Javascript kann man alle möglichen verrückten Dinge tun, ohne sie als "Fehler" zu betrachten. Das bedeutet aber nicht, dass das, was Sie tun, logisch richtig ist. Das muss der Entwickler herausfinden.

Ist ein System/eine Sprache, das/die beim Kompilieren/Erstellen/Interpretieren keine Typsicherheit erzwingt, "untypisiert" oder "dynamisch typisiert"?

Semantik.

EDIT

Ich wollte hier etwas hinzufügen, weil einige Leute anscheinend auf "ja, aber Javascript hat einige "Typen"" hängen bleiben.

In meinem Kommentar zu der Antwort eines anderen Teilnehmers sagte ich:

In Javascript könnte ich Objekte haben, die ich als "Affen" aufgebaut habe, und Objekte, die ich als "Menschen" aufgebaut habe, und einige Funktionen könnten so gestaltet sein, dass sie nur auf "Menschen" wirken, andere nur auf "Affen" und wieder andere nur auf "Dinge mit Armen". Ob der Sprache jemals gesagt wurde, dass es eine solche Kategorie von Objekten wie "Dinge mit Armen" gibt, ist für Assembly ("untyped") genauso irrelevant wie für Javascript ("dynamic"). Es ist alles eine Frage der logischen Integrität - und der einzige Fehler wäre die Verwendung von etwas, das keine Arme hat, mit dieser Methode.

Wenn Sie also der Meinung sind, dass Javascript intern einen "Begriff von Typen" hat - und damit "dynamische Typen" - und glauben, dass sich dies irgendwie "deutlich von einem nicht typisierten System" unterscheidet, sollten Sie anhand des obigen Beispiels sehen, dass jeder "Begriff von Typen", den es intern hat, wirklich irrelevant ist.

Um den gleichen Vorgang mit C# durchzuführen, bräuchte ich zum Beispiel eine Schnittstelle namens ICreatureWithArms oder etwas Ähnliches. Nicht so in Javascript - nicht so in C oder ASM.

Es ist offensichtlich, dass es keine Rolle spielt, ob Javascript überhaupt etwas von "Typen" versteht oder nicht.

Answer 3

Ich bin kein Informatiker, aber es würde mich sehr wundern, wenn "untyped" in der CS-Community (zumindest in wissenschaftlichen Publikationen) wirklich als Synonym für "dynamisch typisiert" verwendet würde, da diese beiden Begriffe imho unterschiedliche Konzepte beschreiben. Eine dynamisch typisierte Sprache hat einen Begriff von Typen und erzwingt die Typbeschränkungen zur Laufzeit (man kann z.B. in Lisp eine ganze Zahl nicht durch einen String dividieren, ohne einen Fehler zu erhalten), während eine untypisierte Sprache überhaupt keinen Begriff von Typen hat (z.B. Assembler). Sogar der Wikipedia-Artikel über Programmiersprachen (http://en.m.wikipedia.org/wiki/Programming\_language#Typed\_versus\_untyped\_languages) macht diese Unterscheidung.

Update: Vielleicht rührt die Verwirrung daher, dass manche Texte sagen, dass "Variablen in Javascript nicht typisiert sind" (was stimmt). Aber das bedeutet nicht automatisch, dass die Sprache untypisiert ist (was falsch wäre).

Answer 4

Ich stimme mit Brendan überein - der Kontext ist alles.

Meine Meinung:

Ich erinnere mich, dass ich um 2004 herum verwirrt war, weil es Streit darüber gab, ob Ruby untypisiert oder dynamisch typisiert ist. C/C++-Leute der alten Schule (zu denen ich gehörte) dachten an den Compiler und meinten, Ruby sei untypisiert.

Denken Sie daran, dass es in C keine Laufzeittypen gibt, sondern nur Adressen, und wenn der Code, der ausgeführt wird, beschließt, das, was an dieser Adresse steht, als etwas zu behandeln, was es nicht ist - ups. Das ist definitiv untypisiert und unterscheidet sich stark von dynamisch typisiert.

In dieser Welt geht es bei der "Typisierung" nur um den Compiler. C++ hatte eine "starke Typisierung", weil die Prüfungen des Compilers strenger waren. Java und C waren eher "schwach typisiert" (es gab sogar Streit darüber, ob Java stark oder schwach typisiert war). Dynamische Sprachen waren in diesem Kontinuum "untypisiert", weil sie keine Compiler-Typüberprüfung hatten.

Heutzutage sind wir praktizierenden Programmierer so sehr an dynamische Sprachen gewöhnt, dass wir unter "untyped" keine Typüberprüfung durch Compiler oder Interpreter verstehen, was wahnsinnig schwer zu debuggen wäre. Aber es gab eine Zeit, in der das nicht offensichtlich war, und in der eher theoretischen Welt der Informatik ist es vielleicht nicht einmal von Bedeutung.

In gewissem Sinne kann nichts untypisiert sein (oder zumindest fast nichts), denn man muss eine Absicht haben, einen Wert zu manipulieren, um einen sinnvollen Algorithmus zu schreiben. Dies ist die Welt der theoretischen Informatik, die sich nicht mit den Besonderheiten der Implementierung eines Compilers oder Interpreters für eine bestimmte Sprache befasst. Daher ist "untypisiert" in diesem Zusammenhang (wahrscheinlich, ich weiß es nicht) völlig bedeutungslos.