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

81

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?

Robert Harvey
źródło
9
Trochę smutne (i dziwne), że tak niewielu broni dynamicznych języków.
davidtbernal
11
Ponieważ jest to jedyny sposób, aby dostać się przede wszystkim do tych, którzy nienawidzą dynamiki poniżej, odpowiem tutaj: języki dynamiczne pozwalają pisać kod szybciej, bez dwóch zdań. Nie muszę martwić się o typ żadnej z moich zmiennych i nie muszę uruchamiać dużego, ciężkiego środowiska IDE, aby pisać kod. W związku z tym znacznie lepiej jest wykonywać szybkie zadania, które trwałyby dłużej w systemach typu statycznego ze względu na nieporęczność systemów czcionek, które powodują, że kompilatorowi powiesz WSZYSTKO.
RCIX
2
O co chodzi z krótkowzrocznością zaściankową programistów C #?
Azeem.Butt
2
Rozumiem, że nie czytałeś steve.yegge.googlepages.com/is-weak-typing-strong-enough ?
RCIX
5
Błędne nazwy zmiennych, które są problemem, pochodzą z niejawnej deklaracji zmiennej, a nie ze statycznej / dynamicznej. Dynamiczne języki, które wymagają jawnej deklaracji zmiennych (np. Smalltalk), nie mają tego problemu.
Frank Shearar

Odpowiedzi:

101

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.

Apocalisp
źródło
26
Porzuć typ bezpieczny dla wolności, na który nie zasługują ... O tak, stary ... Doskonale blisko postu
baash05,
6
lisp jest sam w sobie dość gadatliwy, nie ma nic wspólnego z dynamicznym wpisywaniem ... wypróbuj w Pythonie. def qsort (l): return qsort ([x for x in l [1:] if x <l [0]]) + l [0] + qsort ([x for x in l [1:] if x> = l [0]]) if l else l
fortran
13
Właśnie o to chodzi. Nie ma to nic wspólnego z wpisywaniem dynamicznym lub statycznym.
Apocalisp
9
Twierdzę, że twoje przykłady są raczej kiepskie. Ludzie chwalący języki dynamiczne raczej nie wybierają Lisp of Haskell. Prawdopodobnie wybierają Python lub Ruby zamiast Java lub C #.
Corey D
8
Argument mówi, że istnieje związek między gadatliwością a typowością. Jak widać, każdy taki zbieg okoliczności to czysty przypadek. Nietypowe jest właśnie to, dlaczego wybrałem te języki. Haskell jest silniej typowany niż większość innych, więc jest dobrym reprezentantem języków statycznych. LISP jest kwintesencją dynamicznego języka, który wszyscy inni koniecznie naśladują, ale nigdy nie powielają.
Apocalisp
70

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.

FlySwat
źródło
4
Cieszę się, że nie jestem jedyny. Lepiej spać w nocy.
erikkallen
To jest rzeczywiście duża zaleta pisania statycznego nad dynamicznym. Nie potrafię powiedzieć, ile razy przeoczyłem typ wpisu bezpiecznego w C ++, aby umożliwić kompilatorowi znalezienie kolejnych błędów. (Idź kompilator, idź! Przynieś mi więcej błędów! :-)
Dimitri C.
Nonsens. Jeśli testujesz metodę i testujesz metody, które ją wywołują, wiesz, że przekazywanie parametrów jest prawidłowe. Z definicji dobrze przetestowany kod nie przyniesie żadnych dodatkowych korzyści ze statycznego pisania.
Garth Kidd
4
@Garth: dziwna definicja. Niewiele osób by się z tym zgodziło. OTOH, większość ludzi zgodzi się, że narzędzie do sprawdzania typów kompilatora implementuje wiele (czasami bardzo złożonych) testów.
Konrad Rudolph
3
@yar, jeśli nie testujesz swojego kodu, jesteś podatny na błędy logiki. Pracuję w Pythonie od dekady. Nie sądzę, żebym kiedykolwiek miał TypeError w produkcji. Miałem jednak mnóstwo błędów logicznych. Wniosek: nie potrzebuję zbytnio sprawdzania typów statycznych, ale zdecydowanie potrzebuję testów jednostkowych.
Garth Kidd
40

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ę.

erikkallen
źródło
cytat: W dynamicznych językach możesz natychmiast zobaczyć swoje wyniki. Wiadomości: Możesz to zrobić również w C # w Visual Studio (od 2005). Wystarczy ustawić punkt przerwania, uruchomić program w debugerze i zmodyfikować program podczas debugowania. Robię to cały czas i działa idealnie. To było w Delphi od pierwszego dnia (1995?) I prawdopodobnie wcześniej w Turbo Pascalu (nie pamiętam dokładnie).
No'am Newman
6
10 tys. Linii javascript? Myślę, że to o około 9 000 linijek za dużo i uwielbiam języki skryptowe ...
Oz.
@ No'am: Wiem. Możesz to zrobić również w Visual C ++ 6 (co było dla mnie głównym powodem, dla którego nie przechodziłem na C #, dopóki nie pojawi się VS2k5). Jeśli już, to tylko dodaje do rzeczy. @Oz: Skąd wiesz, ile pracy musi wykonać mój JS?
erikkallen
Myślę, że ludzie, którzy lubią widzieć, jak ich zmiany od razu wchodzą w życie, jak przy użyciu zwykłego edytora tekstu, a nie VS. Do każdej jego własności. Możesz rozważyć użycie czegoś takiego jak JSLint.
dlamblin
2
Dobra uwaga z refaktoryzacją. Naprawdę zaczynam lubić Ruby do szybkiego prototypowania i małych skryptów, ale nigdy nie próbowałbym obsługiwać dużego produktu dla kilku programistów bez statycznego pisania.
LoveMeSomeCode
19

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.

Shog9
źródło
Ciekawe rzeczy ... Zobaczę, czy Ruby mnie przekonuje. PHP nie ma, ale wydaje mi się, że wiele z tego wynika z tego, że jest to po namyśle.
Dan Rosenstark
3
„dwadzieścia wierszy implementacji… i dwieście linijek gotowych do kompilacji”: Nie zgadzam się z tym stwierdzeniem. Jasne, było to prawdą w czasach Javy, ale C # 3 i Scala znacznie zmniejszyły ilość wymaganego standardu.
cdmckay
5
Dni Java się skończyły? tłucze piwo i przygotowuje się do świętowania Oh ... czekaj ... C ++.
Shog9
2
„VBScript jest do bani, chyba że porównujesz go z innym rodzajem VB” Co? Czy twierdzisz, że VBScript jest najlepszym wariantem Visual Basic? Musiałem cię źle oszacować.
MusiGenesis
19

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.

Peter Meyer
źródło
1
Chciałbym, żeby ktoś dodał obsługę plików, gniazda i bibliotekę GUI do JavaScript, a następnie zbudował kompilator ... JS na pulpicie .......
UnkwnTech
Ponadto zawsze można było napisać aplikację GUI dla systemu Windows przy użyciu jscript. Cóż, w każdym razie bardzo, bardzo długo. zobacz "windows hta", aby uzyskać więcej informacji - Otrzymujesz dodatkowe api działające w hta, których nie masz w przeglądarce. Widżety pulpitu nawigacyjnego mają dużo mocy. Aplikacje internetowe na iPhonie są o wiele potężniejsze niż większość ludzi przyznaje. Firma Apple udostępniła wiele potężnych interfejsów API do przeglądania JS w mobilnym safari.
Breton,
commonjs.org
Xiong Chiamiov
+1 dla zamiarów tutaj. Chociaż pewnego dnia twój kod może zostać przetłumaczony na język statyczny, dynamika (szczególnie Python) jest świetna w przypadku projektów jednorazowych i prototypów.
nowy123456
18

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

Chris Upchurch
źródło
25
To nie jest riposta, ale argument wspierający. Pokazuje, że system typów języka (lub jego brak) mówi nam bardzo niewiele o tym, czy będzie on rozwlekły, czy zwięzły.
Apocalisp
2
Zgadzam się z Apocalisp, gadatliwość nie jest zależna ani w językach dynamicznych, ani statycznych. Powiedziałbym nawet, że statyczne / dynamiczne pisanie ma niewielki lub żaden wpływ na gadatliwość języka. Więc tak, to nie jest statyczna niszcząca retorta typowania.
BefittingTheorem
lub perl! sort (@array);
James Anderson
Całe porównanie Apocalisp było bzdurą. Po pierwsze, quicksort (zgodnie z definicją w oryginalnej pracy Tony'ego Hoare'a) jest algorytmem w miejscu zaprojektowanym specjalnie w celu wykorzystania minimalnej dodatkowej przestrzeni, ale Apocalisp użył bastardizowanej wersji poza miejscem społeczności Haskell, która marnuje asymptotycznie więcej pamięci i działa setki razy wolniej niż prawdziwy quicksort. Haskell stara się wyrazić prawdziwy algorytm szybkiego sortowania, ponieważ opiera się na mutacji (!). Sprawdź te próby Haskella i wróć do mnie w sprawie rzekomej zwięzłości Haskella: haskell.org/haskellwiki/Introduction/Direct_Translation
JD
Po drugie, nie można wypowiadać się na temat gadatliwości na podstawie dwóch implementacji algorytmu, który został zniesiony specjalnie dla jednego z języków. Spójrz na APL, J lub K, Mathematica lub jakikolwiek inny zwięzły (= nowoczesny) język z dynamicznym typowaniem. Powinny być bardziej zwięzłe niż jakikolwiek inny język statyczny. Wnioskowanie o typach zmniejsza lukę, ale nadal powinna istnieć.
JD
15

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.

htanata
źródło
Co najmniej jedno środowisko IDE Pythona, o którym wiem (a mianowicie IDLE, to, które zdarza się przy zwykłej kompilacji interpretera Pythona) rzeczywiście ma możliwości automatycznego uzupełniania, chociaż zadeklarowane zmienne mają je tylko w oknie interpretera.
JAB
czytelny? widziałeś przykład quicksort? nie mam pojęcia, co się tam dzieje. Możesz argumentować, że jest źle napisany, aby pokazać, jak szybko możesz coś napisać, ale nie jest to czytelne.
IAdapter
1
@ 01: używa wspólnych konstrukcji języka. Jest dość czytelny, jeśli znasz podstawy języka.
Esteban Küber
1
Czytelność nie ma nic wspólnego z dynamicznym pisaniem. Np. Lambdy Scali są zazwyczaj krótsze (i prawdopodobnie bardziej wyraziste) niż bloki Rubiego, to samo porównuje dopełnienia list Haskella i Pythona. Konsola REPL istnieje np. Dla F #, Scala, Haskell. Szybkie ładowanie zmienionego kodu do uruchomionej aplikacji jest mocną stroną języków dynamicznych. Chociaż istnieją technologie, które pozwalają na to w językach statycznych (np. JavaRebel).
Alexey
1
Co ciekawe, uważam, że kod jest MNIEJ czytelny. Po pierwsze, ponieważ często nie mogę użyć mojego IDE, aby znaleźć deklaracje i osadzoną dokumentację itp., I po drugie, ponieważ składnia jest tak zwarta, dość często zapominam, co to znaczy! Chciałbym również położyć DUŻO większą wagę na utracie autouzupełniania IDE. Nie tylko jest to dar niebios, myślę, że absolutnie zwiększa łatwość konserwacji.
spronkey
12

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.

wvdschel
źródło
7
@wvdschel: Zgodnie z twoją logiką, mógłbym argumentować, że języki skompilowane, takie jak C # i Java, nie muszą być wtedy kompilowane, ponieważ wszystko, co muszę zrobić, to kliknąć przycisk „Graj” w moim IDE i po prostu działają. Ponieważ nie zauważam, że IDE kompiluje się dla mnie, to „po prostu nie ma znaczenia”.
cdmckay
2
@cdmckay: I czy możesz połączyć się z uruchomionym programem C # / Java i uruchamiać polecenia, modyfikując go lub wysyłając zapytania w trakcie działania. Języki zinterpretowane (którym jest wiele języków dynamicznych) pozwalają na introspekcję w czasie wykonywania, której języki kompilowane po prostu nie.
RHSeeger
4
@RHSeeger - Hm, tak, możesz to wszystko zrobić w Visual Studio. Edytuj i kontynuuj nie ogranicza się do języków dynamicznych.
Greg Beech
4
@ baash05, myślę, że całkowicie przegapiłeś punkt hte tej odpowiedzi, 1. oznacza, że ​​możesz szybciej uruchamiać kod tak, jak go poprawiasz, bez potrzeby czekania, aż kompilator zobaczy efekty każdej małej zmiany. 2. czy zgadzasz się z skutkami tego, czy nie, będzie mniej kodu do napisania i przeczytania bez sporu o ten fakt.
Fire Crow
1
2. To nie jest kwestia statyczna kontra dynamiczna, ale proceduralna i funkcjonalna. Prawda: Python (i wiele innych dynamicznych języków) są bardziej funkcjonalne niż Java. Fałsz: ma to coś wspólnego z dynamicznym pisaniem.
erikkallen
8

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.

airportyh
źródło
7

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!)

Matthew Schinckel
źródło
6

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.

yukondude
źródło
Nigdy wcześniej nie słyszałem nikogo, kto choćby sugerował, że lubi prototypowane obiekty JavaScript.
erikkallen
6

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ą.

Kibbee
źródło
Masz rację, że w językach dynamicznie wpisywanych nie ma nic, co pozwala na zmianę kodu w działającym systemie. Jest to o wiele łatwiejsze w przypadku języków interpretowanych (nie mylić z dynamicznymi), ale można to osiągnąć nawet przy użyciu skompilowanego kodu. Jako jeden przykład, Oracle PL / SQL jest statycznym językiem kompilowanym, a Oracle od dziesięcioleci ma tę funkcję, która umożliwia modyfikowanie procedur PL / SQL w działającym systemie.
Apocalisp
Jest teraz C # replika w Mono - mono-project.com/CsharpRepl
Steve
Języki dynamiczne mogą robić tego rodzaju rzeczy poza debugerem i z poziomu aplikacji . Ponadto, możliwość wykonywania małpich poprawek na zajęciach podczas wyłączania testów to oszczędność czasu.
Esteban Küber
6

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.

majkinetor
źródło
6
Czy często tworzysz kalkulatory? Uważam, że argumenty typu „Mogę utworzyć aplikację hello world w 20 znakach” nie mają żadnej wartości.
erikkallen
Właśnie pokazałeś, jak bardzo masz słabą wyobraźnię. Zła rzecz dla programowania m8. GL.
majkinetor
Nie ma potrzeby osobistego. Myślę, że ten punkt jest słuszny. Bardzo łatwo (i bardzo często) jest wymyślić argumenty typu „zobacz, ile kodu musisz napisać, aby wydrukować wiersz na konsoli w C #, w lua mogę po prostu powiedzieć print („ Hello, world ”) ”. Ale stosunek rzeczywistego kodu do standardowego nie pozostaje taki, gdy projekty osiągają realistyczny rozmiar.
erikkallen
2
Głupie gadanie. Oto kilka statycznie wpisywanych F #, które działają na platformie .NET: Linq.QuotationEvaluator.Evaluate <@ 2 + 3 @>
JD
6

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.

RHSeeger
źródło
1
W jakim sensie jest to lepsze niż $ mylist.length-2? Wydaje mi się, że ten rodzaj składni dodaje tylko dodatkowe słowa kluczowe bez realnej korzyści, co oznacza, że ​​język jest trudniejszy do nauczenia.
erikkallen
Będę trochę pedantyczny i zwrócę uwagę, że nie dodaje żadnych słów kluczowych do samego języka, dodaje je do tego polecenia. Biorąc to pod uwagę, jest to kwestia jasności. Termin „koniec” wyraża zamiar / znaczenie, a nie sposób, aby się tam dostać; mówi „ostatni element”.
RHSeeger
1
Jeśli dobrze rozumiem, to jest jeszcze gorzej. Musisz nauczyć się nowej składni dla każdego polecenia. co oznacza pasek słów kluczowych, gdy jest używany w poleceniu foo?
erikkallen
@erikkallen: To to samo, co uczenie się, jakie są różne dane wejściowe do standardowej biblioteki dla dowolnego innego języka. W rzeczywistości każde polecenie w rdzeniu Tcl jest mniej więcej tylko częścią standardowej biblioteki. Teoretycznie nie ma poleceń, których nie można by usunąć i ponownie zaimplementować jako czysty kod Tcl. To powiedziawszy, dane wejściowe i ich znaczenie są dość spójne w całej bibliotece (tj. Koniec oznacza to samo we wszystkich poleceniach)
RHSeeger
5

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.
Mój kod jest kompilowany
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.

UnkwnTech
źródło
3
Ojej, w praktyce ... cóż, może jestem po prostu niekompetentny, ale w PHP gottcha ze zmiennych z błędami ortograficznymi to ogromna strata czasu. Zwłaszcza gdy odziedziczysz ogromną bazę kodu, która nie pozwala na włączenie surowych ostrzeżeń.
Dan Rosenstark
1
Możesz ZAWSZE włączyć ścisłą error_reporting (), a każde dobre IDE zapobiegnie 99% błędnych pisowni zmiennych.
UnkwnTech
Nie wspominając o tym, że można napisać coś błędnego w dowolnym języku, jednak łatwiej (prawdopodobnie szybciej) znaleźć te błędy, ponieważ mój tłumacz jest na tym samym kroku przy linkowaniu / kompilacji, więc znowu twoja rebutacja jest nieistotna.
UnkwnTech
4
-1: argument kompilujący odwraca uwagę od prawdziwego argumentu, który dotyczy pisania, statycznego lub dynamicznego. Można kompilować i interpretować zarówno języki dynamiczne, jak i statyczne. Skargi dotyczące pisowni i czasu kompilacji nie wchodzą w zakres tych problemów.
BefittingTheorem
Dosłownie godziny? Na czym kompilujesz, na oryginalnym IBM PC?
xcramps
3

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.

Matt Mitchell
źródło
3
Wnioskowanie o typie nie jest tym samym, co typowanie dynamiczne, ponieważ wywnioskowany typ nadal musi być znany jednoznacznie w czasie kompilacji.
Marcus Downing
4
-1: C # jest wpisywany statycznie, a nie dynamicznie.
Julia
2

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ę.

Dan Herbert
źródło
2
Uważam, że każdy argument, który używa sformułowania „dla doświadczonych programistów nie stanowi problemu”, jest zwykle trochę niebezpieczny. Tak jak w przypadku, mógłbym powiedzieć, że OOP / zarządzanie pamięcią itp. W C ++ nie stanowi problemu dla doświadczonego programisty. Dlaczego przy czymś tak prostym, jak deklaracja zmiennej i podstawowe sprawdzanie typu, muszę być tak ostrożny i doświadczony? Wolałbym raczej, aby język pomagał mi programować, a nie pozwalał mi popełniać błędy, którym można łatwo zapobiec stosując statyczne podejście. I myślę, że gadatliwość ma bardzo niewiele wspólnego z dynamicznym lub statycznym pisaniem, patrz Haskell czy Scala.
BefittingTheorem
Zgadzam się, uważam ten argument za trochę niebezpieczny. Chodzi mi o to, że kwestia sprawdzania typu w czasie kodowania nie jest taka zła. W 90% przypadków zobaczysz błąd od razu. Jest to problem w 10% przypadków, w których niejawna konwersja typów może powodować stres, jednak kiedy wiesz, co robisz, nie pozwolisz na to. JavaScipt to świetny przykład 10% przypadków, w których może to być niebezpieczne, ale nigdy nie zostałem przez to ugryziony przez cały mój czas, gdy pracowałem nad tym.
Dan Herbert,
@Brian Heylin: musisz nienawidzić C! Tyle sposobów, aby strzelić sobie w stopę, a jednocześnie tak używanych i (w niektórych przypadkach) kochanych.
Esteban Küber
2

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!

umar
źródło
1
Twój punkt 1 i 3 są identyczne, a IMO jest powodem preferowania pisania statycznego. Co się stanie, jeśli zmienisz typ na coś, co nie jest zgodne? Jeśli zmienisz zmienną z int na łańcuch, prawdopodobnie robisz to z jakiegoś powodu. A jeśli nie, po prostu odbuduj projekt, aż wszystkie błędy kompilacji znikną. Zwykle nie zajmuje to dużo czasu, a czasami w trakcie tego procesu odkrywasz prawdziwy problem, z którego cieszysz się, że kompilator ci wskazał. Punkt 2 jest nieważny, rozwijanie łańcucha odbywa się automatycznie we wszystkich językach (chyba przynajmniej we wszystkich, z którymi się spotkałem przez ostatnie 15 lat) z wyjątkiem C.
erikkallen
Zgadzam się, że w zależności od aplikacji, możesz mieć powód, aby preferować jeden z typów języków, a języki statyczne, które są szybsze, mogą zapewnić lepszą wydajność. Ale mówiłem, że jeśli musisz stworzyć podobną do każdej innej aplikacji internetowej, możesz lepiej dostarczać funkcje szybciej, używając języka dynamicznego niż statycznego. załóżmy również, że musisz użyć zmiennej x w taki sposób, że x.func = "yes", a x.func _ = "no". nie obchodzi cię, jaki to rodzaj, jest to kaczka, o ile pływa jak kaczka. z tego powodu dynamiczne pisanie jest również nazywane pisaniem typu kaczego. 0 zostało!
umar
1

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 :)

Jeff Kotula
źródło
1

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.

bdwakefield
źródło
1
Powiedziałbym, że czas kompilacji naprawdę zależy od używanego języka. W .Net kompilacja projektu o takim rozmiarze może zająć tylko kilka minut. Jeśli zrobiło to w C, widziałem, że kompilacja wszystkiego zajmuje trochę czasu.
Kibbee
Okej, dam ci to. Ale kiedy się nad tym zastanowić, ile projektów, które chciałbyś napisać w C, dałoby się napisać w PHP ze znacznym czasem kompilacji? Myślę, że jest pewien punkt, w którym języki interpretowane nie są odpowiednim narzędziem do pracy i odwrotnie. Jestem wielkim fanem wybierania odpowiedniego narzędzia do pracy i używania tego, w czym pracujesz najlepiej. Nie widzę powodu, aby próbować sprawić, by jeden język robił wszystko, podczas gdy inny może to zrobić łatwiej. Nie ma powodu, aby ponownie uczyć się tego, co wiesz.
bdwakefield
Przy okazji, jest wtyczka php dla VS jcxsoftware.com/vs.php Nie próbowałem jej jeszcze, ponieważ nie jest darmowa, ale z tego, co słyszałem, jest tak dobra z php jak Zend (5.5 jak 6 do bani) ze wszystkimi dobroć VS
UnkwnTech
Właśnie trafiłeś na jeden z największych powodów, dla których nikt nie używa tak często języków dynamicznych. Nikt nie zbudował dużego, wymyślnego 2-milionowego kodu IDE, które może zrobić prawie wszystko dla każdego z nich, więc wszyscy narzekają na to, że „nie są bezpieczni, więc łatwo jest popełniać błędy”
RCIX
Nie obchodzi mnie bezpieczny non-sens. To mi nie przeszkadza. Moją największą skargą jest to, że fizycznie zajmuje to więcej czasu i często trudniej jest wyśledzić problemy. Uważam, że styl rozwoju jest sprzeczny z tym, jak lubię pracować.
bdwakefield
1

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.

Stephan Eggermont
źródło
1

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.

RHSeeger
źródło
1

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ś?

Stefano Borini
źródło
1

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)
RCIX
źródło
3
To naprawdę nie kłótnia. Nie jesteśmy zupełnie nowymi programistami; ta debata toczy się zaciekle między niezupełnie nowymi programistami.
peSHIr
To tylko jeden z powodów, dla których programiści mogli preferować języki dynamiczne; są na ogół łatwiejsze do zrozumienia niż inne i dlatego przyciągają do siebie więcej nowych programistów.
RCIX
1

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ę.

dlamblin
źródło
1

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.

Daniel Paull
źródło
1

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.

Pion
źródło
1

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.

Agnel Kurian
źródło
0

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

Andy Lester
źródło
19
Wyrzucanie elementów bezużytecznych jest prostopadłe do statycznego / dynamicznego sprawdzania typów.
mmagin
0

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).

Paul Nathan
źródło
Ekwiwalentem przypisania 9-bitowej szyny do 6-bitowej jest próba przypisania int do short lub czegoś podobnego. Jest to błąd w C # (i, jak sądzę, Javie) i każdy kompilator C lub C ++ powinien być w stanie wydać ostrzeżenie o tym.
erikkallen
-1. Weakly typed language != Dynamically typed language.
Joe D