Języki dynamiczne a statycznie typowane dla stron internetowych [zamknięte]

13

To stwierdzenie sugeruje, że statycznie wpisane języki nie są idealne dla stron internetowych:

Przeciwstawię to budowaniu strony internetowej. Podczas renderowania stron internetowych często wiele elementów wchodzi w interakcje na stronie internetowej. Masz tutaj przyciski i małe widżety, a na stronie internetowej jest ich kilkadziesiąt, a także być może dziesiątki lub setki stron internetowych, które są dynamiczne. W przypadku systemu o naprawdę dużej powierzchni tego typu używanie statycznego języka jest w rzeczywistości dość mało elastyczne. Uznanie, że programowanie w Scali i renderowanie za jej pomocą strony internetowej byłoby dla mnie bolesne, gdybym chciał interaktywnie naciskać przyciski i co nie. Jeśli cały system musi być spójny, tak jak cały system musi sprawdzać, aby móc poruszać przyciskiem, myślę, że może to być naprawdę mało elastyczne.

Źródło: http://www.infoq.com/interviews/kallen-scala-twitter

Czy to jest poprawne? Dlaczego lub dlaczego nie?

Bradford
źródło
6
Wydaje mi się, że nie wzięli pod uwagę języka / pakietu z odpowiednią hierarchią obiektów. Nie ma potrzeby, aby sprawdzić, czy kontrola ruszasz jest Buttongdy WebControlzawiera wszystkie potrzebne informacje, a wszystkie elementy sterujące pochodzą od niego.
Mateusz
5
Tak @Matthew - brzmi jak ktoś, kto tak naprawdę nie zna polimorfizmu
Nicole
8
Również - Twitter może być popularny, ale nie dlatego, że jego strona jest arcydziełem inżynierii.
Nicole

Odpowiedzi:

39

Całkowicie się nie zgadzam. Gdy systemy stają się coraz większe, języki o typie statycznym zapewniają niezawodność na poziomie komponentów, a tym samym elastyczność na poziomie systemu.

Również przykład podany przez autora nie ma żadnego sensu. Wydaje się raczej, że ten facet nie wie, że polimorfizm można osiągnąć innymi sposobami niż pisanie kaczek.

Istnieje wiele osób, które twierdzą, że języki dynamiczne są lepsze, ale zwykle wynika to z braku doświadczenia z ekspresyjnymi systemami typów, które na przykład obsługują podtyp strukturalny, typy danych algebraicznych i funkcje pierwszego rzędu.

back2dos
źródło
1
W jaki sposób funkcje pierwszego rzędu należą do tej samej kategorii, co typy strukturalne i algebraiczne typy danych? Sprawiasz, że brzmi to tak, jakby języki dynamiczne nie miały funkcji pierwszego rzędu, co oczywiście nie jest prawdą (Schemat, Common Lisp, Erlang, Smalltalk, ...).
Frank Shearar
21
+1 za „Wygląda na to, że ten facet nie wie, że polimorfizm można osiągnąć innymi sposobami niż pisanie kaczek”.
Nicole
1
@Frank Shearer: Mam na myśli to, że są obsługiwane z takim samym bezpieczeństwem, jak każda inna wartość. Istnieje wiele ściśle wpisanych języków, które obsługują wartości funkcji, ale nie rozróżniają podpisów.
back2dos
1
Ja też się nie zgadzam, dlatego wybieram to jako odpowiedź.
Bradford,
8

Przede wszystkim należy pamiętać, że autor powyższego oświadczenia mówi o tworzeniu stron internetowych. Martwi się więc rozwojem prezentacji i właśnie tam myśli, że Scala nie byłby dobrym wyborem ...

Powiedziawszy to, mam duże doświadczenie w tworzeniu stron internetowych. Pracowałem z nim przez co najmniej 8 lat, z czego 5 w agencjach cyfrowych.

I tak, z mojego doświadczenia, statycznie wpisany, skompilowany język na warstwie prezentacji może być dużą przeszkodą. Treść musi być ciągle zmieniana, znacznie częściej niż wymagania biznesowe. I zwykle musi to zrobić odrębny zespół (programiści „front-end”). Zwykle dużo wiedzą o HTML, JavaScript, standardach internetowych, CSS, ale niewiele o językach po stronie serwera, takich jak Java i C #. Zakładają również, że każda zmiana w szablonie jest natychmiast dostępna; nie są one używane do kompilacji i pisania błędów. I mają rację: języki o typie statycznym są bardzo dobre w przypadku trudnych, złożonych wymagań, takich jak dostęp do danych i reguły biznesowe, ale nie tak dobre do opracowywania interfejsu.

To w rzeczywistości jedna z głównych zalet korzystania ze specjalistycznego i zinterpretowanego języka szablonów, takiego jak Velocity . Łatwość użycia, moc i elastyczność są wystarczające dla programistów warstwy prezentacji. A potem faceci po stronie serwera mogą używać poważnego, statycznie pisanego języka wszędzie indziej ...

Jednak zgadzam się również, że Scala jest nieco inna. Będąc jednocześnie o wiele mniej gadatliwym i bardziej ekspresyjnym niż Java, uważam, że można go wykorzystać do tworzenia prezentacji - więc może z powodzeniem można go użyć jako języka szablonów. A jeśli można go również połączyć z frameworkiem takim jak Play (który automatycznie kompiluje witrynę po każdej zmianie), może być zwycięzcą IMHO. Mimo to nawet Play wybrał język szablonów Groovy (dynamiczny), co nie jest dobrym znakiem.

Podsumowując: problem ze Scalą jest o wiele bardziej związany z faktem, że jest skompilowany. W rzeczywistości mechanizm wnioskowania o typie sprawia, że prawie zapominasz, że jest on również wpisywany statycznie.

(I przepraszam za mój angielski. Daj mi znać, jeśli coś nie jest jasne, postaram się to naprawić.)

rsenna
źródło
1
Poparłbym to - popatrz na bałagan JSP / STRUTS, kiedy próbowali uczynić Javę językiem internetowym!
James Anderson
8

Myślę, że tekst (i większość odpowiedzi) mieszają języki o typie statycznym i języki zbyt szczegółowe . Oczywiście skrzyżowanie jest bardzo duże (szczególnie biorąc pod uwagę tylko najbardziej popularne języki); ale istnieje kilka interesujących przykładów języków nieokreślonych, o typie statycznym: Go, Haskell, Scala, Rust…

Javier
źródło
2
Zdefiniuj „nadmiernie”. W miarę jak programy stają się coraz bardziej złożone, a ich żywotność i cykle konserwacji rosną, prawdopodobieństwo, że ktoś inny niż oryginalny autor będzie musiał debugować lub modyfikować dowolny fragment kodu, nadal rośnie. Kiedy znajdujesz się w takiej sytuacji, zwykle jesteś pod bronią, a im więcej informacji jest od razu dostępnych na temat dokładnie tego, z którymi danymi masz do czynienia i co może zrobić lepiej. Debugowałem Delphi innych ludzi i JavaScript innych ludzi, a Delphi jest o rząd
Mason Wheeler
1
Na marginesie: coś w rodzaju TypeScript (JavaScript, ze statycznymi informacjami o typie) może być prostym sposobem na przetestowanie teorii OP. Moje krótkie zetknięcie się z tym tematem było całkiem miłe - pewnego razu podczas konwersji niektórych skryptów JavaScript na TypeScript pomogło mi odkryć, że nie ma możliwości wywołania określonej metody i nie powoduje błędu .
Katana314
5

Zachęcam do zapoznania się z Mocnym typowaniem kontra mocne testowanie Bruce'a Eckela . Głównym argumentem jest to, że jakość oprogramowania sprowadza się do testowania. Możesz testować na wiele różnych sposobów. Kompilatory testują niektóre rzeczy w czasie kompilacji: spróbuj zapisać ciąg znaków w zmiennej int i prawdopodobnie cię zaszczeka. W językach dynamicznych wiele testów odbywa się w czasie wykonywania. Ostatecznie nie ma znaczenia, kiedy nastąpi test. To po prostu musi się zdarzyć. Czas, który zyskujesz, nie kompilując w dynamicznych językach, jest tracony podczas testowania. Dokładnie wszystko testujesz, prawda?

Biorąc to pod uwagę, preferencja dla języków skompilowanych ze sztywnymi systemami typów w porównaniu do języków dynamicznych jest właśnie taka - preferencja. Coś jak bokserki kontra figi lub stringi kontra francuskie figi. Nie ma dobrej lub złej odpowiedzi. Noś je z odpowiednim nastawieniem, a jest tylko niesamowite.

Scant Roger
źródło
1
„Kompilatory testują niektóre rzeczy w czasie kompilacji: spróbuj zapisać ciąg w zmiennej int i prawdopodobnie będzie on na ciebie szczekał. W językach dynamicznych wiele testów odbywa się w czasie wykonywania.”: To prawda, że ​​przy użyciu dynamicznego języka zdarza się pisać wiele testów, które zastępują sprawdzanie typu. Używając języka statycznego, mogę sprawić, by moje testy koncentrowały się bardziej na logice biznesowej.
Giorgio
@Giorgio Interesujące, rzadko mam logikę sprawdzania typu w moich testach.
pllee
@pllee: Czasami nie jest to logika bezpośrednio sprawdzająca typ, ale testy sprawdzają pewne zachowanie, które i tak wymusiłby system typu statycznego.
Giorgio
Wydaje się, że Bruce Eckel to kolejna osoba, która spędziła lata na nadmiernie gadatliwych językach (Java, C ++, ...), a następnie przeskakuje pierwszy inny pociąg (Python), z którym się spotyka. Spędza połowę artykułu, chwaląc świetną składnię Pythona. Nie ma nic do wniesienia w tej debacie z powodu braku wiedzy.
ziggystar,
Ale jeśli spróbujesz zapisać ciąg w zmiennej int w języku dynamicznym - na pewno nie zauważysz, dopóki nie uruchomisz / nie przetestujesz aplikacji i nie zobaczysz jej w akcji. Ale w praktyce (ponad 17 lat rozwoju) bardzo rzadko postrzegam to jako główną przyczynę błędu! Zawsze! Ale nawet jeśli JEST - zauważasz to i naprawiasz? O co tyle szumu? To tak, jakby cały argument opierał się na bardzo technicznym rzadkim przypadku krawędzi. To nie jest duży problem! Z drugiej strony zaletą pisania dynamicznego jest to, że programowanie jest znacznie szybsze.
Manachi
2

Zgadzam się z tym w większości przypadków, jeśli, ponieważ spójrzmy prawdzie w oczy, kiedy masz do czynienia z klientami na platformie internetowej, elastyczność jest koniecznością.

Języki o typie statycznym są bardziej niezawodne i bezpieczne niż języki o typie dynamicznym, ale kiedy zaczniesz dostosowywać kod, aby działał w sposób, w jaki nie powinien być, i potrzebujesz go szybko, rozwiązania wyglądają na złożone i sztywne.

Więc jeśli masz zmianę w łączeniu technologii, zaleciłbym utworzenie rdzenia w języku o typie statycznym (rdzeń nie zmienia się dużo) i używanie dynamicznie do interakcji użytkownika.

guiman
źródło
Luźne połączenie jest dobre. Ale dynamiczne języki nie są wymagane do osiągnięcia tego. Widzisz, w sieci chodzi o luźne łączenie przez HTTP, a większość serwerów i przeglądarek jest napisana w językach statycznych. Języki dynamiczne świecą w aplikacjach skryptowych , gdy potrzebujesz fragmentu kodu, który można łatwo modyfikować w czasie wykonywania, bez wywoływania dużego łańcucha narzędzi.
9000
2

Myślę, że autor tego postu nie zajrzał do Scali. Chociaż zgadzam się, że Java i C # mają ograniczenia i są trochę nieelastyczne w programowaniu stron internetowych, Scala jest językiem o typie statycznym, który różni się od tego, o czym zwykle myślisz, kiedy to słyszysz. Scala pozwala na pisanie kaczek, a także jako bezpieczną wersję łatania małp (poprzez niejawne konwersje). To sprawia, że ​​biblioteki programowania są nieco bardziej skomplikowane, ponieważ będziesz musiał pomyśleć o typach, ale jeśli po prostu użyjesz biblioteki takiej jak Lift, będzie to wyglądało jak język dynamiczny, z wyjątkiem tego, że kompilator poinformuje cię o oczywistych błędach, których po prostu nie używasz. dobrze. Osobiście uważam, że framework web windy nie musi się ukrywać przed rubinem na szynach itp. Zobacz przykłady kodu tutaj lub tutaji zdecyduj sam. Rozwijam się w windzie już od dłuższego czasu i nigdy nie miałem sytuacji, w której miałem błąd typu i chociaż „Ach, człowieku, gdyby był dynamiczny, działałby”… ponieważ gdyby był dynamiczny, po prostu nie powiedziałby mi, że występował błąd, dopóki nie zawiesił się podczas działania.

Martin Ring
źródło
1

Osobiście uważam, że to, co mówią, jest prawdziwe dla każdego systemu, nie tylko stron internetowych. Będziesz potrzebować pisania statycznego, gdy rozmawiasz ze sprzętem, ponieważ wszystko inne dynamiczne pisanie ma te same wady i zalety, bez względu na to, co robisz, naprawdę, a to, co najlepsze, zależy od gustu i konkretnych problemów dla każdego projektu.

Lennart Regebro
źródło
Myślę, że warto zauważyć, że Scala jest nieco wyjątkowa, ponieważ korzysta z wnioskowania o typie, a zatem nie należy do tej samej kategorii pisania statycznego, co na przykład Java.
Winston Ewert
1

Praktyczna Szybka odpowiedź: zależy od wielkości i złożoności rozmiaru strony. Mała strona internetowa, dynamiczny program lang., Complex Large strona internetowa, statyczny progr. język

Rozszerzona nudna odpowiedź: wielu programistów nalega, aby strona internetowa była wykonywana przy użyciu dynamicznego programu. Langr. ale prawda jest taka, że ​​ostatecznie narzędzia do tworzenia stron internetowych używają lub emulują języki o typie statycznym.

Pracowałem z PHP kilka razy i prędzej czy później musieliśmy dodać dużo kodu, który weryfikuje typy danych, co jest domniemane w progr o typie statycznym. język

Wpisany Lagn. pomaga również w użyciu IDE, które wymagają dużej weryfikacji typu.

(dostarczone przez twojego sąsiada, programistę i projektanta kompilatorów ;-))

umlcat
źródło
0

W pewnym sensie się zgadzam. Gdy patrzę na większość kodu C # frontonu, jest dużo rzutowania z ciągów i szeregowania danych na ciągi. Zasadniczo HTTP jako protokół dobrze pasuje do języków dynamicznych.

Nemanja Trifunovic
źródło