Witam.
Mam tego typu dylemat. Nie śmiem wątpić w wartość tego dzieła, jednak zastanawiam czy studiowanie go w dzisiejszych czasach ma sens? Czy warto czytać o podstawowych algorytmach, nie lepiej zająć się czymś bardziej "na topie"? Może ktoś z was czytał i może podzielić się wrażeniami?
Pozdrawiam.
Na topie? O co Ci chodzi? Algorytmy, to algorytmy - zmienia się popularność języków, algorytmy są te same...
Coldpeer napisał(a)
Na topie? O co Ci chodzi? Algorytmy, to algorytmy - zmienia się popularność języków, algorytmy są te same...
Witam.
Mam na myśli jakieś aspekty szeroko rozumianej inżynierii oprogramowania, nowe techniki programowania np programowanie aspektowe. Z tego co się zorientowałem to ta książka w dużym stopniu zawiera opisy różnych algorytmów sortowania i wyszukiwania, a przecież te już są świetnie zaimpelentowe w wielu językach. Być może lektura tej książki pozwala lepiej zrozumieć istotę programowania i to później może pomaga w rozumieniu innych zagadnień. Nie wiem czy dobrze mi sie wydaje...
Zależy co Cię interesuje i co chciałbyś robić. Jeżeli chcesz być programistą to ta książka jak najbardziej jest warta uwagi. Jeżeli dobrze zrozumiesz chociażby zwykłe metody sortowania, będziesz potrafił udowodnić ich poprawność i złożoność to nauka kolejnych algorytmów będzie Ci wchodziła jak piwo z rana ;)
Wiadomo że nikt nie chce klepać całe życie kodu. Widząc to co się dzieje obecnie trudno uniknąć odczucia że coraz bardziej na pierwszy plan wychylają się raczej wysokopoziomowe problemy związane z tworzeniem złożonych i skalowalnych aplikacji. Teraz pytanie na ile wiedzę zawarta np. w "Sztuce programowania" można przenieść do skali makro. Osobiście odczuwam zainteresowanie tą książka i chyba ją kupie i przeczytam choćby po to żeby wiedzieć. Tak czy inaczej nasuwa się tutaj refleksja o ewolucji jaką przeszła dziedzina tworzenia programów od czasów stworzenia tej pozycji...
Czym innym sa algorytmy czym innym procesy biznesowe w projektowaniu. Te pierwsze dotycza czystej idei programowania - jak zapisac problem w jezyku matematyki, by stad juz latwo przelozyc na konkretny jezyk programowania. Jak rozwiazywac konkretne problemy obliczeniowe, wydajnosciowe, braku pamieci - innymi slowy recepty na konkretny problem matematyczny. Nigdy sie nie zestarzeja poki beda potrzebne rozwiazania dla komiwojazera (firmy transportowe), grafow (liczna rodzina tych algorytmow), wyliczanie sciezki (ruch w sieci chociazby). Takie problemy nie znikaja z szybszymi komputerami, bo to inny rzad wielkosci zupelnie.
Drugie (szeroko rozumiana inzynieria projektowania) bierze pod uwage inny aspekt projektowania - KLIENT. W tym ujeciu nagle programy moga sie zmieniac, co gorsza nawet zalozenia moga sie walic na leb pod koniec projektu. Tutaj wchodza w gre ludzie - jak rozlozyc zadania, zeby wydajnosc byla najwyzsza (nomen omen tu pomagaja algorytmy, np. simpleks), jak zaprojektowac system, by przy najwiekszej zmianie nie zwalilo sie wszystko na glowe. Jak zrobic, by nawet jak klient zrezygnuje z naszego projektu w ostatnie fazie - dalo sie wykorzystac 80% do nastepnego.
To sa dwie zupelnie dwie rozne dziedziny i fakt, ze jedna jest nowsza od drugiej nic nie zmienia ;) To tak jak twierdzic, ze lepiej uczyc sie o laserach, bo sa na topie niz astronomii, bo jest przestarzala i ostatnio nic nowego nie wniesiono... Znaczenie algorytmow podkresla fakt, ze istnieje sporo opracowanych w latach 60-70, ktorych do dzisiaj nie zastapiono. I to nie dlatego, ze olano sprawe, tylko dlatego, ze lepszych nie udalo sie znalezc. I mimo postepu techniki ciagle uzywamy tego samego sortowania co 45 lat temu (quicksort chociazby), bo jest dobre.
I tak jak dla fizyka wiedza o ruchu planet, zyciu gwiazdy, czarnych dziurach i kwazarach jest wiedza elementarna, bo pozwala mu zrozumiec wszechswiat, tak dla programisty wiedza o quicksorcie, sortowaniu babelkowym (mimo, ze praktycznie nieuzywany) i algorytmach grafowych.
Cześć!
Dzięki za pouczenie ;) Mimo że doskonale rozumiem o czym mówisz to wierci mnie taka myśl czego się właściwie lepiej uczyć. Obie dziedziny są obszerne - i algorytmy i inżynieria oprogramowania, na wszystko trudno znaleźć czas którego i tak jest mało. Jednak z drugiej strony informatyk bez solidnych podstaw matematycznych i w kwestiach obliczeniowych wydaje mi sie ciut niedouczony.
Ehh o ile łatwiej miał Gates :)
No i dalej nie mam pełnego przekonania co do tej książki. Chyba nie jest ona zbyt popularna skoro nikt sie o niej nie wypowiedział.
Popularnosci moze przeszkadza fakt, ze wiekszosc ludzi o algorytmach uczy sie sporo na studiach. Za to z inzynierii oprogramowania juz troche mniej, wiec tutaj czesciej wspiera sie ksiazkami.
Wiesz, nie chodzi o to, zeby na pamiec znac wszystkie sortowania, o 12 w nocy recytowac obliczenia zlozonosci. Chodzi o ten zmysl 'kumam o co chodzi'. Jak bedzie trzeba to zmodyfikujesz takie sortowanie do wlasnych potrzeb albo obliczysz ta zlozonosc w przypadku szczegolnym - po polaczeniu 2 rodzajow sortowan, szukania i jakiegos swojego algorytmu bedziesz umial stwierdzic czy zlozonosc jest O(n) czy O(n!). A roznica potrafi algorytm zamordowac ;)
Racja, racja. Powiem CI że przekonałeś mnie. Ja nie mogę niestety powiedzieć żebym dużo uczył się na studiach o algorytmach. Studiuje zaocznie na uniwerku i różnie to bywa. Sam już miałem takie odczucie żeby do tej książki nie podchodzić jako do katalogu algorytmów które można wkuć tylko jak do przewodnika po materii informatycznej. Ciekawym faktem jest że przykłady w tej publikacji zapisane są w assemblerze, co autor tłumaczy m. in. tym że języki wysokiego poziomu nie umożliwiają przedstawienia szczegółów niskopoziomowych omawianych w książkach i wychodzą z mody mniej więcej co pięć lat. Kolejna ciekawostką jest to, że w 1999 miesięcznik naukowy American Scientist umieścił tę pracę na liście najlepszych dwunastu prac z dziedziny nauk przyrodniczych XX wieku, pośród dzieł m. in. Einsteina, Mandelbrota, Diraca, Neumanna, Wienera, Feynmana.