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

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?

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.

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

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…

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.

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.

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.

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.

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

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.