Obecnie pracuję nad dużą aplikacją Django, w mojej poprzedniej pracy pracowałem nad dużym projektem Java (aplikacja komputerowa, a nie w sieci, ale nadal jest odpowiednia do tej dyskusji) i jestem trochę rozdarty między zgodą a nie zgadzam się z autorem.
Podczas gdy ja lubię Python przez Javę i mam duże doświadczenie w pracy z innymi dynamicznie pisanymi językami, takimi jak Ruby i Objective-C, nadal nie jestem przekonany, który jest lepszy (statyczny vs. dynamiczny). Czasem w Python-land myślę, że byłoby ładniej mieć statyczne typy i kompilator, aby zapobiec błędom; Nie lubię modelu typu Java, ale Scala ma porządny system typów, który nie przeszkadza, ale zapobiega wielu błędom.
To powiedziawszy, uważam, że sukcesy/niepowodzenia w korzystaniu z Pythona lub Javy mają więcej wspólnego z doświadczeniem i doświadczeniem zespołu. Wydaje mi się, że artykuł ten byłby lepiej zatytułowany "Straying from Java denerwuje mnie", ponieważ autor zdaje się głównie mówić: "Mam doświadczenie z Javą, nie rozumiem/nie mam doświadczenia z Pythonem. wygodniejsze pisanie kodu Java. " Myślę, że doświadczeni programiści Pythona uczą się pracować z/wokół większości "problemów", które on postrzega; Python nie jest językiem Java i wymaga innego podejścia do programowania.
miałem też trochę chichotać na tej linii:
Java posiada dobrze przemyślane hierarchii sprawdzonych i uruchomieniowych wyjątkami.
Myślę, że większość zgodzi się, że hierarchia wyjątków Java jest niejasna w najlepszym wypadku, i że sprawdzane wyjątki były opłacalne, ale nie eksperyment, który tak naprawdę nie uczynić kod bardziej wytrzymałe (przypuszczam robią jeżeli są stosowane prawidłowo, ale ilu programistów Java używa wyjątków poprawnie?).
Wydaje się, że robi to źle. Przynajmniej, nawet jeśli kod, który napotkał, nie jest robiony w ten sposób, nic nie stoi na przeszkodzie, by zespół programistów poprawnie dokumentował ich kod (za pomocą docstrukcji itp.), Tak aby dokumentacja zawierała informacje o tym, co nie jest powiedziane przez kod ze względu na brak pisania statycznego. A ponieważ Python jest językiem interpretowanym i często uruchamianym z interpretera, uzyskanie dokumentacji dla metody jest tak proste jak zaimportowanie metody i wpisanie 'help ([nazwa_metody]). (Problem polegałby na tym, że musieliby właściwie udokumentować swój kod, jak sądzę.) – JAB
autor postu nie jest przyzwyczajony do stylu pytonicznego. nie wspomina o doc-stringach. Czytałem doc-stringi. Przeczytałbym dokumentację. Oczekuję, że zespół pracujący nad biblioteką Pythona albo wszystko udokumentuje, albo zbuduje coś, co wymyślę, jak z niego korzystać, bez czytania całego ich kodu. Pierwszą rzeczą, na którą patrzę, kiedy zacznę korzystać z biblioteki, nie są w ogóle sygnatury funkcji, to przypadki testowe i główna aplikacja "main.py" zawierająca kod uruchamiania i zamykania. –
Co do zasady staram się nie przejmować kwestiami poruszanymi przez blogerów, którzy nie są w stanie wyrazić siebie bez wulgaryzmów. Pomyśl o tym jako o "zapachu argumentu". –