czwartek, września 15, 2005

Powrót do C

Ostatnio zostałem "zmuszony" do napisania kodu w czystym C. Mam działający kod w Pythonie, ale jego szybkość pozostawia naprawdę wiele do życzenia. Zdecydowałem się więc na przetłumaczenie tego kodu z Pythona na C.

Dlaczego C, a nie w C++? Z kilku powodów:

1) Piszę moduły dla Pythona. Całego Pythona skompilowałem używając kompilatora C, a nie C++ - więc po prostu łatwiej mi jest teraz pisać moduły w czystym C (buduję je przy pomocy distutils). Całe zbudowanie modułu sprowadza się do wydania jednego polecenia - "python setup.py build".

2) Zdecydowanie lepiej znam C niż C++. A moduły dla Pythona można również pisać w C++, lecz trzeba przestrzegać pewnych reguł... Nie chce mi się wnikać w takie szczegóły - uważam, że mniej się namęczę, jeśli wszystko zrobię w czystym C. I tak nie muszę używać programowania obiektowego, więc w tym przypadku wydaje mi się, że C ma pewną przewagę nad C++.

Przetłumaczenie działającego kodu z Pythona na C nie jest aż takie trudne. Jednakże wczoraj napotkałem na problem, którego nie byłem w stanie rozwiązać przy pomocy tablic w C - musiałem użyć list. Listy są "zwykłym" typem w Pythonie, lecz nie w C.

Miałem do wyboru : albo sam napiszę jakąś prostą bibliotekę do obsługi list, albo nie będę wynajdywał koła i skorzystam z tego, co przede mną zrobili już inni.

Zazwyczaj perspektywa samodzielnego napisania takiej biblioteki byłaby dla mnie - zapalonego kodera - niezwykle kusząca. Mógłbym zrobić to w sposób naśladujący API list z Pythona - i zapewne tłumaczenie kodu byłoby znacznie prostsze. Poza tym miałbym własny kod, wiedziałbym, co w nim mam, mógłbym go bez większego problemu dołączyć do każdego modułu, nad jakim pracuję.

Tylko że mnie się spieszy. Chciałbym jak najszybciej zrobić to, co mam do zrobienia i uruchomić kolejny eksperyment. Zdecydowałem się więc na wykorzystanie GLib.

Będę musiał się wprawdzie nauczyć API, które wymyślił ktoś inny - ale myślę, że w perspektywie to mi się opłaci. Bo skąd mam wiedzieć, czy np. jutro (albo za miesiąc) nie okaże się, że oprócz list potrzebuję czegoś jeszcze? Czegoś, czego napisanie znowu zajęłoby mi czas (i musiałbym się skupić na rozwiązaniu jakiegoś niskopoziomowego zadania zamiast na właściwym celu mojej pracy)? A GLib jest bardzo bogatą biblioteką (porównałbym ją do STL w C++) - i jest duża szansa na to, że będzie w niej już to, co mi będzie potrzebne za jakiś czas.

(Mała dygresja. Mam oczywiście nadzieję, że po napisaniu tego kodu w C będę mógł powrócić do mojego ulubionego Pythona i nie zajmować się dłużej programowaniem niskopoziomowym. Oczywiście oprócz ulepszania już istniejącego kodu. Ale nadzieje nadziejami, a życie życiem.)

Użycie GLib będzie miało też inną, wielką zaletę. Otóż użyję biblioteki przetestowanej. Gdybym wykorzystał własną, musiałbym ją przetestować. Ponieważ zaś nie mam czasu na pisanie testów z prawdziwego zdarzenia, w praktyce sprowadziłoby się to zapewne do testowania jej na "żywym" obiekcie - czyli na moim programie. Korzystając z GLib mam pewność, że używam biblioteki przetestowanej i działającej - a błędów powinienem szukać raczej we własnym kodzie (którego teraz będzie zdecydowanie mniej :D).

Z przymrużeniem oka. Mam jednak pewne obawy... Tak samo, jak wówczas, kiedy poznałem Pythona i zrozumiałem, że jego wykorzystanie może naprawdę znacznie skrócić czas tworzenia oprogramowania. W ciągu zaledwie miesiąca czasu porzuciłem Javę - dla której kilka miesięcy wcześniej zrezygnowałem z używania mojego ukochanego C (do dzisiaj bardzo lubię ten język!) - na rzecz Pythona właśnie. Python ma wiele zalet (development jest naprawdę znacznie szybszy, niż w jakimkolwiek innym znanym mi języku), ale jest potwornie wolny. A mnie jest potrzebna prędkość (ostatni eksperyment trwał ponad miesiąc czasu!). Czyżby więc istniła możliwość, że porzuciłbym Pythona na rzecz C?

E tam... Nie ma się czego bać. Python świetnie nadaje się do "klejenia" różnych fragmentów kodu, napisanych czasami w różnych językach. A tam, gdzie Python jest zbyt wolny, pisze się dodatkowe moduły w C. I to właśnie teraz robię. Cóż - tutaj akurat to ja jestem pionierem.