Przypominam prezentację, która kiedyś zrobiła na nas duże wrażenie.
Oglądając z perspektywy 16 lat:
- Koncepty weszły do standardu C++. To akurat nic dziwnego, Adobe ma ludzi w komitecie ISO.
Łatwiej jest w ten sposób spopularyzować jakiś nowy trend w programowaniu.
W praktyce nie zawsze wsparcie jest w toolchainie projektowym i przypadki użycia są raczej sporadyczne. - W porównaniu z 2007 nastąpiła migracja w kierunku deklaratywnego tworzenia interfejsów.
Przynajmniej QML i Slint faktycznie są oparte na zbliżonych założeniach.
Jakoś nie czuję tego w przypadku np. Reacta, ale nie znam się na współczesnych frontendach JS. - Rozwój oprogramowania oparty na “aproksymacji” jest wszechobecny i powiedziałbym, że coraz częstszy.
Sam napotkałem sytuacje, gdzie bardzo “defensywnie” napisany kod, obsługujący wiele przypadków brzegowych, był odrzucany podczas przeglądu i zastępowany czymś znacznie lżejszym (i niedziałającym w scenariuszach, których nie potrafiłem wykluczyć ani ja, ani reviewer).
Osobiście nie rozumiem takiego podejścia i się z nim nie zgadzam, ale tak działają firmy. - Wielu programistów wyspecjalizowało się w rozwiązywaniu zadań z LeetCode, bo zmusił ich do tego współczesny (całkiem absurdalny zresztą) proces rekrutacji.
Podejrzewam, że tacy kandydaci przeszukiwanie binarne mogliby napisać z zamkniętymi oczami.
Z tego co widziałem to współczesne frameworki js opierają się na śledzeniu zmiennych w modelach i reakcji na to. Html/css jest już deklaratywny. Problemem był tylko model. To się zmieniło. Teraz dodali jeszcze jakąś izolację i szablonowanie części drzewa DOM.
Frameworki przyszłości starają się przenieść najczęściej używane wzorce do znaczników HTML.
Deklaratywne tworzenie interfejsu to także Swift UI. Przełomem było tu raczej oglądanie na żywo zmian w kodzie. I to, że deklaratywny kod UI stał się tym samym językiem co logika. Oczywiście wymaga to odpowiednio ekspresywnego języka.
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Na wschodzie często zamiast rekrutacji jest intensywne szkolenie. Ale za to wymogi formalne są wtedy wysokie. Osobiście wolę śledzić kogoś karierę i działanie i zaproponować mu posadę. Ale w oczach innych to strata czasu.
Czytałem i oglądałem dużo o nowych rozwiązaniach w C++. Osobiście nie stosowałem. Więc nie mam zbyt wiele na ten temat do powiedzenia. Bo to co pokazano nie robiło zbyt dużego wrażenia. Większe wrażenie robiło na mnie starodawne tworzenie typów dla każdej “jednostki fizycznej” i interakcje między nimi za pomocą operatorów.
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Takie podejście jest poprawne na etapie tworzenia software’u.
Jako developer chcę zobaczyć jak najszybciej wynik, bo łatwiej wtedy znaleźć i poprawić błędy.Ja mam na myśli przypadki, w której produkcyjna wersja ma wyciętą obsługę pewnych stanów, bo “taka sytuacja nie powinna wystąpić w praktyce”.
Clownstrike też nie powinien wystąpić w praktyce.
Pamiętam jak dziadek z Microsoftu opowiadał historię o debugowaniu stosu USB w Windows.
Mieli jakiś wózek z różnymi urządzeniami podpiętymi do huba i podłączali go losowo do komputera pracowników. W pierwszych wersjach często kończyło się to BSODem i poprawianiem sterownika.
Na tym polega dbałość o szczegóły i jakość software’u. Nieważne, że w praktyce klient prawdopodobnie nie ma 64 urządzeń podłączonych do portu USB.Pamiętam tę historię. Nie widzę tu dbałości o szczegóły. Raczej widzę, że wózek z donglami był przybliżeniem działania. Dbałość bym widział gdyby kod działał. Coś jak opowieść pana od portowania NT na x86-64. Kiedy zanieśli płytę do AMD i wszystko zadziałało na realnym sprzęcie.
Przypomniałeś mi, że podobny problem z USB stał się exploitem pewnej konsoli.
Ale przynajmniej mieli świadomość, że problem z USB istnieje i podjęli jakieś działania, zamiast zamiatać go pod dywan.
Istniały inne problemy o których nie mówili. Potem i tak przepisali ten stos na jakiś inny język.
Masz rację. To więcej niż firmy które wcale nie robią realnych testów albo nawet nie robią prototypu i badań.
- Koncepty weszły do standardu C++. To akurat nic dziwnego, Adobe ma ludzi w komitecie ISO.
