Co jest tak atrakcyjne w językach dynamicznych? [Zamknięte]

Wygląda na to, że ostatnio wszyscy skaczą na dynamiczną, nieskompilowaną modę. Pracowałem głównie w skompilowanych, statycznych językach (C, Java, .Net). Mam doświadczenie z dynamicznymi językami, takie jak ASP (Vb Script), JavaScript i PHP. Korzystanie z tych technologii pozostawiło w ustach zły smak, gdy myślę o językach dynamicznych. Rzeczy, które zwykle zostałyby wyłapane przez kompilator, takie jak błędne nazwy zmiennych i przypisanie wartości niewłaściwego typu do zmiennej, pojawiają się dopiero w czasie wykonywania. Nawet wtedy możesz nie zauważyć błędu, ponieważ po prostu tworzy nową zmienną i przypisuje jakąś domyślną wartość. Nigdy też nie widziałem, żeby funkcja Intellisense działała dobrze w języku dynamicznym, ponieważ zmienne nie mają żadnego jawnego typu.

Chcę wiedzieć, co ludzie uważają za tak atrakcyjne w językach dynamicznych? Jakie są główne zalety, jeśli chodzi o rzeczy, które umożliwiają języki dynamiczne, a czego nie można zrobić lub są trudne do wykonania w językach kompilowanych. Wydaje mi się, że już dawno temu zdecydowaliśmy, że takie rzeczy, jak nieskompilowane strony ASP, rzucające wyjątki w czasie wykonywania, były złym pomysłem. Dlaczego odradza się tego typu kod? I dlaczego przynajmniej wydaje mi się, że Ruby on Rails tak naprawdę nie wygląda na coś, czego nie mógłbyś zrobić z ASP 10 lat temu?

Myślę, że powodem jest to, że ludzie są przyzwyczajeni do języków statycznych, które mają bardzo ograniczone i niewyrażalne systemy typów. Są to języki takie jak Java, C ++, Pascal itp. Zamiast iść w kierunku bardziej ekspresyjnych systemów typów i lepszego wnioskowania o typach (jak na przykład w Haskell, a nawet w pewnym stopniu SQL), niektórzy ludzie lubią po prostu zachować wszystkie informacje o „typie” w ich głowie (oraz w testach) i całkowicie eliminują statyczne sprawdzanie typów.

Ostatecznie nie jest jasne, co to daje. Istnieje wiele błędnie pojmowanych pojęć dotyczących sprawdzania typów, najczęściej spotykam te dwa.

Błąd: języki dynamiczne są mniej szczegółowe. Błędne jest przekonanie, że informacje o typie są równe adnotacji typu. To jest całkowicie nieprawdziwe. Wszyscy wiemy, że adnotacja typu jest denerwująca. Maszyna powinna być w stanie to rozgryźć. I faktycznie tak jest w nowoczesnych kompilatorach. Oto statycznie wpisany QuickSort w dwóch wierszach Haskell (z haskell.org ):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

A oto dynamicznie wpisywany QuickSort w LISP (ze swisspig.net ):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Przykład Haskella fałszuje hipotezę zapisaną statycznie, a zatem rozwlekłą . Przykład LISP fałszuje hipotezę rozwlekłą, a zatem statycznie typizowaną . Nie ma implikacji w żadnym kierunku między pisaniem a gadatliwością. Możesz bezpiecznie wyrzucić to z głowy.

Błąd: języki statycznie typowane muszą być kompilowane, a nie interpretowane. Ponownie, nieprawda. Wiele języków z typowaniem statycznym ma tłumaczy. Jest interpreter Scala, interpretery GHCi i Hugs dla Haskella i oczywiście SQL był zarówno statyczny, jak i interpretowany dłużej niż żyję.

Wiesz, może dynamiczny tłum po prostu chce wolności, aby nie musieć tak uważnie myśleć o tym, co robią. Oprogramowanie może nie być poprawne lub niezawodne, ale może nie musi.

Osobiście uważam, że ci, którzy zrezygnowaliby z bezpieczeństwa typu, aby kupić trochę tymczasowej wolności, nie zasługują ani na wolność, ani na bezpieczeństwo typu.

Nie zapominaj, że musisz napisać 10-krotne pokrycie kodu w testach jednostkowych, aby zastąpić to, co robi twój kompilator: D

Byłem tam, robiłem to z dynamicznymi językami i nie widzę absolutnie żadnej korzyści.

Czytając odpowiedzi innych osób, wydaje się, że istnieją mniej więcej trzy argumenty za językami dynamicznymi:

1) Kod jest mniej szczegółowy. Nie uważam tego za ważne. Niektóre języki dynamiczne są mniej szczegółowe niż niektóre języki statyczne. Ale F # jest wpisywany statycznie, ale statyczne wpisywanie nie dodaje wiele, jeśli w ogóle, kodu. Jest to jednak niejawnie wpisane na maszynie, ale to inna sprawa.

2) „Mój ulubiony dynamiczny język X ma moją ulubioną funkcję funkcjonalną Y, dlatego dynamika jest lepsza”. Nie mieszaj funkcji i dynamiki (nie rozumiem, dlaczego trzeba to powiedzieć).

3) W dynamicznych językach możesz natychmiast zobaczyć swoje wyniki. Wiadomości: Możesz to zrobić również w C # w programie Visual Studio (od 2005 r.). Wystarczy ustawić punkt przerwania, uruchomić program w debugerze i zmodyfikować program podczas debugowania. Robię to cały czas i działa idealnie.

Osobiście jestem zdecydowanym zwolennikiem pisania statycznego z jednego podstawowego powodu: łatwości konserwacji. Mam system z kilkoma 10 tysiącami wierszy JavaScript, a każda refaktoryzacja, którą chcę wykonać, zajmie około pół dnia, ponieważ (nieistniejący) kompilator nie powie mi, co zepsuło ta zmiana nazwy zmiennej. I to jest kod, który napisałem sam, dobrze zorganizowany IMO. Nie chciałbym, aby powierzono mi zadanie kierowania równoważnym systemem dynamicznym, który napisał ktoś inny.

Myślę, że będę za to masowo odrzucany, ale zaryzykuję.

VBScript jest do bani, chyba że porównujesz go z innym smakiem VB. PHP jest w porządku, o ile pamiętasz, że jest to przerośnięty język szablonów. Nowoczesny Javascript jest świetny. Naprawdę. Mnóstwo zabawy. Po prostu trzymaj się z dala od skryptów oznaczonych jako „DHTML”.

Nigdy nie używałem języka, który nie dopuszczałby błędów w czasie wykonywania. IMHO, to w dużej mierze czerwony śledź: kompilatory nie wychwytują wszystkich literówek ani nie weryfikują zamiarów. Jawne pisanie jest świetne, gdy potrzebujesz jawnych typów, ale w większości przypadków nie. Poszukaj pytań tutaj genericslub tego, czy używanie typów bez znaku było dobrym wyborem dla zmiennych indeksujących - przez większość czasu te rzeczy po prostu przeszkadzają i dają ludziom pokrętło do kręcenia, gdy mają czas na rękach .

Ale tak naprawdę nie odpowiedziałem na twoje pytanie. Dlaczego języki dynamiczne są atrakcyjne? Ponieważ po pewnym czasie pisanie kodu staje się nudne i chcesz po prostu zaimplementować algorytm. Już usiadłeś i opracowałeś to wszystko piórem, sporządziłeś diagram potencjalnych scenariuszy problemów i udowodniłeś, że można je rozwiązać, a jedyne, co pozostało, to zakodowanie dwudziestu linii implementacji ... i dwustu wierszy standardowego schematu, aby je skompilować . Potem okazuje się, że system typu pracy z nie odzwierciedla tego, co ty właściwie robisz, ale ktoś inny jest wyjątkowo abstrakcyjny pomysł co może robić, a ty już dawno opuszczony programowania dla życia knicknack szczypanie tak obsesyjno-kompulsywne, że wstydziłoby się nawet fikcyjnego detektywa Adriana Monka.

To wtedy idź otynkowane zacząć patrzeć poważnie na dynamicznych języków.

Jestem pełnoetatowym programistą .Net w pełni zagłębionym w ferworze C # ze statycznym typowaniem. Uwielbiam jednak nowoczesny JavaScript.

Ogólnie rzecz biorąc, myślę, że języki dynamiczne pozwalają wyrazić swoje zamiary bardziej zwięźle niż języki statyczne, ponieważ spędzasz mniej czasu i miejsca na określaniu elementów składowych tego, co próbujesz wyrazić, podczas gdy w wielu przypadkach są one oczywiste.

Myślę, że istnieje również wiele klas języków dynamicznych. Nie mam ochoty wracać do pisania klasycznych stron ASP w języku VBScript. Myślę, że język dynamiczny, aby był użyteczny, musi w swoim rdzeniu obsługiwać pewnego rodzaju zbiór, listę lub konstrukcję asocjacyjną, tak aby obiekty (lub to, co przechodzą dla obiektów) mogły być wyrażane i pozwalały na budowanie bardziej złożonych konstrukcji. (Może wszyscy powinniśmy po prostu kodować w LISP-ie ... to żart ...)

Myślę, że w kręgach .Net języki dynamiczne cieszą się złą sławą, ponieważ są powiązane z VBScript i / lub JavaScript. VBScript jest po prostu przywoływany jako koszmar z wielu powodów, które podał Kibbee - każdy pamięta wymuszanie pisania w VBScript przy użyciu CLng, aby upewnić się, że masz wystarczającą liczbę bitów dla 32-bitowej liczby całkowitej. Myślę też, że JavaScript jest nadal postrzegany jako język przeglądarki dla menu rozwijanych, który jest napisany inaczej dla wszystkich przeglądarek. W takim przypadku problemem nie jest język, ale różne modele obiektów przeglądarki. Co ciekawe, im bardziej C # dojrzewa, tym bardziej dynamicznie zaczyna wyglądać. Uwielbiam wyrażenia lambda, anonimowe obiekty i wnioskowanie o typie. Codziennie bardziej przypomina JavaScript.

Oto statycznie wpisany QuickSort w dwóch wierszach Haskell (z haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

A oto dynamicznie wpisywany QuickSort w LISP (ze swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Myślę, że masz tendencje do wyboru języka. Lisp jest notorycznie ciężki jak paren. Bliższym odpowiednikiem Haskella byłby Python.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Kod Pythona stąd

Dla mnie zaletą języków dynamicznych jest to, o ile bardziej czytelny staje się kod z powodu mniejszej ilości kodu i technik funkcjonalnych, takich jak blok Rubiego i rozumienie list w Pythonie.

Ale potem trochę mi brakuje sprawdzania czasu kompilacji (literówka się zdarza) i automatycznego uzupełniania IDE. Ogólnie rzecz biorąc, mniejsza ilość kodu i czytelności się opłaca.

Kolejną zaletą jest zwykle interpretowany / nieskompilowany charakter języka. Zmień kod i natychmiast zobacz wynik. To naprawdę oszczędza czas podczas programowania.

Wreszcie podoba mi się fakt, że możesz odpalić konsolę i wypróbować coś, czego nie jesteś pewien, na przykład klasę lub metodę, której nigdy wcześniej nie używałeś, i zobaczyć, jak się zachowuje. Konsola ma wiele zastosowań i zostawię to wam, abyście się zorientowali.

Twoje argumenty przeciwko dynamicznym językom są całkowicie uzasadnione. Jednak weź pod uwagę następujące kwestie:

1. Języki dynamiczne nie muszą być kompilowane : wystarczy je uruchomić. W większości przypadków można nawet ponownie załadować pliki w czasie wykonywania, bez ponownego uruchamiania aplikacji.
2. Języki dynamiczne są generalnie mniej rozwlekłe i bardziej czytelne : czy kiedykolwiek spojrzałeś na dany algorytm lub program zaimplementowany w języku statycznym, a następnie porównałeś go z odpowiednikiem Rubiego lub Pythona? Ogólnie rzecz biorąc, patrzymy na redukcję wierszy kodu o współczynnik 3. Wiele kodu tworzącego szkielet jest niepotrzebne w językach dynamicznych, a to oznacza, że ​​wynik końcowy jest bardziej czytelny i bardziej skupiony na rzeczywistym problemie.
3. Nie martw się o problemy z pisaniem : ogólne podejście podczas programowania w językach dynamicznych polega na tym, że nie musisz martwić się o pisanie: w większości przypadków odpowiedni rodzaj argumentu zostanie przekazany do twoich metod. I od czasu do czasu ktoś może użyć innego rodzaju argumentu, który po prostu się sprawdza. Gdy coś pójdzie nie tak, program może zostać zatrzymany, ale rzadko się to zdarza, jeśli wykonałeś kilka testów.

Mnie też trochę przerażało odejście od bezpiecznego świata statycznego pisania, ale dla mnie zalety zdecydowanie przewyższają wady i nigdy nie oglądałem się za siebie.

Uważam, że „nowo odnaleziona miłość” do języków dynamicznie typowanych ma mniej wspólnego z tym, czy języki statyczne są lepsze, czy najgorsze - w sensie absolutnym - niż wzrost popularności niektórych języków dynamicznych. Ruby on Rails był oczywiście dużym zjawiskiem, które spowodowało odrodzenie dynamicznych języków. To, co sprawiło, że szyny stały się tak popularne i stworzyło tak wielu konwerterów z obozu statycznego, to głównie: bardzo zwięzły i SUCHY kod i konfiguracja. Jest to szczególnie prawdziwe w porównaniu z platformami sieciowymi Java, które wymagały wielu konfiguracji XML. Wielu programistów Javy - także inteligentnych - dokonało konwersji, a niektórzy nawet ewangelizowali ruby ​​i inne dynamiczne języki. Dla mnie trzy różne funkcje pozwalają na bardziej zwięzłe języki dynamiczne, takie jak Ruby czy Python:

1. Minimalistyczna składnia - najważniejsza jest to, że adnotacje typu nie są wymagane, ale projektant języka od początku zaprojektował język tak, aby był zwięzły
2. składnia funkcji inline (lub lambda) - możliwość pisania funkcji inline i przekazywania ich jako zmiennych sprawia, że ​​wiele rodzajów kodu jest krótkich. W szczególności dotyczy to operacji na listach / tablicach. Korzenie tych pomysłów były oczywiście - LISP.
3. Metaprogramowanie - metaprogramowanie jest dużą częścią tego, co sprawia, że ​​szyny działają. Dało to początek nowemu sposobowi refaktoryzacji kodu, który pozwolił, aby kod klienta Twojej biblioteki był znacznie bardziej zwięzły. To również pochodzi z LISP.

Wszystkie te trzy funkcje nie dotyczą wyłącznie języków dynamicznych, ale z pewnością nie są obecne w popularnych współczesnych językach statycznych: Java i C #. Można argumentować, że C # ma numer 2 wśród delegatów, ale ja uważam, że nie jest on w ogóle powszechnie używany - na przykład w operacjach na listach.

Jeśli chodzi o bardziej zaawansowane języki statyczne ... Haskell jest cudownym językiem, ma # 1 i # 2 i chociaż nie ma # 3, jego system typów jest tak elastyczny, że prawdopodobnie nie zauważysz braku meta do ograniczać. Wierzę, że możesz wykonywać metaprogramowanie w OCaml w czasie kompilacji z rozszerzeniem języka. Scala to nowy dodatek i bardzo obiecujący. F # dla obozu .NET. Jednak użytkownicy tych języków są w mniejszości, więc tak naprawdę nie przyczynili się do tej zmiany w środowisku języków programowania. W rzeczywistości bardzo wierzę, że popularność Rubiego wpłynęła pozytywnie na popularność języków takich jak Haskell, OCaml, Scala i F #, oprócz innych języków dynamicznych.

Osobiście uważam, że po prostu większość „dynamicznych” języków, których używałeś, jest ogólnie kiepskimi przykładami języków.

Jestem o wiele bardziej produktywny w Pythonie niż w C czy Javie, i to nie tylko dlatego, że musisz wykonać taniec edycja-kompilacja-link-uruchom. Staję się bardziej produktywny w Objective-C, ale to prawdopodobnie bardziej ze względu na ramy.

Nie trzeba dodawać, że jestem bardziej produktywny w każdym z tych języków niż PHP. Do diabła, wolałbym kodować w Scheme lub Prologu niż w PHP. (Ale ostatnio robiłem więcej Prologu niż cokolwiek innego, więc weź to z przymrużeniem oka!)

Moje uznanie dla języków dynamicznych jest bardzo związane z ich funkcjonalnością . Listy składane w Pythonie, domknięcia Rubiego i prototypowane obiekty JavaScript są bardzo atrakcyjnymi aspektami tych języków. Wszystkie mają również pierwszorzędne funkcje - coś, bez czego nie mogę żyć nigdy więcej.

Nie kategoryzowałbym PHP i VB (skrypt) w ten sam sposób. Według mnie są to głównie języki imperatywne ze wszystkimi sugerowanymi przez ciebie wadami dynamicznego pisania.

Jasne, nie uzyskujesz tego samego poziomu kontroli czasu kompilacji (ponieważ nie ma czasu kompilacji), ale spodziewałbym się, że statyczne narzędzia do sprawdzania składni będą ewoluować w czasie, aby przynajmniej częściowo rozwiązać ten problem.

Jedną z zalet wskazanych w przypadku języków dynamicznych jest możliwość zmiany kodu i kontynuowania działania. Nie ma potrzeby ponownej kompilacji. W VS.Net 2008 podczas debugowania można faktycznie zmienić kod i kontynuować działanie bez ponownej kompilacji. Wraz z postępem w kompilatorach i IDE jest możliwe, że ta i inne zalety używania języków dynamicznych znikną.

Ach, nie widziałem tego tematu, kiedy pisałem podobne pytanie

Poza dobrymi funkcjami, reszta osób, o których mowa tutaj, o językach dynamicznych, myślę, że każdy zapomina o jednej, najbardziej podstawowej rzeczy: metaprogramowaniu.

Programowanie programu.

Ogólnie rzecz biorąc, jest to dość trudne do wykonania w językach kompilowanych, na przykład .Net. Aby to zadziałało, musisz zrobić wszelkiego rodzaju jumbo mambo i zwykle kończy się kodem, który działa około 100 razy wolniej.

Większość języków dynamicznych ma sposób na metaprogramowanie i to jest coś, co mnie tam trzyma - możliwość tworzenia dowolnego rodzaju kodu w pamięci i idealnej integracji go z moją aplikacją.

Na przykład, aby stworzyć kalkulator w Lua, wystarczy, że:

print( loadstring( "return " .. io.read() )() )

Teraz spróbuj to zrobić w .Net.

Głównym powodem, dla którego lubię języki dynamiczne (pisane na maszynie, ponieważ wydaje się, że jest to główny temat wątku) jest to, że te, których używałem (w środowisku pracy), są znacznie lepsze od języków niedynamicznych, których używałem. C, C ++, Java, itd ... wszystkie są okropnymi językami do wykonywania rzeczywistej pracy. Chciałbym zobaczyć niejawnie wpisywany język, który jest tak samo naturalny do programowania w wielu dynamicznie wpisywanych.

Biorąc to pod uwagę, istnieją pewne konstrukcje, które są po prostu niesamowite w językach dynamicznie wpisywanych. Na przykład w Tcl

 lindex $mylist end-2

Fakt, że przekazujesz „koniec-2”, aby wskazać żądany indeks, jest niezwykle zwięzły i oczywisty dla czytelnika. Nie widziałem jeszcze języka statycznego, który to umożliwia.

Myślę, że tego rodzaju argumenty są trochę głupie: „Rzeczy, które zwykle byłyby przechwytywane przez kompilator, takie jak błędne nazwy zmiennych i przypisanie wartości niewłaściwego typu do zmiennej, pojawiają się dopiero w czasie wykonywania”. Programista PHP Nie widzę takich rzeczy jak błędnie wpisane zmienne do czasu uruchomienia, ALE środowisko uruchomieniowe jest dla mnie krokiem 2, w C ++ (który jest jedynym językiem kompilowanym, z jakim mam jakiekolwiek doświadczenie) jest to krok 3, po połączeniu i kompilacji.

Nie wspominając już o tym, że po kliknięciu przycisku Zapisz, gdy mój kod jest gotowy do uruchomienia, zajmuje tylko kilka sekund, w przeciwieństwie do języków kompilowanych, w których może to zająć dosłownie godziny. Przykro mi, jeśli to brzmi trochę wściekle, ale mam dość ludzi, którzy traktują mnie jak programistę drugiej kategorii, ponieważ nie muszę kompilować swojego kodu.

Argument jest bardziej złożony (przeczytaj artykuł Yegge „Is Weak Typing Enough”, aby uzyskać interesujący przegląd).

W językach dynamicznych niekoniecznie brakuje sprawdzania błędów - wnioskowanie o typie języka C # jest prawdopodobnie jednym z przykładów. W ten sam sposób C i C ++ mają fatalne testy kompilacji i są statycznie wpisywane.

Głównymi zaletami języków dynamicznych są a) możliwości (które niekoniecznie muszą być używane przez cały czas) oraz b) prawo iteracji Boyda .

Drugi powód jest ogromny.

Chociaż nie jestem jeszcze wielkim fanem Rubiego, uważam języki dynamiczne za naprawdę wspaniałe i potężne narzędzia.

Pomysł, że nie ma sprawdzania typów i deklarowania zmiennych, nie jest tak naprawdę wielkim problemem. Trzeba przyznać, że nie można wyłapać tych błędów przed uruchomieniem, ale dla doświadczonych programistów nie stanowi to problemu, a kiedy popełniasz błędy, zwykle można je łatwo naprawić.

Zmusza również nowicjuszy do dokładniejszego czytania tego, co piszą. Wiem, że nauka PHP nauczyła mnie zwracania większej uwagi na to, co faktycznie piszę, co poprawiło moje programowanie nawet w językach kompilowanych.

Dobre IDE zapewnią wystarczającą inteligencję, abyś wiedział, czy zmienna została „zadeklarowana”, a także spróbują przeprowadzić za ciebie wnioskowanie o typie, abyś mógł określić, czym jest zmienna.

Moim zdaniem to, co można zrobić z dynamicznymi językami, sprawia, że ​​praca z nimi jest tak przyjemna. Jasne, możesz zrobić to samo w skompilowanym języku, ale wymagałoby to więcej kodu. Języki takie jak Python i PHP pozwalają programować w krótszym czasie i przez większość czasu szybciej uzyskać funkcjonalną bazę kodu.

A propos, jestem pełnoetatowym programistą .NET i uwielbiam języki kompilowane. Używam języków dynamicznych tylko w wolnym czasie, aby dowiedzieć się o nich więcej i poprawić siebie jako programistę.

Myślę, że potrzebujemy różnych typów języków w zależności od tego, co próbujemy osiągnąć lub rozwiązać za ich pomocą. Jeśli chcemy aplikacji, która tworzy, pobiera, aktualizuje i usuwa rekordy z bazy danych przez Internet, lepiej zrobić to za pomocą jednej linii kodu ROR (używając szkieletu) niż pisać go od zera w języku statycznym. Używanie języków dynamicznych uwalnia umysły od zastanawiania się

• która zmienna ma jaki typ
• jak dynamicznie rozwijać sznurek zgodnie z potrzebami
• jak napisać kod, aby zmienić typ jednej zmiennej nie musieć przepisywać wszystkich funkcji, które z nią wchodzą

do problemów, które są bliżej potrzeb biznesowych, takich jak

• dane są zapisywane / aktualizowane itp. w bazie danych, jak ich używać do kierowania ruchu do mojej witryny

W każdym razie jedną z zalet języków luźno pisanych jest to, że nie obchodzi nas, jaki to jest typ, czy zachowuje się tak, jak powinien. To jest powód, dla którego mamy kaczkę na klawiaturze w językach dynamicznie wpisywanych. jest to świetna funkcja i mogę używać tych samych nazw zmiennych do przechowywania różnych typów danych, gdy zajdzie taka potrzeba. ponadto języki z typami statycznymi zmuszają Cię do myślenia jak maszyna (w jaki sposób kompilator współdziała z Twoim kodem itp.), podczas gdy języki z typami dynamicznymi, zwłaszcza ruby ​​/ ror, zmuszają maszynę do myślenia jak człowiek.

Oto niektóre z argumentów, których używam, aby uzasadnić moją pracę i doświadczenie w językach dynamicznych!

Myślę, że oba style mają swoje mocne strony. Moim zdaniem to myślenie albo / albo jest trochę paraliżujące dla naszej społeczności. Pracowałem w architekturach, które były wpisywane statycznie od góry do dołu i było dobrze. Moją ulubioną architekturą jest typowanie dynamiczne na poziomie interfejsu użytkownika i typowanie statyczne na poziomie funkcjonalnym. To również zachęca do tworzenia bariery językowej, która wymusza oddzielenie interfejsu użytkownika od funkcji.

Aby być cynikiem, może po prostu oznaczać, że języki dynamiczne pozwalają programistom na lenistwo i wykonywanie zadań, wiedząc mniej o podstawach informatyki. Czy to dobrze, czy źle, zależy od czytelnika :)

FWIW, Kompilowanie większości aplikacji nie powinno zająć godzin. Pracowałem z aplikacjami, które mają od 200 do 500 tysięcy linii, których kompilacja zajmuje kilka minut. Na pewno nie godzin.

Sam wolę języki kompilowane. Wydaje mi się, że narzędzia do debugowania (z mojego doświadczenia, które mogą nie być prawdziwe) są lepsze, a narzędzia IDE są lepsze.

Lubię mieć możliwość dołączenia mojego programu Visual Studio do uruchomionego procesu. Czy inne IDE mogą to zrobić? Może, ale nie wiem o nich. Ostatnio zajmowałem się programowaniem PHP i szczerze mówiąc, nie jest tak źle. Jednak zdecydowanie wolę C # i VS IDE. Czuję, że pracuję szybciej i szybciej debuguję problemy.

Więc może jest to dla mnie bardziej kwestia zestawu narzędzi niż kwestia dynamicznego / statycznego języka?

Ostatni komentarz ... jeśli tworzysz program na lokalnym serwerze, oszczędzanie jest szybsze niż kompilacja, ale często nie mam dostępu do wszystkiego na moim komputerze lokalnym. Bazy danych i udziały plików znajdują się gdzie indziej. Łatwiej jest przesłać FTP do serwera WWW, a następnie uruchomić mój kod PHP tylko po to, aby znaleźć błąd i naprawić i ponownie ftp.

Produktywność w pewnym kontekście. Ale to tylko jedno środowisko, które znam, w porównaniu do innych, które znam lub widziałem używane.

Smalltalk on Squeak / Pharo with Seaside to znacznie bardziej efektywna i wydajna platforma internetowa niż ASP.Net (/ MVC), RoR czy Wicket, do złożonych aplikacji. Dopóki nie będziesz musiał połączyć się z czymś, co ma biblioteki w jednym z tych, ale nie smalltalk.

Błędnie wpisane nazwy zmiennych są czerwone w środowisku IDE, funkcja IntelliSense działa, ale nie jest tak specyficzna. Błędy czasu wykonywania na stronach internetowych nie są problemem, ale funkcją, jedno kliknięcie, aby wywołać debuger, jedno kliknięcie w moim IDE, napraw błąd w debugerze, zapisz, kontynuuj. W przypadku prostych błędów czas podróży w obie strony dla tego cyklu wynosi mniej niż 20 sekund.

Dynamiczne języki kontratakują

http://www.youtube.com/watch?v=tz-Bb-D6teE

Wykład omawiający języki dynamiczne, jakie są niektóre z pozytywów i ile z nich nie jest tak naprawdę prawdziwych.

Ponieważ uważam za głupie deklarowanie typu pudełka. Typ pozostaje w jednostce, a nie w kontenerze. Statyczne typowanie miało sens, gdy typ pudełka miał bezpośredni wpływ na sposób interpretacji bitów w pamięci.

Jeśli spojrzysz na wzorce projektowe w GoF, zdasz sobie sprawę, że duża część z nich istnieje tylko po to, aby walczyć ze statyczną naturą języka i nie mają żadnego powodu, aby istnieć w dynamicznym języku.

Poza tym mam dość pisania rzeczy takich jak MyFancyObjectInterface f = new MyFancyObject (). Zasada SUCHA ktoś?

Postaw się w miejscu zupełnie nowego programisty, który wybiera język na początek, który nie przejmuje się dynamiką, statystyką, lambdami, tym, itd .; jaki język byś wybrał?

DO#

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Lua:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Wszystko to częściowo sprowadza się do tego, co jest odpowiednie dla określonych celów i jakie są wspólne osobiste preferencje. (Np. Czy będzie to ogromna baza kodu obsługiwana przez więcej osób, niż jest w stanie wspólnie przeprowadzić rozsądne spotkanie? Chcesz sprawdzić typ).

Część osobista polega na zamianie niektórych sprawdzeń i innych kroków w celu rozwoju i testowania szybkości (przy jednoczesnym prawdopodobnie rezygnacji z wydajności procesora). Są ludzie, dla których jest to wyzwalające i poprawiające wydajność, a są tacy, dla których jest to wręcz odwrotne, i tak, to zależy też od konkretnego smaku twojego języka. Chodzi mi o to, że nikt tutaj nie mówi, że Java rządzi się szybkim, zwięzłym programowaniem, ani że PHP jest solidnym językiem, w którym rzadko popełnisz trudną do zauważenia literówkę.

Uwielbiam języki statyczne i dynamiczne. Każdy projekt, w który byłem zaangażowany od około 2002 roku, był aplikacją C / C ++ z wbudowaną interpretacją Pythona. To daje mi to, co najlepsze z obu światów:

1. Komponenty i struktury, które składają się na aplikację, są dla danego wydania aplikacji niezmienne. Muszą być również bardzo stabilne, a co za tym idzie, dobrze przetestowane. Język z typowaniem statycznym jest właściwym wyborem do tworzenia tych części.
2. Okablowanie komponentów, ładowanie komponentów DLL, grafika, większość GUI, itp ... może się znacznie różnić (np. W celu dostosowania aplikacji do klienta) bez konieczności zmiany frameworka lub kodu komponentów. Dynamiczny język jest do tego idealny.

Uważam, że połączenie statycznego języka do budowania systemu i dynamicznego języka do konfiguracji daje mi elastyczność, stabilność i produktywność.

Aby odpowiedzieć na pytanie: „Po co jest miłość do języków dynamicznych?” Dla mnie jest to możliwość całkowitego ponownego okablowania systemu w czasie wykonywania w dowolny możliwy sposób. Postrzegam język skryptowy jako „uruchamiający przedstawienie”, dlatego aplikacja wykonująca może zrobić wszystko, co zechcesz.

Ogólnie nie mam dużego doświadczenia z dynamicznymi językami, ale jedyny dynamiczny język, który znam, JavaScript (znany również jako ECMAScript), bardzo mi się podoba.

Cóż, czekaj, jaka jest tutaj dyskusja? Dynamiczna kompilacja? Lub dynamiczne pisanie? JavaScript obejmuje obie bazy, więc myślę, że opowiem o obu:

Kompilacja dynamiczna :

Na początek kompiluje się języki dynamiczne , kompilację po prostu odkłada się na później. A Java i .NET naprawdę są kompilowane dwukrotnie. Raz na ich odpowiednie języki pośrednie i znowu dynamicznie na kod maszynowy.

Ale kiedy kompilacja zostanie odłożona, wyniki można zobaczyć szybciej. To jedna zaleta. Lubię po prostu zapisać plik i dość szybko zobaczyć mój program w akcji.

Kolejną zaletą jest to, że możesz pisać i kompilować kod w czasie wykonywania . Czy jest to możliwe w kodzie skompilowanym statycznie, nie wiem. Wyobrażam sobie, że tak musi być, ponieważ cokolwiek kompiluje JavaScript, jest ostatecznie kodem maszynowym i statycznie skompilowane. Ale w dynamicznym języku jest to banalna rzecz. Kod może pisać i uruchamiać się sam. (Jestem prawie pewien, że .NET może to zrobić, ale CIL, do którego .NET kompiluje się, i tak jest dynamicznie kompilowany w locie, i nie jest to takie trywialne w C #)

Dynamiczne pisanie :

Myślę, że dynamiczne pisanie jest bardziej wyraziste niż statyczne. Zwróć uwagę, że nieformalnie używam terminu ekspresyjny, aby powiedzieć, że dynamiczne pisanie może powiedzieć więcej za mniej. Oto kod JavaScript:

var Person = {};

Czy wiesz, kim jest teraz Osoba? To słownik ogólny. Mogę to zrobić:

Osoba ["First_Name"] = "John";
Osoba ["Last_Name"] = "Kowal";

Ale to także przedmiot. Mógłbym odwołać się do dowolnego z tych „kluczy” w ten sposób:

Person.First_Name

I dodaj metody, które uznam za konieczne:

Person.changeFirstName = function (newName) {
  this.First_Name = newName;
};

Jasne, mogą wystąpić problemy, jeśli newName nie jest ciągiem. Nie zostanie złapany od razu, jeśli w ogóle, ale możesz to sprawdzić. To kwestia wymiany ekspresji i elastyczności na bezpieczeństwo. Nie mam nic przeciwko dodawaniu kodu do sprawdzania typów itp., A ja jeszcze nie napotkałem błędu typu, który przysporzył mi wiele żalu (i wiem, że to niewiele mówi. To może być kwestia czasu: )). Bardzo podoba mi się jednak ta umiejętność dostosowywania się w locie.

Fajny wpis na blogu na ten sam temat: Python Makes Me Nervous

Podpisy metod są praktycznie bezużyteczne w Pythonie. W Javie statyczne typowanie sprawia, że ​​podpis metody jest przepisem: to wszystko, czego potrzebujesz, aby ta metoda działała. Inaczej jest w Pythonie. Tutaj podpis metody powie ci tylko jedną rzecz: ile argumentów potrzebujesz, aby zadziałała. Czasami nawet tego nie zrobi, jeśli zaczniesz pieprzyć się z ** kwargami.

Bo to fajna zabawa. Po pierwsze, fajnie jest nie martwić się o alokację pamięci. Fajnie jest nie czekać na kompilację. itp itp itp

Języki słabo wpisywane zapewniają elastyczność w zarządzaniu danymi.

Użyłem VHDL zeszłej wiosny dla kilku klas i podoba mi się ich metoda reprezentowania bitów / bajtów oraz sposób, w jaki kompilator wyłapuje błędy, jeśli spróbujesz przypisać 6-bitową magistralę do 9-bitowej magistrali. Próbowałem odtworzyć to w C ++ i mam spory wysiłek, aby starannie sprawić, by pisanie działało płynnie z istniejącymi typami. Myślę, że Steve Yegge bardzo dobrze opisuje problemy związane z silnymi systemami typów.

Odnośnie do gadatliwości: Uważam, że Java i C # są dość rozwlekłe w dużych (nie wybierajmy małych algorytmów, aby „udowodnić” punkt). I tak, napisałem w obu. C ++ również ma problemy w tym samym obszarze; VHDL ulega tutaj.

Parsymonia wydaje się być zaletą języków dynamicznych w ogóle (przedstawiam Perl i F # jako przykłady).