🚀 go-pugleaf

Aleksander Galicki wrote:
- Ale unit testy nie zastapia statycznego typowania. -

No właśnie to negują zwolennicy dynamicznego typowania. Jak patrzę na
w miarę niereligijnie prowadzone dyskusje (np. No Fluff Just Stuff),
to właśnie zwolennicy dynamicznego typowania upierają się, że
statyczne typowanie nie eliminuje błędów (poza - jak twierdzą -
głupimi, typu literówki, które łatwo wyjdą podczas pierwszego
uruchomienia testów lub programu) - a jedynie "zadowala" kompilator.
Błędy semantyczne pozostaną. I podkreślają przy tym, że nie ma co
nawet myśleć o dynamicznym typowaniu, jeśli nie ma się nawyku
pokrywania tworzonego kodu unit testami (przy tym podają miary
pokrycia na poziomie minimum 90%). Przyznam, że mnie to przekonuje (a
przynajmniej na razie - nie popełniłem jeszcze żadnej dużej aplikacji
w takim języku jak choćby Groovy - stąd staram się nie popadać w
skrajności i słuchać argumentów każdej ze stron). Z drugiej strony -
to co starałem się przy okazji Grooviego podkreślić - że można używać
zarówno statycznego (np. String s = 'W') jak i dynamicznego typowania.
Dynamiczne, też w dużym stopniu polega na określaniu typu implicite
(np. def i = 1.0f powoduje, że zmienna i jest typu java.lang.Float).
Każda zmienna ma typ i muszą być zdefiniowane ścisłe reguły konwersji
między typami - miejsca na magię nie ma. Gdzieś podczas przyglądania
się Grooviemu napotkałem taki rule of thumb, że jeśli podczas
tworzenia kodu "myślimy" o typie, to warto go zadeklarować, ale jeśli
myślimy po prostu o obiekcie, to można zastosować dynamiczne
typowanie.

Co do interfejsów - zgoda - ale jak się przyglądam implementacji
generyków w Java 5 (choćby w kontekście ich użycia w interfejsach, po
to aby interfejs i jego implementacje były w miarę zwięzłe), to w
sumie i tak statyczne typowanie jest często tracone, bo np. generyczne
kolekcje wewnętrznie i tak korzystają z Object.

Wydaje mi się, że dużo zależy od indywidualnego stylu programisty i
tego czy wie po co dane narzędzie zastosował - jak to z narzędziami
bywa - czasem można się pokaleczyć..

Cóż - jeśli efektem zainteresowania SOA będzie stosowanie interfejsów
i luźnych połączeń, a efektem zainteresowania językami typu Groovie
czy Ruby będzie wzrost "popularności" unit testów, to chyba warto siać
marketingiem ;-)

Co do Grooviego - to co moim zdaniem przede wszystkim wyklucza go NA
RAZIE z poważniejszych zastosowań, to:
- młody wiek implementacji ("niewygrzanie")
- wciąż duże tempo zmian w samym języku i jego otoczce
- słabe wsparcie narzędziowe (np. IDE)
- słabe wsparcie komercyjne (co pewnie jest pochodną dwóch pierwszych)
- tak, aby zaspokoić odbiorców enterprise

Co do tego co napisał A.L. - dzięki za podzielenie się doświadczeniem
(wow - milion linii w Smalltalku - ile Wam wyszło linii w Java ?). Tak
z ciekawości zapytam - czy te błędy miały związek z brakiem typowania
(bo chyba w Smalltalku ten dynamizm jest aż tak daleko posunięty -
poprawcie jeśli się mylę) ?

Pozdrawiam,
Waldek Kot
BEA