Если мы рассмотрим фразы «статически типизированный» и «динамически типизированный» как жаргон со ссылкой на то, когда язык проверяет достоверность операций с типами, то я думаю, что было бы справедливо охарактеризовать Mathematica, используя жаргон «нетипизированный» - вощущение, что оно «никогда» не проверяет, является ли операция допустимой для типа.
Однако мне нравится использование Велисарием термина «независимость от типа».Я говорю это потому, что хотя почти вся проверка типов в языке идиоматична (т. Е. Реализуется программистом, а не языком), так же как и концепция применения оператора к типизированным операндам!
Считайте «бессмысленным»пример 1 + "foo"
.Я думаю, что было бы справедливо сказать, что значительная часть (приближающаяся к единству) всех пользователей Mathematica сталкивается с такими случаями, когда они впервые изучают язык.Проблема особенно очевидна, когда кто-то пишет код, скажем, в стиле C. В кругах Mathematica много обсуждается, как справляться с такими ситуациями.
С другой стороны, эта слабостьтакже величайшая сила Mathematica.Mathematica оптимизирована для создания новых обозначений.Многие, многие обозначения имеют понятие +
, которое ведет себя очень похоже на сложение в элементарной арифметике.При построении такого обозначения было бы очень неудобно, если бы Mathematica вмешалась и пожаловалась, что операнды на +
не являются числами.В таком высокоуровневом приложении Mathematica «бессмысленный» пример не только «чувственный», но и действительно важный.
Итак, с учетом этого вопрос о типе часто спорен.Следовательно, мне нравится Велизарий '"независимая от типа" характеристика.Подпишись на него, я сделал;)
Редактировать
Я попытаюсь уточнить, что я имел в виду, когда различал «нетипизированный» и «независимый от типа».
Читая различные ответы и комментарии, я попытался выяснить, в чем разница между Mathematica и LISP.Последнее обычно рассматривается как пример «динамически типизированного», хотя основной оценщик LISP очень похож на Mathematica, практически не проверяющий тип.Ошибки типов, которые мы видим в программах LISP, в основном вызываются жестко заданными проверками в (обычно встроенных) функциях.+
, например, будет принимать только числовые аргументы, даже если самому оценщику не безразлично, так или иначе.Сказав это, «чувство» программирования в LISP сильно отличается от «ощущения» Mathematica (по крайней мере, для меня).Пример 1 + "foo"
действительно отражает эту разницу.
Хотя я в целом согласен с «нетипизированным» в качестве характеристики Mathematica, я все же чувствовал, что чего-то не хватает.Мне кажется, что ассемблер нетипизирован, как и ранний FORTRAN и pre-ANSI C. В этих случаях битовая последовательность аргументов имела значение, и программы продолжали бы беспечно, если бы я передал строковый аргумент, где необходимо целое число.Mathematica, безусловно, разделяет это нетипичное поведение.Но есть разница: в ассемблере, FORTRAN и C такое отсутствие проверки типов крайне редко приводит к хорошему результату.Как я уже упоминал выше, в Mathematica можно, а иногда даже часто полагаться на такое поведение.
Введите "независимый от типа".Мне понравилась его бескомпромиссная позиция, звучащая менее радикально, чем «нетипизированная».Я чувствовал, что это отражает по существу нетипизированную природу Mathematica, но оставил некоторое пространство для маневра для тех языковых возможностей, которые легко поддерживают идиоматическую проверку типов в динамическом стиле LISP (то есть идиома «head» и поддерживающая функциональность).* Итак, короче говоря, я чувствую, что Mathematica колеблется между полной нетипизацией и динамической типизацией.«Тип-агностик» уловил это чувство для меня.YMMV:)
Я с готовностью признаю, что никто, вероятно, не восстановит ничего, что я написал в этом ответе, просто из проверки фраз "нетипизированный" и "независимый от типа". Я еще раз подчеркиваю, что я считаю, что «нетипизированный» является хорошей характеристикой Mathematica, но мне также нравится тот факт, что «независимость от типа» напрашивается на многие вопросы, на которые отвечают различные ответы на этот вопрос SO.