Означает ли «нетипизированный» также «динамически типизированный» в академическом мире CS?


165

Я читаю слайд-колоду, в которой говорится: «JavaScript нетипизирован». Это противоречило тому, что я считал правдой, поэтому я начал копать, чтобы попытаться узнать больше.

Каждый ответ на вопрос Является ли JavaScript нетипизированным языком? говорит, что JavaScript не нетипизированным и предлагает примеры различных форм статической, динамической, сильной и слабой типизации, с которыми я знаком и доволен ... так что это был не тот путь.

Поэтому я спросил Брендана Эйха, создателя JavaScript, и он сказал:

академические типы используют «нетипизированный» для обозначения «нет статических типов». они достаточно умны, чтобы видеть, что значения имеют типы (дух!). контекст имеет значение.

Используют ли академически ориентированные специалисты по информатике «нетипизированный» как синоним «динамически типизированного» (и так ли это?) Или есть что-то более глубокое в этом, чего мне не хватает? Я согласен с Бренданом в том, что контекст важен, но любые цитаты с объяснениями были бы хороши, так как мои нынешние книги "Перейти к" не играют в эту тему

Я хочу закрепить это, чтобы улучшить свое понимание, и потому что даже Википедия не ссылается на это альтернативное использование (которое я могу найти в любом случае). Я не хочу, чтобы в будущем я использовал этот термин или ставил под сомнение использование этого термина, если я ошибаюсь :-)

(Я также видел, как один из ведущих Smalltalker сказал, что Smalltalk тоже «нетипизирован», так что это не единственная вещь, которая привела меня в этот квест! :-))


5
Злоупотребление другими номенклатурой не должно формировать ваши привычки - просто используйте (более) правильную фразу. Вы должны знать о проблеме для чтения, очевидно.
Рафаэль

2
Я всегда считал, что переменные нетипизированы, потому что любая переменная может содержать данные любого типа. Тип того, что находится в переменной, может изменяться динамически .
Изката


1
Также (опять же говоря больше о естественном языке, чем о компьютерных языках) "нетипизированный" = "однотипный" (один тип для всех значений).
Филипп

Ответы:


147

Да, это стандартная практика в академической литературе. Чтобы понять это, полезно знать, что понятие «тип» было изобретено в 1930-х годах в контексте лямбда-исчисления (фактически, даже раньше, в контексте теории множеств). С тех пор возникла целая ветвь вычислительной логики, известная как «теория типов». Теория языка программирования основана на этих основах. И во всех этих математических контекстах «тип» имеет конкретное, устоявшееся значение.

Терминология «динамическая типизация» была придумана гораздо позже - и это противоречит в терминах общепринятого математического использования слова «тип».

Например, вот определение «системы типов», которое Бенджамин Пирс использует в своем стандартном учебнике « Типы и языки программирования» :

Система типов - это гибкий синтаксический метод для доказательства отсутствия определенных программных поведений путем классификации фраз в соответствии с типами значений, которые они вычисляют.

Он также отмечает:

Слово «статический» иногда добавляется явно - например, мы говорим о «статически типизированном языке программирования», - чтобы отличать виды анализа во время компиляции, которые мы здесь рассматриваем, от динамической или скрытой типизации, встречающейся в таких языках, как Схема (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996), где теги типа времени выполнения используются для различения различных типов структур в куче. Такие термины, как «динамически типизированный», возможно, являются неправильными и, вероятно, должны быть заменены на «динамически проверенные», но использование является стандартным.

Кажется, большинство людей, работающих в этой области, разделяют эту точку зрения.

Обратите внимание, что это не означает, что «нетипизированный» и «динамически типизированный» являются синонимами. Скорее, последнее является (технически вводящим в заблуждение) именем для конкретного случая первого.

PS: И FWIW, я являюсь как академическим исследователем в системах типов, так и неакадемическим разработчиком JavaScript, поэтому мне приходится жить с расколом. :)


5
Это является очень полезным и может быть даже мой любимый ответ с точки зрения обеспечения некоторую историю к нему.
Питер Купер

2
@PeterCooper, кстати, вам может быть интересно узнать, что одна важная ветвь формальной семантики основана на типизированном лямбда-исчислении; например, семантика Монтегю. Но как декларативную, не порождающую систему я лично всегда разделял типизацию в таких системах, как семантика Монтегю, от типизации на языках программирования.
Knowtheory

+1. "[dynamically typed] is a (technically misleading) name for a particular case of [untyped]"
Стив

1
Это не совсем верно в отношении истории "типов". Они даже старше, чем работы Черча по лямбда-исчислению. Рассел использовал типы, чтобы избежать парадоксов при построении теории множеств.
Сэм Тобин-Хохштадт

1
@ SamTobin-Hochstadt, да, верно. Я говорил только о той части истории, которая имеет непосредственное отношение к основам ЛП. Я уточню.
Андреас Россберг

68

Я академический компьютерщик, специализирующийся на языках программирования, и да, слово «нетипизированный» часто (неправильно) используется таким образом. Было бы неплохо зарезервировать слово для использования с языками, в которых нет динамических тегов типа, таких как Forth и ассемблерный код, но эти языки используются редко и еще реже изучаются, и гораздо проще сказать «нетипизированный» чем «динамически типизированный».

Боб Харпер любит говорить, что такие языки, как Scheme, Javascript и т. Д., Следует рассматривать как типизированные языки только с одним типом: значением. Я склоняюсь к этой точке зрения, поскольку она позволяет построить согласованное мировоззрение, используя только один тип формализма.

PS В чистом лямбда-исчислении единственными «значениями» являются слагаемые в нормальной форме, а единственными замкнутыми членами в нормальной форме являются функции. Но большинство ученых, которые используют лямбда-исчисление, добавляют базовые типы и константы, и тогда вы либо включаете статическую систему типов для лямбда-выражений, либо возвращаетесь к динамическим тегам типов.

PPS К оригинальному постеру: когда речь заходит о языках программирования и особенно о системах типов, информация в Википедии низкого качества. Не верь этому.


12
Я думаю, что в CS (включая научные круги) существует более широкая проблема, заключающаяся в том, что имена используются без строгого определения. Это резко контрастирует с математикой и (большинством?) Науками. Огромное количество споров (например, по поводу ООП), похоже, связано с отсутствием надлежащих определений. Очень надоедливый.
Конрад Рудольф

2
@KonradRudolph: Интересно, а не споры, возникающие из-за отсутствия правильных определений, могут возникать отчасти из-за отсутствия правильных определений. Некоторые термины приобретают эмоциональную валентность (будь то позитивная или негативная), и сторонники определенных языков затем определяют эти термины способами, которые включают или исключают их языки (и исключают или включают их любимые «вражеские» языки). Для математического примера - если бы все еще были люди, поддерживающие наивную теорию множеств
вместо

4
@ Норман, я удивлен, что вы называете это неправильным использованием - как вы знаете, понятие типа предшествует так называемым динамически типизированным языкам на десятилетия, и то, что последний называет «типом», имеет мало общего с первым. Поэтому я думаю, что было бы справедливо сказать, что неправильное использование является наоборот.
Андреас Россберг

5
@ Норман: Когда дело доходит до языков программирования и особенно систем типов, если вы чувствуете, что информация в Википедии плохого качества, не оставляйте ее в покое и улучшайте ее. (только троллинг)
Gyom

3
@ Gyom Я бросил совершенствовать Википедию в тот день, когда понял, что процесс Википедии поощряет изменения , а не опыт . Мое время лучше потратить на улучшение SO :-)
Норман Рэмси

43

Я изучил его и обнаружил, что ответ на ваш вопрос просто и удивительно «да»: академические типы CS или, по крайней мере, некоторые из них, используют «нетипизированный» для обозначения «динамически типизированный». Например, « Языки программирования: принципы и практики» , третье издание (Кеннет Лоуден и Кеннет Ламберт, опубликовано в 2012 году), гласит следующее:

Языки без систем статических типов обычно называют нетипизированными языками (или динамически типизированными языками ). К таким языкам относятся Scheme и другие диалекты Lisp, Smalltalk и большинство языков сценариев, таких как Perl, Python и Ruby. Однако обратите внимание, что нетипизированный язык не обязательно позволяет программам повреждать данные - это просто означает, что все проверки безопасности выполняются во время выполнения. [...]

[ ссылка ] (примечание: выделено жирным шрифтом в оригинале) и продолжает использовать «нетипизированный» именно таким образом.

Я нахожу это удивительным (по тем же причинам, что приводят афришке и Адам Михалцин), но вот вы здесь. :-)


Отредактировано, чтобы добавить: Вы можете найти больше примеров, подключившись "untyped languages"к Поиску книг Google. Например:

[…] Это основной механизм сокрытия информации во многих нетипизированных языках. Например, схема PLT [4] использует генеративные structs, […]

- Джейкоб Мэтьюз и Амаль Ахмед, 2008 [ ссылка ]

[…], Мы представляем анализ времени привязки для нетипизированного функционального языка […]. […] Он был реализован и используется в частичном оценщике для диалекта схемы без побочных эффектов. Однако анализ достаточно общий, чтобы его можно было применять для нестрогих типизированных функциональных языков, таких как Haskell. [...]

- Чарльз Консел, 1990 [ ссылка ]

Кстати, после просмотра этих результатов поиска у меня сложилось впечатление, что если исследователь пишет о «нетипизированном» функциональном языке, то он, скорее всего, считает его «нетипизированным» в том же смысле, что и нетипизированная лямбда исчисление, которое упоминает Адам Михалчин. По крайней мере, некоторые исследователи упоминают Схему и лямбда-исчисление на одном дыхании.

Конечно, поиск не говорит о том, существуют ли исследователи, которые отвергают эту идентификацию и не считают эти языки «нетипизированными». Ну, я нашел это:

Затем я понял, что в действительности нет цикличности, потому что динамически типизированные языки не являются нетипизированными языками - просто типы обычно не сразу очевидны из текста программы.

- кто-то (я не могу сказать, кто), 1998 [ ссылка ]

но очевидно большинство людей, которые отвергают эту идентификацию, не чувствуют необходимости прямо говорить об этом.


2
Вот это да. Shocking. Спасибо за информацию.
афришке

Именно такую ​​цитату я искал, спасибо! Кинда пугает меня тем, что книга на Амазоне имеет в среднем 2 звезды, хотя больше цитат приветствуется, но это хорошее начало.
Питер Купер

@PeterCooper: я отредактировал свой ответ, чтобы добавить больше цитат. Они обходят проблему рейтингов Amazon, основываясь на опубликованных статьях: насколько я знаю, они все еще могут быть мусором, но по крайней мере нам не нужно беспокоиться о том, что Amazon скажет нам об этом. :-P
Руах

Смешивать «нетипизированный» с «динамически типизированным» нелогично. Разработчики не должны быть нелогичными.
ротман

10

Нетипизированный и динамически типизированный абсолютно не синонимы. Языком, который чаще всего называют «нетипизированным», является лямбда-исчисление, которое на самом деле является однотипным языком - все является функцией, поэтому мы можем статически доказать, что типом всего является функция. Динамически типизированный язык имеет несколько типов, но не дает компилятору возможности статически проверять их, заставляя компилятор вставлять проверки во время выполнения для переменных типов.

Затем JavaScript является динамически типизированным языком: можно писать программы на JavaScript так, чтобы какая-то переменная xмогла быть числом, или функцией, или строкой, или чем-то еще (и определять, какая из них потребует решения проблемы остановки или какой-то другой). сложная математическая задача), поэтому вы можете обратиться xк аргументу, и браузер должен проверить во время выполнения, что xэто функция.


AFAIK Те же проблемы относятся к лямбда-выражению. В то время как вы можете передать функцию «моя текущая позиция» в функцию, которая вычисляет «мое расстояние от цели», вы также можете передать ту же самую функцию «моя текущая позиция» в функцию, которая вычисляет «лучше затяжки плюс удары» для вашего носа ". То, что вы можете это сделать, не означает, что оно действительно, как в случае с любой динамической системой.
Стив

5
@Steve Мусор в мусорном ведре имеет место для любого языка программирования, хотя и не связан с понятием типов. Даже в строго типизированном языке, таком как OCaml или SML, я могу передать Северный полюс в функцию, которая вычисляет «мое расстояние от цели» (и нет, моя текущая позиция не является Северным полюсом).
Адам Михалчин

Просто хочу добавить, для людей за пределами академии: такие вещи, как сборка, также будут считаться нетипизированными.
CoffeeTableEspresso

6

Оба утверждения верны, в зависимости от того, говорите ли вы о значениях или переменных. Переменные JavaScript являются нетипизированными, значения JavaScript имеют типы, а переменные могут варьироваться в зависимости от любого типа значения во время выполнения (т. Е. «Динамически»).

В JavaScript и многих других языках значения, а не переменные содержат типы. Все переменные могут варьироваться по всем типам значений и могут рассматриваться как «динамически типизированные» или «нетипизированные» - с точки зрения проверки типов переменная, у которой нет / непознаваемый тип, и переменная, которая может принимать любой тип, логически и практически эквивалентны , Когда теоретики типов говорят о языках и типах, они обычно говорят об этом - переменные, несущие типы, - потому что они заинтересованы в написании контроллеров типов и компиляторов и т. Д., Которые работают с текстом программы (т.е. переменными), а не с запущенной программой в памяти. (т.е. значения).

В отличие от других языков, таких как C, переменные содержат типы, а значения - нет. В таких языках, как Java, переменные и значения содержат типы. В C ++ некоторые значения (с виртуальными функциями) имеют типы, а другие - нет. В некоторых языках даже значения могут изменить типы, хотя это обычно считается плохим дизайном.


5
Я думаю, что ключевое различие не в значениях и переменных , а в значениях и выражениях : в языке со статической типизацией выражения имеют типы, тогда как в языке с динамической типизацией - только значения. (Имена переменных, конечно, являются одним из видов выражения.)
ruakh

4

Этот вопрос все о семантике

Если я дам вам эти данные: 12что это за тип? Вы не можете знать наверняка. Может быть целым числом - может быть плавающей точкой - может быть строкой. В этом смысле это очень «нетипизированные» данные.

Если я даю вам воображаемый язык, который позволяет вам использовать операторы, такие как «сложение», «вычитание» и «сцепление», для этих данных и некоторых других произвольных фрагментов данных, «тип» несколько не имеет значения (для моего воображаемого языка) (пример : возможно , add(12, a)выходы 109которых является 12плюс значение ASCII из a).

Давайте поговорим C на секунду. C в значительной степени позволяет вам делать что угодно с любым произвольным фрагментом данных. Если вы используете функцию, которая принимает два uintс - вы можете привести и передать все, что вы хотите - и значения будут просто интерпретироваться какuint s. В этом смысле C «нетипизирован» (если вы относитесь к нему таким образом).

Однако - и, если говорить о точке зрения Брендана, - если я скажу вам, что «мой возраст 12», - тогда 12есть тип - по крайней мере, мы знаем, что он числовой. С контекстом у всего есть тип - независимо от языка.

Вот почему я сказал в начале - ваш вопрос - один из семантики. Что означает «нетипизированный»? Я думаю, что Брендан ударил по гвоздю в голову, когда сказал «нет статических типов» - потому что это все, что это может означать. Люди естественно классифицируют вещи по типам. Мы интуитивно знаем, что между автомобилем и обезьяной есть что-то принципиально иное, и нас никогда не учили проводить такие различия.

Возвращаясь к моему примеру в начале - язык, который «не заботится о типах» (per se), может позволить вам «добавить» «возраст» и «имя», не вызывая синтаксической ошибки ... но это не означает, что это логически обоснованная операция.

Javascript может позволять вам делать всякие сумасшедшие вещи, не считая их «ошибками». Это не значит, что то, что вы делаете, логично. Это для разработчика, чтобы работать.

Является ли система / язык, который не обеспечивает безопасность типов во время компиляции / сборки / интерпретации, «нетипизированной» или «динамически типизированной»?

Семантика.

РЕДАКТИРОВАТЬ

Я хотел бы добавить кое-что здесь, потому что некоторые люди, кажется, догоняют «да, но у Javascript есть некоторые« типы »».

В своем комментарии к чужому ответу я сказал:

В Javascript у меня могли быть объекты, которые я построил, чтобы быть «Обезьянами», и объекты, которые я создал, чтобы быть «Людьми», и некоторые функции могли быть предназначены для работы только с «Людьми», другие - только с «Обезьянами», и третьи только на «Вещи с оружием». Независимо от того, говорилось ли когда-либо языку, существует ли такая категория объектов, как «вещи с оружием», не имеет значения для сборки («нетипизированный»), как для Javascript («динамический»). Это все вопрос логической целостности - и единственной ошибкой было бы использование чего-то, что не имело оружия с этим методом.

Итак, если вы считаете, что Javascript имеет некоторое внутреннее «представление о типах» и, следовательно, «динамические типы», и думаете, что это как-то «заметно отличается от нетипизированной системы», вы должны увидеть из приведенного выше примера, что любое «понятие Типы "это имеет внутренне действительно не имеет значения.

Например, чтобы выполнить ту же операцию с C #, мне нужен интерфейс ICreatureWithArmsили нечто подобное. Не так в Javascript - не так в C или ASM.

Понятно, имеет ли Javascript какое-либо понимание «типов» вообще не имеет значения.


4
-1. Вопрос состоит в том, используется ли определенное слово в определенных кругах с определенным значением, и ваш ответ состоит в том, чтобы объяснить, что это вопрос о том, имеет ли слово это значение? На самом деле, я думаю, что вы проделали замечательную работу, объясняя все, что ОП уже знает, не добавляя ничего нового вообще. , ,
Руах

Кажется, есть несколько вопросов, необходимых для построения определения, возможно? Это принудительное исполнение типов (статическое или динамическое) и наличие определенных типов. То есть в JavaScript есть типы, но их можно считать «нетипизированными» из-за отсутствия проверки правильности типов перед выполнением операции?
Питер Купер

@ruakh - я могу понять твою точку зрения. Однако ФП спросил: is there something deeper to this that I am missingи, я думаю, что неспособность понять, что это семантическая проблема, является более глубокой вещью - поэтому я приложил все усилия, чтобы сделать фишку в любой лакомый кусочек, который мог.
Стив

@PeterCooper - посмотрите мои изменения и скажите, добавит ли это что-нибудь для вас (так как вы сказали JavaScript has typesв своем ответе).
Стив

2
«Понятно, имеет ли Javascript какое-либо понимание« типов »вообще не имеет значения». Не правда. Как я намекал в своем ответе, независимо от контекста, вы не можете рассматривать 12 как функцию. Поскольку JavaScript имеет тип функции (или, в зависимости от вашей точки зрения, несколько типов функций), это важное различие.
Адам Михалчин

4

Хотя верно, что большинство исследователей CS, которые пишут о типах, по существу рассматривают только языки с синтаксически выводимыми типами как типизированные языки, гораздо больше нас используют языки с динамической / латентной типизацией, которые обижаются при таком использовании.

Я считаю, что есть 3 типа [SIC] языков:

Нетипизированный - только оператор определяет интерпретацию значения - и он обычно работает на что угодно. Примеры: Ассемблер, BCPL

Статически типизированный - с выражениями / переменными связаны типы, и этот тип определяет интерпретацию / достоверность оператора во время компиляции. Примеры: C, Java, C ++, ML, Haskell

Динамически типизированный - значения имеют типы, связанные с ними, и этот тип определяет интерпретацию / достоверность оператора во время выполнения. Примеры: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

Насколько мне известно, все языки с динамической типизацией являются типобезопасными, то есть только допустимые операторы могут работать со значениями. Но то же самое не относится к статически типизированному языку. В зависимости от мощности используемой системы типов некоторые операторы могут быть проверены только во время выполнения или вообще не проверяться. Например, большинство статически типизированных языков не обрабатывают целочисленное переполнение должным образом (добавление 2 положительных целых может привести к получению отрицательного целого числа), а ссылки на массивы вне границ либо вообще не проверяются (C, C ++), либо проверяются только при время выполнения. Кроме того, некоторые системы типов настолько слабы, что полезное программирование требует экранирующих штриховок (приведений в C и семейства), чтобы изменить тип выражений во время компиляции.

Все это приводит к абсурдным утверждениям, например, что C ++ безопаснее, чем Python, потому что он (статически типизирован), тогда как правда в том, что Python искробезопасен, в то время как вы можете отстрелить ногу с помощью C ++.


Upvoted. Рад знать, что "все динамически типизированные языки безопасны для типов". «Но то же самое не относится к языку со статической типизацией». Вы имеете в виду, что все или большинство языков со статической типизацией небезопасны?
Тим

Upvoted. (1) Рад знать, что «все динамически типизированные языки безопасны для типов», но Javascript динамически типизирован и слабо типизирован, см. Stackoverflow.com/questions/964910/… . (2) «Но то же самое не относится к языку со статической типизацией». Вы имеете в виду, что все или большинство языков со статической типизацией небезопасны?
Тим

Очень немногие языки являются статически безопасными по типу, если вы включаете в качестве типов возможность сбоя преобразования, исключений нижнего индекса или исключений нулевого указателя (и большинство людей включают по крайней мере сбой преобразования как ошибку типа). Rust, например, более статически безопасен для типов, чем Java, потому что вы не можете иметь нулевой указатель. Java динамически безопасна по типу, поскольку вы получаете исключения для любых недопустимых операций, и все указано (кроме собственных методов). Аналогично Rust (исключая «небезопасный» код, обозначенный так).
Дэйв Мейсон

Однако C ++, C даже не являются динамически безопасными по типу, потому что есть «неуказанные» части языка, и если вы выполните одну из «неуказанных» операций, буквально что-нибудь является законным ответом от языка (значения не связанных переменных могут изменения, вирусы могут заразить вашу программу, программа может записать все на вашем диске и затем аварийно завершить работу, программа может даже сделать то, что вы ожидали :-).
Дэйв Мейсон

@DaveMason: не определено. Существует огромная разница между «неопределенным» и «неопределенным» в C. Неопределенное поведение - это, по сути, недопустимые вещи, которые могут делать то, что вы описали - в то время как неопределенное по существу означает «определенный реализацией, где реализация не должна документировать его». "(есть некоторые нюансы здесь и там, так что это является упрощение). Вызывать неопределенное поведение, таким образом, совершенно законно (фактически, каждый делает это всякий раз, когда пишет, скажем, вызов функции).
Тим

2

Я не специалист по информатике, но я был бы весьма удивлен, если бы «нетипизированный» действительно использовался в качестве синонима для «динамически типизируемого» в сообществе CS (по крайней мере, в научных публикациях), поскольку imho эти два термина описывают разные понятия. В динамически типизированном языке есть понятие типов, и оно применяет ограничения типов во время выполнения (вы не можете, например, разделить целое число на строку в Лиспе, не получив ошибку), в то время как нетипизированный язык не имеет никакого представления о типах в все (например, ассемблер). Даже статья в Википедии о языках программирования (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) делает это различие.

Обновление: возможно, путаница связана с тем, что некоторые тексты говорят что-то в той степени, что «переменные не напечатаны» в Javascript (что верно). Но это автоматически не означает, что язык нетипизирован (что было бы ложным).


1
Ассемблер имеет очень слабое представление о типах. По крайней мере, в x86 все является целым числом, но некоторые целые числа отличаются по размеру от других. Это даже до того, как перейти к MMX, x87 и другим расширениям оригинальной спецификации x86.
Адам Михалчин

Я должен не согласиться. В Javascript у меня могли быть объекты, которые я построил, чтобы быть «Обезьянами», и объекты, которые я создал, чтобы быть «Людьми», и некоторые функции могли быть предназначены для работы только с «Людьми», другие - только с «Обезьянами», и третьи только на «Вещи с оружием». Независимо от того, говорилось ли когда-либо языку, существует ли такая категория объектов, как «вещи с оружием», не имеет значения для сборки («нетипизированный»), как для Javascript («динамический»). Это все вопрос логической целостности - и единственной ошибкой было бы использование чего-то, что не имело оружия с этим методом.
Стив

@ Адам Михалчин Правда. Языки ассемблера [Macro] могут, конечно, иметь различное представление о типах. (Посмотрите, например, «Язык типизированных ассемблеров».) Я все еще думаю, что моя точка зрения остается верной.
афришке

3
@ Стив, я не уверен, что смогу следовать за тобой. ОП спросил, не проводится ли различие между «динамически типизированными» и «нетипизированными» в кругах CS. Это не имеет никакого отношения к тому, считаете ли вы, что практически нет различий между тем, как Javascript и сборка обрабатывают биты в памяти. В соответствии с тем, что я прочитал (и мне пришлось искать это специально, так как я не программист Javascript): Стандарт ECMAScript / Javascript определяет 6 типов данных (Boolean, String, Undefined, Number, Null и Object) и в любой точке во времени значение одного конкретного типа ...
afrischke

1
... Теперь это понятие (большинство) языков ассемблера не имеют (все, что есть, это биты и байты), поэтому imho это отмечает четкое различие между Javascript и сборкой.
афришке

1

Согласитесь с Бренданом - контекст это все.

Мой дубль:

Я помню, что был сбит с толку, примерно в 2004 году, потому что вспыхивали споры о том, был ли типизирован Ruby или динамически типизирован. Люди старой школы C / C ++ (из которых я был одним) думали о компиляторе и говорили, что Ruby не имеет типа.

Помните, в C нет типов времени выполнения, есть только адреса, и если код, который выполняется, решает обрабатывать то, что находится по этому адресу, как что-то не так, к сожалению. Это определенно нетипизированный и сильно отличается от динамически типизированного.

В этом мире «печатать» - это все о компиляторе. C ++ имел «строгую типизацию», потому что проверки компилятора были более строгими. Java и C были более «слабо типизированы» (были даже аргументы о том, была ли Java строго или слабо типизирована). Динамические языки в этом континууме были «нетипизированы», потому что у них не было проверки типов компилятора.

Сегодня для практикующих программистов мы настолько привыкли к динамическим языкам, что мы, очевидно, думаем, что нетипизированный означает отсутствие проверки компилятором или интерпретатором интерпретатора, что было бы безумно сложно отладить. Но был период, когда это было неочевидным, а в более теоретическом мире КС, возможно, даже не имеет смысла.

В некотором глубоком смысле ничто не может быть нетипизировано (или почти ничего, во всяком случае), потому что вы должны иметь какое-то намерение манипулировать значением, чтобы написать осмысленный алгоритм. Это мир теоретического CS, который не имеет отношения к особенностям реализации компилятора или интерпретатора для данного языка. Так что «нетипизированный» (вероятно, я не знаю) совершенно бессмысленный в этом контексте.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.