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

Ich lese ein Dia-Deck mit der Aufschrift "JavaScript ist untypisiert". Dies widersprach dem, was ich für wahr hielt, und so begann ich zu graben, um mehr zu lernen.

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

Also fragte ich Brendan Eich, den Schöpfer von JavaScript, und er sagte:

Akademische Typen verwenden "untypisiert", um "keine statischen Typen" zu bedeuten. 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 dies gültig?) Oder fehlt mir etwas Tieferes? Ich stimme Brendan zu, dass der Kontext wichtig ist, aber alle Zitate von Erklärungen wären großartig, da meine aktuellen "Gehe zu" -Bücher zu diesem Thema keine Rolle spielen.

Ich möchte das festhalten, damit ich mein Verständnis verbessern kann und weil selbst Wikipedia nicht auf diese alternative Verwendung verweist (die ich sowieso finden kann). Ich möchte mich nicht damit herumschlagen, den Begriff zu verwenden oder die Verwendung des Begriffs in Zukunft in Frage zu stellen, wenn ich falsch liege :-)

(Ich habe auch einen Top-Smalltalker gesehen, der sagte, Smalltalk sei auch "untypisiert", also ist es kein Einzelstück, was mich auf diese Suche gebracht hat! :-))

Ja, dies ist in der akademischen Literatur Standard. Um es zu verstehen, ist es hilfreich zu wissen, dass der Begriff "Typ" in den 1930er Jahren im Kontext der Lambda-Rechnung erfunden wurde (sogar noch früher im Kontext der Mengenlehre). Seitdem ist ein ganzer Zweig der Rechenlogik entstanden, der als "Typentheorie" bekannt ist. Die Programmiersprachtheorie basiert auf diesen Grundlagen. Und in all diesen mathematischen Kontexten hat "Typ" eine bestimmte, gut etablierte Bedeutung.

Die Terminologie "Dynamische Typisierung" wurde viel später erfunden - und ist angesichts der üblichen mathematischen Verwendung des Wortes "Typ" ein Widerspruch.

Hier ist zum Beispiel die Definition des "Typensystems", die Benjamin Pierce in seinem Standardlehrbuch Typen und Programmiersprachen verwendet :

Ein Typsystem ist eine nachvollziehbare syntaktische Methode, um das Fehlen bestimmter Programmverhalten zu beweisen, indem Phrasen nach den Arten von Werten klassifiziert werden, die sie berechnen.

Er bemerkt auch:

Das Wort "statisch" wird manchmal explizit hinzugefügt - wir sprechen beispielsweise von einer "statisch typisierten Programmiersprache" -, um die Arten von Analysen zur Kompilierungszeit, die wir hier betrachten, von der dynamischen oder latenten Typisierung zu unterscheiden, die in Sprachen wie z Schema (Sussman und Steele, 1975; Kelsey, Clinger und Rees, 1998; Dybvig, 1996), bei dem Laufzeit-Tag-Tags verwendet werden, um verschiedene Arten von Strukturen im Heap zu unterscheiden. Begriffe wie "dynamisch typisiert" sind wohl falsche Bezeichnungen und sollten wahrscheinlich durch "dynamisch überprüft" ersetzt werden, aber die Verwendung ist Standard.

Die meisten Leute, die vor Ort arbeiten, scheinen diesen Standpunkt zu teilen.

Beachten Sie, dass dies nicht bedeutet, dass "untypisiert" und "dynamisch typisiert" Synonyme sind. Vielmehr ist letzteres ein (technisch irreführender) Name für einen bestimmten Fall des ersteren.

PS: Und FWIW, ich bin sowohl ein akademischer Forscher in Typensystemen als auch ein nicht-akademischer Implementierer von JavaScript, also muss ich mit dem Schisma leben. :) :)

Ich bin ein akademischer Informatiker, der sich auf Programmiersprachen spezialisiert hat, und ja, das Wort "untypisiert" wird auf diese Weise häufig (falsch) verwendet. Es wäre schön, das Wort für die Verwendung mit Sprachen zu reservieren, die keine dynamischen Typ-Tags enthalten, wie Forth und Assembly-Code. Diese Sprachen werden jedoch selten verwendet und noch seltener studiert, und es ist viel einfacher, "untypisiert" zu sagen. als "dynamisch getippt".

Bob Harper sagt gern, dass Sprachen wie Scheme, Javascript usw. als typisierte Sprachen mit nur einem Typ betrachtet werden sollten: value. Ich lehne mich an diese Ansicht an, da es möglich ist, eine konsistente Weltanschauung mit nur einem Typ Formalismus zu konstruieren.

PS In der reinen Lambda-Rechnung sind die einzigen "Werte" Terme in normaler Form und die einzigen geschlossenen Terme in normaler Form sind Funktionen. Aber die meisten Wissenschaftler, die den Lambda-Kalkül verwenden, fügen Basistypen und Konstanten hinzu, und dann fügen Sie entweder ein statisches Typsystem für Lambda hinzu oder Sie kehren direkt zu dynamischen Typ-Tags zurück.

PPS Zum Originalplakat: Wenn es um Programmiersprachen und insbesondere Typensysteme geht, sind die Informationen auf Wikipedia von schlechter Qualität. Vertraue ihm nicht.

Ich habe mich damit befasst und festgestellt, dass die Antwort auf Ihre Frage einfach und überraschend "Ja" lautet: Akademische CS-Typen oder zumindest einige von ihnen verwenden "untypisiert", um "dynamisch typisiert" zu bedeuten. In Programmiersprachen: Prinzipien und Praktiken , dritte Ausgabe (von Kenneth C. Louden und Kenneth A. Lambert, veröffentlicht 2012) heißt es beispielsweise:

Sprachen ohne statische Typsysteme werden normalerweise als untypisierte Sprachen (oder dynamisch typisierte Sprachen ) bezeichnet. Zu diesen Sprachen gehören Scheme und andere Dialekte von Lisp, Smalltalk und die meisten Skriptsprachen wie Perl, Python und Ruby. Beachten Sie jedoch, dass eine untypisierte Sprache nicht unbedingt zulässt, dass Programme Daten beschädigen. Dies bedeutet lediglich, dass alle Sicherheitsüberprüfungen zur Ausführungszeit durchgeführt werden. […]

[ link ] (Hinweis: Fettdruck im Original) und verwendet "untyped" auf diese Weise.

Ich finde das überraschend (aus den gleichen Gründen, die afrischke und Adam Mihalcin geben), aber da sind Sie. :-)

Zum Hinzufügen bearbeitet: Weitere Beispiele finden Sie "untyped languages"in der Google Buchsuche. Beispielsweise:

[…] Dies ist der primäre Mechanismus zum Ausblenden von Informationen in vielen untypisierten Sprachen. Zum Beispiel verwendet das PLT-Schema [4] generative structs, […]

- Jacob Matthews und Amal Ahmed, 2008 [ Link ]

[…] Präsentieren wir eine Bindungszeitanalyse für eine untypisierte funktionale Sprache […]. […] Es wurde implementiert und wird in einem Teilevaluator für einen nebenwirkungsfreien Dialekt des Schemas verwendet. Die Analyse ist jedoch allgemein genug, um für nicht streng typisierte funktionale Sprachen wie Haskell gültig zu sein. […]

- Charles Consel, 1990 [ Link ]

Übrigens habe ich nach Durchsicht dieser Suchergebnisse den Eindruck, dass ein Forscher, der über eine "untypisierte" Funktionssprache schreibt, diese höchstwahrscheinlich als "untypisiert" im gleichen Sinne wie das untypisierte Lambda betrachtet Kalkül, den Adam Mihalcin erwähnt. Zumindest erwähnen mehrere Forscher das Schema und den Lambda-Kalkül in einem Atemzug.

Was die Suche natürlich nicht sagt, ist, ob es Forscher gibt, die diese Identifizierung ablehnen und diese Sprachen nicht als "untypisiert" betrachten. Nun, ich habe folgendes gefunden:

Dann wurde mir klar, dass es wirklich keine Zirkularität gibt, weil dynamisch typisierte Sprachen keine untypisierten Sprachen sind - es ist nur so, dass die Typen normalerweise nicht sofort aus dem Programmtext ersichtlich sind.

- jemand (ich kann nicht sagen wer), 1998 [ Link ]

Aber offensichtlich hätten die meisten Leute, die diese Identifikation ablehnen, nicht das Bedürfnis, dies ausdrücklich zu sagen.

Untypisiert und dynamisch typisiert sind absolut keine Synonyme. Die Sprache, die am häufigsten als "untypisiert" bezeichnet wird, ist der Lambda-Kalkül, der eigentlich eine einheitliche Sprache ist - alles ist eine Funktion, sodass wir statisch beweisen können, dass der Typ von allem die Funktion ist. Eine dynamisch typisierte Sprache hat mehrere Typen, bietet dem Compiler jedoch keine Möglichkeit, diese statisch zu überprüfen, sodass der Compiler Laufzeitprüfungen für Variablentypen einfügen muss.

Dann ist JavaScript eine dynamisch typisierte Sprache: Es ist möglich, Programme in JavaScript so zu schreiben, dass eine Variable xeine Zahl oder eine Funktion oder eine Zeichenfolge oder etwas anderes sein kann (und zu bestimmen, welche das Problem des Anhaltens oder eine andere lösen müsste schweres mathematisches Problem), so dass Sie xauf ein Argument anwenden können und der Browser zur Laufzeit überprüfen muss, ob es sich xum eine Funktion handelt.

Beide Aussagen sind richtig, je nachdem, ob es sich um Werte oder Variablen handelt. JavaScript-Variablen sind untypisiert, JavaScript-Werte haben Typen und Variablen können zur Laufzeit über jeden Werttyp reichen (dh 'dynamisch').

In JavaScript und vielen anderen Sprachen tragen Werte und keine Variablen Typen. Alle Variablen können sich über alle Arten von Werten erstrecken und können als "dynamisch typisiert" oder "untypisiert" betrachtet werden - aus der Perspektive der Typprüfung sind eine Variable ohne / einen nicht erkennbaren Typ und eine Variable, die einen beliebigen Typ annehmen kann, logisch und praktisch gleichwertig . Wenn Typentheoretiker über Sprachen und Typen sprechen, sprechen sie normalerweise darüber - Variablen, die Typen tragen -, weil sie daran interessiert sind, Typprüfer und Compiler usw. zu schreiben, die mit Programmtext (dh Variablen) und nicht mit einem laufenden Programm im Speicher arbeiten (dh Werte).

Im Gegensatz dazu tragen Variablen in anderen Sprachen wie C Typen, Werte jedoch nicht. In Sprachen wie Java tragen Variablen und Werte beide Typen. In C ++ tragen einige Werte (diejenigen mit virtuellen Funktionen) Typen und andere nicht. In einigen Sprachen ist es sogar möglich, dass Werte Typen ändern, obwohl dies normalerweise als schlechtes Design angesehen wird.

Diese Frage dreht sich alles um Semantik

Wenn ich Ihnen diese Daten gebe: 12Was ist der Typ? Sie haben keine Möglichkeit, sicher zu wissen. Könnte eine ganze Zahl sein - könnte ein Float sein - könnte eine Zeichenfolge sein. In diesem Sinne handelt es sich um sehr "untypisierte" Daten.

Wenn ich Ihnen eine imaginäre Sprache gebe, mit der Sie Operatoren wie "Addieren", "Subtrahieren" und "Verketten" für diese Daten und einige andere beliebige Daten verwenden können, ist der "Typ" (für meine imaginäre Sprache) etwas irrelevant (Beispiel) : vielleicht add(12, a)ergibt sich 109das 12plus dem ASCII-Wert von a).

Reden wir eine Sekunde über C. Mit C können Sie so ziemlich alles tun, was Sie wollen, mit beliebigen Daten. Wenn Sie eine Funktion verwenden, die zwei uintSekunden benötigt - Sie können alles, was Sie wollen, umwandeln und übergeben -, werden die Werte einfach als uints interpretiert . In diesem Sinne ist C "untypisiert" (wenn Sie es so behandeln).

Wenn ich Ihnen jedoch sage, dass "Mein Alter ist 12" - und dann 12einen Typ hat - wissen wir zumindest, dass er numerisch ist. Mit Kontext hat alles einen Typ - unabhängig von der Sprache.

Deshalb habe ich am Anfang gesagt - Ihre Frage ist eine der Semantik. Was bedeutet "untypisiert"? Ich denke, Brendan hat den Nagel auf den Kopf getroffen, als er "keine statischen Typen" sagte - denn das ist alles, was es möglicherweise bedeuten kann. Menschen klassifizieren Dinge natürlich in Typen. Wir wissen intuitiv, dass es zwischen einem Auto und einem Affen etwas grundlegend anderes gibt - ohne jemals gelernt zu haben, diese Unterscheidungen zu treffen.

Zurück zu meinem Beispiel am Anfang - in einer Sprache, die sich "nicht um Typen kümmert" (per se), können Sie möglicherweise ein "Alter" und einen "Namen" "hinzufügen", ohne einen Syntaxfehler zu erzeugen ... aber das bedeutet nicht, dass es sich um eine logisch einwandfreie Operation handelt.

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

Ist ein System / eine Sprache, die zum Zeitpunkt der Kompilierung / Erstellung / Interpretation keine Typensicherheit erzwingt, "untypisiert" oder "dynamisch typisiert"?

Semantik.

BEARBEITEN

Ich wollte hier etwas hinzufügen, weil einige Leute anscheinend mit "Ja, aber Javascript hat einige" Typen "" beschäftigt sind.

In meinem Kommentar zur Antwort eines anderen 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 mit "Menschen" funktionieren, andere nur mit "Affen" und noch andere nur auf "Things With Arms". Ob der Sprache jemals gesagt wurde, dass es eine solche Kategorie von Objekten wie "Dinge mit Waffen" gibt oder nicht, ist für die Montage ("untypisiert") ebenso irrelevant wie für Javascript ("dynamisch"). Es ist alles eine Frage der logischen Integrität - und der einzige Fehler wäre, etwas zu verwenden, das mit dieser Methode keine Waffen hatte.

Wenn Sie also davon ausgehen, dass Javascript intern einen "Begriff von Typen" hat - und damit "dynamische Typen" - und denken, dass dies irgendwie "deutlich anders ist als ein untypisiertes System", sollten Sie anhand des obigen Beispiels erkennen, dass jeder "Begriff von" Typen "es hat intern ist wirklich irrelevant.

Um dieselbe Operation beispielsweise mit C # auszuführen, BRAUCHE ich eine Schnittstelle namens ICreatureWithArmsoder etwas Ähnliches. Nicht so in Javascript - nicht so in C oder ASM.

Es ist klar, ob Javascript überhaupt ein Verständnis für "Typen" hat oder nicht.

Während es stimmt, dass die meisten CS-Forscher, die über Typen schreiben, im Wesentlichen nur Sprachen mit syntaktisch ableitbaren Typen als typisierte Sprachen betrachten, verwenden viel mehr von uns dynamisch / latent typisierte Sprachen, die sich über diese Verwendung lustig machen.

Ich betrachte es als 3 Arten [SIC] von Sprachen:

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

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

Dynamisch typisiert - Werten sind Typen zugeordnet, und dieser Typ bestimmt die Interpretation / Gültigkeit des Operators zur Laufzeit. Beispiele: LISP, Schema, Smalltalk, Ruby, Python, Javascript

Meines Wissens sind alle dynamisch typisierten Sprachen typsicher - dh nur gültige Operatoren können mit Werten arbeiten. Gleiches gilt jedoch nicht für statisch typisierte Sprachen. Abhängig von der Leistung des verwendeten Typsystems werden einige Bediener möglicherweise nur zur Laufzeit oder überhaupt nicht überprüft. Beispielsweise behandeln die meisten statisch typisierten Sprachen den Ganzzahlüberlauf nicht richtig (das Hinzufügen von 2 positiven Ganzzahlen kann zu einer negativen Ganzzahl führen), und nicht gebundene Array-Referenzen werden entweder überhaupt nicht (C, C ++) oder nur bei geprüft Laufzeit. Darüber hinaus sind einige Typsysteme so schwach, dass für eine nützliche Programmierung Escape-Schraffuren (Casts in C und Familie) erforderlich sind, um den Typ der Ausdrücke zur Kompilierungszeit zu ändern.

All dies führt zu absurden Behauptungen, wie zum Beispiel, dass C ++ sicherer ist als Python, weil es (statisch typisiert) ist, während die Wahrheit ist, dass Python an sich sicher ist, während Sie Ihr Bein mit C ++ abschießen können.

Ich bin kein Informatiker, aber ich wäre ziemlich überrascht, wenn "untypisiert" wirklich als Synonym für "dynamisch typisiert" in der CS-Community (zumindest in wissenschaftlichen Veröffentlichungen) verwendet würde, da imho diese beiden Begriffe unterschiedliche Konzepte beschreiben. Eine dynamisch typisierte Sprache hat einen Typbegriff und erzwingt die Typbeschränkungen zur Laufzeit (Sie können beispielsweise eine Ganzzahl in Lisp nicht durch eine Zeichenfolge teilen, ohne einen Fehler zu erhalten), während eine untypisierte Sprache keinen Typbegriff hat alle (zB Assembler). Sogar der Wikipedia-Artikel über Programmiersprachen (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) macht diese Unterscheidung.

Update: Vielleicht liegt die Verwirrung daran, dass einige Texte etwas in dem Maße aussagen, dass "Variablen nicht in Javascript eingegeben werden" (was wahr ist). Dies bedeutet jedoch nicht automatisch, dass die Sprache untypisiert ist (was falsch wäre).

Stimmen Sie mit Brendan überein - Kontext ist alles.

Meine Einstellung:

Ich erinnere mich, dass ich um 2004 verwirrt war, weil es Streit darüber gab, ob Ruby untypisiert oder dynamisch typisiert war. C / C ++ - Leute der alten Schule (von denen ich einer war) dachten über den Compiler nach und sagten, Ruby sei untypisiert.

Denken Sie daran, dass es in C keine Laufzeittypen gibt, sondern nur Adressen. Wenn der ausgeführte Code beschließt, alles, was sich an dieser Adresse befindet, als etwas zu behandeln, das es nicht ist, whoops. Das ist definitiv untypisiert und unterscheidet sich sehr von dynamisch getippt.

In dieser Welt dreht sich beim "Tippen" alles um den Compiler. C ++ hatte "starke Typisierung", weil die Überprüfungen des Compilers strenger waren. Java und C waren eher "schwach typisiert" (es gab sogar Argumente darüber, ob Java stark oder schwach typisiert war). Dynamische Sprachen waren in diesem Kontinuum "untypisiert", da sie keine Überprüfung des Compilertyps hatten.

Heutzutage sind wir für praktizierende Programmierer so an dynamische Sprachen gewöhnt, dass wir offensichtlich an untypisiert denken, was bedeutet, dass weder Compiler noch Interpreter die Typprüfung überprüfen, was wahnsinnig schwer zu debuggen wäre. Aber es gab eine Zeit, in der dies nicht offensichtlich war und in der theoretischeren Welt von CS möglicherweise nicht einmal von Bedeutung ist.

In gewissem Sinne kann nichts untypisiert werden (oder sowieso fast nichts), da Sie die Absicht haben müssen, einen Wert zu manipulieren, um einen aussagekräftigen Algorithmus zu schreiben. Dies ist die Welt der theoretischen CS, in der es nicht darum geht, wie ein Compiler oder Interpreter für eine bestimmte Sprache implementiert wird. "Untypisiert" ist in diesem Zusammenhang also (wahrscheinlich weiß ich nicht) völlig bedeutungslos.