"Języki typowane dynamiczne - wolność w popełnianiu błędów"
Jestem znany z przywiązania do języków typowanych statycznie, jednak żeby się nie ograniczać postanowiłem poszukać czegoś dla siebie wśród języków z typowaniem dynamicznym*. Ostatecznie przekonało mnie do tego nowe podejście firmy Microsoft, która postanowiła zainwestować trochę kasy w integrację języków dynamicznych z platformą .NET. O innych względach przemawiających za językami dynamicznymi pisałem już w „Czy języki dynamiczne wyprą języki typowane statycznie?” (http://nandrew.blogspot.com/2007/10/czy-jzyki-dynamiczne-wypr-jzyki.html).
* - pozwolę sobie tutaj zauważyć, że język dynamiczny != język z typowaniem dynamicznym. Nie każdy zdaje sobie z tego sprawę ;)
Wbrew pozorom wybór języka okazał się dość prosty. Postawiłem przed nim niezbyt wygórowane wymagania:
a) normalna, czytelna składnia;
b) duża społeczność (eliminacja niszowych rozwiązań);
c) duża ilość stabilnych bibliotek (żadnych nowości);
d) opinia o języku;
Takie sito wyeliminowało: D (b,c), Groovy (b, c, d), Lisp (a), Perl (a), PHP (a, d), Ruby (a, c), Tcl (a, d).
And the winner is: Python.
Zaraz przejdę do subiektywnego opisu wad i zalet tego języka, najpierw jednak mała dygresja. Pamiętam jak X lat temu Java zdobywała popularność. Jednym z częstszych argumentów wysuwanych przeciw niej była szybkość programów pisanych w tym języku. Zresztą, to był także jeden z powodów, dla których pozostałem przy C++. Teraz jednak, gdy języki dynamiczne zdobywają popularność nagle okazuje się, że nikomu ta szybkość nie jest potrzebna. A przecież taki PHP czy Ruby jest wolniejszy od Javy o rząd wielkości. Jest wiele opinii o przyczynie tego stanu rzeczy, jednak na razie nie będę o tym pisał...
Zalety języka Python
a) ciekawe, czytelna i szybka składnia; bardzo duża społeczność użytkowników; bardzo dużo dojrzałych bibliotek i framework'ów; bardzo dobra opinia o języku (to tyle jeżeli chodzi o „sito”).
b) szybkość w porównaniu do PHP, Ruby, Groovy (Python jest częściowo kompilowany do bytecodu);
c) sporo typów wbudowanych i bardzo duże możliwości manipulowania nimi;
d) IronPython – czyli port języka na platformę .NET. Bardzo duży plus, ponieważ... to nie wymaga nawet uzasadnienia :)
Wady
Trochę tego uzbierałem w trakcie nauki języka.
a) Brak stałych
Bardzo dziwna sytuacja, gdy można bez problemu nadpisać wartość PI (math.pi = 4)! Coś takiego może rozłożyć program na łopatki, a szukanie takiego bug'a to horror, bo kto by pomyślał, że któryś z zaimportowanych modułów nadpisał PI (czyt. jakąś wartość uznawaną za stałą).
Na upartego można opakować stałe w metody typu getXXX(), jednak jest to jawne spowalnianie programu oraz burzenie przyzwyczajeń programistycznych.
b) Niezbyt czytelne elementy składni
Jak już pisałem, składnia Pythona powszechnie jest uważana za „ładną”, jednak zawiera parę elementów, które ją psują:
- prywatne pola klasy oznaczane przez „__” (double underscore) – no jakby jedna twarda spacja nie wystarczyła...;
- parametr self w metodach klas – w większości języków jest on ukryty, co ZMNIEJSZA konieczność bezsensownego klepania w klawiaturę. Tu jednak go postawili na piedestale, po co, dlaczego?! Nie wiem. Gruba przesada.
- tworzenie obiektów ma składnię taką samą jak wywołanie metody – przez co na pierwszy rzut oka nie widać o co chodzi. Dziwne, że pożałowali „self”, a „new” było dla twórców języka zbyt explicit :-\ Brak konsekwencji...
c) Wolny
Nie mówię o szybkości działania odziedziczonej ze „skryptowości” języka, lecz o tym, że przez wbudowane konstrukcje bardzo ułatwione jest wykorzystywanie operacji „czaso i zasobo chłonnych”. Bardzo częste jest wykorzystanie tupli (tworzonych w dużych ilościach), operacji na listach typy zip(), itp. Nawet kompilacja do exe nie pomoże przy nieoptymalnym kodzie. Oczywiście mając na uwadze wydajność przy programowaniu można temu zaradzić.
d) Słaby private
Jak już pisałem składniki prywatne oznacza się jako „__”. Jednak jest to bardzo słaba ochrona i rzeczywiste odwołanie się do takich pół nie stanowi większego problemu (ale lepsze to niż nic).
e) Brak modyfikatora typu protected dla metod
Zastosowanie tego modyfikatora przy skomplikowanych modelach obiektowych jest bardzo częste. Aż dziwne, że zabrakło go w Pythonie (w sumie może nie jest to aż tak dziwne, skoro ledwo private zaimplementowano).
f) Brak klas i metod abstrakcyjnych
Jest to kolejna wada i to dość duża odnosząca się do sposobu implementacji programowania obiektowego. Pod znakiem zapytania staje możliwość zastosowania niektórych wzorców projektowych. Szybkie przeszukiwanie google dało podpowiedź jak zaimplementować klasy abstrakcyjne, jednak wymaga to pisania około 100 linii kodu...
Ergo: ten język chyba nie służy do tworzenia skomplikowanych modeli obiektowych (biorąc pod uwagę punkty d, e, f);
g) Brak bloku try/except/finally
Jest to dziwne, ponieważ są konstrukcje try/except oraz try/finally, jednak try/except/finally jest niedozwolone. Trochę ogranicza to programistę.
Od wersji 2.5 blok try/except/finally jest zaimplementowany. Ach te 3 letnie książki... ("Beginning Python - From Novice to Professional", cyt. "Note that you cannot have both except clauses and a finally clause in the same try statement").
h) Brak porządnego IDE
Dobre środowisko jest nieodzowne przy profesjonalnych zastosowaniach (wspomaganie debuggingu, refactoringu (!), tworzenie GUI graficznie (a nie tekstowo) itp.). Zdaje się, że Python takiego nie posiada. Wprawdzie jest PyDev, jednak wiele mu brakuje do ideału (czyt. Visual Studio), np. IntelliSense działa tylko częściowo (bo zmienne nie maja typów, ale jest to raczej spowodowane cechą języka).
ALE jeżeli weźmiemy pod uwagę IronPython to sytuacja się trochę polepsza, bo VS będzie go wspomagał w przyszłości tak jak każdy inny standardowy język na platformę .NET.
i) Mała popularność wśród firm hostingowych
Język ten ciągle nie jest tak popularny jak PHP jako platforma dla aplikacji web. Przez to trudniej znaleźć hosting komercyjny, o darmowym nie wspominając (nie ma nic sensownego, gdzie by można pobawić się z językiem).
W prawdzie jest darmowy „Google App Engine”, jednak narzuca on wiele ograniczeń i udziwnień, które powodują, że aplikacje nie są przenośne – żaden inny hosting tego nie obsługuje.
Summary
Ze wszystkich języków dynamicznych najlepszy dla mnie okazał się Python. Ma on parę zalet i sporo unikalnych wad. Dopiero próba czasu (czyt. jakiś porządny projekt testowy) pokaże czy da się go użyć w sensownej aplikacji biznesowej (czyli w obszarze moich zainteresowań).
Testowy projekt oparty będzie na Django (czyt. dzengo). Framework webowy wybierałem o wiele dłużej niż język. Jednak tego wyboru nawet nie będę się starał uzasadniać...
