Які аргументи є на користь слабкого набору тексту?

Це виникла в дискусії з другом, і мені стало важко придумувати якісь хороші аргументи. Які переваги дає слабкий набір тексту?

Проблема такого типу дискусій полягає лише в тому, що терміни "слабке введення тексту" та "сильне введення тексту" не визначено, на відміну, наприклад, від термінів "статичне введення тексту", "динамічне введення тексту", "явне введення тексту", "неявне введення тексту", " набору качок "," структурного набору "або" номінального набору тексту ". Хек, навіть терміни "маніфестний набір тексту" та "латентне введення тексту", які все ще є відкритими областями дослідження та обговорення, напевно, краще визначені.

Отже, поки ваш друг не дасть визначення терміну "слабкий набір тексту", який є досить стійким, щоб послужити основою дискусії, відповідати на це питання навіть не має сенсу.

На жаль, окрім відповіді Ніка , ніхто з відповідачів також не покладався надати своє визначення, і ви можете побачити плутанину, яка породжується в деяких коментарях. Важко сказати, адже ніхто насправді не дає своїх визначень, але я думаю, що я рахую принаймні три різні, саме на цій самій сторінці.

Деякі з найбільш часто використовуваних визначень є (і так, я знаю, що майже жодне з них не має сенсу, але це визначення, які я бачив, як насправді люди використовують):

• слабкий набір тексту = небезпечний набір тексту / сильний набір тексту = безпечний набір тексту
• слабке введення = динамічне введення / сильне введення тексту = статичне введення тексту
• слабкий набір тексту = качка набору / сильний набір тексту = номінальний набір тексту
• слабке введення = структурне введення / сильне введення = номінальне введення тексту
• слабке введення = неявне введення / сильне введення тексту = явне введення тексту
• слабке введення = приховане введення / сильне введення тексту = явне введення тексту
• слабкий набір тексту = відсутність набору / сильний набір тексту = набір тексту
• слабке введення = неявні касти / сильне введення = лише явні касти
• слабке введення = неявні або явні касти / сильне введення тексту = взагалі відсутні
• слабке введення = неявна конверсія / сильне введення тексту = лише явні конверсії
• слабке введення = неявна або явна конверсія / сильне введення тексту = відсутність перетворень
• слабкий набір тексту = інтерпретація / сильний набір тексту = компіляція
• слабкий набір тексту = повільний / сильний набір тексту = швидкий
• слабкий набір тексту = збирання сміття / сильний набір тексту = ручне управління пам’яттю
• слабкий набір тексту = ручне управління пам’яттю / сильне введення тексту = вивезення сміття
• … Та багато інших

Однак три визначення, які, як видається, використовуються найбільш широко

• слабкий набір тексту = ваша дурна хитра мова програмування / сильна введення тексту = моя супер-чудова мова програмування
• слабкий набір тексту = будь-яка інша мова програмування / сильний набір тексту = єдина мова програмування, яку я коли-небудь намагався вивчити (як правило, або 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 - найвідоміша слабо типізована мова, і вона не виконує перевірки часу виконання або перевірки часу компіляції типу змінних. По суті , ви можете кинути char *в int *і мові не буде піклуватися. То чому б ти це робив?

Програмування на C досить близьке до того, як ви могли б робити речі зі збиранням, тому бувають випадки, коли ви дбаєте лише про адресу. З void *цієї причини не рідкість подавати або передавати посилання. Якщо ви знаєте, як організована пам'ять (знову це стосується проблеми C і збірки), ви можете зробити досить круті обчислення, виходячи з адреси в адресі, void *щоб отримати потрібну інформацію. Це може дозволити вам коротко замикати процес, який, наприклад, вам доведеться пройти в Java.

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

Однак, у більшості випадків наявність сильної системи типу, яка перевіряється часом компіляції або виконуваною програмою, допомагає частіше, ніж шкодить.

Слабке введення текстів, як правило, простіше зрозуміти новачкам, наприклад, у таких як excel, javascript та vbscript. Ви також торгуєте деякою швидкістю розробки для потенційних помилок.

Хороша стаття на тему: Сильний набір тексту та сильне тестування