Czy macie czasem poczucie, że rozwiązujecie co raz bardziej wirtualne problemy na co raz bardziej wirtualnym sprzęcie? W dzisiejszym, pędzącym świecie musimy poruszać się na bardzo wysokich poziomach abstrakcji, ponieważ gonią nas terminy i musimy dowieźć oprogramowanie na czas. Piszemy kod pod wirtualne maszyny, które pracują na nieznanym nam systemie operacyjnym, na nieznanym sprzęcie, często jeszcze w chmurze. Wielu programistów Javy czy C# szczególnie tych młodych zapomniało już co to jest zarządzanie pamięcią, jej alokowanie, zwalnianie czy odwoływanie się do niej. Frameworki w stylu Hibernate zwalniają nas z potrzeby pisania kodu SQL, a wielu Javowych wymiataczy nie wie nawet czym jest strona w bazie danych. Piszemy z umiłowaniem lambdy w Kotlinie bez świadomości, że tworzymy tysiące małych obiektów, które zaśmiecają pamięć i obciążają GC. Programujemy wątki, które wykonuje JVM na wieloprocesorowych maszynach, na wielordzeniowych procesorach, które często jeszcze używają hyper-threading, a często nie mamy świadomości czym jest semafor i synchronizacja. Zawsze tam pod spodem jest jakiś sprzęt i wszelkie problemy na niskich poziomach abstrakcji rzutują na ten na którym się poruszamy. Jak szczur przegryzie kabel w serwerowni, to zapomnijcie o tym, że rozwiązanie będzie w waszej dokumentacji...
Korzystanie z wyzszych poziomow abstrakcji przyspiesza development (i nie ma w tym nic zlego). Problem pojawia sie jak cos sie psuje np. przez bug w ktorejs warstwie. Wtedy wiedza jak dzialaja nizsze warstwy zaczyna byc przydatna. A czesto jej brakuje.
Zgadza się, praca na wyższym poziomie abstrakcji często zdejmuje nam z pleców wiele problemów. Ale czy można pracować na najwyższym poziomie abstrakcji nie wiedząc co dzieje się poniżej? Od jakiegoś czasu można zaobserwować taki trend, że ludzie co raz mniej orientują się na tym jak działa pamięć, baza danych czy synchronizacja wątków.
Bo w każdej dziedzinie występuje specjalizacja. Są tacy którzy wiedzą jak działa sprzęt czy strona pamięci. Są także tacy którzy tego problemu nie dotykają.
Chodzi o kombatanckie wspomnienia że "dawniej było lepiej" ? :-)
Żeby pisać kod, muszę dojechać do pracy samochodem który nie wiem dokładnie jak działa a wiem jedynie jak go użyć, tankuję benzynę z zewnętrznej usługi o której wiem tyle że wkładam pieniążek i po wciśnięciu spustu leci paliwo. Jak dojadę, to robię kawę w automacie który ma 5 przycisków do kubka który w jakiś sposób znalazł się w szafce.
Życie to abstrakcja.
Oczywiście rozumiem co chcesz przekazać, ale Twoje porównanie jest nieadekwatne. Jesteś użytkownikiem samochodu i automatu do kawy, podobnie jak pani Zosia z księgowości jest użytkownikiem aplikacji, którą programujesz. Pani Zosia nie musi wiedzieć, że jej cieknie abstrakcja, ona tylko widzi, że raport się wolno generuje.
Pani Zosia ma prawo nie wiedzieć, ale Ty jako programista to chyba już co innego?! Podobnie mechanik musi wiedzieć jak działa samochód, a serwisant musi wiedzieć jak działa automat do kawy.
I ja wiem czemu raport się wolno generuje. Bo skorzystałem z narzędzia które oszczędziło mi setki godzin pracy zamiast pisać to od nowa. I w tym momencie to ja staję się jego użytkownikiem, tak jak Pani Zosia systemu raportoweg który pisałem. Jestem użytkownikiem systemu operacyjnego, hibernate, IDE i expresu do kawy. Pani Zosia może mieć do mnie pretensje, bo to ja źle wybrałem, a ja mogę mieć pretensje że mi sałatka w restauracji nie smakuje, co nie znaczy że zaraz mają uruchamiać własne farmy z warzywami. Mogą po prostu zmienić dostawcę (aka implementację abstrakcji).
Rust ma łączyć zalety C i Javy, prostota, szybkość i bezpieczeństwo. Jest blisko sprzętu jak i na wyższym poziomie.
krzysiek050 napisał(a):
I ja wiem czemu raport się wolno generuje. Bo skorzystałem z narzędzia które oszczędziło mi setki godzin pracy zamiast pisać to od nowa. I w tym momencie to ja staję się jego użytkownikiem, tak jak Pani Zosia systemu raportoweg który pisałem. Jestem użytkownikiem systemu operacyjnego, hibernate, IDE i expresu do kawy. Pani Zosia może mieć do mnie pretensje, bo to ja źle wybrałem, a ja mogę mieć pretensje że mi sałatka w restauracji nie smakuje, co nie znaczy że zaraz mają uruchamiać własne farmy z warzywami. Mogą po prostu zmienić dostawcę (aka implementację abstrakcji).
Chyba się nie rozumiemy. Ja nie twierdzę, że programista ma wszystko napisać od nowa, twierdzę, że powinien wiedzieć jak to działa. Tzn. programista Hibernate powinien potrafić podejrzeć co mu się wygenerowało i wiedzieć czy tutaj trzeba coś poprawić czy nie i potrafić to zrobić. Biblioteka powinna ułatwiać i przyspieszać pracę, a nie zwalniać programistę z myślenia i odpowiedzialności.
Analogicznie restauracja nie musi uruchamiać własnej farmy z warzywami, ale powinna potrafić odróżnić produkt świeży od nieświeżego, dobrego dostawcę od złego.
No, ale teraz nie ma już prawie programistów, są głównie "znawcy frameworków", którzy wierzą w to, że ORM magicznie generuje wydajne zapytania do bazy (bo tak napisali twórcy na stronie), albo w to, że jak jest GC, to nie trzeba myśleć o pamięci (bo skoro się automatycznie zwalnia, to znaczy, że nic się zepsuć nie da).
No i co można z tym zrobić? Chyba tylko pośmiać się i wrócić do swoich zajęć.
Mogą po prostu zmienić dostawcę (aka implementację abstrakcji).
Albo sprawdzic dlaczego cos nie dziala, bo moze uzywasz ta abstrakcje w nieprawidlowy sposob. Korzystanie z frameworkow na zasadzie "jak wrzuce na input X to dostane Y" bez zadnego zainteresowania dlaczego i jak mi to zwrocilo Y jest niebezpieczne. A jak przez przypadek zwroci Z to juz w ogole tragedia i trzeba caly framework wymienic bo sie okazal zla abstrakcja.
Jeżeli chcesz odczytać propertiesy z pliku to możesz.
- Stworzyć obiekt Properties i podać Stringiem nazwę pliku
- Stworzyć obiekt File() i czytać ze strumienia
- Czytać z api posix
- Zagłębić się w przerwania systemowe i obsługę urządzeń
- Zagłębić się w sterownik dysku
Na którym punkcie powinieneś się zatrzymać Twoim zdaniem?
Na pewno nie na pierwszej, ok. Ale myślę że nie ma programistów którzy nie domyślają się jak działa używane przez nich narzędzie. Myślę też że nikt nie zna jakiegoś zagadnienia od A do Z.
@krzysiek050: dyskusja jest o ludziach, którzy nie znają innych możliwości niż pierwsza i pół drugiej.
@somekind Z pierwszego postu zrozumiałem że chodzi o każdego używającego abstrakcji bez jej rozumienia lub chociaż przypuszczania jak działa. Czyli IMHO każdego.
Ludzie którzy znają punkt 1 i pół drugiego to nie programiści, tylko klepacze. A tych drugich szkoda dyskutować.
@krzysiek050 - nie wiem czy trollujesz, czy sens mojej wypowiedzi jest aż tak niezrozumiały?! Dlaczego popadasz w taką przesadę? Napisałem konkretne przykłady tego gdzie abstrakcja przecieka i gdzie niższe warstwy mają duży wpływ na to jak działa nasz kod.
Miałem na studiach taki przedmiot jak bodajże "Systemy operacyjne" gdzie jedno z zadań polegało na napisaniu w C pod Linuxem kodu manipulującego procesami. W zadaniu chodziło przede wszystkim o to, żeby się przekonać, że równoczesne wykonywanie wielu zadań na jednym procesorze to złudzenie, a procesy są wstrzymywane i wznawiane. Czy programista powinien wiedzieć co to jest proces i w jaki sposób wykonuje go procesor czy też jest to zbędna wiedza, którą ktoś próbował zaśmiecić mi umysł?
Czy programista powinien wiedzieć co to jest proces i w jaki sposób wykonuje go procesor czy też jest to zbędna wiedza, którą ktoś próbował zaśmiecić mi umysł?
Ależ oczywiście, że może nie wiedzieć - ale taki programista pewnie będzie próbował przyśpieszyć swój program np. wrzucając długo trwające zapytania SQL do wątków bo przecież wincyj rdzeni = wincyj szybkości ;-)
Jeżeli ktoś pisze aplikacje jednowątkowe, to może nie wiedzieć czym jest proces. Jeżeli pisze wielowątkowo, nie musi wiedzieć czym jest semafor, jeżeli ma inne, nowocześniejsze systemy synchronizacji (na wierzchu).
Tak, oczywiście - zdarzają się takie sytuacje, w których programista w ogóle nie zna się na wielowątkowości, ponieważ nie ma wprost takiej potrzeby (bądź możliwości). Jeśli jednak tworzy na platformę obsługującą wielowątkowość bądź działającą w oparciu o nią, warto byłoby co nieco wiedzieć, aby właśnie nie być ignorantem z motto wincyj rdzeniuf.
Programowanie ewoluuje. Kiedyś dziurkowało się karty, dzisiaj masz metodę "CreateGame" w klasie "Super3DGames". Standardowy klepacz kodu dzisiaj tak naprawdę chyba rzadko potrzebuje wiedzy na temat niższych poziomów (mówię o językach typu C#, Java), bo nie jest mu to faktycznie potrzebne.
Jak pisałem w Delphi też nie wiedziałem, jak to działa wszystko pod spodem. Chociaż sam musiałem zarządzać pamięcią itd. to nie interesowało mnie zupełnie jak tak naprawdę powstają guziki, czy coś. Dopiero jak zacząłem robić w C++ i bardziej zainteresowałem się WinAPI, zobaczyłem tą kobyłę, która wcześniej nie była mi potrzebna. Kiedyś nie lubiłem też C#, uważałem to za język dla głupich Amerykanów. Ale z czasem doceniłem szybkość, z jaką można tam napisać gotową aplikację. Chociaż np. nadal nie używam ORMów, uważam je za coś zbędnego. Ale myślę, że ktoś, kto zaczyna dzisiaj, jeśli zainteresuje się np. programowaniem urządzeń, w końcu to wszystko ogarnie. To będzie duże zderzenie ze ścianą, ale do ogarnięcia.
Niskopoziomowe podejście czasem w dzisiejszych czasach nie jest zupełnie potrzebne. Pamiętam jak pisałem w Delphi czy C++ to czytałem przestrogi, że obiektówka powoduje narzut na tworzenie obiektów, że wywołanie funkcji powoduje narzut czasowy na wywołanie funkcji (dlatego pamiętam, że można było zadeklarować funkcję jako inline w C++), pamietam jak optymalizowało się każdą pętlę i każde działanie, jak unikało się liczb zmiennoprzecinkowych bo inty były szybsze itp.
A teraz w JS wszyscy tworzą radośnie obiekty (w Redux to nawet co chwila, bo każda akcja powoduje zwykle utworzenie nowego obiektu-kopii w reducerze), używają bezwiednie floatów, tworzą mnóstwo funkcji pomocniczych aż stos wywołań puchnie, zamiast prostej pętli używają jakichś dziwów w stylu map (nie wiem jakim cudem to jest wydajne, jeszcze z jakiś czas temu bałem się używać funkcji map co chwila, bo cały czas myślałem o tym, że tworzę niepotrzebnie nową tablicę), tworzy się też ciągle domknięcia jakby pamięci RAM było nieskończenie wiele... Generalnie na więcej można sobie pozwolić nie myśląc o konsekwencjach.
Oczywiście jak się przesadzi i utworzy np. z milion obiektów i wykona na nich jakieś operacje, to też raczej szybko nie będzie. Chodzi mi o to jednak, że można pisać wiele rzeczy w zasadzie nie myśląc o optymalizacji, ew. optymalizując z profilerem w dłoni, dopiero jak wystąpi konkretny problem (bo występują niestety). Wydaje mi się, że kiedyś bardziej trzeba było zwracać uwagę na optymalizację już na wczesnych etapach developerki, dość wcześnie problemy z optymalizacją dawały o sobie znać.
Wideo w temacie z zeszłorocznego geecona
Naszła mnie taka refleksja, gdy kodzę sobie trochę i w domu i w pracy w Elixirze. Aby sensownie podejść do tematu starałem się w trakcie ogarniać Erlanga z naciskiem na OTP. Generalnie to, co się tam dzieje pod spodem jest bardzo złożone i trudne do ogarnięcia. Informacji o maszynie Erlanga w zasadzie brak, zrozumieć jak działa OTP też wymaga bardzo dużo czasu i tak właśnie wtedy pomyślałem, że będą ludzie, którzy będą pisać sobie CRUDy w Phoenixie i nie będą w ogóle ogarniać, że Elixir / Phoenix to nie tylko "nowy Ruby on Rails", ale w większości przypadków głębsza wiedza o Erlangu i możliwościach Elixira - GenServerach, Agentach, Taskach, Makrach itp. nie będzie im potrzebna.
Co do samej abstrakcji to generalnie jest to dobre, że nie musisz cały czas skupiać się na tym, co jest w warstwie niżej. Wręcz nie powinieneś, bo jednak masz się skupić w pracy na "delivery ticketów". Czasami zaś taka wiedza jest bezcenna, bo rzadko się zdarza, żeby wszystko szło jak należy. Co do tych zapytań do bazy to u mnie zespole każdy jest w stanie wykodzić szybko poprawne zapytanie do bazy o co tylko chce, ale z wiedzą o stronach, indeksach itp. może być już gorzej.
Pipes napisał(a):
Co do tych zapytań do bazy to u mnie zespole każdy jest w stanie wykodzić szybko poprawne zapytanie do bazy o co tylko chce, ale z wiedzą o stronach, indeksach itp. może być już gorzej.
Zapytanie napisane przez programistę, który nie wie jak działa baza danych będzie zwracać pożądane dane (do tego wystarczy znajomość SQL), ale może być nieoptymalne. Jeżeli Waszym klientom to wystarcza i pani Zosia z księgowości jest zadowolona, że ma dwie godzinki wolnego gdy generuje się raport albo klient zawiesza działalność gdy na bazie zrobią się deadlocki, bo Wasze selecty nie chodzą po indeksach i lockują całą tabelę to spoko.
krzysiek050 napisał(a):
Żeby pisać kod, muszę dojechać do pracy samochodem który nie wiem dokładnie jak działa a wiem jedynie jak go użyć, tankuję benzynę z zewnętrznej usługi o której wiem tyle że wkładam pieniążek i po wciśnięciu spustu leci paliwo. Jak dojadę, to robię kawę w automacie który ma 5 przycisków do kubka który w jakiś sposób znalazł się w szafce.
Życie to abstrakcja.
- Żeby znaleźć pracę, nie muszę znać rynku pracy i swoich umiejętności; udaję się do urzędu pracy, gdzie doradca zawodowy tym się zajmie.
- Jak chcę znaleźć kobietę, wystarczy udać się do biura matrymonialnego, lub co bardziej powszechne, skorzystać z portalu randkowego lub tindera.
- Jeśli chcę się ożenić, to udaję się do prawnika, który załatwi formalności i zlecam komuś organizację ślubu i wesela.
- Jeśli chcę mieć dzieci, to ich wychowywanie zlecam opiekunce; wszakże ja oraz moja żona ma pracę z pkt. 1.
(...) - Jeśli chcę spędzić godnie starość, to udaję się do domu starców.
A teraz odnieśmy to do programowania.
- Żeby być programistą i zarabiać 10k zł miesięcznie, nie muszę wiedzieć jak działa komputer, odpowiednie oprogramowanie tym się zajmie...
Wyobraźnia działa szybciej od logiki, więc łatwiej asymilować pewne związki w znaczenia wyższego rzędu.
Potem po tych znaczeniach można wskoczyć w pewien poziom logiki, który nas interesuje, na który 'patrzymy'.
Po co się uczyć skomplikowanych tworów? jak wystarczy umieć wyobrazić sobie jak to 'wygląda', a neurony przy wykonywaniu czynności same nauczą się odzwierciedlać daną rzecz.
Albo po co się uczyć jak coś działa, jak działa tak samo jak coś innego w świecie?
Wystarczy tylko znaleźć te znaczenia i je ze sobą skojarzyć, resztą zajmie się mózg.
W moim przypadku nie pawam się radością do obiektów, dlatego bardzo cenię sobie programowanie w asemblerze. Lubię, gdy każdy mnemonik wykonuje jedno proste zadanie, a całość ze sobą współgra. Każdy Bajt mam pod kontrolą, każdą abstrakcję, którą wykorzystałem - stworzyłem od podstaw.
Ot takie przemyślenie.
PS: tak, znam inne języki i je wykorzystuję w pracy.
Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.) The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.
@up - głupia, bezsensowna paplanina. Tak jakby jakość kodu lub jego szybkość albo wrażenia użytkownika nie miały wpływu na zyski i redukcję kosztów...
Haskell napisał(a):
@up - głupia, bezsensowna paplanina. Tak jakby jakość kodu lub jego szybkość albo wrażenia użytkownika nie miały wpływu na zyski i redukcję kosztów...
No więc są sposobami osiągania celu, a nie celem samym w sobie.
Niemniej jednak, pisanie dobrego kodu jest łatwiejsze niż pisanie słabego i zajmuje znacznie mniej czasu. Niestety większość programistów woli sobie utrudniać życie (albo opiera swój model kariery na wiecznym łataniu kupy, którą sami stworzyli).
somekind napisał(a):
No więc są sposobami osiągania celu, a nie celem samym w sobie.
To już jest wyłącznie kwestia definicji. Są ludzie, którzy większy cel dzielą na kilka mniejszych i wtedy jak najbardziej pisanie dobrego kodu staje się celem, w drodze po ten większy cel, którym może być sukces zawodowy, zarobienie pierwszego miliona czy szacunek "na dzielni".