Miesiąc temu wpadłem na genialny pomysł napisania kilku skryptów w Pythonie dla pewnego banku. Ponieważ ich system posiadał natywne wsparcie dla skryptowania w Pythonie, oraz było dużo przykładów, no i oczywiście wiadomo, że "wszyscy lubią Pythona, bo Python dobrym językiem jest", a do tego projekt nie był jakiś bardzo duży, to zdecydowałem się, że zrobię to w Pythonie i że powinien być w sam raz do tego celu.
Wnioski:
-
Brak statycznej kontroli typów ssie. Brak konieczności pisania typów: oszczędność 10 sekund. Brak walki z kompilatorem o to że typ się nie zgadza - oszczędność kolejnej minuty, oszczędność czasu kompilacji: pięć minut. Uruchamianie programu tylko po to, aby przeklikać się przez 5 formularzy i na piątym z pięciu, po kliknięciu ok, skrypt się wywalił, bo jest zła kolejność argumentów - bezcenne. Za pierwszym razem jest facepalm, spokojnie się poprawia i testuje dalej, ale jak się robi takie coś 10 razy z rzędu to ma się ochotę wyp****yć komputer za okno. Kto w swoich programach ma zawsze 100% pokrycia testami automatycznymi, może się nie zgodzić.
-
Biblioteka standardowa ssie. Język, który ma lambdy a nie ma czegoś tak podstawowego jak fold, forall czy exists w standardzie, tylko trzeba sobie samemu napisać?
-
Brak statycznej kontroli typów ssie nawet bardziej. Przypomniały mi się stare dobre czasy szablonów C++, kiedy dostałem gdzieś z czeluści biblioteki standardowej pythona błąd postaci "list indices must be integers, not strings". Pół godziny albo i więcej szukania, gdzie przekazałem obiekt złego typu. Oczywiście było to w zupełnie innym miejscu niż wskazany błąd.
-
Pisałem już, że biblioteka standardowa ssie? Dlaczego jest os.listdirs, shutil.ignore_patterns i zipfile.ZipFile??
-
Brak statycznej kontroli typów rozkłada IDE. Podpowiadanie nazw metod/funkcji dla bardziej podstawowych rzeczy nawet działa. Z wyjątkiem sytuacji kiedy nie działa, albo podpowiada jakieś głupoty.
-
Składnia jest spoko, ogólnie język dosyć łatwy do nauczenia. Oczywiście mogło być lepiej. Np. [] służą zarówno do indeksowania tablic/stringów jak i do specyfikowania ich zawartości. Specyficzna składnia dla słowników też zalatuje trochę Perlem.
-
A, no i bibliteka standardowa... Język ponoć zachwalany do zadań administracyjnych (jako konkurencja dla Perla), niektórzy chcieli nim powłokę zastępować, a nie można jednym poleceniem skopiować rekurencyjnnie plików z jednego katalogu do drugiego, niepustego katalogu. No dobra, można wywołując funkcję powłoki systemu, ale traci się przenośność.
-
Nadal nie mogę dojść do tego, kiedy coś jest zwykłą funckją globalną (jak np. map, reduce, filter), a kiedy metodą - czy oni się tu kierowali jakąś zasadą czy dodawali tak jak się wylosowało. Np. czemu jest len(string), ale już string.upper()? Idzie się do tego przyzwyczaić, ale dla poczatkującego, jeszcze przy nie-do-końca-działającym podpowiadaniu w IDE takie nielogiczności są okropne.
-
Szybkość... Eee tam, stary i oklepany argument. Akurat szybkość wykonywania kodu w tym projekcie była bardzo zadowalająca, większość czasu męczył się system przy przesyłaniu danych przez sieć.
-
Znaczące wcięcia - mnie jakoś nie przeszkadza, dopóki ktoś nie otwiera mojego kodu w notatniku ustawionym domyślnie na taby a nie spacje.
-
Język ma lambdy, ale sensownie programować funkcyjnie w tym się nie da. Po co to? Chyba tylko by drażnić ludzi. Czuję się jakby ktoś otworzył pudełko z czekoladkami, dał mi jedną, a sam zjadł całą resztę.
Podsumowując, nie zaczynajcie uczyć się Pythona po nauczeniu się Scali, bo się tylko niepotrzebnie poirytujecie.