З контрольованих експериментів лише три показують ефект, достатньо великий, щоб мати будь-яке практичне значення. Дошкільне дослідження, що порівнює C, C ++, Java, Perl, Python, Rexx та Tcl; дослідження Endrikat, що порівнює Java та Dart; і експеримент Кулі з VHDL та Verilog. На жаль, всі вони мають проблеми, які важко зробити дійсно сильний висновок.
У дослідженні Prechelt популяції відрізнялися між динамічними та типовими мовами, а умови для виконання завдань також були різними. Було проведено наступне дослідження, яке проілюструвало цю проблему, запропонувавши Лісперсу придумати власні рішення проблеми, що передбачало порівняння таких людей, як Даріус Бекон, із випадковими підлеглими. Подальше спостереження буквально включає порівняння коду від Пітера Норвіга з кодом випадкових студентів коледжу.
У дослідженні Endrikat вони спеціально вибрали завдання, де вони вважали, що статичне введення тексту має значення, і вони вивели своїх предметів із населення, де всі проходили заняття, використовуючи статично набрану мову. Вони не коментують, чи мали студенти досвід динамічно набраної мови, але здається безпечним припустити, що більшість чи всі мали менший досвід роботи з динамічно набраною мовою.
Експеримент Кулі був одним із небагатьох, що привертав людей з не студентського населення, що чудово. Але, як і у всіх інших експериментів, завдання було тривіальним завданням іграшки. Хоча це дивно, що жоден із учасників VHDL (статичної мови) не зміг виконати завдання вчасно, вкрай незвично хочеться закінчити дизайн обладнання за 1,5 години в будь-якому місці поза шкільним проектом. Ви можете стверджувати, що велике завдання може бути розбито на багато менших завдань, але правдоподібним контраргументом є те, що за допомогою VHDL є фіксовані витрати, які можуть бути амортизовані у багатьох завданнях.
Що стосується решти експериментів, то головне, що я маю від них, - це те, що за конкретного набору обставин, описаних у дослідженнях, будь-який ефект, якщо він взагалі існує, малий.
Переходячи до тематичних досліджень, обидва випадки пошуку помилок приносять цікаве читання, але вони насправді не складають справи про типи чи проти. Одне показує, що при транскрибуванні програм Python на Haskell знайдеться нульова кількість помилок невідомої тяжкості, які можуть бути не знайдені шляхом тестування одиниць, орієнтованих на покриття ліній. Пара робіт Erlang показує, що ви можете знайти деякі помилки, які було б важко знайти через будь-яке тестування, деякі з яких є серйозними, використовуючи статичний аналіз.
Як користувач, мені здається, що мій компілятор видає мені помилку перед тим, як запустити окремі інструменти статичного аналізу, але це незначно, можливо, навіть менше, ніж розмір ефекту від контрольованих досліджень, перелічених вище.
Я виявив тематичне дослідження 0install (яке порівнювало різні мови з Python і врешті-решт влаштувалося на Ocaml) як одне з найбільш цікавих речей, на які я натрапив, але це така суб'єктивна річ, яку кожен буде тлумачити по-різному, що ви можете побачити, дивлячись .
Це відповідає моєму враженню (у моєму маленькому куточку світу ACL2, Isabelle / HOL та PVS - найпоширеніші докази, і є сенс, що люди віддають перевагу більшої автоматизації при вирішенні проблем у галузі), але це також суб'єктивні.
А потім є дослідження, які виводять дані з існуючих проектів. На жаль, я не зміг знайти когось, хто щось зробив, щоб визначити причинно-наслідкову ситуацію (наприклад, знайти відповідну інструментальну змінну), тому вони просто вимірюють кореляцію. Деякі кореляції є несподіваними, але недостатньо інформації, щоб визначити, чому.
Єдине дослідження з видобутку даних, яке представляє потенційно цікаві дані без подальшого вивчення, - огляд Смоллшира про помилки Python, але недостатньо інформації про методологію, щоб визначити, що насправді означає його дослідження, і не ясно, чому він натякнув на це. дані для інших мов без подання даних3.
Деякі помітні упущення досліджень - це комплексні дослідження з використанням досвідчених програмістів, не кажучи вже про дослідження, які мають велику групу «хороших» чи «поганих» програмістів, дивлячись на те, що наближається до значного проекту (у місцях, де я працював, тримісячний проект би вважати невеликим, але це на кілька порядків більше, ніж будь-який проект, що використовується в контрольованому дослідженні), використовуючи "сучасні" статично типовані мови, використовуючи поступовий / необов'язковий введення тексту, використовуючи сучасні основні IDE (наприклад, VS та Eclipse), використовуючи сучасні радикальні IDE (наприклад, LightTable), використовуючи старі шкільні редактори (наприклад, Emacs та vim), проводити технічне обслуговування нетривіальної бази коду, обслуговувати все, що нагадує реалістичне середовище, проводити обслуговування на базі коду, з якою ви вже знайомі тощо.
Якщо ви подивитесь на коментарі до цих досліджень в Інтернеті, більшість з них передаються навколо, щоб виправдати ту чи іншу точку зору. Дослідження «Пречельт» щодо динамічного проти статичного, а також подальші спостереження на Ліспі - це багаторічні фаворити прихильників динамічної мови, і дослідження гірничих видобутку останнім часом стало модним серед функціональних програмістів.