Czy dynamiczne języki maszynowe zasługują na całą krytykę? [Zamknięte]

35

Przeczytałem kilka artykułów w Internecie na temat wyboru języka programowania w przedsiębiorstwie. Ostatnio popularne jest wiele dynamicznych języków pisanych, tj. Ruby, Python, PHP i Erlang. Ale wiele przedsiębiorstw nadal korzysta z języków o typie statycznym, takich jak C, C ++, C # i Java.

I tak, jedną z zalet statycznych języków typowych jest to, że błędy programistyczne są wykrywane wcześniej, w czasie kompilacji, a nie w czasie wykonywania. Ale są także zalety dynamicznych języków maszynowych. ( więcej na Wikipedii )

Głównym powodem, dla którego przedsiębiorstwa nie zaczynają używać języków takich jak Erlang, Ruby i Python, wydaje się być fakt, że są one pisane dynamicznie. To także wydaje się być głównym powodem, dla którego ludzie na StackOverflow decydują się na Erlanga. Zobacz, dlaczego zdecydowałeś się „przeciw” Erlangowi .

Wydaje się jednak, że istnieje silna krytyka przeciwko dynamicznemu pisaniu w przedsiębiorstwach, ale tak naprawdę nie rozumiem, dlaczego jest tak silny.

Naprawdę, dlaczego jest tak wiele krytyki przeciwko dynamicznemu pisaniu w przedsiębiorstwach? Czy tak naprawdę wpływa to tak bardzo na koszty projektów, czy co? Ale może się mylę.

— Jonas
źródło

3

Myślę, że pisanie statyczne z wnioskowaniem typu i możliwym pisaniem kaczek jest najlepszym możliwym sposobem robienia rzeczy. Jest to również bardzo skomplikowane

— Casebash

2

Właśnie rzuciłem okiem na pisanie kaczką w C # (nie używam tego języka) i chociaż wydaje się, że wypełnia definicję kaczego pisania, wymagana szczegółowość wydaje się pokonywać cel. Nie oznacza to jednak, że czasami nie jest to przydatne.

— Chinmay Kanchi,

3

Czy to tylko ja, czy jest więcej krytyki języków pisanych statycznie niż języków pisanych dynamicznie? Z mojego doświadczenia wynika, że wybory językowe / technologiczne dużych „przedsiębiorstw” wydają się być podyktowane raczej obecnymi trendami / bezpiecznymi wyborami niż prawdziwymi zaletami technicznymi.

— MAK

2

@ChinmayKanchi: Szczegółowość? Po prostu zadeklarujesz coś jako dynamici zaczniesz go używać. Nie jest to bardziej szczegółowe niż zwykłe wywołania metod lub przeciążenia operatora.

— Joey,

4

Nie mogę zliczyć liczby godzin, które zmarnowałem na bieżące błędy w debugowaniu mojej firmy w kodzie Groovy na kodzie Grails, które kompilator wykryłby natychmiast, gdybyśmy użyli Javy.

— WKS

46

Tak, wierzę, że tak.

Przy wyborze języka dla nowego projektu należy wziąć pod uwagę kilka powodów:

Szybkość działania W porównaniu do C / C ++ / Fortran, Perl i Python są tak wolne, że jest zabawne.
Szybkość inicjalizacji. W porównaniu z powyższymi szybkimi językami, Java przewraca się i płacze, gdy JVM ładuje się i ładuje i ... while(1)....
Zdolność prototypowa. Wyczerpujące przechodzenie i wykonywanie prac związanych z deklaracją / definicją wymaganych dla C ++ lub Java zwiększa LOC, który jest jedyną znaną miarą, która niezawodnie koreluje z liczbą błędów. Zajmuje to również dużo czasu. Wymaga to również nieco więcej myślenia o typach i połączeniach.
Wewnętrzna płynność. Dynamiczne mieszanie się z elementami wewnętrznymi jest świetne, dopóki nie zaczniesz debugować samodomodującego się kodu . (Python, Lisp, Perl)
Weryfikacja poprawności. Kompilator może zapewnić szybkie powtórzenie pół-poprawności kodu w C ++, a to może być naprawdę miłe.
Szczegóły analizy statycznej. C i Java mają dość dobrą analizę statyczną. Perl nie jest w pełni statystycznie analizowany na poziomie teoretycznym (prawdopodobnie również Python). Jestem dość pewien, że Lisp też nie jest.
Dziwne platformy przyjmują ogólnie tylko C.
Łańcuch wsparcia. Jeśli możesz mieć umowę, w której będziesz sprawdzać i pracować nad błędami, to ogromne .

Jeśli możesz założyć, że organizacja, z którą współpracujesz, ma zasadę „iść naprzód” (jest to termin księgowy) i nie po prostu losowo zdecyduje się nie pracować na oprogramowaniu, masz o wiele lepsze argumenty za za pomocą oprogramowania. Ponieważ nie ma sprzedaży dużych firm (pociągającej za sobą przejęcie odpowiedzialności za utrzymanie) Python / Perl / $ język_ dynamiczny, znacznie zmniejsza to ryzyko.

Z mojego doświadczenia wynika, że opiekunowie oprogramowania typu open source często mają problem z pełną odpowiedzialnością za poprawki błędów i publikowaniem aktualizacji. „To nic nie kosztuje, TY nad tym pracujesz!” to nie jest odpowiedź, że jest do zaakceptowania dla większości firm (nie ich podstawowych compentencies, między innymi).

Oczywiście nie mówię o świecie aplikacji internetowych / startupów, który zwykle gra według zasad wysokiego ryzyka / wysokich nagród i jest bardzo otwarty na pozostawanie na krawędzi spienionej technologii.

— Paul Nathan
źródło

16

„To nic nie kosztuje, TY nad tym pracujesz!” <- Największy problem z F / OSS w ogóle,

— dałbym

4

Ładne podsumowanie. Przypiszę, że dobrze skonstruowane typy przekazują znaczenie semantyczne (mogę spojrzeć na typ i zrozumieć, co on robi, w jaki sposób można go używać) i można go użyć do wymuszenia poprawności (mogę zbudować typ, który akceptuje tylko ograniczony inpus ) i nie dostaję głupich błędów w literówkach (nienawidzę deklaracji automatycznej zmiennej)

— smithco,

4

Możesz uzyskać komercyjne wsparcie dla każdego dużego projektu typu open source. Duże firmy używają dynamicznie wpisywanego PL do dużych części (na pewno odpowiednie), Facebook używa PHP (UI) i Erlang (czat), Twitter używa Ruby (UI), Google używa Python (nie wiem po co), a Lisp i Python to stosowane w wielu zaawansowanych projektach badawczych. Uwaga: Jestem programistą C # (prawie) nigdy nie używałem dynamicznie pisanego języka; jednak punkty te nie są ważne w znacznym stopniu.

— Kaveh Shahbazian

4

Podoba mi się twoja odpowiedź, ale Java nie jest dynamicznie wpisywana ...

— Mehrdad

2

@PaulNathan: Za dużo myślisz. Pytanie dotyczyło języków dynamicznie wpisywanych, a ta odpowiedź wspomina o Javie tak, jakby była pisana dynamicznie.

— Mehrdad

24

Dajesz zdecydowanie zbyt dużo kredytu technicznego decydentom Enterprise. Jest takie stare powiedzenie: „Nikt nie został zwolniony za kupowanie IBM”. Jeśli pójdziesz inną drogą i wszystko się ułoży (zawsze tak jest), nikt nie chce ryzykować obwinienia. Trzymaj się standardów i obwiniaj kogoś innego.

Istnieje wiele młodszych firm, które ostatecznie staną się przedsiębiorstwami jutra i będą używać tych języków.

I nie zapominajmy o błędnych liniach kodu napisanych w VBA!

— JeffO
źródło

1

+1 za „... przedsiębiorstwa jutra [i] będą używać tych języków”.

— rdmueller

6

„Istnieje wiele młodszych firm, które ostatecznie staną się przedsiębiorstwami jutra i będą używać tych języków.”: Wydaje się, że sugerujesz, że dynamiczne języki są raczej nowe i potrzebują czasu na przyjęcie przez kolejne firmy. Z drugiej strony języki dynamiczne istnieją już od dawna.

— Giorgio

17

Powodem, dla którego przedsiębiorstwa używają C, C ++, C # i Java, nie jest to, że są one wpisywane statycznie (przynajmniej nie bezpośrednio). Zapewniam, że decydenci w przedsiębiorstwach nie dokonują tego rodzaju wyborów na podstawie obiektywnego porównania systemów typów.

Przedsiębiorstwa zrobić dbałość o:

Długoterminowe koszty utrzymania : czy można oczekiwać, że po 10 latach wszystko będzie dobrze działać? Dobrze jest, jeśli ewolucja języka jest konserwatywna i kompatybilna wstecz (jak w Javie). W tym przypadku pomocne jest wpisywanie statyczne, ponieważ wychwytuje duży typ błędów w czasie kompilacji, zanim trafią one do systemów produkcyjnych .....
Dostępność talentów - czy będziesz w stanie znaleźć programistów, którzy utrzymają Twój błyszczący nowy system? co jeśli oryginalny programista odejdzie, czy wszyscy inni zrozumieją kod? Stanowi to dużą przeszkodę we wprowadzaniu jakiegokolwiek „nowego” języka (zwłaszcza jeśli stwarza nowe wymagania dotyczące wdrażania, budowania systemów, wsparcia operacyjnego itp.). Daje to ogromne korzyści powszechnie używanym językom (C, C ++, C # i Java)
Koszty integracji : czy łatwo jest łączyć się / integrować z innymi technologiami, które już masz lub które możesz nabyć? Jeśli masz już stos starszych systemów J2EE, musisz się z nimi zintegrować. Nowe rozwiązanie Java EE może być do tego znacznie bardziej praktyczne niż np. Python.
Przewidywalność / niskie ryzyko : czy platforma / język jest sprawdzony i czy mogę być pewien, że zadziała? Zazwyczaj jest to bardziej istotne niż proste produktywności. Menedżerowi znacznie łatwiej jest przekonać szefa, aby dał mu duży budżet na siłę roboczą do zbudowania nowego systemu, niż gdyby mógł wrócić później i powiedzieć, że to nie zadziałało .....
Wsparcie / wsparcie dla przedsiębiorstw - czy główne organizacje międzynarodowe są zaangażowane we wspieranie języka i platformy? Czy podpiszą umowę, aby mnie wspierać, abym miał do kogo zadzwonić, jeśli coś pójdzie nie tak?
Neutralność dostawcy / niezależność platformy - czy zamierzam zostać zamknięty na jednym dostawcy? Czy mam dostęp do szerokiej gamy przyszłych opcji dostawców / ścieżek przejścia? Nie chcesz tkwić w architektonicznym ślepym zaułku, nie być w stanie robić postępów, gdy konkurenci jedzą lunch. Jeśli dobrze wykonujesz swoją pracę jako architekt korporacyjny, musisz myśleć o tym co najmniej 5-10 lat wcześniej.

Osobiście uważam, że jeśli chcesz używać dynamicznych języków w Enterprise, to twoja najlepsza szansa to zdecydowanie skorzystanie z czegoś, co łączy się z istniejącym ekosystemem przedsiębiorstwa. Najbardziej godne uwagi są nowe dynamiczne języki JVM: np. JRuby, Groovy, Clojure. Jeśli chodzi o zarządzanie IT, są to „bezpieczne” dynamiczne wybory językowe, ponieważ działają one wewnątrz i ładnie współpracują z resztą ekosystemu Java firmy.

— mikera
źródło

1

Nie mogę uwierzyć, że nikt jeszcze nie ocenił twojej odpowiedzi.

— Sebastian N.

11

Głównym powodem, dla którego przedsiębiorstwa nie zaczynają używać języków takich jak Erlang, Ruby i Python, wydaje się być fakt, że są one pisane dynamicznie.

Myślę, że to tylko ich podstawowa wymówka. Prawdziwy powód jest taki, że firmy tak naprawdę nie traktują ich tak poważnie i uważają, że są może zbyt amatorskie. Java i .NET to „wielkie firmy”, mają dobry marketing komercyjny, obsługę klienta komercyjnego i dlatego są bardzo poważnie traktowane bardzo poważnie.

Szkoda, że praktycznie nie ma języka o typie statycznym, który byłby tak popularny jak nazwy dużych firm. Dlaczego środowiska programistyczne typu open source / wolne oprogramowanie prawie zawsze są dynamicznie pisane? Może to wskazywać, że statycznie pisany język nie jest tak łatwy do zrobienia, a dynamiczne pisanie jest „hackem leniwego mężczyzny”. W takim przypadku firmy, które decydują się na języki dynamicznie pisane, mogą mieć rację.

— Timwi
źródło

8

Naprawdę? Ostatnio widziałem, że Google rzucił sporo wagi i znaczny wysiłek rozwojowy za Pythonem, w tym zatrudnienie twórcy Pythona i umożliwienie mu spędzenia 50% czasu na pracy nad językiem. Google wnosi także sporo kodu do Pythona, zwłaszcza teraz, gdy nieobciążona jaskółka została scalona z drzewem źródłowym Pythona 3. To sprawia, że Python jest dla mnie „wielką firmą”.

— Chinmay Kanchi,

13

@Chinmay Kanchi: Interesujące, w jaki sposób wyciągasz wnioski ze statystyki z wielkością próby 1.

— Timwi

6

Touché. Jednak niektóre z twoich wniosków są również błędne. Prawidłowe wdrożenie języka dynamicznego jest znacznie trudniejsze niż wdrożenie języka o typie statycznym. Pisanie dynamiczne z pewnością nie jest „hackem leniwego mężczyzny”. Pozwala programistom być leniwym, ale nie osobą, która pisze kompilator / tłumacz. W rzeczywistości optymalizacja dynamicznie typowanego języka jest tak trudna, że mogę myśleć tylko o jednym języku, który w ostatnim czasie otrzymał obszerne leczenie (JavaScript), chociaż istnieją projekty optymalizacji / JIT dla innych języków (Python, PHP).

— Chinmay Kanchi,

2

Ponadto, jeśli uważasz, że dynamicznie pisane języki są najczęściej używane w środowiskach typu open source, nie jest to jednoznaczne. W zależności od wybranych danych może to być prawda, ale często tak nie jest. C mierząc linie kodu, C wygrywa z dystansu. Jeśli zmierzysz, jakie języki są używane w projektach open source, w tym wielojęzycznych, najpopularniejszymi językami są JavaScript, C, C ++ i PHP w tej kolejności. Jeśli mierzysz tylko język podstawowy, najpopularniejszymi językami są Perl, Java, C # i JavaScript. bit.ly/C6xTB

— Chinmay Kanchi

7

Oczywiście napisanie optymalizatora dla języków z dynamicznym pisaniem jest trudne, ale nie jest to tłumacz : możesz zrezygnować ze sprawdzania wszystkich typów, a reszta jest taka sama. Żaden amator języka nie myśli o napisaniu optymalizatora. - Jeśli chodzi o ostatni kawałek, nie chciałem sugerować, że większość oprogramowania typu open source jest napisana w dynamicznie pisanym języku programowania, ale raczej w większości języków programowania typu open source (powiedziałem „środowiska”, ponieważ mówię o kompilatory / interpretatory, IDE itp.) są dynamicznie pisane.

— Timwi

9

Języki o typie dynamicznym są zwykle wolniejsze niż ich kuzyni o typie statycznym.
Błędy są trudniejsze do wykrycia i trudniejsze do debugowania
Kompilator / interpreter jest o wiele mniej wybredny w kwestii tego, co możesz, a czego nie możesz zrobić. tzn. właściwie wychwytujesz błędy składniowe tylko na etapie kompilacji
Jeśli nie jesteś bardzo ostrożnym z konstrukcją dynamicznie wpisywanych języka, możesz skończyć z Javascript, który jest język kodu-pachnie

EDYCJA: Powinienem wspomnieć, że moim głównym językiem programowania jest obecnie Python, który jest dynamicznie pisany. Osobiście kocham wolność, która nie pochodzi z konieczności wstępnie deklarować zmienne, ale czasami, że byłoby miło, aby określić (na przykład), jakie parametry funkcją trwa do błędów dotyczących połowów wcześnie niż późno.

— Chinmay Kanchi
źródło

1

Chociaż prawdą jest, że kompilator nie jest wybredny, zwykle tak jest. W większości przypadków tłumacz wykrywa problematyczne sytuacje i sygnalizuje błędy.

— Winston Ewert

17

Uwielbiam dynamiczne pisanie, ale nie cierpię konieczności uprzedzania zmiennych! Tak wiele razy przypadkowo wprowadziłem nową zmienną, ponieważ źle napisałem nazwę zmiennej.

— Frank Shearar

1

@Frank: Uwielbiam to, że Perl ma ustawienie wymuszające deklarację zmiennej. Moim zdaniem jest to jedna z zalet Perla.

— Paul Nathan

8

Języki o typie dynamicznym są postrzegane (przez niektórych programistów / szefów) do tworzenia kodu, który również nie działa. Fakt, że program z dynamicznym typowaniem kompiluje, niewiele mówi o jego poprawności. Fakt, że kompilowany język o typie statycznym mówi ci wiele więcej. (Z drugiej strony, między kompilacjami jest jeszcze długa droga i robi to, co należy, więc może to być mniej znaczące, niż się wydaje)

Języki o typie dynamicznym są postrzegane jako języki skryptowe. Nigdy nie napisałeś aplikacji w bash ani pliku wsadowym. Wszystkie języki dynamicznie typowane są zapętlone do tej kategorii (niesprawiedliwie).

Języki pisane dynamicznie są wolniejsze niż języki pisane statycznie. (Zobaczymy jednak, jak dobra praca nad JIT to zmienia)

— Winston Ewert
źródło

2

„Są postrzegani przez” niektórych programistów. Kiedy kłócę się z programistami o dynamiczne pisanie, zwykle przyznają, że nigdy nie używali tego rodzaju języka.

— Frank Shearar

1

@Frank, czy mówisz, że ludzie, którzy opowiadają się za gorszym pisaniem dynamicznym, na ogół go nie używali?

— Winston Ewert

2

@Frank: Użyłem tego rodzaju języka i przez większość czasu był to nie do utrzymania bałagan. (Szczerze mówiąc, to był PHP, a PHP ma inne problemy oprócz dynamicznego pisania)

— Billy ONeal

@Billy: Myślę, że jest to powszechne. Przez lata nie lubiłem dynamicznego pisania z powodu mojego doświadczenia z VB - kiedy w końcu zdałem sobie sprawę, że ta straszna, schizofreniczna implementacja dynamicznego pisania nie była typowa, moja opinia zmieniła się diametralnie.

— Shog9

@Winston: Mówię, że ludzie, z którymi się kłóciłem, nie mają. Zdarzało mi się, że „dynamiczne pisanie nie może działać” ... ale z radością wykorzystają wiele technik opracowanych najpierw w, przez i dla dynamicznych języków (IDE, refaktoryzacja, z góry mojej głowy). Ponadto pytania takie jak: stackoverflow.com/questions/2317579 wskazują, że chociaż prawdopodobnie nie jest to uniwersalne, mój przypadek kłótni z programistami „nie mogę działać”, ale „nie wypróbowałem” nie jest odizolowany. (Ja myślę, że oba podejścia mają wartość.)

— Frank Shearar

8

Uwaga: jest to głównie subiektywne i oparte na moich doświadczeniach i wrażeniach.

Języki wpisywane dynamicznie bardzo różnią się od języków pisanych statycznie. Różnice te prawdopodobnie stają się ważniejsze w ciężkim oprogramowaniu dla przedsiębiorstw niż w większości innych aplikacji.

Języki o typie statycznym mają zazwyczaj charakter nakazowy. Metoda pobiera tylko dane wejściowe dokładnie pasujące do jej podpisu. Poziomy dostępu są zwykle bardzo ważne, a interfejsy są zdefiniowane wyraźnie, z pełnymi, ale jednoznacznymi ograniczeniami w celu egzekwowania tych definicji.

Z drugiej strony dynamicznie pisane języki są bardzo pragmatyczne. Konwersje typów często zachodzą niejawnie, funkcje mogą nawet grać razem, jeśli podasz niewłaściwy typ danych wejściowych, o ile zachowuje się wystarczająco podobnie. W językach takich jak Python nawet poziomy dostępu będą oparte na umowach, a nie na ograniczeniach technicznych (tj. Tylko privatedlatego, że powiedziano ci, aby go nie używać i ma zabawną nazwę).

Wielu programistów preferuje języki dynamiczne, ponieważ (prawdopodobnie) umożliwiają szybkie prototypowanie. Kod często kończy się krócej (choćby z powodu braku deklaracji typu), a jeśli chcesz naruszyć odpowiedni protokół, ponieważ potrzebujesz szybkiego i brudnego rozwiązania lub chcesz coś przetestować, to łatwo możliwe.

Powodem, dla którego „przedsiębiorcze” firmy często preferują języki o typie statycznym, jest to, że są bardziej restrykcyjni i wyraźniej wyrażają te ograniczenia. Chociaż w praktyce idioci z kompilatorem mogą nawet złamać kod o typie statycznym, wiele problemów będzie znacznie bardziej widocznych znacznie wcześniej w procesie (tj. Przed uruchomieniem). Oznacza to, że nawet jeśli baza kodu jest duża, monolityczna i złożona, wiele błędów można łatwo wychwycić bez konieczności uruchamiania kodu lub wysyłania go do działu kontroli jakości.

Powodem, dla którego korzyści nie przeważają wady wielu programistów spoza tego środowiska, jest to, że są to błędy, które często można łatwo wykryć poprzez dokładną kontrolę kodu lub nawet próbę jego uruchomienia. Błędy te często stają się łatwe do uchwycenia i łatwe do naprawienia, szczególnie przy zastosowaniu metodologii opartej na testach. Ponadto, ponieważ wiele takich firm ma znacznie krótszy cykl wydawania, wydajność jest często ważniejsza niż sztywność, a sami programiści wykonują wiele (podstawowych) testów.

Innym powodem, dla którego korporacje korporacyjne nie używają języków dynamicznie typowanych, jest starszy kod. Choć głupoty mogą się nam wydawać, nerdowie, duże korporacje często trzymają się rozwiązań, które działają, nawet jeśli są już na wyczerpaniu. Właśnie dlatego tak wiele dużych firm wymusza przeglądarkę Internet Explorer 6 i tak wolno aktualizuje swoje systemy operacyjne. Z tego też powodu często piszą nowy kod w „starych” językach (np. Starożytne wersje Javy): o wiele łatwiej jest dodać kilka wierszy kodu do nieżywego oprogramowania, niż uzyskać zgodę na całkowite przepisanie nowego język.

tl; dr: języki statyczne bardziej przypominają biurokrację, więc bardziej podoba się im menedżerowie przedsiębiorczości.

— Alan Plum
źródło

3

Języki z luźno-głupimi regułami pisania stwarzają wiele możliwości dla rzeczy, które nie są w porządku. Na przykład w JavaScript przekazanie liczby do kodu, która oczekuje, że ciąg znaków będzie często zachowywać się tak, jakby ktoś przekazał ciąg reprezentujący tę liczbę, ale nie zawsze. Próba np. Dodania 456 do 123 nie da 123456, ale zamiast tego da 579. O ile nie jest jasne, kto jest odpowiedzialny za konwersję liczb na ciąg, może to zostać wykonane redundantnie lub w ogóle nie zostać wykonane.

— supercat

1

@ supercat, myślę, że PHP i JavaScript są dobrymi przykładami na dwa sposoby radzenia sobie z tym problemem (w odniesieniu do operatorów): w PHP operatorzy są jednoznaczni - +biorą liczby i dodają je, jeśli chcesz konkatenacji, musisz użyć .; w JS obie operacje współużytkują tego samego operatora - jeśli nie wiesz, jak zachowają się twoje wartości, możesz je jawnie przekonwertować. Oczywiście ma to również związek z pisaniem swobodnym a pisaniem ścisłym (Python jest jeszcze bardziej rygorystyczny), ale w zasadzie musisz albo upewnić się, że wartości mają odpowiedni typ, albo wymusić, aby operacje wymuszały oczekiwane typy.

— Alan Plum

1

Nie znam się zbyt dobrze na PHP, ale wygląda na to, że używa tego, co nazwałbym „właściwym” podejściem. JavaScript jest wstrętnie na wiele sposobów IMHO, ale myślę, że zachowanie „+” jest jednym z najgorszych. Właściwie nie jestem przekonany, że dynamiczne pisanie na maszynie loozy-goosy miałoby znacznie przewagę nad silniejszym systemem typów, który pozwalał interfejsowi zadeklarować, że rzeczy innej klasy lub typu interfejsu powinny być traktowane jako implementujące lub wywodzące się z niego, z określonymi regułami o tym, w jaki sposób roszczenia będą traktowane priorytetowo. Wielkim ograniczeniem, jakie znam z obecnych struktur typu strukturalnie, jest to, że ...

— supercat

1

... jeśli dwie osoby niezależnie opracują podobne interfejsy, nie ma możliwości, aby osoba trzecia napisała kod, który mógłby ich używać zamiennie. Jeśli strona trzecia może zdefiniować nowy interfejs i zadeklarować, że implementacje jednego lub obu istniejących powinny automatycznie implementować nowy (w razie potrzeby za pomocą opakowań dostarczonych w nowym interfejsie), myślę, że poradziłoby sobie z 99% tego, co jest semantyczne dobre w dynamicznym pisaniu.

— supercat

3

Nie, nie sądzę, aby dynamicznie pisane języki zasługiwały na całą krytykę. (Lub, jeśli wolisz, zasługują na tyle samo krytyki, co języki pisane statycznie).

Z mojego doświadczenia (i nie próbuję uogólniać tego stwierdzenia), programiści, którzy krytykują dynamiczne języki, nie używali ich. Rozmowa zwykle przebiega „ale przy statycznym pisaniu kompilator wyłapuje tyle błędów!” i mówię „cóż, z mojego doświadczenia to nie jest problem”. (Zwykle inny programista wywodzi się z języka Java, Delphi lub podobnego; nie znam żadnego programisty Haskell lub ML).

Jedyną rzeczą, która naprawdę mnie narzekanie jest, gdy ktoś twierdzi, że technika Foo nie mogą ewentualnie być wykonane (lub może być bardzo trudne do zrobienia) w dynamicznie wpisywanych języka ... kiedy to technika została wymyślona w, przez i dla dynamicznie wpisane język. IDE? Pogawędka. Automatyczne refaktoryzacja? Pogawędka. Dzwoniący / realizatorzy? Pogawędka.

— Frank Shearar
źródło

Nie chciałem zaśmiecać mojej odpowiedzi osobistą postawą, która brzmi następująco: właściwe narzędzie do właściwej pracy. Niezależnie od tego, jakiego języka używasz, lepiej nadaje się do niektórych zadań, a gorzej do innych, niż inny rodzaj języka.

— Frank Shearar,

6

Kiedy inny programista pochodzi z Haskell, on już wie, że jest to język lepszy od języków Java i języków dynamicznych;)

— Andres F.

0

Przedsiębiorstwa po prostu nie dostosowują nowych języków i narzędzi wystarczająco szybko i istnieją ku temu dobre powody. Ale gdy jedno z głównych narzędzi, takich jak C #, wdroży niektóre z tych funkcji, dostaną się do głównych firm ...

— aggietech
źródło

Nie wiem, dlaczego zostało to odrzucone, ale jest to wnikliwe stwierdzenie. Przedsiębiorstwa są powolne i konserwatywne. Ludzie wolą także stopniową zmianę (jak dynamiczne słowo kluczowe w C #, która pozwala od czasu do czasu używać dynamicznego pisania w języku o statycznym typie) niż nagłą zmianę (jak Ruby).

— Vaddadi Kartick 23.04.16