Jaki język programowania generuje najmniej trudnych do znalezienia błędów? [Zamknięte]

54

Jaki język, Twoim zdaniem, pozwala przeciętnemu programistowi wyświetlać funkcje z najmniejszą ilością trudnych do znalezienia błędów? To jest oczywiście bardzo szerokie pytanie, a ja interesują mnie bardzo szerokie i ogólne odpowiedzi i mądrości.

Osobiście uważam, że spędzam bardzo mało czasu na szukaniu dziwnych błędów w programach Java i C #, podczas gdy kod C ++ ma odrębny zestaw powtarzających się błędów, a Python / podobny ma własny zestaw typowych i głupich błędów, które byłyby wykrywane przez kompilator w innych językach.

Trudno mi też brać pod uwagę języki funkcjonalne pod tym względem, ponieważ nigdy nie widziałem dużego i złożonego programu napisanego w pełni funkcjonalnym kodzie. Twój wkład proszę.

Edycja: Całkowicie arbitralne wyjaśnienie trudnego do znalezienia błędu: reprodukcja zajmuje więcej niż 15 minut lub ponad godzinę, aby znaleźć przyczynę i naprawić.

Wybacz mi, jeśli to duplikat, ale nie znalazłem nic na ten konkretny temat.

— Magnus Wolffelt
źródło

10

Chciałbym zobaczyć badania przeprowadzone na ten temat! Nie tylko „moje anegdotyczne dowody sugerują, że jedynym językiem, który znam, jest królem”, ale odsetek błędów z dużych projektów i tak dalej.

— Frank Shearar,

@Frank .. jeśli miałeś DUŻO (a mam na myśli DUŻO) czasu, prawdopodobnie mógłbyś wydobyć trochę statystyk z ohloh, pod warunkiem, że możesz zidentyfikować łatki naprawiające błędy z tysięcy repozytoriów kodu.

— Tim Post

Ten, w którym dozwolone są tylko komentarze. Brak innych instrukcji :)

— Victor Hurdugaci,

4

Myślę, że „trudne do znalezienia” wymaga wyjaśnienia. Twoje pytanie i większość odpowiedzi wydają się definiować „trudne do znalezienia” jako równoważne „nie złapanym przez kompilator”. Wspominasz, że python ma głupie błędy, które zostałyby wykryte przez kompilator. Słusznie. Ale te głupie robale zwykle nie są trudne do znalezienia. Z pewnością nie należą do tej samej kategorii, co błędy C ++ wynikające ze zbyt wczesnego zwalniania pamięci.

— Winston Ewert,

@Winston Zgadzam się.

— Magnus Wolffelt,

58

Im mocniejszy system typów języka, tym więcej błędów zostanie wychwyconych w czasie kompilacji.

Poniższy rysunek porównuje niektóre z dobrze znanych języków programowania pod względem mocy, prostoty i bezpieczeństwa ich systemów typów. [ Źródło ]

alternatywny tekst

* Uwzględniając zdolność do używania niebezpiecznych konstrukcji.

C # zostaje upchnięty w niebezpiecznym wierszu ze względu na słowo kluczowe „niebezpieczne” i powiązaną maszynę wskaźnika. Ale jeśli chcesz myśleć o nich jako o wbudowanym mechanizmie funkcji obcych, możesz swobodnie podnieść C # w stronę nieba.

Haskell '98 oznaczyłem jako czysty, ale GHC Haskell jako nie czysty ze względu na niebezpieczną * rodzinę funkcji. Jeśli wyłączysz niebezpieczne *, przeskocz odpowiednio GHC Haskell.

— brakfaktor
źródło

8

To jest genialne!

7

Nie mogłem znaleźć Common Lisp na grafice: (let ((itbe '())) ... )...

— duros

7

Co? Po lewej stronie nie było już miejsca na PHP?

— pestaa

7

C # pozwala na bezpieczne wskaźniki: sprawdzana jest cała arytmetyka wskaźnika. Dlatego uważam, że powinno być tam z Javą.

— Alex ten Brink,

11

@missingfaktor: Myślę, że C # nie jest dobrze ustawiony. C # pozwala i promuje bezpieczniejsze style programowania. Nie należy mierzyć najgorszej rzeczy, na jaką pozwala.

— back2dos,

20

Moim zdaniem Haskell pomaga uniknąć niektórych typowych źródeł błędów:

jest czysto funkcjonalny: funkcje nie mogą mieć (niezamierzonych) skutków ubocznych, co sprawia, że programowanie wielordzeniowe jest łatwiejsze i mniej podatne na błędy
jest mocno wpisany: nie można np. przypadkowo wymieszać wartości bool, char, int i float
jest on wpisany statycznie: wiele błędów programistycznych jest wykrywanych podczas kompilacji
nullnie jest częścią definicji typów wartości: dzięki temu można uniknąć błędu w miliardach dolarów
istnieje wiele gotowych funkcji wyższego rzędu, których można użyć ponownie zamiast pisać własne, być może wadliwe implementacje
ma moduł wyrzucający elementy bezużyteczne: błędy pamięci są prawie całkowicie wyeliminowane (z wyjątkiem „przecieków przestrzeni” z powodu leniwej strategii oceny)

— LennyProgrammers
źródło

11

Nie będę głosować za tym, ale kusi mnie to, ponieważ nie spełnia kryteriów. Ma to pozwolić „przeciętnemu programistowi wyprowadzać funkcje” przy minimalnej liczbie błędów, ale przeciętny programista, mówiąc wprost, nie jest w stanie zrobić główek ani ogonów Haskella.

— Mason Wheeler,

5

Wiele dobrych punktów, ale usuwając niektóre klasy błędów (niezamierzone skutki uboczne, nieoczekiwane konwersje typu) Haskell dodaje zupełnie nową klasę błędów: przecieki przestrzeni. (Również, chociaż nie ma null, istnieje undefined, który jest członkiem każdego typu.)

— j_random_hacker

5

@Mason: Jeśli nie piszesz, nie możesz mieć w tym żadnych błędów :)

— Michael K

2

Wydaje mi się, że nie ma czegoś takiego jak darmowy lunch - możesz mieć łatwe do znalezienia błędy lub łatwe do napisania kody, ale nie jedno i drugie :)

— Benjol

6

@Mason czym dokładnie jest „przeciętny programista”? Pytanie zaczyna się od „jaki język programowania ...”, a nie „który spośród C, C ++ i java ...”;)

— Agos

18

Tradycyjnie najtrudniejsze do znalezienia błędy to takie same warunki wyścigowe w aplikacjach wielowątkowych

prawie niemożliwe do odtworzenia
może być bardzo subtelny

Dlatego potrzebujesz języków, które zarządzają dla ciebie paraliżem tak bardzo i nieinwazyjnie, jak to możliwe. Nie są to jeszcze główne nurty. Java robi trochę, ale zostawia cię z trudną częścią.

Według mnie potrzebujesz funkcjonalnego języka, ponieważ „brak efektów ubocznych” to przede wszystkim to, że dwa pociski znikają. Widziałem, że trwają prace nad przezroczystym uczynieniem Haskell wydajnym językiem wielowątkowym, i uważam, że Fortress został zaprojektowany od podstaw jako wydajny język równoległy.

Edycja: w Javie Executorsobsłuż jeszcze więcej twardych części. Musisz dostosować poszczególne zadania do Callableinterfejsu.

— 1249
źródło

5

++ Warunki wyścigu. Możesz powtórzyć.

— Mike Dunlavey,

Tak. Pamiętaj, że obliczenia równoległe w ogóle są trudne, nawet przy pomocy języka. (Często używane makra Lisp są trudne, pomimo dużej obsługi języka, ponieważ to, co robią, jest bardzo potężne. Ta sama zasada.)

— David Thornley,

Co z Erlangiem?

— Malfist,

@Malfist, nie wiem wystarczająco dużo o Erlangu, aby na to odpowiedzieć. Być może powinieneś otworzyć pytanie, jeśli naprawdę chcesz wiedzieć?

2

Erlang to funkcjonalne programowanie zaprojektowane tak, aby wielowątkowość była prosta i bezpieczna. Nie udostępniasz zmiennych, przekazujesz wiadomości. Przeczytaj stronę Wikipedii.

— Malfist,

13

Ada została zaprojektowana tak, aby w miarę możliwości wychwytywano jak najwięcej podczas kompilacji, a nie w czasie wykonywania. Oznacza to, że często kompilacja programu w Adzie zajmuje około 10 razy więcej niż powiedziałby odpowiednik w Javie, ale kiedy się kompiluje, możesz być bardziej pewny, że całe klasy błędów nie pojawią się, gdy program biegać.

— Mark Pim
źródło

7

+1 za prawidłowe zauważenie, że Ada łapie w kompilatorze rzeczy, które inne języki ignorują. -1 dla twierdzenia, że oznacza to, że potrzeba 10 razy dłużej, aby skompilować program Ada. Ada nagradza programistę, który PROJEKTUJE !!! jego kod, który MYŚLI !!! o tym, co robi, zanim zacznie szaleńczo pisać. Moje osobiste doświadczenia związane z programowaniem produkcji w Adzie do pracy w obronie polegały na tym, że skompilowanie kodu Ady nie trwało dłużej niż w C / C ++ lub FORTRAN, ale kod Ady miał później znacznie mniej problemów. Pratt i Whitney zauważyli coś podobnego.

— John R. Strohm,

1

@ john r strohm, z tego, co rozumiem, nie mówi on o czasie, który zajmuje kompilatorowi na skompilowaniu kodu, a raczej o czasie, aby kompilować kod.

— Malfist,

oh zgodził się na kompilację kodu. Pamiętam całkiem sporo seksistowskich komentarzy programistów uczących się języka na temat wybierania nitów. Zwykle w stylu Cóż, jeśli nazywasz język po kobiecie ...

— Michael Shaw

@Polememy, jeśli łodzie można nazwać po kobietach (z wyjątkiem najwyraźniej amerykańskich przewoźników), języki programowania też mogą. Zamiast tego ma on nazwę „Ada” niż „USS Ronald Reagan” :)

1

Po przejściu przez krzywą uczenia się zacząłem pisać kod Ady dość szybko - po tym, jak spędziłem sporo czasu na przemyśleniu projektu. Ada zdecydowanie NIE jest językiem hakera. Obecnie pracuję w Javie, a niektóre rzeczy, które widzę w moich obecnych projektach, tak naprawdę trochę tęsknię za Adą (nigdy nie sądziłem, że to powiem).

— James Adam

7

Po pierwsze definicja: trudny do znalezienia błąd, tak jak go rozumiem, to błąd, który można odtworzyć, ale jego przyczyna jest trudna do znalezienia.

Prawdopodobnie najważniejszym aspektem jest to, co nazwałbym wąskością , tj. Jak daleko może uciec błąd, jak duży jest zasięg, na jaki błąd może potencjalnie wpłynąć. W językach takich jak C błąd, np. Ujemny indeks tablicy lub niezainicjowany wskaźnik, może wpływać dosłownie na wszystko w całym programie, więc w najgorszym przypadku musisz sprawdzić wszystko wszędzie, aby znaleźć źródło problemu.

Dobre języki pod tym względem wspierają modyfikatory dostępu i egzekwują je w sposób, który utrudnia lub uniemożliwia ich obejście. Dobre języki zachęcają do ograniczenia zakresu zmiennych, zamiast zbyt łatwego posiadania zmiennych globalnych (np. „Wszystko, co nie zostało wyraźnie zadeklarowane, jest zmienną globalną o domyślnym typie i wartości”).

Drugim ważnym aspektem jest współbieżność . Warunki wyścigowe są na ogół trudne do odtworzenia, a zatem trudne do znalezienia. Dobre języki oferują łatwe w użyciu mechanizmy synchronizacji, a ich standardowe biblioteki lib są w razie potrzeby bezpieczne dla wątków.

To już uzupełnia moją listę; inne rzeczy, takie jak mocne pisanie, pomagają wykrywać błędy w czasie kompilacji, ale te błędy prawdopodobnie nie będą trudne do znalezienia później.

Biorąc to wszystko pod uwagę, powiedziałbym, że Java i C # oraz wiele innych języków w JVM i .net są odpowiednie, aby uniknąć trudnych do znalezienia błędów.

— użytkownik 281377
źródło

Ręczne blokowanie może wydawać się „łatwym w użyciu mechanizmem synchronizacji”, ale tak naprawdę jest „tylko proste w użyciu, ale masz czas na zabawę, gdy gonisz za tym impasem”. Cóż, możesz wykonywać współbieżność opartą na Aktorach w kilku językach.

— Frank Shearar,

Frank: przynajmniej blokowanie jest wystarczająco proste, aby każdy mógł to zrobić bez spędzania dni, zastanawiając się, którego interfejsu API użyć itp.

— 281377

Jest też punkt widzenia, że rozwiązanie do współbieżności, które „jest wystarczająco proste, aby każdy mógł to zrobić”, przypomina dawanie pił stołowych przedszkolakom.

— David Thornley,

@David: Rozumiem, o co ci chodzi, ale w wielu przypadkach wystarczy proste rozwiązanie. Rozważmy na przykład serwlet używany tylko przez garstkę użytkowników, który musi korzystać z udostępnionego zasobu (np. Połączenia z bazą danych). Bez synchronizacji od czasu do czasu zdarzają się warunki wyścigu; ale umieszczenie wszystkich operacji dostępu do bazy danych w bloku zsynchronizowanym (połączenie) {} nie jest do końca rakietą.

— user281377,

+1 Dla tej definicji „jak duży jest zasięg, na który błąd może potencjalnie wpłynąć”. Miałem kilka bardzo nieprzyjemnych błędów z dynamicznymi językami, w których obiekt niewłaściwego typu danych dostał się bardzo daleko w kodzie (dzięki pisaniu kaczek), zanim przejawił się jako błąd.

— Giorgio

7

Ponieważ Excel jest najczęściej używanym DSL, skorzystam z Excela. (oczywiście z wyłączeniem VBA)

Pasuje do rachunku:

Reprodukcja jest zawsze łatwa (oto arkusz kalkulacyjny - nie działa)
Łatwo jest znaleźć błąd, ponieważ jest on całkowicie „funkcjonalny” - zacznij od nieprawidłowej komórki i prześledzić wszystkie jej zależności.

— Scott Whitlock
źródło

Może tak być, o ile nie dodajesz łatwych do znalezienia błędów.

— mouviciel

+1 Trochę bezczelny, ponieważ Excel to dane, a nie język. Dobrze się śmiałem :)

— recursion.ninja

2

@awashburn - och, nie wiem. Myślę, że kwalifikuje się jako język. Każda komórka jest „zmienną”. Każda zmienna jest deklaratywnie ustawiona jako literał (taki jak 123lub ABC) lub funkcja ( =SUM(A2:A5)). Excel następnie ocenia wszystkie zmienne, ustalając kolejność rozwiązywania zależności itp. Z pewnością nie są to tylko dane.

— Scott Whitlock

2

Wycofuję moje oświadczenie, okazuje się, że Excel jest Turing Complete ... Nauczyłem się czegoś całkowicie niepokojącego ...

— recursion.ninja

1

„... prawdziwy mistrz [Lisp] zdaje sobie sprawę, że wszystkie dane to kod.” Być może dotyczy to również Excela, dość dziwnie. blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

To trudne pytanie, ponieważ większość błędów nie wynika z samego języka - raczej z winy programistów, którzy popełniają błędy w używaniu języka.

Uważam, że istnieje kilka aspektów funkcji językowych, które wpływają na prawdopodobieństwo błędów:

Interaktywność - dynamiczne języki z REPL zachęcają do interakcji / eksperymentów z uruchomionymi programami i znacznie mniejszymi cyklami kodu / testów. Jeśli uważasz, że iteracja jest dobrym sposobem na znalezienie czystych prostych rozwiązań i wykrycie / wyeliminowanie błędów, wówczas faworyzuje to interaktywne języki.
Ekspresyjność - jeśli kod jest krótszy i ma mniejszą złożoność / przypadkową złożoność, łatwiej jest dostrzec błędy / błędy logiczne.
Bezpieczeństwo typu - im więcej sprawdzania czasu kompilacji, tym więcej błędów zostanie wychwyconych przez kompilator, więc ogólnie bezpieczeństwo typu jest dobrą rzeczą. Jednak zwykle nie są trudne do znalezienia błędów - nawet w pełni dynamicznym języku niewłaściwy typ w strukturze danych zwykle powoduje bardzo oczywisty błąd w czasie wykonywania, a TDD prawie zawsze wykrywa takie błędy.
Niezmienność - wiele trudnych błędów jest spowodowanych złożonymi interakcjami stanu zmiennego. Języki, które podkreślają niezmienność (Haskell, Clojure, Erlang) mają ogromną przewagę, unikając zmienności
Programowanie funkcjonalne - funkcjonalne podejście do pisania kodu jest bardziej „możliwe do udowodnienia” niż kod obiektowy ze złożonymi sekwencjami efektów / interakcji. Z mojego doświadczenia wynika, że FP pomaga uniknąć trudnych błędów - wierzę, że są gdzieś jakieś badania naukowe, których obecnie nie mogę znaleźć, które to potwierdzają.
Obsługa współbieżności - problemy z współbieżnością są szczególnie trudne do wykrycia i debugowania, dlatego jest to tak ważne. Wszystko, co wymaga ręcznego blokowania, jest ostatecznie skazane na niepowodzenie (a obejmuje to prawie każde podejście obiektowe do współbieżności). Najlepszym językiem, jaki znam pod tym względem, jest Clojure - ma unikalne podejście do zarządzania współbieżnością, które łączy w sobie pamięć transakcyjną oprogramowania z niezmiennymi strukturami danych, aby uzyskać nowatorską, niezawodną i możliwą do skomponowania strukturę współbieżności. Aby uzyskać więcej informacji, zobacz http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

— mikera
źródło

Ludzie tacy jak ja, którzy są pasjonatami programowania funkcjonalnego, doceniają tę odpowiedź. Ekspresyjność jest twoim przyjacielem.

— Sridhar Sarnobat

1

Najlepsza odpowiedź do tej pory! Myślę, że jest to poparte następującymi dwiema analizami częstotliwości błędów: deliberate-software.com/safety-rank-part-2 i macbeth.cs.ucdavis.edu/lang_study.pdf . Oba pokazują, że im czystszy, im bardziej funkcjonalny, tym bardziej wyrazisty i bezpieczniejszy język, tym mniej błędów ma. Podobnie, oba pokazują, że Clojure i Ruby uciekają od zasady bezpieczeństwa, prawdopodobnie wskazując, że interakcja ma taki sam wpływ, jak wskazałeś.

— Didier A.

@DidierA. niestety link ucdavis jest zepsuty (bez archiwum wbm) - myślę, że dostałeś go ze strony Prem Devanbu, która teraz wskazuje na zaktualizowany link: Badanie na dużą skalę języków programowania i jakości kodu w Github

— icc97

5

Im słabszy jest język, tym mniej opcji daje ci strzelanie własną stopą.

Języki wysokiego poziomu, takie jak Java i C #, będą generować mniej błędów niż języki niskiego poziomu, takie jak C ++.

Powiedziawszy, że uważam, że Java jest bezpieczniejsza niż C #. Java jest sztucznie ograniczona, więc przeciętny programista bez zaawansowanej wiedzy może ją opanować i tworzyć stabilne programy.

— wersje user8685
źródło

4

+1 dla „Im słabszy jest język, tym mniej opcji daje mu się zastrzelić własną stopę”.

— Michael K

Wykres z brakującego faktora zdaje się mówić, że C # i C ++ są na równi, jeśli chodzi o to, aby móc się tam zastrzelić, i podnosi Javę ponad to. Jednak nie zgadzam się z tą częścią wykresu. Jesteś zmuszony przejść przez obręcze, aby strzelać do C #.

— Jesse C. Slicer,

6

Bezpieczeństwo i moc nie są odwrotnie proporcjonalne (wydaje się, że tak myślisz ;-) Haskell, na przykład, jest BARDZO potężny, a jednak ma bardzo niewiele sposobów na strzelanie sobie w stopy.

— missingfaktor

3

Jeśli język jest słaby, potrzebujesz tylko większej stopy.

7

@missingfaktor, ponieważ jest to efekt uboczny strzelania sobie w stopę.

3

Jaki język, Twoim zdaniem, pozwala przeciętnemu programistowi wyświetlać funkcje z najmniejszą ilością trudnych do znalezienia błędów?

Moim zdaniem Delphi. Oparty na Pascalu, język jest wystarczająco prosty i intuicyjny, aby przeciętny programista (a nawet niedoświadczony programista) mógł go łatwo odczytać, a jego bogate narzędzie i obsługa biblioteki ułatwiają znalezienie większości błędów.

Silne pisanie i ścisły kompilator wychwytujący wiele typowych błędów.
Intuicyjna składnia, która nie zachęca do typowych błędów. (Na przykład „Ostatni błąd na świecie” if (alert = RED) {LaunchNukes;}nie zostanie skompilowany).
Dobrze zaprojektowany model obiektowy, który eliminuje wiele typowych błędów OOP C ++.
Sprawdzanie granic i sprawdzanie zasięgu wbudowane w język, drastycznie zmniejszające ryzyko problemów z bezpieczeństwem.
Prawdopodobnie najszybszy kompilator znany człowiekowi, który zwiększa produktywność i utrudnia utratę myślenia podczas oczekiwania na kompilację.
Debuger Debuger programu Visual Studio chce być, gdy dorośnie.
Śledzenie wycieków wbudowane bezpośrednio w menedżerze pamięci, dzięki czemu wyszukiwanie i usuwanie wycieków pamięci jest banalne.
Duża, dojrzała standardowa biblioteka zapewniająca gotowe i przetestowane sposoby wykonywania typowych zadań bez konieczności budowania własnych, prawdopodobnie błędnych implementacji.
Dostarcza użyteczne narzędzia, takie jak potężny system rejestrowania i profiler, aby ułatwić śledzenie problemów.
Silne wsparcie społeczności dla typowych problemów, których nie ma w standardowej bibliotece, w tym potężna biblioteka współbieżności innych firm .

— Mason Wheeler
źródło

Jestem dżokejem z Delphi od dawna, ale odeszło od korzeni Pascala, kiedy pozwoliło mi to przypisać cokolwiek do niczego innego, a la C / C ++:var I: Integer; Pointer(I)^ := $00;

— Jesse C. Slicer

1

@Jesse: Być może, ale uważam to za konieczne ustępstwo wobec pragmatyzmu. Kernighan napisał wiele dobrych punktów, gdy napisał, dlaczego Pascal nie jest moim ulubionym językiem programowania. Rzutowanie jest niezbędne, aby wykonać wiele ważnych rzeczy na niskim poziomie. Ale jedną z mocnych stron Delphi jest sposób, w jaki jego biblioteki zawierają szczegóły niskiego poziomu i sprawiają, że większość niebezpiecznego wskaźnika i typografii nie jest potrzebna.

— Mason Wheeler,

Nie zgadzam się, że może to być konieczne - ale twierdzenie, że pisanie z silnym pisaniem jest przez to nieco negowane. Pierwotny Pascal nie pozwalał na takie shenanigany i dlatego był mocno napisany na maszynie. Ale nie posunąłbym się tak daleko, by nazwać Delphi słabym pisaniem - to rodzaj „średnio dobrze napisanego”.

— Jesse C. Slicer,

1

@Jesse: Czy oryginalna wersja Pascala Wirtha nie pozwalała na zapisy wariantów? IIRC ostatecznie stały się tak powszechnie używane do obalenia silnego pisania, że Borland i inni postanowili po prostu wstawić typecasta, aby było to prostsze, ponieważ wszyscy i tak to robili.

— Mason Wheeler,

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisions and en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism, jak również pascal-central.com/ppl/chapter3.html wydają się wskazywać, że to część pierwszy standard w 1983 roku. Widzę kilka odniesień Wirtha, które wydają się być datowane na 1974 rok, więc powiedziałbym, że tak. Myślę, że część problematyczna polegała na tym, że można ją było obalić jako taką (warianty zajmujące tę samą pamięć, jak związki w C). Gdyby były one po prostu używane jako mechanizm określania zakresu, a układ pamięci był przeznaczony dla nadzbiórki, byłby silniej napisany.

— Jesse C. Slicer,

2

Jedną z rzeczy, które należy wziąć pod uwagę, jest zwrot w czasie.

Przez ostatnie pięć lat głównie tworzyłem aplikacje internetowe w Javie (JSF, Seam itp.). Niedawno dostałem nową pracę i korzystamy z Perla (z Catalyst i Moose).

W Perlu jestem znacznie bardziej produktywny niż w Javie.

Jednym z powodów jest brak konieczności kompilacji i (gorącej) instalacji. Uważam również, że pisanie przypadków użycia jest łatwiejsze, ponieważ można to zrobić w bardziej iteracyjny sposób. A frameworki w Javie wydają się niepotrzebnie złożone, przynajmniej w przypadku projektów, w które byłem zaangażowany.

Wydaje mi się, że liczba błędów w moim kodzie Perl jest mniej więcej taka sama jak liczba błędów w moim kodzie Java, może nawet być wyższa. Ale znajduję i łatwiej i szybciej znajduję i naprawiam te błędy.

— slu
źródło

1

Być może badanie liczby dostępnych narzędzi do statycznej i dynamicznej analizy kodu dla każdego języka programowania może dać pomysł. Im więcej narzędzi dla danego języka, tym bardziej prawdopodobne jest, że język ten jest albo bardzo popularny wśród użytkowników, albo bardzo popularny w generowaniu trudnych do znalezienia błędów. Ale nie mogę zmusić Google do wskazania jakichkolwiek badań na ten temat. Należy również zauważyć, że niektóre języki, takie jak C, mogą być używane do obejścia podstawowych błędów sprzętowych, a także do obejścia zużycia sprzętu w miarę starzenia się.

— vpit3833
źródło

1

„obejść zużycie sprzętu w miarę starzenia się” ...?

— j_random_hacker

Czytałem, że niektóre systemy operacyjne Unix działające na maszynach o znaczeniu krytycznym sprawdzają kondycję procesora, pamięci RAM i innego sprzętu. serverfault.com/questions/56192/... omawia to dogłębnie. Jeśli niektóre linie w module RAM z czasem ulegną uszkodzeniu, te wadliwe moduły nie będą używane przez system operacyjny i nie będą raportować ich w całkowitej dostępnej pamięci fizycznej. Takie rzeczy można zrobić również na innym sprzęcie.

— vpit3833,

To ciekawa ciekawostka, ale nie rozumiem, jak ma to znaczenie. Również nic w twoim linku nie wspomina o samonaprawiających się systemach Unix - mówi tylko o sposobach testowania warunków skrajnych sprzętu komputera.

— j_random_hacker

1

Wspomniałem, że oznacza to, że same programy mogą nie być źródłem błędów, może to być także sprzęt lub inne czynniki zewnętrzne.

— vpit3833,

1

Zamiast mówić o językach, co z mówieniem o funkcjach językowych

java zmusza cię do myślenia o wyjątkach (rzuca ...) i musisz opublikować lub obsłużyć te wyjątki. Czy to naprawdę uniemożliwia mi zapomnienie błędów, czy też używam więcej wyjątków wynikających z SystemException, które nie wymagają tej obsługi?
co z „projektowaniem na podstawie umowy” (http://en.wikipedia.org/wiki/Design_by_contract), które zmusza mnie do myślenia o warunkach wstępnych i późniejszych. Przeczytałem, że jest to teraz możliwe dzięki c # -4,0.

— k3b
źródło