- cross-posted to:
- interesting
- cross-posted to:
- interesting
You must log in or # to comment.
Uświadomiłem sobie, że nie robiłem niczego w kernelu.
Nie przypominam też sobie, żebym napisał jakiegoś puzzle solvera.
Nie wiem czy zadania ze SPOJa albo Advent of Code się liczą.To chyba służy jako prywatny rachunek sumienia. Nikt nikogo z tego nie rozlicza. Sam spisałem sobie co robiłem z tej listy z datami. Jeśli coś robiłem dawniej niż 10 lat temu, to uznałem, że tego nie robiłem. Ostatnio jest taki trend, że programiści nie powinni rywalizować. Powinni się rozliczać sami ze sobą i doskonalić. Być lepszymi niż rok temu. Tak przynajmniej mówił Andrzej od AI.
Trzeba zacząć od tego, że nie każdy chce być generalistą.
Jest wielu bardzo dobrych programistów, którzy nie skreśliliby tutaj pewnie połowy kratek.Zresztą to jest jakaś indywidualna wizja autora obrazka. Każdy przygotowałby pewnie taką listę inaczej. Patrząc na obecne trendy, brakuje kratki “transformer model”. ;-)
Rywalizacja jest genetycznie wpisana w każdą formę życia. Ciekawe czemu programiści nie powinni tego robić. Gdyby nie rywalizacja, nie mielibyśmy np. demosceny.
Każdy powinien mieć pojęcie o kosztach tego, czego używa. Jest bardzo mało dobrych programistów. W życiu pewnie słyszeliśmy o 3 takich.
Tabelka do bingo to rozrywka. Dla mnie fajne są listy z zaliczonymi todo. Sporo sensu jest w tym, by się porównywać z przeszłością. Moim zdaniem to nie tylko wymaga dostrzegania błędów z przeszłości. Wymaga też tego, czy się te błędy poprawiło i jakie były z tego wnioski.
Demoscena to nie rywalizacja programistów. Przynajmniej nie w normalnym znaczeniu. Tam liczy się więcej niż kod i algorytmy. Sam kod raczej nie podoba się purystom. Sposób wykorzystania platformy często nie podoba się społeczności skupionej wokół niej. Z resztą stosowane jest dużo sztuczek by zadziwić społeczność możliwościami, których nie ma, ale na animacji wydaje się, że są.
Demoscena bezpośrednio wywodzi się z sceny crackerskiej, gdzie rywalizacja jak najbardziej występuje.
Gdyby w demoscenie nie chodziło o rywalizację, to autorzy nie prześcigaliby się w udoskonalaniu efektów, które zobaczyli w innych demach.
W latach 80 było pełno produkcji gdzie programiści chwalili się, ile animują kropek/bobów.
Nie chodzi o rywalizację w sensie publikacji kodu, tylko o stworzenie ładniej wyglądającego i/lub wymagającego technicznie efektu.Czytałem sporo recek dem w zinach i ludzie tam nie oceniali przez pryzmat ile ktoś animował kropek więcej niż poprzednicy. Raczej oceniało się to czy muzyka jest synchroniczna z efektami. Jakie są przejścia między scenami. Czy reżyseria i narracja są dobre. Taka rywalizacja mogła istnieć w głowie twórcy. Ale chyba niewielu się tym przejmowało, łącznie z konkurentami. Czy liczyłeś te kropki? Czemu nikt nie zrobił białego ekranu i nie napisał 64000 dots? Czy ludzie oburzali się, kiedy nie zostali wymienieni na liście w scrollu?
Jeśli chodzi o wyzwania, to tworzono też zawiłe algorytmy i szyfrowanie produkcji. Odgrażano się, że nikt tego nie rozwinie i nie pozna tajemnic kodu. Oczywiście w warunkach tamtych czasów.
A co jest oceniane w compo 4k procedural gfx i 256b intro?
Nie chodzi o to, jakie kto przyjmie kryteria. Każdy uczestnik ma prawo mieć inne.
Chodzi o to, ze finalnie uczestniczą w jakiejś formie rywalizacji. Inaczej nie byłoby głosowania.Oceniane są wrażenia. Wrażenia są podsycane ograniczeniami. 256B jest chyba najtrudniejsze w obiektywnej ocenie. Ale ocena na scenie nigdy nie była obiektywna. Co niektórych wkurzało i odchodzili. Za to dobrze czuli się ci, którzy nie mieli złudzeń i działali by odnieść skalkulowany sukces. Tacy robili najefektywniejsze toolsy.
