Badania języków dynamicznie a statycznie typowanych [zamknięte]

69

Czy istnieją badania dotyczące skuteczności języków statystycznych i dynamicznych?

W szczególności:

  • Pomiary wydajności programisty
  • Wskaźnik defektów

Uwzględnia także skutki zastosowania testu jednostkowego.

Widziałem wiele dyskusji na temat zalet każdej ze stron, ale zastanawiam się, czy ktoś to zrobił.

productivity comparison type-systems dynamic-typing static-typing Winston Ewert
źródło
8
@ Bigown, nie wydaje mi się, że problemy związane z produktywnością i wadami dotyczą teorii informatyki
Winston Ewert,
2
@Winston: Studiowanie tego rodzaju problemów jest zadaniem informatyków, a nie programistów.
Maniero,
9
@bigown, tak, to problem informatyczny, ale nie problem teoretyczny. Teoria CS zasadniczo zajmuje się tym, co możemy matematycznie udowodnić na temat programów i komputerów. Kwestie produktywności programisty nie są pytaniami teoretycznymi. Dyskutowano o dynamicznym pisaniu zarówno tutaj, jak i o przepełnieniu stosu. Cstheory nie było.
Winston Ewert
8
Pytanie doskonale dotyczy tematu. To pytanie omawia jedną z najważniejszych właściwości narzędzi, których używamy do programowania.
Frank Shearar
4
@Winston: Systemy pisania należą do teorii CS, ale praktyczne badania nie.
David Thornley,

Odpowiedzi:

42

Niektórzy sugerowali lekturę:

Nie do końca przy pisaniu statycznym, ale powiązane:

Kilka interesujących artykułów lub esejów na ten temat lub ogólnie na temat analizy statycznej programów:

A dla tych, którzy zastanawiają się, o co w tym wszystkim chodzi:

Wątpię jednak, aby którekolwiek z nich dało bezpośrednią odpowiedź, ponieważ nie wykonują dokładnie tego, czego szukasz. Będą to ciekawe lektury.

Osobiście, Zdecydowanie uważam, że pisanie statyczne zamiast pisania dynamicznego ułatwia wykrywanie błędów. O wiele za dużo piszę, szukając literówek i drobnych błędów takich jak te w JavaScript, a nawet w kodzie Ruby. A jeśli chodzi o pogląd, że dynamiczne pisanie daje ci wzrost wydajności, myślę, że sprowadza się to głównie do narzędzi. Jeśli statycznie wpisane języki mają odpowiednie narzędzia, które pozwalają na rekompilację w tle i zapewniają interfejs REPL, zyskujesz korzyści z obu światów. Scala zapewnia to na przykład, co bardzo ułatwia naukę i tworzenie prototypów w interaktywnej konsoli, ale daje korzyści płynące z pisania statycznego (i silniejszego systemu pisma niż wiele innych języków, pomijając języki ML). Podobnie, nie sądzę, żebym stracił produktywność przy użyciu Java lub C ++ (z powodu pisania statycznego), dopóki używam IDE, które mi pomaga. Kiedy wracam do kodowania tylko w prostych konfiguracjach (edytor + kompilator / interpreter), wydaje mi się, że korzystanie z bardziej dynamicznych języków jest niewygodne. Ale nadal polujesz na błędy. Sądzę, że ludzie powiedzieliby, że kwestia narzędzi jest odwracalnym argumentem, tak jakby gdyby narzędzia były lepsze dla języków dynamicznych, wówczas większość błędów i literówek byłaby wskazywana w czasie kodowania, ale moim zdaniem odzwierciedla to wadę systemu. Mimo to zwykle prototypuję w JRuby i koduję w Javie później większość rzeczy, które robię. jakby narzędzia były lepsze dla języków dynamicznych, wówczas większość błędów i literówek będzie wskazywana w czasie kodowania, ale moim zdaniem odzwierciedla to wadę systemu. Mimo to zwykle prototypuję w JRuby i koduję w Javie później większość rzeczy, które robię. jakby narzędzia były lepsze dla języków dynamicznych, wówczas większość błędów i literówek będzie wskazywana w czasie kodowania, ale moim zdaniem odzwierciedla to wadę systemu. Mimo to zwykle prototypuję w JRuby i koduję w Javie później większość rzeczy, które robię.

OSTRZEŻENIE: Niektóre z tych łączy są niewiarygodne, a niektóre przechodzą przez portale różnych towarzystw komputerowych korzystających z opłat dla członków. Przepraszam za to, próbowałem znaleźć wiele linków dla każdego z nich, ale nie jest to tak dobre, jak bym tego chciał.

Haylem
źródło
Znalezienie błędu - czy to głównie z powodu błędnie napisanych nazw zmiennych lub nazw metod, czy gdzieś pomiędzy? ( Nienawidzę niejawnej deklaracji zmiennej właśnie z tego powodu: w Smalltalk deklarujesz wszystkie swoje zmienne u góry, więc od razu wiesz, kiedy pomyliłeś nazwę zmiennej. (Literówki nazw metod są czasami wychwytywane, jeśli nazwa metody nigdy nie jest był używany na zdjęciu wcześniej.))
Frank Shearar
Jeśli chodzi o narzędzia, muszę powiedzieć, że to zależy od twojego języka - Smalltalk ma doskonałe narzędzia, w tym Przeglądarkę Refaktoryzacji, której Eclipse (jak mi powiedziano) jeszcze nie nadrobił.
Frank Shearar
@Frank Shearar, odkąd zacząłem od Ruby (pochodzącego z Javy), zdałem sobie sprawę, że to, co mówi @ haylem, prawdopodobnie nie dotyczy Smalltalk. Moja mantra o automatycznym refaktoryzacji jest niemożliwa w dynamicznie pisanych językach. Całkowicie zgadzam się z sekcją „osobiście” Haylem… oczywiście ignorując SmallTalk :) Jest to do pewnego stopnia sprawiedliwe, ponieważ SmallTalk, chociaż nie jest martwy, zdecydowanie nie cieszy się popularnością, jaką mają Python lub Ruby (teraz w październiku 2010 r. ).
Dan Rosenstark
3
@haylem, osobiście dziękuję za to, że poczułem, że nie jestem jedyną osobą na świecie, która działa w dynamicznych językach, ale gdy mam wybór, wiele razy WYBIERA języki o typie statycznym (ten sam przypadek, Java vs. JRuby lub Groovy).
Dan Rosenstark
4
Jest to interesujące, ponieważ moje własne preferencje dotyczące dynamicznego pisania są z różnych powodów. Chodzi mi o to, że szybkie kompilacje i interaktywny interpreter są przydatne, ale nie dlatego lubię dynamiczne pisanie. Lubię dynamiczne pisanie, ponieważ znajduję wiele sytuacji, w których statyczne języki pisania utrudniają opisanie konkretnej koncepcji.
Winston Ewert
19

Wczoraj znalazłem to badanie: Testowanie jednostkowe nie wystarczy. Potrzebujesz także pisania statycznego.

Zasadniczo autor użył narzędzia zdolnego do automatycznej konwersji projektu z niestatycznego języka pisania na język pisania statycznego (python do haskell)

Następnie wybrał wiele projektów Pythona o otwartym kodzie źródłowym, które również zawierały rozsądną liczbę jednostek testowych, i automatycznie przekonwertował je na haskell.

Tłumaczenie na Haskell ujawniło szereg błędów związanych z typem zmiennych: błędy nie zostały wykryte przez jednostki testowe.

PBrando
źródło
4
Nieprzyjemna prawda dynamicznego pisania.
Den
6
„Tłumaczenie na Haskell ujawniło szereg błędów związanych z typem zmiennych: błędy nie zostały wykryte przez jednostki testowe.”: W języku o dynamicznym typie musisz ręcznie przetestować właściwości swojego kodu, który w sposób statyczny -typedowane języki są automatycznie sprawdzane przez kompilator. Jest to zarówno bardziej czasochłonne, jak i podatne na błędy. +1
Giorgio
4
Odpowiedziałem na post na ten link na Reddit. Nie sądzę, aby wnioski wyciągnięte z pracy były rozsądne.
Veedrac
Oba systemy pisania mają zalety / wady i ich zastosowania. To tak, jakby dyskutować o doprowadzeniu karabinu maszynowego do walki wręcz. To wojna religijna daleka od końca. To powiedziawszy, zgadzam się z Veedrac. Języki niestatyczne potrzebują więcej przypadków testowych, aby wychwycić błędy spowodowane przez typy. Taka jest ich natura i oszustwo. Ale programista musi napisać test, który wykryje błąd w kodzie spowodowany nieoczekiwanym stanem danych wejściowych, niekoniecznie wyczerpujące testowanie typu danych wejściowych.
Andre Figueiredo
10
  • Link do dyskusji na temat artykułu ACM „ Eksperyment dotyczący układów typu statycznego i dynamicznego ” (2010) autorstwa Stephana Hanenberga (do którego odwołuje się Lorin Hochstein w poprzednim poście).
  • Wniosek: Wydajność dla podobnej jakości była wyższa w dynamicznym języku.
  • Potencjalne uprzedzenia / problemy z trafnością: Wszyscy badani byli eksperymentalni. Również ograniczona różnorodność zadań programistycznych (badani zostali poproszeni o wdrożenie skanera i parsera).
  • Artykuł ACM „ Czy języki programowania wpływają na produktywność? ” (2007) autorstwa Delorey, Knudson i Chun.
  • Wniosek: JavaScript, Tcl, Perl bardziej produktywny niż C # C ++ i Java. Python i PHP znajdują się pośrodku.
  • Potencjalne błędy stronniczości / ważności: brak miary jakości (np. Błędy wykryte po wydaniu). Brak miary wiarygodności (czy oprogramowanie napisane w statycznie typowanych językach jest bardziej niezawodne?). Przykładowe uprzedzenie - wszystkie projekty zostały otwarte pobrane z repozytoriów CVS typu open source. Ponadto nie ma rozróżnienia między słabo i mocno wpisanymi językami (tzn. Wskaźnikami).
  • Teza „ Empiryczne badanie produktywności i jakości oprogramowania ” (2008) Michaela F. Sioka
  • Wniosek: wybór języka programowania nie wpływa znacząco na wydajność ani jakość. Wpływa to jednak na koszty pracy i „jakość w całym portfolio projektów oprogramowania”.
  • Potencjalne błędy stronniczości / ważności: Ograniczone do dziedziny awioniki. Języki programowania mogły być wszystkie wpisane statycznie. Nie przeczytałem pracy, więc nie mogę ocenić jej rygoru.
    Moja opinia. Chociaż istnieją słabe dowody, że dynamicznie pisane języki są bardziej produktywne, nie jest to jednoznaczne. (1) Istnieje wiele czynników, które nie były kontrolowane, (2) jest zbyt mało badań, (3) niewiele lub nie było dyskusji na temat tego, co stanowi odpowiednią metodę badania.
ahoffer
źródło
6

Oto punkt wyjścia:

Artykuł podważa powszechnie przyjętą mądrość, że programiści piszą tę samą liczbę wierszy kodu na raz, niezależnie od języka. Innymi słowy, artykuł powinien służyć jako dowód empiryczny, że produktywność mechaniczna (napisane wiersze kodu) nie jest dobrą miarą wydajności funkcjonalnej i musi być przynajmniej znormalizowana przez język.

Piet Delport
źródło
5
Jakie jest podstawowe podsumowanie dla osób spoza IEEE?
Frank Shearar
1
@Frank Shearar, doszli do wniosku, że język programowania wpływa na wydajność. Co roku mierzą wiersze kodu na programistę i język, nie jestem pewien, czy to dobra miara wydajności.
Winston Ewert
3
@Winston: To zdecydowanie błędna metryka. Przekonasz się, że COBOL jest bardzo produktywnym językiem: do zrobienia czegokolwiek przydatnego potrzeba wielu wierszy, ale są dość łatwe do napisania.
David Thornley,
Winston, David: Jestem prawie pewien, że autorzy nie sugerują, że produktywność według linii kodu jest miarą wydajności funkcjonalnej . Przeciwnie, artykuł kwestionuje powszechnie przyjętą mądrość, że programiści piszą tę samą liczbę wierszy kodu na raz, niezależnie od języka. Innymi słowy, artykuł powinien służyć jako dowód empiryczny, że produktywność mechaniczna (napisane wiersze kodu) nie jest dobrą miarą wydajności funkcjonalnej i musi być przynajmniej znormalizowana przez język.
Pi Delport,
Zgadzam się z tym. Ale nie służy to odpowiedzi na moje pierwotne pytanie.
Winston Ewert,
1

Znalazłem języki statyczne vs. dynamiczne: przegląd piśmiennictwa , w którym wymieniono niektóre badania na ten temat i podano ładne podsumowanie każdego z nich.

Oto streszczenie:

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.

Mr.WorshipMe
źródło
0

Szczerze mówiąc, nie sądzę, aby pisanie statyczne vs. dynamiczne było prawdziwym pytaniem.

Myślę, że na pierwszym miejscu powinny być dwa parametry:

  • poziom wiedzy w języku: im bardziej jesteś doświadczony, tym więcej wiesz o „gotchas” i tym bardziej prawdopodobne jest, że będziesz ich unikać / łatwo je wyśledzić. Dotyczy to również konkretnej aplikacji / programu, nad którym pracujesz
  • testowanie: Uwielbiam pisanie statyczne (piekło lubię programować w C ++: p), ale jest tyle rzeczy, które kompilator / analizator statyczny może dla Ciebie zrobić. Po prostu nie można być pewnym programu bez jego przetestowania. Jestem zwolennikiem rozmytych testów (jeśli dotyczy), ponieważ po prostu nie możesz myśleć o wszystkich możliwych kombinacjach danych wejściowych.

Jeśli znasz się na języku, napiszesz kod i z łatwością wyszukasz błędy.

Jeśli napiszesz oddzielony kod i dokładnie przetestujesz każdą funkcjonalność, to stworzysz dobrze dopracowany kod, a tym samym będziesz produktywny (ponieważ nie możesz zakwalifikować się jako produktywny, jeśli nie ocenisz jakości produktu, prawda? )

Dlatego uważam, że debata statyczna kontra dynamiczna dotycząca produktywności jest dość dyskusyjna lub przynajmniej w znacznym stopniu zastąpiona innymi rozważaniami.

Matthieu M.
źródło
2
Jeśli jest to pytanie przeciwne, gdzie jest pytanie? :) Zgadzam się, że inne czynniki są ważniejsze niż pisanie statyczne vs. dynamiczne. Jednak zwolennicy pisania dynamicznego twierdzą, że mają większą wydajność, a zwolennicy pisania statycznego twierdzą, że ma lepszą jakość kodu. Zastanawiałem się, czy ktoś miał faktyczne dowody na poparcie swoich roszczeń.
Winston Ewert
@Winston: Usunąłem bit licznika: p Jak wspomniałeś, to głównie roszczenia. Myślę, że większość zwolenników pisania dynamicznego łączy mieszanie łatwości użycia z dynamicznym pisaniem, podczas gdy łatwość użycia dotyczy głównie narzędzi. Zgadzam się, że możliwość pisania szybkich prototypów i eksperymentowania krótkich poleceń za pomocą interpretera to wzrost produktywności, ale nawet Haskell (być może język z najbardziej imponującym systemem typów w danym momencie) ma interpretera do szybkiego eksperymentowania: )
Matthieu M.,
Ale dopóki ktoś nie zrobi badania, które rozważy to pytanie - czy metodologia, narzędzia mają większy wpływ niż wskaźnik błędów na wydajność, produktywność - po prostu porównujemy anegdoty.
Frank Shearar,
0

Tu jest kilka:

  • Stefan Hanenberg. 2010. Eksperyment na temat układów typu statycznego i dynamicznego: wątpliwości dotyczące pozytywnego wpływu układów typu statycznego na czas opracowywania. W materiałach z międzynarodowej konferencji ACM na temat języków i aplikacji systemów programowania obiektowego (OOPSLA '10). ACM, Nowy Jork, NY, USA, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, „Czy języki programowania wpływają na produktywność? Studium przypadku z wykorzystaniem danych z projektów Open Source”, floss, str. 8, Pierwsze międzynarodowe warsztaty nt. Pojawiających się trendów w badaniach i rozwoju FLOSS (FLOSS '07: warsztaty ICSE 2007), 2007

  • Daly, M .; Sazawal, V., Foster, J .: Work in Progress: Empirical Study of Static Typing in Ruby, Workshop on Evaluation and Usability of Programming Languages ​​and Tools (PLATEAU) na ON-WARD 2009.

  • Lutz Prechelt i Walter F. Tichy. 1998. Kontrolowany eksperyment mający na celu ocenę korzyści wynikających z kontroli argumentów typu procedury. IEEE Trans. Oprogramowanie Inż. 24, 4 (kwiecień 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Lorin Hochstein
źródło