Какие есть аргументы в пользу слабой типизации?

Это возникло в дискуссии с другом, и я оказался в затруднении, чтобы придумать какие-либо хорошие аргументы. Какие преимущества дает слабая типизация?

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

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

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

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

• слабая типизация = небезопасная типизация / строгая типизация = безопасная типизация
• слабая типизация = динамическая типизация / строгая типизация = статическая типизация
• слабая типизация = утка / строгая типизация = номинальная типизация
• слабая типизация = структурная типизация / строгая типизация = номинальная типизация
• слабая типизация = неявная типизация / строгая типизация = явная типизация
• слабая типизация = скрытая типизация / строгая типизация = манифестная типизация
• слабая типизация = нет типизации / строгая типизация = типизация
• слабая типизация = неявное приведение / строгая типизация = только явное приведение
• слабая типизация = неявное или явное приведение / строгая типизация = вообще не приведение
• слабая типизация = неявные преобразования / строгая типизация = только явные преобразования
• слабая типизация = неявные или явные преобразования / строгая типизация = вообще никаких преобразований
• слабая типизация = интерпретация / строгая типизация = компиляция
• слабая типизация = медленная / сильная типизация = быстрая
• слабая типизация = сборка мусора / строгая типизация = ручное управление памятью
• слабая типизация = ручное управление памятью / строгая типизация = сборка мусора
• … и многие другие

Три определения, которые, как представляется, используются наиболее широко, однако, являются

• слабая типизация = ваш тупой дрянной язык программирования / строгая типизация = мой супер-классный язык программирования
• слабая типизация = любой другой язык программирования / строгая типизация = единственный язык программирования, который мне когда-либо удавалось выучить (обычно это Java, C # или C ++; как ни странно, люди, которые изучают, например, Haskell или Scheme в качестве своего первого и единственного языка, похоже, не разделяют это мировоззрение)
• слабая типизация = все языки, которые я не понимаю / строгая типизация = Java (замените на C # или C ++ по желанию)

Если все не согласится на определении того , что «слабая типизация» даже есть , она даже не имеет смысла думать о том, что его преимущество может быть. Преимущества чего? Еще хуже, если нет определения вообще , то каждый может просто перенести их определения в соответствии со своими аргументами, и каждое обсуждение в значительной степени гарантированно делегируют в flamewar.

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

Помните, что есть две основные концепции, которые обычно путают:

Динамическая печать

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

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

if (!(arr is Array)) arr = [arr]; // is, instanceof, .constructor ==, whatever

Меньше кода в любом случае, где в противном случае вам пришлось бы привести или присвоить новое значение:

if (data is Array)) {
    i = data.length; // no i = ((Array)data).length or Array myArr=(Array)data;
}

Слабая или слабая типизация

Слабая типизация означает, что язык неявно преобразует (или преобразует) типы при использовании.

Выгоды:

• Передайте любое значение типа в качестве параметра функции . Полезно для обратных вызовов, гибких API и упрощает реализацию замыканий.

• Неявная логическая оценка . Любой тип может быть оценен как логическое значение. Это также имеет побочные преимущества, такие как часть ||может использоваться в присваивании без преобразования в логическое значение:

  var a = param || defaultValue;
  

• Опять же, меньше кода:

  var num = 5;
  var str = "Hello";
  input.innerHTML = input.value = num;
  for (var i=0; i < input.value; i++) { ... }
  

  Даже Java должен был идти наполовину с неявным вызовом .toString()при объединении объектов с a String; в противном случае Java-программисты проклинали бы это весь день (операторы журнала вышли бы из-под контроля).

^{Оба определения взяты из http://en.wikipedia.org/wiki/Type_system . Он сказал это лучше, чем мог.}

Основной аргумент в пользу слабой типизации - это производительность. (это ответ на вопрос ОП, как указано). Существует много хороших дискуссий о динамическом и статическом, неявном и явном. и т.п.

C является самым известным слабо типизированным языком, и он не выполняет никакой проверки во время выполнения или проверки времени компиляции типа переменных. В сущности, вы можете привести a char *к a, int *и язык не будет заботиться. Так зачем ты это делаешь?

Программирование на C довольно близко к тому, как вы делаете вещи со сборкой, поэтому бывают случаи, когда вам важен только адрес. По void *этой самой причине нередко разыгрывать или передавать ссылку. Если вы знаете, как организована память (опять же проблема C и сборки), вы можете сделать несколько довольно крутых вычислений, основываясь на адресе в, void *чтобы получить необходимую информацию. Это может позволить вам замкнуть процесс, который вам, например, придется пройти в Java.

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

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

Новичкам обычно легче понять слабую типизацию, например, в Excel, Javascript и VBScript. Вы также обмениваете некоторую скорость разработки на возможные ошибки.

Хорошая статья на эту тему: Строгая типизация против Строгого тестирования