Zapiski programistyczne: niepewność - Programowanie jest łatwe

Tworząc oprogramowanie, nieuniknionym jest czytanie dokumentacji, specyfikacji czy samego kodu napisanego przez kogoś innego. Czasami można natrafić na poszlaki, prowadzące do wprowadzających w zakłopotanie konkluzji.

create-own-memes.jpg

Pewnego razu, pisząc program wykorzystujący wielowątkowość, natrafiłem na następujący fragment w dokumentacji man, który dotyczy wyjaśnienia powodu błędu, który kryje się za wartością (EDEADLK):

"This error means you got lucky and the system noticed; it might just hang."

“Ten błąd znaczy, że miałeś farta, bo system zauważył; mógł się zawiesić”. Do tej pory żyłem w przekonaniu, że w informatyce nie ma czegoś takiego jak szczęście, a coś albo działa albo nie. Otóż mogłoby się wydawać, że fart jest jeszcze czymś, co faktycznie, może mieć jakąś rację bytu, np. częściej pojawiające się wyniki, które nie uwidaczniają błędu, mogą być uznane za pewnego rodzaju szczęście.

Twórcy wynalazków mają tendencję do nazywania swoich dzieł- czasami po imieniu, czasami imieniem swojej ulubionej postaci z filmu/literatury. Czasami jest jeszcze gorzej i wynalazki podlegają procesowi personifikacji- mają nie tylko imię, ale także “ja”. Spece od linux kernel na pewno są tymi drugimi. Otóż wyposażając kernel w obsługę “rad”, które program może do niego wysłać w nadziei na zmianę polityki, np. przydzielania pamięci, w dokumentacji do “rad” (ang. advise), można przeczytać:

The kernel is free to ignore the advice.

“Kernel może zignorować radę”. Brzmi to tak, jakby kernel był osobą, którą można namówić na coś, może nam pozwoli, może nie. Życia swojego bym nie zastawił, gdyby miało zależeć od kernel’a.

Istnieje jeszcze jedno miejsce, w którym przekonałem się, że szczęście jest potrzebne, kiedy nawet twórcy nie potrafią przewidzieć zachowania algorytmu, który stworzyli. Taka sytuacja ma miejsce np. przy korzystaniu z wywołania polecenia systemowego system. W dokumentacji można doczytać:

The effects (...) depend on the system and library implementation and may cause a program to behave in a non-standard manner or to terminate

“Efekty (...) zależą od implementacji systemu i biblioteki, i mogą spowodować, że program zachowa się w niestandardowy sposób albo się zakończy”. Mógłby to być napis na pudełku z pigułkami, których spożycie ma za każdym razem inny efekt. Prawdziwy rollercoaster. To by się pokrywało z opinią o JavaScript. Kiedyś na twitterze przeczytałem:

JavaScript is like LSD You have no idea where you are and what "this" even means.

“Javascript jest jak LSD. Nie wiesz gdzie jesteś i co “to” znaczy”. Na szczęście przyszedł czas na ES6, który już jakoś sobie radzi z przestrzenią nazw.

Jednak JS nie jest jedynym językiem, który wprowadza w obłęd. Moim mistrzem ostatnio jest Swift, w którym pewna linia, w którym obliczana była szerokość okna wywołała komunikat błędu o treści:

Expression was too complex to be solved in reasonable time;

“Wyrażenie było zbyt skomplikowane, aby rozwiązać je w sensownym czasie”. Jak widać, przerosło to Swifta’a, a mnie utwierdziło w przekonaniu, że już niczego nie mogę być pewny.

Przemyślenia?

Dodano: 2018-05-25 07:27 przez Piotr Poźniak

zapiski ,
Piotr Poźniak
O autorze:

Programuję od ponad 15 lat. Prowadzę software house. Angażuję i zachęcam wszystkich do programowania w ramach inicjatywy Programowanie jest łatwe.