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

166

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! :-))

Peter Cooper
quelle
5
Der Missbrauch der Nomenklatur durch andere muss Ihre Gewohnheiten nicht beeinflussen - verwenden Sie einfach den (mehr) richtigen Ausdruck. Sie müssen sich natürlich des Problems beim Lesen bewusst sein.
Raphael
2
Ich habe es immer so genommen, dass die Variablen untypisiert sind, da jede Variable jede Art von Daten enthalten kann. Der Typ der Variablen kann sich dynamisch ändern .
Izkata
1
Auch (wieder mehr über natürliche Sprache als über Computersprachen) "untyped" = "single-typed" (ein Typ für alle Werte).
Philipxy

Antworten:

148

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

Andreas Rossberg
quelle
5
Es ist sehr hilfreich und kann sogar meine Lieblingsantwort sein, wenn es darum geht, etwas Geschichte zu liefern.
Peter Cooper
2
@PeterCooper Übrigens könnte es Sie interessieren zu wissen, dass ein Hauptzweig der formalen Semantik auf typisierten Lambda-Berechnungen basiert (ha a pun). zB Montague Semantik. Aber als deklaratives, nicht generatives System habe ich die Eingabe in Systemen wie Montague Semantics persönlich immer von der Eingabe in Programmiersprachen getrennt.
Know-Theorie
+1. "[dynamically typed] is a (technically misleading) name for a particular case of [untyped]"
Steve
1
Dies ist in Bezug auf die Geschichte der "Typen" nicht ganz richtig. Sie sind sogar älter als die Arbeit der Kirche am Lambda-Kalkül. Russell verwendete Typen, um Paradoxien bei der Konstruktion der Mengenlehre zu vermeiden.
Sam Tobin-Hochstadt
1
@ SamTobin-Hochstadt, ja, richtig. Ich habe nur über den Teil der Geschichte gesprochen, der sich direkt auf die Grundlagen von PLs bezieht. Ich werde klären.
Andreas Rossberg
68

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.

Norman Ramsey
quelle
12
Ich denke, es gibt ein breiteres Problem in CS (einschließlich der Wissenschaft), dass Namen ohne strenge Definition verwendet werden. Dies steht in krassem Gegensatz zu Mathematik und (den meisten?) Wissenschaften. Eine große Anzahl von Streitigkeiten (z. B. über OOP) scheint auf diesen Mangel an richtigen Definitionen zurückzuführen zu sein. Sehr nervig.
Konrad Rudolph
2
@KonradRudolph: Ich frage mich, ob anstelle der Streitigkeiten, die sich aus dem Fehlen geeigneter Definitionen ergeben, das Fehlen geeigneter Definitionen teilweise aus den Streitigkeiten resultieren könnte. Einige Begriffe erhalten eine emotionale Wertigkeit (sei es positiv oder negativ), und Unterstützer bestimmter Sprachen definieren diese Begriffe dann so, dass sie ihre Sprachen einschließen oder ausschließen (und ihre bevorzugten "feindlichen" Sprachen ausschließen oder einschließen). Für ein mathematisches Beispiel - wenn es immer noch Leute gäbe, die die Theorie der naiven Mengen gegenüber der Theorie der axiomatischen Mengen unterstützen, können Sie sicher sein, dass sie ihre eigenen Ansichten "Theorie der axiomatischen Mengen" nennen und "naiv
ruakh
4
@Norman, ich bin überrascht, dass Sie es Missbrauch nennen - wie Sie wissen, ist der Begriff des Typs um Jahrzehnte älter als sogenannte dynamisch typisierte Sprachen, und was der letztere "Typ" nennt, hat wenig mit dem ersteren zu tun. Ich denke, es ist fair zu sagen, dass der Missbrauch umgekehrt ist.
Andreas Rossberg
5
@Norman: Wenn Sie der Meinung sind, dass die Informationen auf Wikipedia von schlechter Qualität sind, wenn es um Programmiersprachen und insbesondere Typsysteme geht, lassen Sie sie nicht in Ruhe und verbessern Sie sie. (nur Trolling)
Gyom
3
@Gyom Ich habe es aufgegeben, Wikipedia zu verbessern, als mir klar wurde, dass der Wikipedian-Prozess Veränderungen belohnt , nicht Fachwissen . Meine Zeit wird besser damit verbracht, SO zu verbessern :-)
Norman Ramsey
43

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.

Ruakh
quelle
2
Beeindruckend. Schockierend. Danke für die Information.
Afrischke
Genau die Art von Zitat, nach der ich gesucht habe, danke! Ein bisschen macht mir Angst, dass das Buch bei Amazon durchschnittlich 2 Sterne hat, obwohl mehr Zitate begrüßt werden, aber dies ist ein großartiger Anfang.
Peter Cooper
@PeterCooper: Ich habe meine Antwort bearbeitet, um weitere Zitate hinzuzufügen. Sie umgehen das Problem der Amazon-Bewertungen, indem sie aus veröffentlichten Zeitungen stammen: Soweit ich weiß, sind sie möglicherweise immer noch Müll, aber zumindest müssen wir uns keine Sorgen machen, dass Amazon es uns sagt. :-P
Ruakh
Es ist unlogisch, "untypisiert" mit "dynamisch typisiert" zu verwechseln. Entwickler sollten nicht unlogisch sein.
Rotman
10

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.

Adam Mihalcin
quelle
AFAIK Die gleichen Probleme gelten für einen Lambda-Ausdruck. Während Sie möglicherweise eine Funktion für "meine aktuelle Position" an eine Funktion übergeben können, die "meine Entfernung vom Ziel" berechnet, können Sie dieselbe Funktion "meine aktuelle Position" auch an eine Funktion übergeben, die berechnet, dass "sind Puffs plus mit Vicks besser" für deine Nase ". Nur weil Sie es können, heißt das nicht, dass es gültig ist - wie es bei jedem dynamischen System der Fall ist.
Steve
5
@Steve Garbage in Garbage Out ist jedoch für jede Programmiersprache der Fall und hat nichts mit dem Begriff der Typen zu tun. Selbst in einer stark typisierten Sprache wie OCaml oder SML kann ich den Nordpol in eine Funktion überführen, die "meine Entfernung vom Ziel" berechnet (und nein, meine aktuelle Position ist nicht der Nordpol).
Adam Mihalcin
Ich wollte nur hinzufügen, für Leute außerhalb der Wissenschaft: Dinge wie Versammlung würden auch als untypisiert gelten.
CoffeeTableEspresso
6

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.


quelle
5
Ich denke, der Hauptunterschied besteht nicht zwischen Werten und Variablen , sondern zwischen Werten und Ausdrücken : In einer statisch typisierten Sprache haben Ausdrücke Typen, während in einer dynamisch typisierten Sprache nur Werte dies tun. (Variablennamen sind natürlich eine Art von Ausdruck.)
Ruakh
4

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.

Steve
quelle
4
-1. Die Frage fragt, ob ein bestimmtes Wort in bestimmten Kreisen mit einer bestimmten Bedeutung verwendet wird, und Ihre Antwort lautet, zu erklären, dass es sich um eine Frage handelt, ob das Wort diese Bedeutung hat. Wirklich, ich denke, Sie haben bewundernswerte Arbeit geleistet und alles erklärt, was das OP bereits zu wissen scheint, ohne etwas Neues hinzuzufügen. . .
Ruakh
Es scheint, dass mehrere Fragen notwendig sind, um eine Definition zu erstellen, vielleicht? Die der Typdurchsetzung (statisch oder dynamisch) und das Vorhandensein definierter Typen. JavaScript hat also Typen, kann aber als "untypisiert" betrachtet werden, da die Typgültigkeit vor dem Ausführen einer Operation nicht überprüft wird.
Peter Cooper
@ruakh - Ich kann deine Perspektive verstehen. Das OP fragte jedoch: is there something deeper to this that I am missingund ich denke, dass das Unverständnis, dass es sich um ein semantisches Problem handelt, die tiefere Sache ist - also habe ich mein Bestes getan, um alles zu tun, was ich konnte.
Steve
@PeterCooper - Sehen Sie sich meine Bearbeitung an und sagen Sie mir, ob dies etwas für Sie bedeutet (da Sie dies JavaScript has typesin Ihrer Antwort gesagt haben ).
Steve
2
"Es ist klar, ob Javascript überhaupt ein Verständnis für" Typen "hat oder nicht." Nicht wahr. Wie ich in meiner Antwort angedeutet habe, können Sie 12 unabhängig vom Kontext nicht als Funktion behandeln. Da JavaScript einen Funktionstyp hat (oder, abhängig von Ihrer Sichtweise, mehrere Funktionstypen), ist dies eine wichtige Unterscheidung.
Adam Mihalcin
4

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.

Dave Mason
quelle
Upvoted. Ich bin froh zu wissen, dass "alle dynamisch typisierten Sprachen typsicher sind". "Aber das Gleiche gilt nicht für statisch typisierte Sprachen". Meinen Sie damit, dass alle oder die meisten statisch typisierten Sprachen typunsicher sind?
Tim
Upvoted. (1) Ich bin froh zu wissen, dass "alle dynamisch typisierten Sprachen typsicher sind", aber Javascript ist dynamisch typisiert und schwach typisiert, siehe stackoverflow.com/questions/964910/… . (2) "Aber das Gleiche gilt nicht für statisch typisierte Sprachen". Meinen Sie damit, dass alle oder die meisten statisch typisierten Sprachen typunsicher sind?
Tim
Nur sehr wenige Sprachen sind statisch typsicher, wenn Sie die Möglichkeit eines Umwandlungsfehlers, eines Indexüberschreitens oder von Nullzeigerausnahmen als Typen angeben (und die meisten Benutzer geben mindestens einen Umwandlungsfehler als Typfehler an). Rust ist beispielsweise statisch typsicherer als Java, da Sie keinen Nullzeiger haben können. Java ist dynamisch typsicher, da Sie Ausnahmen für illegale Vorgänge erhalten und alles angegeben ist (mit Ausnahme nativer Methoden). Ebenso Rust (mit Ausnahme des so genannten "unsicheren" Codes).
Dave Mason
C ++, C sind jedoch nicht einmal dynamisch typsicher, da es "nicht spezifizierte" Teile der Sprache gibt. Wenn Sie eine der "nicht spezifizierten" Operationen ausführen, ist buchstäblich alles eine rechtliche Antwort der Sprache (Werte von nicht verwandten Variablen könnten ändern, Viren könnten Ihr Programm infizieren, das Programm könnte auf Ihre Festplatte schreiben und dann abstürzen, das Programm könnte sogar das tun, was Sie erwartet haben :-).
Dave Mason
@ DaveMason: Undefiniert. Es gibt einen enormen Unterschied zwischen "nicht spezifiziert" und "undefiniert" in C. Undefiniertes Verhalten ist im Grunde genommen eine illegale Sache, die das tun kann, was Sie beschrieben haben - während nicht spezifiziert im Wesentlichen "implementierungsdefiniert" bedeutet, wenn die Implementierung es nicht dokumentieren muss "(Es gibt hier und da einige Nuancen, dies ist also eine Vereinfachung). Das Aufrufen von nicht spezifiziertem Verhalten ist daher vollkommen legal (tatsächlich tut man dies immer dann, wenn man beispielsweise einen Funktionsaufruf schreibt).
Tim am
2

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

afrischke
quelle
1
Assembler hat eine sehr schwache Vorstellung von Typen. Zumindest in x86 ist alles eine Ganzzahl, aber einige Ganzzahlen haben andere Größen als andere. Das ist noch bevor Sie sich mit MMX, x87 und anderen Erweiterungen der ursprünglichen x86-Spezifikation befassen.
Adam Mihalcin
Ich muss nicht zustimmen. 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.
Steve
@ Adam Mihalcin Stimmt. [Makro] Assemblersprachen können natürlich auch verschiedene Arten von Typen haben. (Schauen Sie sich zum Beispiel die "Typed Assembly Language" an.) Ich denke jedoch immer noch, dass mein Punkt zutrifft.
Afrischke
3
@Steve Ich bin mir nicht sicher, ob ich dir folgen kann. Das OP fragte, ob in CS-Kreisen nicht zwischen "dynamisch typisiert" und "untypisiert" unterschieden wird. Dies hat nichts damit zu tun, ob Sie glauben, dass es praktisch keinen Unterschied gibt, wie Javascript und Assembly die Bits im Speicher behandeln. Nach dem, was ich gelesen habe (und ich musste dies speziell nachschlagen, da ich kein Javascript-Programmierer bin): Der ECMAScript / Javascript-Standard definiert 6 Datentypen (Boolean, String, Undefined, Number, Null und Object) und zu jedem Zeitpunkt Mit der Zeit ist ein Wert von einem konkreten Typ ...
Afrischke
1
... Nun, dies ist ein Konzept, das (die meisten) Assemblersprachen nicht haben (alles, was es gibt, sind Bits und Bytes). Imho markiert dies eine klare Unterscheidung zwischen Javascript und Assemblierung.
Afrischke
1

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.

Dan Yoder
quelle