Przegląd prasy
Dlaczego konkursy programistyczne (w obecnie najpopularniejszej formie) nie są najlepszym pomysłem. [1] W skrócie argumentacja sprowadza się do tego, że różnej maści konkursy programistyczne promują dużą wiedzę algorytmiczną pozwalającą na intuicyjne dopasowywanie algorytmu do zadania, pisanie na czas, czyli najpaskudniejszy kod przejdzie, byle się go szybko pisało oraz dopasowywanie algorytmu do małej ilości danych testowych.
W rzeczywistości zaś najważniejszy jest bardzo dobry design, czytelny i dobrze udokumentowany kod oraz obiektywnie sprawdzone na zazwyczaj dużej ilości danych wejściowych, a nie intuicyjnie przypasowane algorytmy (gdzie znowu wychodzi zaleta dobrego designu, który pozwala na łatwe podczepienie jakiś automatów do sprawdzania rzeczywistej wydajności proponowanych rozwiązań; w praktyce liczenie tylko na swoją intuicję w zakresie optymalizacji jest bardzo często bardzo bolesne).
Autor bardzo uważa, żeby nie sprawiać wrażenia, że osób dobrze sobie radzących w takich konkursach uważa za istoty niższe i w sumie chwała mu za to, bo faktem jest, że umiejętność szybkiego pisania kodu i duża wiedza algorytmiczna to też jest powód do dumy, już niezależnie od tego, że w praktyce istnieje niewielka szansa na jakieś sensowne użycie tych umiejętności.
(Ja tam intuicyjnie nigdy nie "szanowałem" takich konkursów, ale u mnie to wynikało i wynika z tego, że (a) uczenie się algorytmów uważam za nudne i trudne i (b) wiem, że w takim konkursie wypadłbym zapewne dosyć blado, więc moja motywacja do startowania w nich nigdy nie była jakoś specjalnie duża. Teraz przynajmniej mam o wiele lepsze i mądrzej brzmiące wytłumaczenie mojej niechęci, niż "to jest trudne, a poza tym nie lubię przegrywać". Hehehe.)
Zapewne spora część z was już słyszała wypowiedź Stewarda Butterfielda, współzałożyciela flickra, w której zapowiada, że flickr będzie udostępniał zestawy api do pełnej migracji danych użytkowników, ale tylko do serwisów, które również będą dysponowały takimi api (innymi słowy wolny rynek, ale tylko wśród tych, którzy też wolny rynek wspierają).
Ja bym chciał tu zwrócić uwagę na (oczywiście optymistyczny, a odnoszący się bezpośrednio do wpisu jakiegoś Sunowca, który w sumie też warto przeczytać) komentarz Iana Murdocka w którym zaznacza, że korzysta z del.icio.us właśnie dlatego, że w dowolnym momencie może zabrać swoje dane i pójść gdzie indziej.
Ciekawa uwaga w kontekście joggera2 która jak widzę nadal nie dorobił się eksportu danych. Osobiście jestem zdania, że, hmm, "porażka" nią nie jest pod warunkiem, że człowiek wcześniej przewidział ewentualne ryzyko i je zaakceptował (tzn. pożyczając ci rower godzę się z faktem, że ktoś ci go może rąbnąć, trzymając bloga na joggerze godzę się z faktem, że może wyniknąć dziwna sytuacja w wyniku której go utracę wraz z archiwami, etc.). Dla mnie "przegrana" jest dopiero wtedy, jeśli zdarzy się coś, co weźmie mnie z zaskoczenia. Coś czego nie przewidziałem.
(Uprzedzając zarzuty -- nie, to nie jest atak na sparrowa. Jeśli ktoś z was nie rozumie dlaczego jogger2 powinien mieć eksport danych i to w ogóle abstrahując od osoby sparrowa, to najprawdopodobniej nie jestem tego w stanie wytłumaczyć. Musicie trochę poczekać, przyjdzie samo, wraz z doświadczeniem.)
I jeszcze mała uwaga w kontekście mojego wpisu sprzed dwóch tygodni o tym co jest fajnego w opiece nad czyimiś programami.
Nigdy nie przepadałem za programowaniem, więc moje doświadczenia, choć niezerowe, nigdy nie były jakieś specjalnie duże. Dłubałem w kilku różnych programach, w jednych mniej, w drugich więcej, nic specjalnego. Ale dopiero przy obecnym projekcie dotarło do mnie jak dużo na temat prawidłowego designu można się nauczyć czytając czyiś kod. Gdy zaczynasz rozumieć dlaczego te kawałki są bardzo dobrze zrobione, zaczynasz dostrzegać miejsca, w których oryginalnym autorom jednak nie wyszło i zaczyna ci się w głowie kształtować prawidłowe rozwiązanie... W tym momencie trudno mi sobie wyobrazić, żeby istniał lepszy sposób na naukę takich rzeczy, niż właśnie czytanie i grzebanie w gotowym kodzie.
Cóż, może programowanie wcale nie jest takie złe :)
[1] Nawiasem mówiąc jest to przykład tekstu, z którego możnaby wygolić sporo objętości nie tracąc treści.
17 VII 2006 o 20:34
Do tych konkursów. Owszem, programowanie to nie tylko wynalezienie sposobu na jak najmniejszą złożoność obliczeniową. Ale, jeśli oprócz algorytmiki, dołożyć do konkursów np. kryterium zaprojektowania całości (w tym czytelność kodu, udokumentowanie i reszta), to nagle powstaje problem związany z oceną prac. Nie tylko trzeba by zainwestować mnóstwo pieniędzy w ludzi, którzy by wszystko to przejrzeli (a do tej pory wystarczy wszystko wrzucić w automat, który zwyczajnie uruchamia program dla każdego testu i porównuje jego wyjście z wzorcem); ale i dyskusyjna byłaby sama istota rankingu w takim konkursie. Nie dosyć, że można by dyskutować nad wyższością pewnych rozwiązań nad innymi w nieskończoność, to różni oceniający byliby zaznajomieni z różnymi rozwiązaniami; więc dodatkowo trzeba by uwzględnić ich indywidualny sposób osądzania. Dlatego nie sądzę, żeby w tradycyjną formę konkursu dało się wpasować wszystkie kryteria, które istnieją w prawdziwym świecie.
Poza tym, uważam, że algorytmy to faktycznie rzecz najważniejsza. Sprowadzenie algorytmiki do zakucia milionów sposobów to zamach na całą dziedzinę. Noce spędzone nad wzorami matematycznymi, to wcale nie "zakuwanie", ale nauka innego spojrzenia na problemy spotykane w informatyce i radzenia sobie z nimi. Na przykład, wiesz co to jest wspomniana złożoność obliczeniowa, oraz jak ją się wyraża? Pewnie wiesz. Więc, samo zrozumienie sensu tego pojęcia otwiera oczy na oczywiste rozwiązania problemów z przeszłości, głównie tych pod tytułem "Dlaczego to się tak wlecze?". Kiedy czasami widzę kod, w którym namiętnie w środku pętli odwołuje się do size() z stlowej listy, to pytam się ścian "co ja tu robię?" - bo jak każdy, kto miał związek z algorytmitką, wiem, że obliczenie rozmiaru listy ma złożoność O(n), a dodatkowa pętla daje już O(n^2). Ludzie z algorytmiką nie zaznajomieni nie mają o tym pojęcia, i choć przykład jest banalny, to często powoduje, że kod - choć zupełnie czytelny i zakomentowany od stóp do głowy - nie jest wart niczego. A dobrych nawyków i wcześniejszego rozplanowania można się bez problemu nauczyć "przy okazji", podczas normalnej pracy i zetknięcia się z cudzym kodem.
Acha, jeszcze chciałem wspomnieć, że genialną rzeczą, która w sposób właściwy ocenia i nagradza nie tylko algorytmiczną wiedzę, ale zaplanowanie i jakość kodu, jest Summer Of Code (choć trudno to nazwać konkursem).
17 VII 2006 o 20:51
Co do samej organizacji konkursów, to się zgadzam, przy czym 'nie da się lepiej' wcale nie umniejsza wagi stawianych zarzutów.
Natomiast co do samych algorytmów, to tak, wiem co to jest złożoność obliczeniowa, wiem jakie ma przełożenie na faktyczne kodowanie jakiegoś systemu, a w głowie mam pewnie kilka nazw co popularniejszych algorytmów do różnych rzeczy, dzięki czemu jeśli kiedykolwiek będzie mi to potrzebne, jestem w stanie pogrzebać trochę w internecie i znaleźć optymalny algorytm do tego, co będę akurat robił.
I uważam, że jeśli chodzi o przydatność na codzień, to moja znajomość tematu (obiektywnie rzecz biorąc mizerna; udało mi się zapomnieć nawet podstawowe formalizmy związane ze złożonością obliczeniową) jest wystarczająca, a nacisk powinienem kłaść na lepsze rozeznanie w dziedzinie ogólnie pojętego designu, bo to jest to, co mi się zdecydowanie bardziej przyda.
I taka jest też argumentacja autora eseju.
W skrócie sprowadza się to do tego, że programista *musi* przerobić podstawy algorytmiki, bo nie ma innego wyjścia (inaczej będzie dupa, a nie programista). Ale *nie* musi być w stanie z głowy zaimplementować dwieście najpopularniejszych algorytmów, od sortowania i szukania, po grafy (bo od tego jest knuth i internet). A takiego czegoś właśnie wymagają te konkursy.
17 VII 2006 o 21:55
Okej, zgadzam się.
Acha, przyszła mi taka myśl jeszcze. Kodowanie podzielić można z grubsza na dwie składowe: jedna to pisanie kodu względnie prostego, co wypełnia większość czasu (chociaż to głównie zależy od samego projektu); oraz kodu, który jest "mięsem" projektu, ma gigantyczne wcięcia, nad którymi trzeba zapanować, zanim zabraknie ekranu; przy jego pisaniu przeszkadzają wszelkie dźwięki a potem i tak nie działa, i trzeba go mnóstwo czasu debugować (potem taki kod się skleja, które to sklejanie kwalifikuje się do pierwszej składowej) - zazwyczaj to jakieś parsowanie, rysowanie jakichś skomplikowanych rzeczy, etc. I ta właśnie część programowania, trudna, nieprzyjemna i wymagająca skupienia; w zasadzie w całości wypełnia rozwiązywanie zadań z konkursów stricte algorytmicznych. Można się stąd spodziewać, że programiście "wytresowanemu" na algorytmach pisanie "trudnego" kodu przychodzi później znacznie łatwiej. Ale to chyba średni argument, w końcu taka sprawność przychodzi każdemu po przepracowaniu n+1 godzin.