Spośród kontrolowanych eksperymentów tylko trzy wykazują efekt wystarczająco duży, aby mieć jakiekolwiek praktyczne znaczenie. Badanie Prechelt porównujące C, C ++, Java, Perl, Python, Rexx i Tcl; badanie Endrikat porównujące Javę i Dart; oraz eksperyment Cooleya z VHDL i Verilog. Niestety wszystkie mają problemy, które utrudniają wyciągnięcie naprawdę mocnych wniosków.
W badaniu Prechelt populacje różniły się między językami dynamicznymi i pisanymi na maszynie, a warunki dla zadań były również różne. Przeprowadzono dalsze badanie ilustrujące ten problem, zapraszając Lispers do opracowania własnych rozwiązań tego problemu, polegającego na porównaniu ludzi takich jak Darius Bacon z przypadkowymi studentami. Kontynuacja obserwacji dosłownie polega na porównaniu kodu od Petera Norviga z kodem od przypadkowych studentów.
W badaniu Endrikat wybrali zadanie, w którym myśleli, że statyczne pisanie może coś zmienić, i wyciągnęli swoje podmioty z populacji, w której wszyscy uczęszczali na zajęcia w języku typowanym statycznie. Nie komentują, czy uczniowie mieli doświadczenie w języku dynamicznie typowanym, ale wydaje się, że można bezpiecznie założyć, że większość lub wszyscy mieli mniej doświadczenia w języku dynamicznie typowanym.
Eksperyment Cooleya był jednym z nielicznych, który przyciągnął ludzi z populacji studentów, co jest świetne. Ale, podobnie jak w przypadku wszystkich innych eksperymentów, zadanie było trywialnym zadaniem zabawki. Choć wydaje się to przekleństwem, że żaden z uczestników VHDL (języka statycznego) nie był w stanie ukończyć zadania na czas, niezwykle niezwykłe jest chęć ukończenia projektowania sprzętu w 1,5 godziny w dowolnym miejscu poza szkolnym projektem. Można argumentować, że duże zadanie można podzielić na wiele mniejszych zadań, ale wiarygodnym przeciwwskazaniem jest to, że przy użyciu VHDL istnieją stałe koszty, które można amortyzować dla wielu zadań.
Jeśli chodzi o resztę eksperymentów, głównym wnioskiem, jaki mam z nich, jest to, że w określonych okolicznościach opisanych w badaniach każdy efekt, o ile w ogóle istnieje, jest niewielki.
Przechodząc do studiów przypadków, dwa studia przypadków wykrywania błędów stanowią ciekawą lekturę, ale tak naprawdę nie przedstawiają argumentów za ani przeciw typom. Jeden pokazuje, że transkrypcja programów Pythona na Haskell znajdzie niezerową liczbę błędów o nieznanym poziomie ważności, które mogą nie zostać wykryte podczas testów jednostkowych ukierunkowanych na pokrycie linii. Para artykułów Erlanga pokazuje, że można znaleźć błędy, które byłyby trudne do znalezienia za pomocą dowolnego rodzaju testów, z których niektóre są poważne, przy użyciu analizy statycznej.
Jako użytkownik uważam, że jest to wygodne, gdy mój kompilator wyświetla mi błąd przed uruchomieniem osobnych narzędzi analizy statycznej, ale jest to niewielki, być może nawet mniejszy niż rozmiar efektu kontrolowanych badań wymienionych powyżej.
Uważam, że studium przypadku 0install (które porównywało różne języki z Pythonem i ostatecznie osiedliło się na Ocaml) było jedną z bardziej interesujących rzeczy, na które natknąłem się, ale jest to rodzaj subiektywnej rzeczy, którą każdy interpretuje inaczej, co można zobaczyć, patrząc .
Odpowiada to wrażeniu, jakie mam (w moim małym zakątku świata, ACL2, Isabelle / HOL i PVS są najczęściej używanymi dowodami i ma sens, że ludzie wolą większą automatyzację przy rozwiązywaniu problemów w przemyśle), ale to również subiektywne.
A potem są badania, które wydobywają dane z istniejących projektów. Niestety nie mogłem znaleźć nikogo, kto zrobiłby cokolwiek, aby ustalić związek przyczynowy (np. Znaleźć odpowiednią zmienną instrumentalną), więc po prostu mierzą korelacje. Niektóre korelacje są nieoczekiwane, ale nie ma wystarczających informacji, aby ustalić, dlaczego.
Jedynym badaniem eksploracji danych, które prezentuje dane, które mogą być potencjalnie interesujące bez dalszej eksploracji, jest przegląd błędów Pythona w Smallshire, ale nie ma wystarczających informacji na temat metodologii, aby dowiedzieć się, co naprawdę oznacza jego badanie, i nie jest jasne, dlaczego sugerował, aby spojrzeć na dane dla innych języków bez prezentacji danych3.
Niektóre znaczące pominięcia w badaniach to kompleksowe badania z udziałem doświadczonych programistów, nie mówiąc już o badaniach, które mają dużą populację „dobrych” lub „złych” programistów, patrząc na wszystko zbliżające się do znaczącego projektu (w miejscach, w których pracowałem, trzymiesięczny projekt byłby być uważane za małe, ale to o wiele rzędów wielkości większe niż jakikolwiek projekt wykorzystywany w kontrolowanym badaniu), przy użyciu „nowoczesnych” języków o typie statycznym, przy użyciu pisania stopniowego / opcjonalnego, przy użyciu nowoczesnych IDE głównego nurtu (takich jak VS i Eclipse), przy użyciu nowoczesnych radykalnych IDE (np. LightTable), używając oldschoolowych edytorów (takich jak Emacs i vim), wykonując konserwację na nietrywialnej bazie kodu, wykonując konserwację z czymkolwiek przypominającym realistyczne środowisko, wykonując konserwację na bazie kodu, którą już znasz, itp.
Jeśli spojrzysz na internetowy komentarz do tych badań, większość z nich jest przekazywana w celu uzasadnienia takiego czy innego punktu widzenia. Badanie Prechelt na temat dynamiki vs. statyczności, wraz z kontynuacjami na temat Lisp, są odwiecznymi ulubieńcami dynamicznych zwolenników języka, a badania górnictwa github stały się ostatnio modne wśród funkcjonalnych programistów.