Dlaczego Python?

Przed wybraniem nowego języka programowania, czy zdecydowaniem się na użycie nieznanej nam wcześniej technologii, zadajemy sobie pytanie „dlaczego?”.

Dlaczego właśnie w tym powinienem pisać?

Dlaczego właśnie tego powinienem używać?

Czy nie wystarczy mi znajomość języka X, czy technologii Y?

I na koniec:

Czy nauka da mi wymierne efekty i koniec końców okaże opłacalnym wysiłkiem?

Na te pytania wbrew pozorom niełatwo odpowiedzieć, nawet jeśli dysponuje się garścią sprawdzonych stwierdzeń, wyłuskanych niekiedy z dziesiątek podręczników dotyczących omawianego zagadnienia. Autorzy książek, czy osoby prowadzące szkolenia często zresztą faworyzują prezentowane narzędzia i odnosimy w pewnym momencie wrażenie, że po raz kolejny ktoś próbuje nam wmówić, że jest to najlepsza dla nas alternatywa.

Czy tak jest w przypadku Pythona?

Niestety nie.

Dlaczego powinieneś, bądź nie powinieneś zdecydować się na Pythona?

Kiedy zaczynałem swoją przygodę z programowaniem, a było to jeszcze w czasach gdy na Pascalu można było zarobić pieniądze, największą wadą jaką dostrzegałem w językach programowania, było po prostu marnowanie mojego czasu. Niezależnie od języka (Pascala, C/C++) wszędzie musiałem liczyć się z koniecznością wklepania kodu, który sam w sobie nie dawał mi żadnego naocznego efektu. Niejednokrotnie spędzałem godziny nad czynnościami, które mogły być w pełni zautomatyzowane, umożliwiając mi faktyczne skupienie się na zadanym problemie. O ile w przypadku pisania programów w celach edukacyjnych nie byłem jakoś przesadnie zniesmaczony nadmiarowym wklepywaniem kodu (każdy pewnie miał drobny epizod w życiu, gdy pisanie dla samego pisania stawało się niejako fetyszem ;) ), o tyle obawiałem się, jak w przypadku takich języków będą wyglądały prawdziwe projekty.

Jak zapewne już się domyślasz, Python próbował sobie poradzić z moim i przypuszczam, że nie tylko moim problemem. Czy dał radę? Zdecydowanie. :)

Pewien autor, który jest dla mnie autorytetem pośród wyznawców Pythona, stwierdził, że Python w istocie nie jest już tylko językiem, a sposobem myślenia. Możesz pomyśleć, że zabrzmiało to nieco pompatycznie – przyznam, że sam odniosłem takie wrażenie, gdy przeczytałem te słowa po raz pierwszy. Po kilku tygodniach zdałem sobie jednak sprawę, że jest w tym sporo racji.

Python wymaga - tak! wymaga! - odrzucenia wcześniejszych przyzwyczajeń, wynikających z używania języków C-podobnych, które uczyły złych nawyków poprzez umożliwienie pisania jednolinijkowców (programów zawierających się w całości w pojedynczej linii), nieprzestrzeganie organizacji kodu, wymuszenie tworzenia bloków przez stosowanie dodatkowych znaków, co w połączeniu z tendencją do pomijania wcięć doprowadzało do sytuacji, gdy w przypadku kilkukrotnie zagnieżdżonych instrukcji, zastanawialiśmy się, gdzie jest koniec pierwszej, a gdzie początek czwartej. Co więcej, mówię o językach, które są używane na co dzień i sprawdzają się dopóty, dopóki są używane z głową.

Oczywiście nie twierdzę, że nie potrafisz utrzymać porządku w swoim kodzie, ale jeśli tylko masz choćby niewielkie doświadczenie w programowaniu większych projektów, to dostrzeżesz, że masa dostępnych bibliotek, rozszerzeń jest tak naprawdę napisana w tragiczny sposób, a zinterpretowanie kodu pozbawionego wszelkich zasad przyzwoitości jest równie przyjemne, co depilacja woskiem. Sprawdziłem na własnej skórze...

Wolę Pythona od języków C-podobnych, bo chroni przed stosowaniem może i początkowo zabawnych mechanizmów (pamiętam minę prowadzącej w momencie oddania programu "skompresowanego" do granic możliwości), które w konsekwencji powodują jedynie irytację.

Wolę Pythona również dlatego, że pozwala mi skupić się na faktycznym problemie i rozwiązaniu zadania, a nie na takich prozaicznych czynnościach jak chociażby deklarowanie dziesiątek, a czasem i setek zmiennych. Krótko mówiąc: oszczędza wiele godzin, który możnaby spożytkować na ciekawsze aspekty własnego życia.

To dwie podstawowe zalety, które osobiście cenię najbardziej i które sprawiły, że pozostałem przy Pythonie, mimo wad, mimo silnej konkurencji i mimo większej ilości ofert pracy po stronie takich języków jak Java czy C# bądź jakiegokolwiek innego, który w chwili, gdy czytasz te słowa, wiedzie prym.

Dla dociekliwych przedstawiam poniżej krótką listę najważniejszych cech Pythona. Celowo nie podjąłem się podziału tych atrybutów na zalety i wady. Dlaczego? O tym za chwilę.

Charakterystyka Pythona:

• nowoczesny styl programowania oparty o paradygmat obiektowy (nie będący jedynie opcją) i pozwalający na łatwiejsze tworzenie wielomodułowych aplikacji w dużych zespołach projektowych;
• język interpretowany i skryptowy;
• łatwość nauki i duża dostępność materiałów (przeważnie w języku angielskim);
• oszczędność czasu wynikająca z prostoty składni i interpretowanego charakteru języka;
• wysoka dostępność komercyjnych bibliotek oferujących tworzenie aplikacji okienkowych (PySide), obliczeń matematycznych (NumPy), budowy aplikacji sieciowych (Django), itd.;
• rosnąca z kolejnymi wersjami wydajność języka, aczkolwiek nadal wyraźnie mniejsza od C;
• multiplatformowość;
• darmowa dostępność dla każdego;
• uczy dobrych nawyków (choćby poprzez wymuszenie wcięć w kodzie);
• brak ograniczeń w kwestii rozwiązywania problemu na różne sposoby;
• duża społeczność i bogata dokumentacja języka.

Dlaczego nie podzieliłem tych cech na wady i zalety? Z prostej przyczyny - byłby to podział skrajnie subiektywny. :) W tej sytuacji masz wybór i dokonaj go mądrze.

Wracając jednak do drugiej części pytania zadanego na początku - dlaczego nie powinieneś się zdecydować na ten język? Otóż, Python jak już wcześniej wspomniałem, wymaga odrzucenia nawyków nabytych w takich językach jak C. Dla niektórych może być to trudne, albo wydawać się niedorzeczne. Jeśli po kilku wpisach na tym blogu będziesz nadal twierdził, że jest to zły pomysł, to najprawdopodobniej ten język nie jest dla ciebie.

Nie będzie on także spełniał twoich oczekiwań, jeśli zależy ci przede wszystkim na wydajności aplikacji. Nie zrozum mnie źle – wydajność Pythona w większości przypadków jest satysfakcjonująca, a inne jego zalety zdecydowanie usprawiedliwiają tę - i jakby nie patrzeć - wadę. Oczywiście zdarzają się sytuacje, w których lepiej będzie wybrać C, a może nawet Assemblera. Nie wyobrażam sobie programowania sprzętu w Pythonie, np. pisania sterowników, gdzie popularne są w dalszym ciągu wspomniane powyżej języki. Python jest językiem o wysokim poziomie abstrakcji, co z jednej strony zachwyca prostotą nauki i późniejszego wykorzystania, a z drugiej nie pozwala na uniwersalne zastosowanie.

Podobnie jeśli marzysz o karierze twórcy gier, Python nie otworzy przed tobą drzwi do kariery, no chyba że skupisz się na grach indie, które nie są tak wymagające jak typowa produkcja o wysokim budżecie.

Jak już wcześniej zasugerowałem, Python w Polsce nie jest jeszcze na tyle popularny, żeby można było łatwo znaleźć pracę, jak to ma miejsce w przypadku chociażby Javy. Jeśli chcesz chcesz rozpocząć jego naukę pod tym kątem, miej to na uwadze.

W przypadku, gdy powyższe sytuacje nie dotyczą cię, Python może okazać się najpiękniejszym językiem, z jakim miałeś styczność. :) Do zakochania jeden krok, który miejmy nadzieję postawimy już niedługo. ;)

Na koniec pozwolę sobie zacytować nieco humorystyczny wiersz, napisany przez Tima Petersa, przedstawiający w skrócie ideę Pythona. Zachęcam do zapoznania się z nim i zapraszam do następnej lekcji kursu, podczas której zajmiemy się instalacją Pythona i napisaniem pierwszych programów.

The Zen of Python

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!