Od początków istnienia Internetu, jedną z jego głównych funkcji było zadawanie pytań odpowiednio sprofilowanemu gronu słuchaczy – np. grupom dyskusyjnym Usenetu – i otrzymywanie na nie odpowiedzi. Narzędzia i sposoby komunikacji się zmieniają (mamy teraz fora, strony typu StackExchange, a nawet serwisy społecznościowe), ale ich przydatność w rozwiązywaniu programistycznych problemów pozostaje co najmniej niezmienna.
Odpowiednią pomoc możemy często znaleźć, przeszukując po prostu archiwum dyskusji. Niekiedy jednak musimy (lub chcemy) zadziałać aktywniej i założyć nowy wątek, opisując nasz problem. I tu podobno otwiera się przed nami całe uniwersum detali, o których powinniśmy pamiętać, i które zwykle zostały “wygodnie” zebrane do postaci kilometrowych poradników takich jak ten. Część z nich jest techniczna i często przestarzała (80 znaków w wierszu?…), a reszta nie jest dostatecznie poglądowa, aby uchwycić istotę sprawy.
A ta jest – według mnie – zupełnie nieskomplikowana i łatwa w praktycznym stosowaniu. Skuteczne prośby o pomoc w sprawach technicznych można bowiem rozważać jako proces obejmujący tylko trzy proste kroki – uniwersalne i niezależne od medium komunikacji.
Powszechny stereotyp sugeruje, że programiści uwielbiają spierać się co do zalet i wad używanych przez siebie rozwiązań: języków, frameworków, bibliotek czy nawet narzędzi takich jak edytory. Zapewne jest w tym spore ziarno prawdy. Nie ma oczywiście nic złego w rzeczowej dyskusji, w której używane są racjonalne i mające podstawy argumenty. Z tym jednak nie zawsze jest tak różowo.
Jednym z często używanych, ogólnych i pasujących niemal wszędzie “argumentów” jest wspominanie o naturalności danego rozwiązania – lub o jej braku. Mam osobiście duży problem z określeniem zarysów jakichkolwiek użytecznych granic dla tego pojęcia. Nawet więcej: jest ono na tyle niedookreślone, że z niemal równym powodzeniem można by mu przypisać dwa dokładnie przeciwstawne znaczenia. Oba byłyby wprawdzie ścisłe i pozwalały jednoznacznie powiedzieć, czy coś faktycznie jest naturalne czy nie. Problem w tym, że dla wszystkich rozważanych rzeczy odpowiedź byłaby taka sama – a to już jest bezużyteczne. Predykat, który zwraca zawsze
true
lub zawsze false
nie niesie ze sobą żadnej informacji.
Jak więc wyglądają te dwie przeciwstawne postacie?… Z jednej strony trudno zareagować inaczej niż śmiechem na wszelkie próby doszukiwania się pierwotnej Natury w takich zjawiskach jak języki programowania. Życzę powodzenia każdemu, kto próbowałby znaleźć paralele między alternatywą w rodzaju “pętla for
czy funkcja map
” a decyzjami, jakie musieli podejmować nasi przodkowie na afrykańskiej sawannie jakieś 200 tysięcy lat temu. Tak pojmowana naturalność wyklucza oczywiście wszystkie te rzeczy, o które tak przyjemnie jest się spierać. Pocieszmy się przynajmniej tym, że porażka w używaniu któregoś z nich nie oznacza skończenia jako posiłek dla lwa.
Z drugiej strony jednak nie widać powodu, dla którego dowolne wytwory człowieka nie miałyby być uważane za w pełni naturalnie, jeśli nie odmawiamy tego miana mrowiskom, gniazdom ptakom czy pajęczynom. To znów tworzy nam dobrze określony, jednoznaczny predykat… który jednak zawsze zwraca true
, co redukuje jego przydatność do zera.
To wszystko jest oczywiście podejrzane. Jeśli pojęcie ‘naturalny’ nie służy do przekazania nawet jednego bitu użytecznej informacji, to nie powinno być w ogóle używane. Ale jest; to sugeruje, że jego cel jest inny. Może być nim na przykład ukrycie braku rzeczywistego argumentu i próba przemycenia subiektywnego punktu widzenia pod przykrywką obiektywnie brzmiącej etykiety. Słówko ‘naturalny’ brzmi bowiem lepiej niż nawet ‘intuicyjny’. Wydaje się być znacznie precyzyjniejsze (intuicje są przecież mgliste) i sprawia wrażenie odwoływania do pozornie uniwersalnych kryteriów (w przeciwieństwie do subiektywnych intuicji).
Zwykle jednak to tylko złudzenie, ukrywające brak dobrego uzasadnienia dla swoich twierdzeń. Zatem nie mów mi, co jest naturalne. Magiczne zaklęcia nie zastąpią braku rzetelnych argumentów.