Czy Python jest za prosty?

Nieposkromiony Kura napisał(a):

Programuje na codzień w pracy w pythonie i muszę powiedzieć, że wydaję mi się to strasznie prosty język i czuję się z tego powodu niedowartościowany. Po godzinach wracam do domu i z zapałem siadam do pisania w c++, gdzie niemalże czuję jakbym był jednym ciałem z moim laptopem. Zarządzanie pamięcią, multithreading, statyczne typowanie to jest prawdziwe życie.

a potem pytają na rekrutacji o zainteresowania i dowiadujesz się, że nie pasujesz pan do naszej kultury organizacyjnej.
Taka mała frustracja na to, że pracodawcy chcą gości, co i wymiatają jak geniusze i zarazem wiodą żywot bananowego normika z iq 100.

Python to dobry język do wymyślania, tworzenia, szkicowania. Z Pythonem łatwiej można zrozumieć produkt, jest mniejsze tarcie podczas zrzutu myśli na kod, łatwiej jest eksperymentować, upraszczać, a także oferować różne warianty rozwiązań dla klienta. Tymczasem programiści z tego nie korzystają, oni wykonują odgórne zadania, jak kopacze którzy kopią rowy. W trybie "wykonywania" praca z Pythonem rzeczywiście jest uwłaczająca.

Python jest super, jeśli jako programista próbujesz sobie odpowiedzieć co ma znaczenie dla człowieka.

C++ jest super jeśli jako programista próbujesz sobie odpowiedzieć co ma większe znaczenie dla maszyny.

Pytanie do wszystkich programistów siedzących w wysoko poziomowych językach jak python, ruby itp. Czy też czujecie niedosyt?

Niedosyt - owszem, ale raczej stosunku możliwości do stopnia skomplikowania.
Język zadziwiająco skomplikowany i barokowy jak na swoje mizerne możliwości. Nadrabia jedynie bibliotekami.
Po tymczasowej przesiadce z języków takich jak Scala i Rust na Pythona czuję się jakbym się cofnął w czasie o 15 lat.

1. Skomplikowana składnia
   Niby powierzchownie jest nieźle - funkcje, zmienne, pętle, warunki - wszystko sprawia wrażenie przyjaznych; w sumie na podobnym poziomie co w C czy Javie. Ale już jak chcę aby 'if' zwrócił wartość, to się okazuje, że konieczna jest inna składnia o odwrotnej kolejności. Jak chcę zrobić generator, to znowu - inna składnia, do tego pisana na odwrót. Do tego dochodzą takie mocno nietrafione decyzje projektowe jak np. operator := vs =, które tylko mącą. Wiele rzeczy jest dość pokracznych np. lambdy które mogą mieć jedno wyrażenie i nie ma możliwości zrobienia wyrażenia składającego się z wielu poleceń. Samo rozdzielenie poleceń od wyrażeń jest już niepotrzebną komplikacją języka, mającą daleko idące konsekwencje. Na tym poziomie zarówno Scala jak i Rust są znacznie mniej skomplikowane, mają bardziej regularną składnię (np. wszystko jest wyrażeniem), a zarazem oferują lepszą ergonomię.

2. Pomieszanie obiektowości z programowaniem strukturalnym. Część funkcji jest globalna (np. len()), część jest metodami np. join(). Wiem, że to wynik historii, bo obiektowość dodano później, ale jest to dość irytujące dla osoby przyzwyczajonej, że po wduszeniu "." za obiektem dostaję w IDE przynajmniej wszystkie najbardziej podstawowe operacje jakie mają sens dla obiektu. Do tego wszelkie łancuszki przekształceń funkcyjnych (map, reduce, filter itp) wyglądają paskudnie i czyta się je bardzo źle.

3. Słabe "batteries included". Zadziwiająco podstawowe rzeczy trzeba ogarniać bibliotekami third-party. Nawet głupie wyszukanie duplikatów na liście. Ogólnie wbudowane metody do manipulacji podstawowymi kolekcjami pozostawiają bardzo duży niedosyt. Scala mnie rozpieściła pod tym względem.

4. Obsługa błędów wyjątkami unchecked. Na papierze wygląda pięknie, ale w praktyce prowadzi to do tego, że programy pythonowe notorycznie wywalają niezrozumiałe stacktrace'y nawet we względnie oczywistych i spodziewanych sytuacjach błędnych jak brak pliku. Piszę na podstawie doświadczeń z naszym toolingiem robionym w Pythonie przez wiele zespołów i wielu programistów Pythona. Można zwalać winę na kulturę i złe przyzwyczajenia, ale język niestety nie zachęca do pisania kodu solidnie, a właśnie na szybko - taki "happy-path programming". Zresztą wyjątki same w sobie w takiej postaci jak w Pythonie nie są wcale prostym mechanizmem, nie ma w nich absolutnie nic prostszego niż w Javie.

5. Wiele intrygujących niespójności / niekonsekwencji rodem z PHP. Np. słowniki są uporządkowane w kolejności wstawiania kluczy, ale zbiory już nie.

6. Wbrew założeniom, wiele sposobów na zrobienie tej samej rzeczy i brak oczywistego najlepszego sposobu. Twórcy Pythona często nie mogli się zdecydować jak chcą np. w języku modelować dane i dodali wszystkie sposoby jakie im przyszły do głowy, więc mamy tu i zwykłe klasy, i @dataclass, i nazwane tuple i nienazwane tuple, a część ludzi używa sobie do tego słowników ala JS. Niezły barok.

7. Paczkowanie zależności. Temat rzeka. Nie znam innego języka, który miałby to bardziej spartolone. Jak pytam jak mam spaczkować swoją apkę aby inny team mógł jej użyć, a oni mówią "docker", to już wiem że jest bardzo źle. Oczywiście mamy kilka konkurujących rozwiązań, które miały ten problem naprawić (np. poetry) ale żaden z nich nie działa tak bezproblemowo i tak dobrze jak cargo. No i żaden nie rozwiązuje problemu "diamentowych zależności".

8. Brak wielu fajnych mechanizmów poprawiających ergonomię, które mam w innych językach - np. wspomniany pattern matching. Tak, dodano dopiero ostatnio, jakieś 10-20 lat po tym jak był w innych językach. To powoduje że Python sprawia dla mnie wrażenie przestarzałego. Podobnie jest z kwestią weryfikacji typów - te adnotacje to zabawka przy tym co jest w TypeScript, Scala i Rust. Widać, że język się zestarzał i teraz próbują na siłę go modernizować, ale nie jest to łatwe (patrz: Python 3 vs Python 2; Python 2 nie umiał nawet w unikod). W efekcie stopień skomplikowania jest większy niż w językach, w których te mechanizmy były od początku.

9. Brakuje specjalnej składni tam gdzie akurat być powinna - specyfikatory dostępu. Prywatność składowych określa się przez nazwę, bo szkoda było użyć na to słowa kluczowego (inne języki mają jakieś public/private/protected itp). Parę znaków pisania mniej, a w zamian problemy jak się chce zmienić dostęp, bo trzeba zrobić "znajdź i zamień" na całym projekcie. Nie mówiąc już o tym że w drugiej dekadzie XXI wieku trzy poziomy dostępu to zdecydowanie za mało. Nawet Java z lat 90-tych miała 4 i wiadomo, że nie są wystarczające.

@Krolik trochę tak, trochę nie. Dziwi mnie, że Pythona postrzegasz jako język ze skomplikowaną składnią, gdy obok sobie chwalisz Scalę czy Rusta jakby tam było znacząco prościej O.o Poza tym Twoja odpowiedź wskazuje tylko minusy. Nie wiem na ile merytoryczna jest wypowiedź, gdy ktoś wyłącznie narzeka, że młotkiem ciężko maluje się ściany. Pewne ma rację, ale taka wypowiedź bardziej wskazuje przemęczenie tematem niż jakieś konkrety.

Python owszem pod wieloma technicznymi kwestiami zawodzi i utrudnia pracę, przykładowo:

• jak chcesz pocisnąć OOP.. to tracisz. Bo nie ma interfejsów, modyfikatory są umowne, a typowanie dynamiczne.
• chcesz FP? również tracisz, bo nie ma TCO, brak persistent structures, i uboga ilość funkcji do manipulacji strukturami.

Także im bardziej elastyczne oprogramowanie tworzymy w Pythonie tym trudniej jest tym zarządzać i utrzymywać.

Python się zwraca gdy:

1. Zamiast OOP, wybierasz skromne object based - czyli zamiast definiować nowe klasy to dane modelujesz wyłącznie przy użyciu wbudowanych typów. W pythonie jest to o tyle wygodniejsze względem javascript, że tutaj struktury lepiej się printują, python jest silnie typowany, łatwiej się kopiuje, jest większy wybór kolekcji przy modelowaniu, źródłowe dane łatwiej jest chronić, bo są opcje na niemodyfikowalne dane, a i też Python ułatwia zapisanie kodu tak, by to co robimy zbiegało do postaci wyrażeń niż instrukcji.

2. Gdy większość swojej pracy realizujesz z poziomu REPL. Na przykład jak kodujesz selenium to nie piszesz najpierw programu, a potem sprawdzasz jak to działa. Tylko uruchamiasz REPL i każde Twoje działanie od razu wpływa na selenium, piszesz i widzisz jak każda najmniejsza operacja rzutuje na pracę programu od razu. Jest szybsza pętla zwrotna, lepszy feedback. Pisanie w REPL może się wydawać niepraktyczne i niewygodne w operowaniu, ale w PyCharm możesz bez problemu podpiąć skrót, by fragment kodu jaki napiszesz w IDE został wykonany w bezpośrednio w podtrzymywanej sesji REPL. Tu warto również ustawić REPL, aby miał włączony autoreloading i wtedy praca z kodem to bajka.

Jak dla mnie Python jest spoko do szkicowania, zadań w tle, wizualizacji danych, przerzucana danych z miejsca A do miejsca B, automatyzacji, jest jak programowalny excel. Excel to dobre słowo, najlepiej oddaje możliwości Pythona. Python pozwala myśleć o danych, o programie w paru płaszczyznach, ułatwia myślenie, ale sam w sobie arkusz excela nie jest jednak końcowym produktem. Tak samo w Pythonie ciężko jest pisać kod od razu pod końcowego użytkownika. Nie ważne czy robisz web, desktop czy mobilne. Stack się komplikuje i zwiększa nakłady pracy i utrudnia utrzymanie.

Z tego względu jak robię rzeczy pod koncowego usera to przełączam się na Clojure. Jeden język w którym mogę pisać web, rzeczy mobilne, gry, desktop zachowując wydajny przepływ pracy i sprowadzając efekt pracy wyłącznie do jednego pliku.

Nie jestem programistą pythona, dla mnie python zawsze służył do "toolingu" i z mojej perspektywy język ten leży w dziwnym miejscu. Do prostych rzeczy wolę ostatnio sobie basha naskrobać. A jeśli chodzi o bardziej skomplikowane rzeczy to w pythonie nadal fajnie protytypuje się różne rzeczy, np. przetwarzanie obrazów, operacje na danych geoprzestrzennych itp, ale jeśli jakiś skrypt po czasie okazuje się przydatny na dłuższą metę to i tak wolę go przepisać na coś natywnego.

Więc tak jak napisałem, w dziwnym miejscu python leży, ani do prostych rzeczy, ani w sumie do skomplikowanych. Dzięki licznym bindingom szybko się w nim prototypuje i to w sumie tyle.

Piszę głównie w javie, ale w pythonie trochę też. Python taki właśnie ma być. Prosty, żeby się nie zastanawiać nad zarządzaniem pamięcią, itd., tylko nad rozwiązywaniem problemu. Myślę, że po prostu pracujesz nad projektami, które są poniżej Twoich kwalifikacji/potencjału, skoro się nudzisz ;-). W pythonie też można np. programować asynchronicznie, co w każdym języku nie jest łatwym zadaniem, albo np. zajmować się machine learningiem, data science, itd. No ale w tym przypadku, python stanowi jedynie narzędzie i programiści nie skupiają się na detalach "technicznych", tylko na algorytmach. Język jest wtedy drugorzędną sprawą, tylko akurat python ma najwięcej bibliotek i tooli do takich rzeczy. Możesz też pisać różne toole do terminala i w zależności od tego, co to będzie, może to być prosty lub bardzo trudny projekt.

Im w języku i bibliotekach jest mniej udogodnień tym większe cuda na kiju wymyślają programisci i potem ciężko się z tym pracuje. Np. jak język ma słabo rozwiązanie modelowanie danych, to programiści używają wszędzie typów prostych wbudowanych lub słowników i taki kod jest potem trudny do zrozumienia i do tego bardzo błędogenny.

Prosty bo składnia jest prosta? Pewnie na normalnym interview jako python dev szybko się wyłożysz

Descendant napisał(a):

Prosty bo składnia jest prosta?

od kiedy?
Python to jest bardzo trudny język. Mówię serio.
Nie dość, że nieczytelny to jeszcze ludzie piszą w nim tak chaotycznie, że przy > 1000 linijek nic już nie widać.

Każdy g**no kod jest trudny bez względu na język :D Polecam wpis na blogu @grski, gdzie jest jasno wytłumaczone do czego python nadaje się lepiej a do czego gorzej ;)

Jakby było to takie proste to sami by na to wpadli.

ledi12 napisał(a):

gdzie jest jasno wytłumaczone do czego python nadaje się lepiej

do niczego