Klątwa Dijkstry
Od wielu wielu lat uparcie twierdzę, że nie lubię programować. Ostatnio usłyszałem ciekawe stwierdzenie -- pisanie programów jest dlatego wciągające, że programista ma cały czas wrażenie, że już zaraz za chwilę wszystko mu zacznie działać. I chyba coś w tym jest. Jeśli już się zmuszę do zabrania się, to czas upływa dosyć szybko i się nie nudzę. Rzecz w tym, że ja już bardzo dawno temu sobie w jakimś stopniu uzmysłowiłem, że "już zaraz za chwilę" to tylko złudzenie. Mam już pewne doświadczenia w tej kwestii, ale i tak nadal konsekwentnie udaje mi się niedoszacowywać czasochłonność kolejnych projektów. I tego właśnie nie lubię. Ten jednozdaniowy punkt na liście TODO może mi zająć równie dobrze 4 godziny, jak i najbliższe dwa tygodnie. Tym bardziej do szewskiej pasji doprowadza mnie fakt, że poniekąd pracuję w dziale R&D.
A, tak, radości płynące z pracowania nad rzeczami, których nikt wcześniej nie robił i których działania tak do końca nie jestem w stanie zrozumieć. Jest problem? No to trzymam kciuki, żeby wyrobiona na poprzednich błędach intuicja naprowadziła mnie na prawidłowe rozwiązanie. A jeśli nie naprowadziła? To za kilka tygodni, gdy będę miał już tego po dziurki w nosie i będzie mi się chciało płakać, kompletnie przez przypadek znajdę jakąś drobną rzecz, która wszystko naprawi. Przeżyłem to już kilkukrotnie, w tym kilka dni temu.
Przy czym różnica pomiędzy teraz i kiedyś polega na tym, że kiedyś na zakończenie takiego maratonu wysmarowałbym obszerny mail do przełożonego z "wytłumaczeniem" dlaczego nie działało i dlaczego moje zmiany wszystko naprawiły.
Teraz nie mam już takich złudzeń. Nie wiem co konkretnie powodowało, że system nie działał, nie wiem które z moich działań tak naprawdę poprawiły jego działanie, a tym bardziej nie wiem dlaczego.
I tylko jak sobie przypominam kazania Dijkstry o tym, jak to programy powinny być formalnie weryfikowalne, a nie pisane "na czuja", to mnie pusty śmiech ogarnia. Szkoda, że nie jestem satanistą, bo bym mu zbezcześcił grób, albo coś.
05 VIII 2007 o 15:00:52
Dijkstra to nie przypadkiem agent królestwa Wyzimy z Wiedźmina? :]
05 VIII 2007 o 15:01:39
oczywiście, że być powinny, ale nikt nie ma na to czasu (pieniędzy – ale to sprowadza się do tego samego)
05 VIII 2007 o 17:27:12
Możesz ulepić woskową figurkę i wbijać w nią chorągiewki z napisem „GOTO”. A Dijkstra to popularne nazwisko… Na wypadek, gdyby Mateusz pytał poważnie: http://pl.wikipedia.org/wiki/Edsger_Dijkstra
05 VIII 2007 o 23:15:46
> Teraz nie mam już takich złudzeń. Nie wiem co konkretnie powodowało, że system nie działał, nie wiem które z moich działań tak naprawdę poprawiły jego działanie, a tym bardziej nie wiem dlaczego.
A widzisz. Mnie się zdarzyło tylko dwa razy oddać do działania coś, co nie wiem dlaczego działało. Z czego jeden to były sprawy kodowania między MySQL-em i Pythonem, czyli dwa paskudztwa.
> I tylko jak sobie przypominam kazania Dijkstry o tym, jak to programy powinny być formalnie weryfikowalne, a nie pisane „na czuja”, to mnie pusty śmiech ogarnia. Szkoda, że nie jestem satanistą, bo bym mu zbezcześcił grób, albo coś.
Dijkstra, z tego co pamiętam, miał między innymi na myśli używanie narzędzi, które pozwalają na taką weryfikację. Przeciętne PHP, C czy inny Python są wyjątkowo złośliwe jeśli o to chodzi.
06 VIII 2007 o 22:42:25
I dlatego ja zawsze mówiłam, że nie będę programować. I podobnie też ja ostatnio się popłakałam przed kompem zanim zauważyłam, że jeden cholerny cudzysłów rozwalił mi parsowanie dalszej części pliku… Tu o tyle mam lepiej, że ja mogę ryczeć i robię to… A najbardziej mnie irytuje jak ktoś do mnie z tekstem jak najbardziej dobrotliwym „ale zrób sobie przerwę, odpocznij” a ja mu na to (tu krzyk)„ale ja nie mogę zrobić sobie przerwy rozumiesz?! muszę to zrobić, muszę to skończyć a przerwa mi nie pomoże”. Po czym jakiś czas później okazuje się, że to mała literówka lub gdzieś mi się zapodział znak którego gdzieś być nie powinno… ręce mi opadają ;p
06 VIII 2007 o 23:01:43
Kwestia obycia z różnymi rodzajami błędów. W sumie najtrudniej bywało mi znaleźć niektóre błędy w skryptach PHP i szablonach w HTML::Masonie, a przede wszystkim błędy składniowe w Adzie w wydaniu Gnat (GCC 3.4).
07 VIII 2007 o 01:05:25
@Ania
Akurat to o czym piszesz, to kwestia braku doświadczenia. Raz, że z czasem tego typu błędy się robią bardziej oczywiste, dwa, że zaczynasz się przyzwyczajać, że co pewien czas będziesz się natykała na oczywiste błędy, których z różnych powodów (zazwyczaj zmęczenie) nie będziesz w stanie dostrzec. Ja już kilka lat temu sobie ukułem powiedzenie, że „jeśli zaczynam podejrzewać problem w glibcu, to na pewno jest to błąd gdzie indziej”. Na razie nie sprawdziło się tylko raz.
Ja pisałem o czymś innym — o systemie, który jest tak skomplikowany, że pełne zrozumienie go jest albo w ogóle niemożliwe, albo zbyt nieopłacalne.
07 VIII 2007 o 08:20:44
No cóż, ale przynajmniej z pierwszym zdaniem się zgadzam :P
08 VIII 2007 o 22:25:10
Weryfikacja jak sie okazalo nie jest zbyt droga ani nieskuteczna.
Gdy poszperasz w wikipedii znajdziesz informacje na temat tego, ze
faktyczny koszt projektow formalnych jest nizszy niz tych robionych nieformalnie. Zludzenie wyzszych kosztow jest glownie wywolane tym, ze weryfikacja zajmuje sie jedna, dwie osoby a zespol programistow sobie czeka i nic nie robi przez kilkanascie tygodni.
Gdy przyjdzie jednak do programowania to zespol dostaje konkretna specyfikacje gdzie niemalze nie ma miejsca na bledy.
A Tobie jako osobie doswiadczonej nie musze chyba mowic co pochlania najwiecej czasu w programowaniu.
Co do samej weryfikacji to uzywa sie jej juz w Visual Studio 2005 na dosc srednio zaawansowanym poziomie; w oprogramowaniu lotniczym, oprogramowanie samolotow, kontroli ruchu, itp.
Nie wspominajac juz o Verilog / VHDL i projektowaniu sprzetu
gdzie weryfikacja jest uzywana w praktyce od kilkunastu lat
14 VIII 2007 o 16:24:13
Shortcutting. Leaping to solutions in an instinctive way or intuitive way—i.e. the “blink” method of problem-solving—seldom leads to an elegant solution because deeper, hidden causes don’t get addressed. Watch CSI and House: first they collect the evidence, then diagnose, and then solve. It’s never the guy or the disease you initially suspect.