Zapytuje o rozne ciekawe…

Categories Programowanie

Zapytuje o rozne ciekawe ksiazki z zakresu programowania, w ktorych mozna poczytac o interesujacych, istotnych, ale i nieoczywistych aspektach pisania kodu.
Nizej kilka przykladow tego, co mam na mysli, a o co ciezko w literaturze:

– Ze paradygamty programowania to nie religie. Ze niczego tak naprawde nie dodaja, a wrecz odwrotnie – odejmuja. Ze wartosc paradygmaty tkwi w tym, jak narzuca on ograniczenia w pracy z kodem, przez co powoduje koniecznosc pracy w okreslony sposob, ktory finalnie sprowadza sie do utrzymania dyscypliny w pisaniu kodu.
– Ze od wielu juz lat nie ma nowych paradygmatow programowania i moze juz nie bedzie. To, na co w tej chwili jest hype to wariacje na temat technologii z lat 60/70/80…
– Ze programowanie obiektowe TO JEST polimorfizm. Ze to wlasnie on rozni w praktyce OOP od innych paradygmatow programowania. (Ciekawe jest tez jak w przeszlosci programisci pracujacy w jezykach, gdzie nie da sie bezpiecznie osiagnac polimorfizmu – jak C – radzili sobie z takimi rzeczami).
– Ze czytanie „Structure and Interpretation of Computer Programs” wcale nie jest dobrym pomyslem dla poczatkujacego programisty. (wiele osob bezmyslnie ja poleca na rozwoj horyzonotw, podczas gdy ksiazka zajmuje sie w 50% argumentowania za funkcyjnym paradygmatem programowania z przykladami w bardzo waskich zastosowaniach).
– Ze istnieja srodowiska programistyczne obslugujace wiele jezykow programowania, gdzie korzystajac z jezyka X, ktory znamy, mozemy latwo skorzystac z bibliotek jezyka, ktorego nie znamy.
– Ze niektore pomysly w jezykach programowania, ktore moglyby sie wydawac super, jak wstrzykiwanie kodu na poziome runtime w Ruby, sa tak naprawde recepta na katastrofe. Ze sa takie rzeczy, ktorych nie warto czynic zbyt „nimble”. (Pracowalem kiedys nad takim projektem, gdzie musielismy zmodyfikowac dzialanie programu w Ruby, do ktorego nie mielismy zrodel i nie moglismy zatrzymac dzialania programu. Na poczatku szlo super, a pod koniec projektu narobilismy takiego bajzlu w tym dzialajacym stale systemie, ze az wstyd)
– Ze kiedys byly fantastyczne wojny na wydajnosc miedzy producentami baz danych, ktorych bylo niewiele. Cale imperia biznesowe powstaly z kasy zarobionej na bazach – patrz Oracle (swoja droga sposob budowy tego typu produktow jest fascynujacy).
– Ze Test Driven Development to nie opcja, a koniecznosc. Ze tylko tak mozna skutecznie zachowac spokoj umyslu i zapewnic sobie pokrycie wiekszosci kodu testami juz od poczatku jego tworzenia. Taka filozofia etyki pracy polaczona z gamifikacja tej niezbyt przyjemnej roboty, ktora po prostu ma gleboki sens. A nie tak sie to u nas przedstawia…
– Ze nie ma czegos takiego jak branza IT. Dzis praktycznie kazda firma jest firma technologiczna. Nie tak rozroznia sie role programistow w firmie, ale jest na to sposob – okreslic czy jestesmy cost center (firma nie zarabia na pracy z technologia) czy profit center (zarabia, np. tworzy produkty). Chcemy byc w tej drugiej sytuacji.
– Ze praca z kodem to najblizsza magii rzecz jaka kiedykolwiek istniala na tej planecie 😉 Wypowiadasz zaklecia, a maszyna tworzy cale mini wszechswiaty robiace dla ciebie rozne rzeczy.
– Ze kiedys debuger to nie bylo cos, do czego dostep mial kazdy. Trzeba bylo za to zaplacic kase, a jak jej nie miales, to robilo sie debugowanie na poziomie RAMu w systemie szesnastkowym (co ponoc nie nalezalao do przyjemnosci) 😉 Dzis jestesmy w super komfortowej sytuacji.
– Ze w programowaniu wazna jest nie umiejetnosc kodowania (bo nie wiadomo co to w zasadzie jest), a umiejetnosc budowy systemow oprogramowania (ich architektura) tak, aby nie zawalily sie pod swoim ciezarem. Ta druga dziedzina jest nieco ezoteryczna, ciezko w niej o dobre materialy do nauki, stad wazne jest doswiadczenie (wzorce projektowe nie zrobia z ciebie programisty) i warto od samego poczatku nauki poswiecac czas na drazenie tego tematu. W wielu przypadkach wynajdziemy kolo na nowo, ale jak juz tak zrobimy, to dane rozwiazanie na zawsze zostanie nam w pamieci miesniowej jako istotne. Ja tak mialem z odwroceniem zaleznosci; nie moglem przez ten problem spac po nocach zanim jeszcze odkrylem istnienie takiego pojecia.
– Ze progamowanie nie jest trudne, ale jest kompleksowe. Warto rozumiec roznice miedzy tymi pojeciami.
Programowanie (nawet algorytmy) pracuja w przestrzeni dwuwymiarowej z czasem polynacym zawsze do przodu (mam na mysli to, co dzieje sie na poziomie runtime’u). Taka struktura kodu powoduje, ze mozliwym jest zrozumienie co sie dzieje w czasie jego wykonywania. Jesli czego nie rozumiesz, to ZAWSZE masz na to szanse, o ile odpowiednio swiadomie przysiadziesz do tematu.

Chetnie dowiem sie o ksiazkach / innych zrodlach, gdzie mozna poczytac o podobnych rzeczach. Jesli sam masz jakies interesujace przemyslenia na takie tematy, to tez o nich napisz.

Chcialbym kiedys zobaczyc ksiazke „Najistotniejsze apekty programowania komputerow dla programistow dowolnego jezyka i dowolnej domeny”, ale wedlug mojej najlepszej wiedzy nie ma czegos takiego. I oczywiscie nie chodzi mi o zbiory dobrych praktyk, a o rzeczy uniwersalnie wazne dla kazdego programisty.

Wyluszczenie rzeczy uniwersalnie waznych wydaje mi sie istotne. Wydaje mi sie tez wyjatkowo interesujace. Moze to dlatego, ze sam jestem poczatkujacy.

#programowanie #naukaprogramowania #programista15k