14 lutego 2017

Bicie piany

Czy słyszałeś o tym gościu, który powiedział, że Object Oriented to przeżytek?

No nie. Następny. Co powiedział?
Opisał wszystkie obietnice OO, i jak żadna z nich tak naprawdę nigdy nie została spełniona i o tych wszystkich możliwościach OO, które kosztują więcej, niż są warte i że funkcjonalne programowanie jest lepsze i ...
Phi. Tak słyszałem już to wcześniej.
No, więc OO jest martwe, leży i kwiczy i możemy przejść dalej.

Przejść dalej do czego?

Co? No do NASTĘPNEJ WIELKIEJ RZECZY oczywiście.

Aaaa, do tego. Czy wiesz już co to jest?

Nie bałdzo, ale jestem podekscytowany na myśl o mikroserwisach; jaram się Elixirem; i słyszałem, że React jest fantastyczny; i ...

Tak, tak. Bicie piany. Dałeś się nabrać na bicie piany.

Co? Co masz na myśli. Przecież mamy takie wspaniałe czasy.

Tak naprawdę postrzegam te czasy jako depresyjne.

Ale dlaczego? Przecież co kilka dni wyskakują nowe wspaniałe technologie! Wspinamy się na coraz wyższe szczyty.

Phi. To, co tak naprawdę robimy, to wymyślanie koła od nowa. Wciąż i wciąż od nowa. I tracimy ogromne ilości czasu i zasobów, aby to robić.

Ej, no weź, no. Przecież to jest właśnie POSTĘP.

Postęp? Naprawdę? Nie widzę tego w ten sposób.

No dobra, to w takim razie co widzisz?

Widzę marnotrawstwo. Ogromne, niepoliczalne marnotrawstwo. Marnotrawstwo na marnotrawstwie, marnotrawstwem pogania.

Jak możesz tak mówić?

No więc, rozważmy ten przypadek Programowania Zorientowanego Obiektowo. To nie jest tak, że OO jest martwe. OO nigdy nie było żywe. OO to jest technika i to dobra. Twierdzić, że OO jest martwe, to jak twierdzić, że doskonale sprawny śrubokręt jest martwy. Mówienie nara do OO jest jak mówienie nara do doskonale działającego śrubokręta. Co za marnotrawstwo!

Ale Programowanie Funkcyjne jest lepsze!

No sorry, ale to jak mówienie, że młotek jest lepszy od śrubokręta. Programowanie funkcyjne nie jest lepsze od programowania zorientowanego obiektowo. Programowanie Funkcyjne jest techniką i to dobrą i może być użyte obok Programowania Zorientowanego Obiektowo.

Nie jest to to, co słyszałem. To, co słyszałem, to to, że te techniki są rozłączne.

Oczywiście, że nie są. Adresują problemy, które wzajemnie się przenikają. Takie problemy występują we wszystkich projektach informatycznych.
Słuchaj, są ludzie, którzy uważają, że oprogramowanie naturalnie podąża za postępem, że bez przerwy wchodzi po drabinie w górę. Każda "nowa" rzecz jest lepsza niż poprzednia "starsza" rzecz. Tak to nie działa.


No więc jak to działa - według Ciebie?

Postęp w oprogramowaniu podąża za krzywą logarytmiczną. We wczesnych latach postęp był ostry i dramatyczny. W późniejszych latach postęp stał się bardziej przyrostowy. Teraz postęp praktycznie nie istnieje.

Zobacz, asembler był o niebo lepszy od binarnego kodu maszynowego. Fortran był dużo lepszy od asemblera. C był lepszy niż Fortran. C++ był prawdopodobnie lepszy od C. Java to ulepszenie w stosunku do C++, a Ruby jest tylko troszkę lepszy od Javy.

Waterfall był o niebo lepszy niż nic. Agile był lepszy niż waterfall. Lean był trochę lepszy niż Agile, a Kanban to tylko usprawnienie.

Każdego roku, mimo, że dokonujemy ogromnego wysiłku, robimy mniejsze postępy niż rok wcześniej, ponieważ zbliżamy się coraz bliżej i bliżej do asymptoty.

Asymptoty! Czy uważasz, że jest górna granica technologii oprogramowania i postępu?

Absolutnie, tak właśnie uważam. Co więcej uważam, że jesteśmy tak blisko tej asymptoty, że dalsze staranie się nie ma sensu. Myślę, że przekroczyliśmy punkt, który opisuje prawo malejących przychodów.

Co takiego? To brzmi śmiesznie! To brzmi deprymująco!

Rozumiem to. To wszystko przez to, że przywykliśmy do tych początkowych etapów szybkiego wzrostu. To były ekscytujące czasy i bardzo chcemy żeby powróciły. Ale one odeszły i musimy stanąć przed faktem, że marnujemy czas i wysiłki na masową skalę, aby poczuć się tak, jak wtedy.

No, ale jeżeli nie będziemy pchać do przodu, nie stworzymy świetlanej przyszłości.

Uwierz mi, ja bardzo chcę abyśmy pchali do przodu, ku przyszłości. Nie robimy jednak tego. To co robimy, to trzymanie się kurczowo czasów minionych.

No więc jak wygląda przyszłość, do której powinniśmy dążyć?

Produktywnie. Niech to będzie przyszłość, która nie jest zdominowana przez te marnotrawne bicie piany.

O co chodzi z tą marnotrawnością.

Czy używałeś kiedyś IntelliJ Idea lub Eclipse do programowania w Javie?

No pewnie.

To są niesamowicie użyteczne narzędzia. Doświadczony profesjonalista może być dzięki nim bardzo efektywny. Te refaktoringi! Te ułatwienia! Mój Boże, te narzędzia są spektakularne.

Każdorazowo, kiedy wyjdzie nowy język programowania uciekamy od tych mocarnych narzędzi, żeby używać NOWEJ WSPANIAŁEJ RZECZY. Tymczasem narzędzia do tego nowego języka pozostawiają wiele do życzenia. Wielkie nieba, tam zwykle nie ma nawet dobrze działającego narzędzia do automatycznej zmiany nazwy!

Mijają wieki zanim ten język doczeka się sensownego zestawu narzędzi. Jeżeli będziemy ciągle zmieniać języki nigdy nie będziemy w stanie zbudować im odpowiednio dobrych narzędzi.

Ale te nowe języki są lepsze.

Byzydura. One są różne, ale nie są lepsze. Lub przynajmniej nie lepsze na tyle byśmy mogli usprawiedliwić wysłanie naszego całego zestawu narzędzi z powrotem do epoki kamienia łupanego.

I pomyśl o kosztach szkolenia, potrzebnego do adaptacji do nowego języka. Pomyśl o kosztach organizacyjnych konieczności używania 84 różnych języków tylko dlatego, że programiści są podjarani błyszczącym nowością świecidełkiem raz na dwa tygodnie.

Błyszczące nowością świecidełka? To trochę obraźliwe, nieprawdaż?

A i owszem, ale do tego to się sprowadza. Nowe języki nie są lepsze. One są po prostu błyszczące. Co więcej poszukiwanie złotego runa nowego języka, nowego frameworku, nowego paradygmatu, czy nowego procesu jest podejściem nieprofesjonalnym.

Jak to nieprofesjonalnym?

Tak! Nieprofesjonalnym! Potrzebujemy uświadomić sobie, że osiągnęliśmy asymptotę.

Czas skończyć z bezproduktywnym biciem piany o językach, frameworkach, paradygmatach czy procesach.

To jest czas, aby po prostu zabrać się do roboty.

Potrzebujemy wybrać język, dwa czy trzy. Mały zbiór prostych frameworków. Zbudować nasze narzędzia. Utwierdzić nasze procesy. I stać się w końcu cholerną profesją.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


10 komentarzy:

  1. Fajne, ale... :) Pod koniec XIX w. stwierdzono, że co miało zostać odkryte już odkryte zostało i musimy jedynie doskonalić dokładność pomiaru.

    Kilka lat potem pojawiły się prace Plancka, Einsteina i Bohra i nic już nie było takie jak wcześniej.

    Być może zbliżamy się do asymptoty w kategoriach myślowych i pojęciowych, w jakich się poruszamy. Sądzę, że należy się spodziewać, że pewnym momencie pojawi się koncepcja, które ujmie problemy, z którymi się mierzymy w inny bardziej ogólny sposób i nic już nie będzie takie jak wcześniej.

    Twierdzenie, że zbliżamy się kresu tak w ogóle, globalnie to arogancja :) Niezależnie od tego, iloma latami doświadczenia jest poparta i jakim nazwiskiem, to wciąż arogancja :)

    Z najlepszymi intencjami,
    Michał

    OdpowiedzUsuń
    Odpowiedzi
    1. Cześć Michał,
      Wydaje mi się, że wujek trochę się plącze. Raz chodzi mu ogólnie o całą branżę, raz o domenę języków programowania. Jeżeli chodzi o języki to zgodzę się z UB - trochę żeśmy już tę gałąź wyeksplorowali. Jeżeli chodzi o całą branżę, to zgadzam się z Tobą - wiele jeszcze przed nami.

      Usuń
  2. Zabawne. Mam wrażenie, że uczę się tyle Co nigdy, każdego miesiąca coraz więcej. Coraz ciekawsze możliwości się otwierają. Mam wrażenie eksplozji...
    .... programuje od roku 1991.

    jarek


    OdpowiedzUsuń
    Odpowiedzi
    1. Hej Jarek,
      Ja też zaczynałem około tej daty w Atari Basic :) z Bajtkiem z 87' na kolanach razem z Tatą wklepywaliśmy tekstówkę.

      Usuń
  3. UB ma potrzebę rozpoznania fundamentów. Ma również potrzebę aby istniały fundamenty blisko wartości asymptotycznej.
    Intuicyjnie przeczuwam, że granica poznania istnieje. Jeśli tak, można by zatem wyróżnić w naszej dyscyplinie obszary gdzie taką granicę osiągamy.
    Osiągnąć w programowaniu sprawność matematyka, to by było mistrzostwo. Na moich studiach biegłe opanowanie technik i warsztatu było często kluczem do sprawnego udowadniania kolejnych aksjomatów. Dzisiaj nasza matematyka jest sfromalizowana do granic absurdu. Nie zostałem uczony inaczej niż poprzez dowód formalny. Może tak właśnie UB chciałby się poruszać w świecie programowania. Szybkie, precyzyjne, podstawowe metody formalizacji.

    OdpowiedzUsuń
    Odpowiedzi
    1. Ciekawe przemyślenia Macieju. Rzeczywiście nasza branża na początku składała się z samych matematyków o nieprzeciętnych zdolnościach. 70 lat później, ja, jako programista nie mogę o sobie powiedzieć, że jestem matematykiem o nieprzeciętnych zdolnościach. Tylko czy informatyka/programowanie to jeszcze nauka czy już sztuka czy też coś pomiędzy - rzemiosło?

      Usuń
  4. Michał, poruszyłeś ciekawy temat. Nie jestem pewna, czy faktycznie wymyśliliśmy już wszystko i powinniśmy już teraz tylko leżeć i pachnieć.. Ale na pewno rzucanie się na nowinki jest mało produktywne.

    Co innego jest budowanie petshopów, żeby się czegoś nauczyć, co innego oranie produkcji co sezon. Niestety na konferencjach często entuzjaści nowych frameworków/ języków/ technologii mają za sobą jedynie petshopy, a publiczność po powrocie do pracy chce ich popróbować na produkcji.

    OdpowiedzUsuń
    Odpowiedzi
    1. Hej Ola,
      To nie ja tylko Wujek Bob. Ja jestem tylko przetłumaczyłem Jego tekst.
      http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html

      Z tym, co napisałaś zgadzam się w całej rozciągłości.

      Usuń
  5. Cześć Michał,
    zacytowałem Ciebie odnośnie filmu na YT: https://tom.sapletta.com/pl/opinia-pl/to-be-or-not-to-be-czyli-wypalenie-zawodowe-w-it/
    , bo ciekawe rzeczy mówisz i cytujesz.

    Oczywiście nie zgadazam się z tymi tezami o przemijaniu...

    To co myślę nie ma znaczenia, bo wystarczy obserować rzeczywisty świat oparty o hardware.
    Hardware poszedł niesamowicie do przodu i niestety programiści są w tyle.
    Okazuje się, że od kilkunastu albo i ponad 20 lat używamy ten sam hardware, ale np w mobilnym wydaniu i nadal nie mamy dobrych, wydajnych rozwiązań software-owych.
    To pokazuje jak daleko w tyle jest Software-owa dziedzina.

    Samo zarządzanie dobiero rozkwita.
    Funkcjonalne programowanie istniało dziesiątki lat temu, OOP również nie jest nowe, ale to ludzie są problemem, dla ludzi sam compiler jest problemem, bo jest ścisły i określony, chociaż okazuje się, że są wyjątki i myśleć compilerem pythona można się nauczyć i wten sposób pisać lepiej i szybciej.

    pozdrawiam myślących, myślenie ma przyszłość ;)
    Tomasz


    OdpowiedzUsuń
  6. Tomku,

    Dzięki za to, że rozprzestrzeniasz dalej idee proponowane przez Wujka Boba. Idee oparte na wieloletnim doświadczeniu.


    Zgadzam się z Tobą, że mamy pod palcami i w kieszeniach ogromną potęgę obliczeniową i nie wykorzystujemy w pełni możliwości jakie daje nam sprzęt.

    OdpowiedzUsuń

Podstawy Programowania Funkcyjnego Epizod 3

Czy wszystkie Zasady Się Zmieniają? Kiedy tylko zaczynamy używać nowego paradygmatu , porównujemy z nim na...