Koniec żartów z Delphi - White House poleca

Biały Dom nie zaleca programować w językach "memory unsafe", za to poleca inne i na liscie bezpiecznych języków jest Pascal i Delphi!
https://www.tomshardware.com/software/security-software/white-house-urges-developers-to-avoid-c-and-c-use-memory-safe-programming-languages

W każdym języku da się napisać program memory safe i memory unsafe

Z ciekawostek natomiast
https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
używają wordpressa

to object Pascal nie ma ręcznego zarządzania pamięcią ? Macie już GC czy liczenie referencji?

Kristof napisał(a):

Biały Dom nie zaleca programować w językach "memory unsafe", za to poleca inne i na liscie bezpiecznych języków jest Pascal i Delphi!

Nie Biały Dom tylko NSA. Swoją drogą jak NSA coś poleca to wystarczające zalecenie by nie używać tego w systemach safety-critical

KamilAdam napisał(a):

to object Pascal nie ma ręcznego zarządzania pamięcią ? Macie już GC czy liczenie referencji?

pewnie chodzi o inne atrybuty. np. znalazłem taką opinię:
https://news.ycombinator.com/item?id=37845577

Delphi (and probably also Free Pascal?) is not wholly memory safe, but at least it has bounds checking for arrays and a sane string type, which is more than you get with C...

c++ też może mieć sprawdzanie indeksów, ale kto z tego korzysta?

Nie mamy i nie potrzebujemy, bo w odróżnieniu od bootcampoowców, którzy myślą że wszystkie rozumy zjedli i są lepsi, bo ich zdaniem ten czy tamtej język jest "cool" a inny "be" potrafimy programować. Mamy alokację pamięci (wywołując konstruktor) i potrafimy ją zwalniać gdy przestaje być potrzebna (za to odpowiada destruktor) i co że linię kodu trzeba więcej napisać i mieć święty spokój?. Nie potrzebne są pseudo automaty gdzie później często okazuje się, że użycie pamięci przez aplikację jest kilkakrotnie wyższe niż powinno być...

To tak samo jak w C++. Tym bardziej nie widzę gdzie jest wyższość Object Pascala nad C++. W C++ tez wystarczy umieć programować i nie ma wycieków pamięci. No cóż. Jak będę miał czas to muszę doczytać

Eh w c++ czy pascalu, a czym się różni delphi od pascala tym samym co C od C++?

Enyway garbage collector jak się zrobi w C to będzie bezpiecznie, C++ jest bezpieczniejszy bo jak się korzysta ze struktur danych dostępnych w standard library to do wycieków nie dojdzie i nigdy nie powinno się robić new czy delete, a bardziej bazować na make_shared czy strukturach dostępnych w std stanard library.

KamilAdam napisał(a):

Macie już GC czy liczenie referencji?

Licznik referencji to forma optymalizacji, nie zabezpieczenia przed wyciekami pamięci.

Współczesny obiektowy Pascal ma trochę wbudowanych i ukrytych mechanizmów, które faktycznie zajmują się inicjalizacją i finalizacją różnych elementów języka. Np. z góry wiadomo, że pola każdej klasy są zerowane tuż po utworzeniu instancji, że zmienne globalne są automatycznie zerowane, interfejsy są automatycznie zwalniane, C-stringi w formie typu PChar są automatycznie alokowane i niszczone w wielu przypadkach itd. Delphi może mieć też inne automaty, których nie wiem — w końcu Delphi nie używam.

Sprawdzanie zakresów i tego typu rzeczy są normą, ale głównie używane są do debugowania. Oczywiście nic nie stoi na przeszkodzie, aby użyć ich w release, ale to troszkę obniży wydajność (co jest logiczne, bo więcej kodu do wykonania).

KamilAdam napisał(a):

To tak samo jak w C++. Tym bardziej nie widzę gdzie jest wyższość Object Pascala nad C++.

Zawiłość i brzydota składni C++ jest tym, co stawia ten język niżej wszelkich Pascali.

Autysta napisał(a):

Eh w c++ czy pascalu, a czym się różni delphi od pascala tym samym co C od C++?

Delphi to odrębny dialekt obiektowego Pascala, inny niż np. Free Pascal.

Ja uważam, że ten raport jest bardziej przeciwko Linuxom, (a więc przede wszystkim programowaniu w czystym C), ponieważ najwięksi antagoniści USA, czyli kraje takie jak Chiny, Rosja i Iran, poprzez między innymi obustronnne sankcje, przyswoiły sobie na własne państwowe potrzeby właśnie systemy z pingwinem jako podstawa w bezpieczeńswie i administracji z jednoczesnym zakazem używania systemów i produktow Microsoftu.

davout napisał(a):

Ja uważam, że ten raport jest bardziej przeciwko Linuxom, (a więc przede wszystkim programowaniu w czystym C), ponieważ najwięksi antagoniści USA, czyli kraje takie jak Chiny, Rosja i Iran, poprzez między innymi obustronnne sankcje, przyswoiły sobie na własne państwowe potrzeby właśnie systemy z pingwinem jako podstawa w bezpieczeńswie i administracji z jednoczesnym zakazem używania systemów i produktow Microsoftu.

A myślisz, że w czym jest napisany Windows?

Poza tym już od jakiegoś czasu da się pisać moduły do kernela w Rust.

Żaden język nie zwalnia z myślenia. GC jest dobry i ułatwia jeśli wie co się robi. Niestety najczęściej właśnie juniorzy myślą, że GC ma szklaną kule oraz potrafi wszystko. No niestety nie potrafi. Największe i najbardziej spektakularne wycieki pamięci widziałem właśnie w C# gdy ktoś nie używał using oraz nie disposował obiektu, lub jak ładował na potęgę te same assembly doprowadzając proces do wielkości dziesiątek GB.

Z drugiej strony dobre praktyki lub ograniczenia konwencji potrafią zabezpieczyć program. Jakiś czas temu zapoznałem się z wymaganiami wojskowymi co do oprogramowania. Zasady odnosiły się do C i m.in. zakazane było dynamiczne alokowanie pamięci. Program miał zajmować w RAMie tyle miejsca ile maksymalnie musi do spełnienia wszystkich zadań i nie może tworzyć nowych obiektów w trakcie pracy, bo co by było jeśli w połowie wykonywania algorytmu nastawiania rakietnicy wysypie się proces z powodu braku pamięci?

Moim daniem ten tekst świadczy o małej wiedzy autora niż o bezpieczeństwie Delphi.

@roark.dev no to coś źle widziałeś. Jak nie użyjesz using to GC i tak za ciebie sfinalizuje obiekt, tylko będzie to nieco dłużej trwało.
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose#implement-the-dispose-pattern

No chyba że kod pisany był przez niezbyt ogarniętych deweloperów.

Wycieki pamięci w GC są jak najbardziej możliwe ale dotyczą one:

• Alokacji natywnych zasobów (a więc na własne życzenie wyłączamy sobie magię GC)
• Event handlerów, callbacków itp. które nie są odłączane we właściwym momencie, często skutkując akumulacją obiektów w pamięci (każdy handler ma zazwyczaj wskaźnik na klasę w które został zdefiniowany jeżeli używa jej pól)
• Statycznych pól typu cache które powoli akumulują dane.

Ostatnie 2 przypadki są banalnie proste do wykrycia, wystarczy wykonać heap dump załadować do profilera i sprawdzić class histogram (czyli liczbę instancji po typie).

@0xmarcin nigdzie nie napisałem, że to trudne do lokalizacji. Zazwyczaj jak wspomniałeś, dump oraz analiza RedGate Ants pozwala wykryć gdzie się naakumulowały obiekty. Co nie zmienia faktu, że to najbardziej spektakularne wycieki. W C++ dość, szybko pamięć zaczyna się mieszać i lecą AV, a w takim przypadku mamy dumpy pamięci po 50GB.

Zasoby niezarządzane są enkapsulowane przez obiekty CLR i jeśli nie zadba się o dispose czy przeciążenie destruktora to naraża się człowiek na wycieki. Natomiast nie jest błędem używanie takich zasobów - to normalna praktyka tylko trzeba wiedzieć co się robi o czym właśnie pisze.

Wyciekiem może być też ładowanie assembly do procesu i tutaj żaden GC na to nie pomoże bo CLR nie potrafi wyładować assembly z procesu tylko oznacza je jako nieaktualne.

GC dzieli obiektu na generacje i nie masz pewności, czy dany obiekt zostanie zwolniony zanim aplikacja się nie zamknie (wtedy cały proces jest sprzątany). Jedynym założeniem słusznym jest założenie, że nie wiadomo czy GC obsłuży obiekt bez referencji czy nie. W Javie można chyba wpływać na strategie GC, ale w przypadku C# programista nie ma żadnej kontroli, ale sposobów na przewidzenie czegokolwiek.

Jeśli dla kogoś krytyczne jest zarządzanie pamięci to języki z GC są złym rozwiązaniem, przy czym wielu, wielu programistom, w tym kilku z userów tego forum, jedynie wydaje się, że w ich projektach zarządzanie pamięcią jest kluczowe i wymyślają sobie bajki nie podparte żadnymi badaniami i wmawiają sobie, że ich honorem jest walka o każdy bajt w każdym cyklu procesora - "premature optimization is the root of all evil" a to już nie czasy spektrusiów gdzie człowiek miał 4KB RAM i wykonywał program w przerwach na generowanie obrazu przez CPU.

Ba! Co więcej - może okazać się, że nawet jeśli aplikacja ma wyciek to taniej jest przez całe życie tej aplikacji zaplanować cykliczne restarty niż, faktycznie znaleźć dany wyciek. Znam takie historie, gdzie poszukiwanie kosztowało X, po czym zastosowano wspominaną strategie która kosztowała 5% tego X, aż w końcu zakończyło się życie tego oprogramowania... niemniej pewnie trudno niektórym uwierzyć, że workaround może być odpowiednim docelowym rozwiązaniem lepszym niż zlikwidowanie przyczyny problemu.

Ostatecznie chcę zwrócić uwagę, że żaden GC nie zwalnia z używania mózgu oraz wiedzy co się robi, i posiadanie GC magicznie nie zabezpiecza programu.

Narzekanie na to, że język nie jest dobry, bo nie ma GC, jest spowodowane wyłącznie przez skill-issue. Ten można rozbić na dwa scenariusze, z czego co najmniej jeden ma miejsce, jeśli wycieki się pojawiają i są uciążliwe:

1. Programista jest niedbały i w trakcie pisania kodu alokacji, w dupie ma dealokację.
2. Programista nie zna i/lub nie potrafi używać narzędzi do monitorowania i zgłaszania wycieków.

W 99% przypadków, bez żadnego problemu można od razu określić miejsce, w którym dane należy zwolnić z pamięci. Rzadko kiedy puszcza się np. wskaźniki czy referencje z jednej funkcji, a następnie zwalnia w zupełnie innej (np. w callbacku). Tak więc jeśli programista myśli co robi, nie ma powodu, aby musiał później walczyć z wyciekami. A nawet jeśli dane trzeba dealokować gdzieś indziej, to jest to deterministyczne, a nawet dokładnie opisane w dokumentacji. Alokacje nie pojawiają się z d**y, więc nie istnieje przypadek, w którym nie wiadomo w którym miejscu i momencie te dane zwolnić.

Druga sprawa to narzędzia do szukania wycieków. Mamy 2024 rok, każde normalne IDE ma narzędzia do monitorowania dynamicznie alokowanych bloków danych. Jeśli coś wycieknie, do dostajemy raport o tym, czego nie zwolniliśmy. Jeśli ktoś nie potrafi z takich narzędzi korzystać i/lub olewa pamięć, to technologia nie jest niczemu winna.

Po trzecie, wycieki pamięci nie są poważnym problem — ich niesamowita waga i znaczenie to mit. Nawet jeśli proces pogubi bloki pamięci, to nie będzie miało to niemal żadnego znaczenia, więc nie ma powodu, aby z każdym istniejącym wyciekiem robić w spodnie. Wycieki są poważnym problemem tylko wtedy, gdy bloki ciekną często i w dużych ilościach (a więc pamięć rezerwowana przez proces bardzo szybko puchnie), a także w systemach krytycznych, w których każdy wyciek przybliża proces do katastrofy (np. oprogramowanie samolotu, teleskopu, urządzeń podtrzymywania życia itd.) oraz tych, których sesja trwa miesiącami/latami i nawet powolna kumulacja wycieków w końcu doprowadzi do crashu i poważnych strat. W typowym programie, którego sesja trwa najwyżej kilka godzin, i któremu cieknie co najwyżej kilka(dziesiąt) bajtów, nie ma powodu do żadnej paniki, ani też natychmiastowego podejmowania działań w celu załatania wycieków.

Dodam coś od siebie, bo od długiego czasu pracuję nad projektem, który tworzę niskopoziomowo i w którym wszędzie walają się wskaźniki, każdy blok pamięci jest ręcznie alokowany i dealokowany — niby Pascal, a jednak zdecydowanie bliżej mu do C.

Wycieki pamięci nie są absolutnie żadnym powodem do zmartwień. Stosując zasadę „piszę alokację, więc od razu piszę i dealokację”, przez ostatnie dwa lata nie spędziłem łącznie nawet 10 minut na łatanie wycieków. One się pojawiały, ale HeapTrc, mimo iż prymitywny, elegancko wskazuje każdy niezwolniony blok, razem z takimi danymi jak jego adres, rozmiar, a także miejsce alokacji w kodzie projektu (nazwa modułu i numer linii). Nawet tak proste narzędzie pozwala w 5 sekund namierzyć problem i go naprawić.

Z dynamicznie alokowaną pamięcią i jej zwalnianiem jest jak z robieniem ”dwójki” — nie zapomnij zdjąć spodni przed robotą (zaalokować pamięci), ani też nie zapomnij wytrzeć tyłka po robocie (zwolnić pamięć). Jeśli zapomnisz choćby jedno to pobrudzisz majtki i to będzie wyłącznie twoja wina.

Przy mikroserwisach + pipeline'ach przetwarzających 10tki GB danych na sekundę, wyciek pamięci często objawi się już po 10 min (95% heap), on-call dostanie po kolejnych 5 min alert i po kolejnych 5 min k8s ubije kontener i postawi nowy. Tak to mniej więcej wyglądało w firmach w których pracowałem. To był dość poważny problem, choć by ze względu na on-call noise.

Nikt o zdrowych zmysłach nie narzeka dziś na ABS w samochodzie czy wspomaganie kierownicy. Zarzuty o GC są zupełnie nie uzasadnione. Im mniej low-level konceptów muszę mieć w głowie w trakcie programowania tym lepiej. To czyni mnie bardziej produktywnym programistą.

Te kawałki kodu które wymagają troski zawsze można przepisać w C++ lub C, a 99% aplikacji pozostawić w Java/C#/Python. Te dwa światu nie muszą ze sobą walczyć (GC vs ref counting vs manual).

@furious programming zgadzam się niemal ze wszystkim co mówisz. Wybacz, ale widać, że nie jesteś komercyjnym programistą, ani nawet nie pracujesz w zespole. To szukanie wycieków to często jest tak, że jesteś jak przedszkolanka, do której dzwoni koleżanka z innego przedszkola i mówi:

• Śmierdzi u nas gównem. Pomóż nam, bo jesteś dobra z likwidacji gówna.

Jedziesz tam i okazuje się, że śmierdzi gównem w całym budynku. Jeden dzieciak poszedł z przedszkolanką do WC, zrobił dwójkę, ta nie wytarła mu tyłka i założyła mu spodnie i puściła dalej. Potem nie dostała banana z okazji owocowego czwartku i sie zwolniła i nie odbiera telefonu. Obsrany dzieciak zaczął biegać po całym przedszkolu i wszędzie już śmierdzi. Ty biegasz i robisz inspekcje każdego tyłka, ale dzieci się przemieszają i z każdym cyklem są gdzie indziej. Co więcej okazuje się, że dzieciaki mogą nawet sobie nawzajem srać do gaci jak nikt nie patrzy (multi threading).

Jeśli wycieki miały by się ograniczyć do kodu jaki sam napisałeś to nie było by problemu. W praktyce szukasz wycieku, który zrobił ktoś inny nierzadko kilkadziesiąt lat temu, ale po ostatnich modyfikacjach problem zaczął eskalować.

0xmarcin napisał(a):

Przy mikroserwisach + pipeline'ach przetwarzających 10tki GB danych na sekundę, wyciek pamięci często objawi się już po 10 min (95% heap), on-call dostanie po kolejnych 5 min alert i po kolejnych 5 min k8s ubije kontener i postawi nowy. Tak to mniej więcej wyglądało w firmach w których pracowałem. To był dość poważny problem, choć by ze względu na on-call noise.

Nikt o zdrowych zmysłach nie narzeka dziś na ABS w samochodzie czy wspomaganie kierownicy. Zarzuty o GC są zupełnie nie uzasadnione. Im mniej low-level konceptów muszę mieć w głowie w trakcie programowania tym lepiej. To czyni mnie bardziej produktywnym programistą.

Te kawałki kodu które wymagają troski zawsze można przepisać w C++ lub C, a 99% aplikacji pozostawić w Java/C#/Python. Te dwa światu nie muszą ze sobą walczyć (GC vs ref counting vs manual).

Raczej nikt nie zarzuca nic GC. Bardziej zauważamy, że GC to nie złote remedium i trzeba zachować trzeźwość umysłu. Owszem uważam, że ABS jest dobrym zabezpieczeniem, ale nie uchroni cię od wypadku jak stracisz przyczepność nie na skutek zablokowania kół, a na skutek oblodzenia i złych opon. Czasem też zadziała negatywnie - np. podczas awaryjnego hamowania na dziurach i wertepach - ABS wykryje to jako zablokowanie koła i odłączy hamulec.

Mając ABS możesz tak samo skończyć na drzewie jak mając GC zapełnić cały ram.

roark.dev napisał(a):

Jeśli wycieki miały by się ograniczyć do kodu jaki sam napisałeś to nie było by problemu. W praktyce szukasz wycieku, który zrobił ktoś inny nierzadko kilkadziesiąt lat temu, ale po ostatnich modyfikacjach problem zaczął eskalować.

Nie ma znaczenia to kto napisał kod powodujący wycieki, ani czy pracuje się w zespole czy solo. Skoro wyciek istnieje, wiesz o nim, masz o nim informacje, to albo sam go łatasz, albo przekazujesz informacje tym, którzy znają tę część kodu (lub utrzymują zewnętrzną bibliotekę) i są w stanie to naprawić. Tłumaczenie się zespołem i korpo-bagnem to umywanie rąk i zwalanie winy na innych, aby uniknąć odpowiedzialności za niską jakość.

roark.dev napisał(a):

Wybacz, ale widać, że nie jesteś komercyjnym programistą, ani nawet nie pracujesz w zespole.

Owszem, rzeźbię solo i się to nie zmieni. Dzięki temu jestem odpowiedzialny za wszystko co robię, zamiast szukać powodu, aby tę odpowiedzialność zwalić na kogoś innego, i umyć rączki, tak jak to korpo-szczurki zwykły robić.

Jeśli mam problemy z cudzym kodem, to te problemy zgłaszam i dbam o to, aby zostały naprawione — przyda się to i mnie, i innym. I jednym z takich problemów były wycieki w SDL-u, związane z obsługą zdarzeń dotyczących wprowadzania tekstu. Wycieki zostały namierzone przez użytkowników SDL-a, nie przez deweloperów tej biblioteki. Norma — chcesz mieć godne warunki pracy i tworzyć jakość, to o nią zadbaj, zamiast listować wymówki.

To jak, udało się już ustalić, że GC jest przydatny w 70-80% komercyjnych problemów a do reszty przypadków używa się C/czegoś innego, albo do tych ultra wyjątkowych to nawet C++?

Programiści Delphi, pracujący nad rozwiązaniami komercyjnymi, rozwiązują 100% problemów bez GC, bo język go nie zapewnia. GC jest potrzebny tym, którzy nie potrafią programować i potrzebują wymówek, aby móc spojrzeć w lustro.

furious programming napisał(a):

Programiści Delphi, pracujący nad rozwiązaniami komercyjnymi, rozwiązują 100% problemów bez GC, bo język go nie zapewnia. GC jest potrzebny tym, którzy nie potrafią programować i potrzebują wymówek, aby móc spojrzeć w lustro.

Rozumiem, że podobną pogardą obdarzasz ludzi jeżdżących automatami, lub o zgrozo elektrykami, które same parkują i wyjeżdżają z garażu ;)? Chyba zbyt wielką wagę przywiązujesz do używanych narzędzi.

O ile automatyczna skrzynia nie zwalnia z myślenia - np. co zrobić podczas wyprzedzania tak samo GC nie zwalnia, z myślenia o pamięci. Niemniej jednocześnie szaleńcze machanie lewarkiem biegów, nie przynosi żadnego splendoru podobnie jak benedyktyńskie pilnowanie par kreacji i destrukcji obiektów. Owszem można się umartwiać, niektóre religie i systemy filozoficzne uważają, że to uszlachetnia, a inne twierdzą że raczej powinniśmy dążyć do wyzwolenia się od cierpienia (Budduś i spółka).

Są natomiast przypadki gdzie zarówno ręczne zarządzanie pamięcią, jak i manualna skrzynia się przydają. Nie rozumiem tylko dlaczego ktoś na siłę próbuje udowodnić, uniwersalność jednego lub drugiego rozwiązania, kiedy są one komplementarne i na równi dobre dla zastosowań do jakich zostały stworzone.

Zresztą w tego typu dyskusji zostało powiedziane już wszystko przez dziesiątki lat, a jeśli ktoś ma kilka lat doświadczenia w enterprise sam to i tak odkrywa, dlatego dalsza dyskusja nie ma sensu i w zasadzie niepotrzebnie w niej wziąłem udział.

roark.dev napisał(a):

Rozumiem, że podobną pogardą obdarzasz ludzi jeżdżących automatami […]

Stwierdzenie, że ktoś czegoś nie potrafi robić dobrze to nie akt pogardy, a stwierdzenie faktu.

Tworzysz wycieki pamięci, to znaczy, że albo nie potrafisz programować jak należy, albo robisz to niedbale. Idąc w twoją analogię, jeśli obijasz się samochodem i ciągle łapiesz mandaty, to albo nie potrafisz jeździć, albo robisz to niedbale. Brutalne, ale prawdziwe i żadnymi wytłumaczeniami rzeczywistości nie zmienisz — stało się źle, więc bierz za to odpowiedzialność. Jeśli siadasz za kółko w aucie z manualną skrzynią, to używasz sprzęgła podczas zmiany biegu, czy zażynasz skrzynię zmieniając biegi bez sprzęgła i zwalasz winę na brak automatu? Ciekawe jak by świat wyglądał, gdyby specjaliści z innych profesji tak samo głupkowato tłumaczyli swoją niekompetencję, jak programiści.

Istnieje niezliczona ilość operacji, które należy poprzedzić inicjalizacją i zakończyć finalizacją, i do których nie ma automatów, w żadnym języku programowania, bo jest to kwestia logiki, nie języka. Jeśli nie potrafisz zaalokować pamięci, a po jej użyciu zwolnić, to i nie będziesz potrafił zrobić porządnie absolutnie niczego, co inicjalizacji i finalizacji wymaga — w żadnym języku programowania.

Dobry specjalista poradzi sobie z każdą technologią, bez względu na to ile ona robi za niego. Ma język z GC, to ma mniej roboty; nie ma GC, to sam zarządza pamięcią i nie widzi w tym żadnego problemu. To samo jeśli chodzi o typowanie — nie ważne czy słabe, silne czy kacze, poradzi sobie z każdym, a jeśli coś zrobi źle, to skorzysta z narzędzi jakie ma pod ręką, znajdzie problem i go naprawi. Reszta natomiast będzie się tłumaczyć i zwalać winę na wszystko inne, tylko nie na własną niekompetencję i/lub niedbałość.

Chcesz zobaczyć pogardę to zaglądnij choćby do kategorii Kariera.

Twoja analogia jest błędna. Nie każdy, kto jeździ automatem obija inne samochody... Co więcej pewnie większość ludzi co jeździ automatami, potrafi jeździć manualem, ale po prostu wygodniej jest nie martwić się o biegi i operować jednym pedałem.

Uważam, że odnosisz się z pogardą, bo arbitralnie(i za razem bezpodstawnie) zakładasz, że każdy kto potrzebuje GC nie potrafi programować, oraz zakładasz rzekome poczucie winy i potrzebną wymówkę, by nie stracić twarzy przed samym sobą. De facto deprecjonujesz każdego kto potrzebuje GC, jakoby nie potrafił programować.

Ja potrzebuję GC do 90% pisanego przeze mnie kodu bo szanuje swój czas i mam ciekawsze rzeczy do roboty niż zajmowanie się zarządzaniem pamięcią w w takim zakresie jaki może za mnie zrobić GC, który jest głupszy ode mnie. Jest to moja świadoma decyzja scedowania pewnego odtwarzalnego procesu na maszynę. Są dużo ważniejsze i bardziej krytyczne aspekty tworzenia systemów, gdzie faktycznie potrzebny jest ludzki umysł i doświadczenie niż alokowanie i zwalnianie pamięci do której program nie ma już dostępu (bo stracił referencje) i każdy dobry specjalista szanujący swój czas o tym wie, chyba, że jest się specjalistą ds. zarządzania pamięcią procesu.

Uważasz, że dobry specjalista radzi sobie z każdą technologią - zgodzę się po części jedynie. Jeśli, zostanie wrzucony do projekty legacy z lat 80/90 napisanego w C++ czy Delphi - pełna zgoda, powinien potrafić pisać bez wycieków kolejne funkcjonalności, czy usuwać bugi w projekcie. Natomiast, jeśli wybiera on technologię dla nowego projektu - np. rozproszonego systemu wspierającego biznes, jakiś fintech etc. gdzie sama komunikacja stanowi 90% lattency, to wybór języka bez GC i do tego mało popularnego świadczy o fanatyzmie i właśnie braku wyobraźni i doświadczenia.

Natomiast ocenianie kogoś na nieposiadającego kompetencji bo doprowadził do jakiegoś bug'a czy wycieku jest absurdem. Moim zdaniem świadczy to co najmniej o braku doświadczenia w tworzeniu i utrzymywaniu realnych systemów. Po pierwsze systemy są dużo bardziej skomplikowane niż największe fabryki. Wyobraź sobie procesy, pętle, komunikacje z typowego programu jako fabrykę z wieloma trybami, taśmami i manipulatorami. Patrząc na poziom skąplikowania wcale nie dziwne, jest, że czasem ktoś coś przeoczy. Co więcej wytwarzanie oprogramowanie poza pewnymi wynaturzonymi przypadkami nie jest pracą samodzielną, jakiegoś szalonego naukowca. Tworzenie oprogramowania to praca zespołowa, począwszy od analityka, poprzez architekta, sztab programistów, testerów, integratorów skończywszy na nieprzekraczalnych terminal oraz zmiennych wymaganiom klienta. W takim środowisku naturalną rzeczą jest bug. Co więcej ten proces na samym końcu ma generować $$, a czasem taniej jest wypuścić system z bugiem i go naprawić, niż wypuszczać dopiero jak nie ma zupełnie błędów* ale za to z releasem raz na kilka lat.

*Jest to sytuacja jedynie hipotetyczna. W mojej filozofii nie ma systemu bez błędów, a także czasem trudno określić gdzie są granice definiowania błędu.

roark.dev napisał(a):

Twoja analogia jest błędna. Nie każdy, kto jeździ automatem obija inne samochody...

A w którym miejscu napisałem, że tak jest?

Uważam, że odnosisz się z pogardą, bo arbitralnie(i za razem bezpodstawnie) zakładasz, że każdy kto potrzebuje GC nie potrafi programować […] De facto deprecjonujesz każdego kto potrzebuje GC, jakoby nie potrafił programować.

Jeśli potrzebujesz sprzątaczki, to znaczy, że nie potrafisz samodzielnie zarządzać pamięcią i będzie generował wycieki — to fakt, nie opinia. Ktoś, kto potrafi programować, poradzi sobie zarówno z GC, jak i bez niego.

Uważasz, że dobry specjalista radzi sobie z każdą technologią - zgodzę się po części jedynie. Jeśli, zostanie wrzucony do projekty legacy z lat 80/90 napisanego w C++ czy Delphi - pełna zgoda, powinien potrafić pisać bez wycieków kolejne funkcjonalności, czy usuwać bugi w projekcie. Natomiast, jeśli wybiera on technologię dla nowego projektu - np. rozproszonego systemu wspierającego biznes, jakiś fintech etc. gdzie sama komunikacja stanowi 90% lattency, to wybór języka bez GC i do tego mało popularnego świadczy o fanatyzmie i właśnie braku wyobraźni i doświadczenia.

No i gdzie widzisz problem? Ja nie widzę tutaj żadnego. Wybierasz technologię z GC, bo przyspiesza twoją pracę.

Moje komentarze odnoszą się do sytuacji, w której ktoś narzeka na to, że Delphi nie ma GC i nie potrafi tej technologii używać w taki sposób, aby nie było wycieków, a nie do sytuacji, w której ktoś używa języka z GC i innymi automatami, bo chce przyspieszyć swoją pracę i mieć mniej na głowie. Jest gigantyczna różnica pomiędzy używaniem GC z wyboru, a z przymusu, aby software nie spadł z rowerka.

Natomiast ocenianie kogoś na nieposiadającego kompetencji bo doprowadził do jakiegoś bug'a czy wycieku jest absurdem.

Ach tak, powinienem go pogłaskać po głowie i dać podwyżkę — najwyraźniej w obecnym, poprawnym politycznie świecie śnieżynek i unikania odpowiedzialności za wszystko, niekompetencję należy nagradzać. To jest dopiero absurd.

Bugi to błędy, wycieki to błędy — im mniej błędów, tym kompetencje wyższe. A kompetencje to nie tylko zdolność do klepania kodu, ale też dbałość o środowisko pracy i o skuteczność w działaniu. Jeśli bugi istnieją, ale nie ma czasu ich naprawić, to cóż — nie ma czasu. Natomiast jeśli wycieki są, jest czas je naprawić, ale nijak nie potrafi się tego zrobić, to wychodzi na jaw skill-issue.

furious programming napisał(a):

Jeśli potrzebujesz sprzątaczki, to znaczy, że nie potrafisz samodzielnie zarządzać pamięcią i będzie generował wycieki — to fakt, nie opinia. Ktoś, kto potrafi programować, poradzi sobie zarówno z GC, jak i bez niego.

Ja uważam, że potrzebuję do życia zarówno sprzątaczki, jak i ogrodnika oraz "konserwatora", co nie znaczy, że sam nie potrafię sprzątać, czy przycinać drzewek.

Jest gigantyczna różnica pomiędzy używaniem GC z wyboru, a z przymusu, aby software nie spadł z rowerka.

Dla mnie tutaj znów przebija brak doświadczenia w pracy z zespołem. Cały czas piszesz z perspektywy "Ja". Pomyśl, że czasem architekt wybiera technologię, nie z powodu, że on potrafi czy nie potrafi - ale, zdaje sobie sprawę, że będzie dany system utrzymywało kilkudziesięciu lub kilkuset programistów o różnym poziomie. Jeśli powiesz, że w takim razie trzeba zatrudniać tylko kompetentne osoby to odpowiem na to tylko pobłażliwym uśmiechem pod nosem i będę scrollował dalej.

Natomiast ocenianie kogoś na nieposiadającego kompetencji bo doprowadził do jakiegoś bug'a czy wycieku jest absurdem.

Ach tak, powinienem go pogłaskać po głowie i dać podwyżkę — najwyraźniej w obecnym, poprawnym politycznie świecie śnieżynek i unikania odpowiedzialności za wszystko, niekompetencję należy nagradzać. To jest dopiero absurd.

Jestem jak najdalej od poprawności politycznej. Po prostu uważam, że Twoja definicja kompetentnej osoby nie istnieje w rzeczywistości.

Moje komentarze odnoszą się do sytuacji, w której ktoś narzeka na to, że Delphi nie ma GC i nie potrafi tej technologii używać w taki sposób, aby nie było wycieków, a nie do sytuacji, w której ktoś używa języka z GC i innymi automatami, bo chce przyspieszyć swoją pracę i mieć mniej na głowie.

Tu się zgadzam. Świadomy wybór to podstawa, a narzekanie na brak GC w Delphi jest słuszne, jeśli nie miało się wyboru i zostało się wrzuconym do projektu Delphi i teraz trzeba martwić się o pamięć co może być żmudne i w wielu przypadkach wydawać się niepotrzebne. W innym przypadku jeśli ktoś narzeka na brak GC i wybrał Delphi, to podstawowym błędem był wybór Delphi do tego zadania.

roark.dev napisał(a):

Ja uważam, że potrzebuję do życia zarówno sprzątaczki, jak i ogrodnika oraz "konserwatora", co nie znaczy, że sam nie potrafię sprzątać, czy przycinać drzewek.

Czyli w sumie nie potrzebujesz.

Źle zrobiłem, że użyłem słowa potrzebować, bo jest mało precyzyjne — powinienem użyć słowa wymagać. Potrzebować (GC) można z różnego powodu, a wymagać tylko z braku możliwości obejścia się bez niego.

Dla mnie tutaj znów przebija brak doświadczenia w pracy z zespołem. Cały czas piszesz z perspektywy "Ja". Pomyśl, że czasem architekt wybiera technologię, nie z powodu, że on potrafi czy nie potrafi - ale, zdaje sobie sprawę, że będzie dany system utrzymywało kilkudziesięciu lub kilkuset programistów o różnym poziomie. Jeśli powiesz, że w takim razie trzeba zatrudniać tylko kompetentne osoby to odpowiem na to tylko pobłażliwym uśmiechem pod nosem i będę scrollował dalej.

Jeśli firma zatrudnia osoby niekompetentne (np. juniorów), nie robi review ich kodu i pozwala aby ich niskiej jakości kod trafiał na produkcję i obniżał jakość całego projektu, to odpowiem na to tylko pobłażliwym uśmiechem pod nosem i będę scrollował dalej.

furious programming napisał(a):

roark.dev napisał(a):

Ja uważam, że potrzebuję do życia zarówno sprzątaczki, jak i ogrodnika oraz "konserwatora", co nie znaczy, że sam nie potrafię sprzątać, czy przycinać drzewek.

Czyli w sumie nie potrzebujesz.

Źle zrobiłem, że użyłem słowa potrzebować, bo jest mało precyzyjne — powinienem użyć słowa wymagać. Potrzebować (GC) można z różnego powodu, a wymagać tylko z braku możliwości obejścia się bez niego.

Być może faktycznie jest tutaj problem językowy. Potrzebuję GC, jako, że GC spełnia moje potrzeby. Wymagać jest lepszym słowem, ale chyba najbardziej jasnym było by, że "GC jest dla kogoś niezbędny". Tak, to się zgodzę, jeśli dla kogoś GC jest niezbędny to może oznaczać, że nie potrafi programować w danej technologii.

Dla mnie tutaj znów przebija brak doświadczenia w pracy z zespołem. Cały czas piszesz z perspektywy "Ja". Pomyśl, że czasem architekt wybiera technologię, nie z powodu, że on potrafi czy nie potrafi - ale, zdaje sobie sprawę, że będzie dany system utrzymywało kilkudziesięciu lub kilkuset programistów o różnym poziomie. Jeśli powiesz, że w takim razie trzeba zatrudniać tylko kompetentne osoby to odpowiem na to tylko pobłażliwym uśmiechem pod nosem i będę scrollował dalej.

Jeśli firma zatrudnia osoby niekompetentne (np. juniorów), nie robi review ich kodu i pozwala aby ich niskiej jakości kod trafiał na produkcję i obniżał jakość całego projektu, to odpowiem na to tylko pobłażliwym uśmiechem pod nosem i będę scrollował dalej.

Tu chodzi o kwestię zarządzania ryzykiem. Code review czy QA są działaniami mającymi obniżyć ryzyko wystąpienia błędu na produkcji. Równie dobrym środkiem jest, wybranie technologii z GC do nowego projektu. Przy czym wybranie innej technologii do projektu legacy nawet z GC może zwiększyć ryzyko - zarówno błędów bo przepisania/przeportowania wiąże się z ryzykiem błędów, jak i nie dotrzymanie terminu projektu. Wybór odpowiedniej technologii czy QA lub pisanie UT, są to komplementarne, równe sobie działania mające zapewnić jakość oraz zmniejszyć ryzyko błędów na produkcji,

roark.dev napisał(a):

Tu chodzi o kwestię zarządzania ryzykiem. Code review czy QA są działaniami mającymi obniżyć ryzyko wystąpienia błędu na produkcji. Równie dobrym środkiem jest, wybranie technologii z GC do nowego projektu.

Wybranie technologii z GC pozwoli wykluczyć wycieki pamięci, natomiast nie rozwiąże problemu niskiej jakości.

Sam zauważyłeś, że projekt może być rozwijany (i większość będzie) również przez osoby niedoświadczone i niekompetentne, więc aby ich praca nie dewastowała produkcji, musi podlegać kontroli. Tego problemu nie rozwiąże żaden automat, ale rozwiąże solidne review lub opiekun, bo to jedyna i ostatnia zapora przed wepchnięciem niskiej jakości rozwiązań na produkcję.

furious programming napisał(a):

roark.dev napisał(a):

Tu chodzi o kwestię zarządzania ryzykiem. Code review czy QA są działaniami mającymi obniżyć ryzyko wystąpienia błędu na produkcji. Równie dobrym środkiem jest, wybranie technologii z GC do nowego projektu.

Nie do końca — wybranie technologii z GC pozwoli wykluczyć wycieki pamięci, natomiast nie rozwiąże problemu niskiej jakości kodu.

Sam zauważyłeś, że projekt może być (i większość będzie) rozwijany również przez osoby niedoświadczone i niekompetentne, więc aby ich praca nie dewastowała produkcji, musi podlegać kontroli. Tego problemu nie rozwiąże żaden automat, ale rozwiąże solidne review lub opiekun, bo to jedyna i ostatnia zapora przed wepchnięciem niskiej jakości rozwiązań na produkcję.

Dlatego napisałem, że te środki są względem siebie komplementarne a nie redundantne.

furious programming napisał(a):

Programiści Delphi, pracujący nad rozwiązaniami komercyjnymi, rozwiązują 100% problemów bez GC, bo język go nie zapewnia. GC jest potrzebny tym, którzy nie potrafią programować i potrzebują wymówek, aby móc spojrzeć w lustro.

Lol stary, GC to jest ułatwienie które pozwala oszczędzić czas nie tylko przy wyciekach pamięci ale też eliminuje zbędny kod przy czyszczeniu zasobów, co za tym idzie szybszy maintance i wdróżenie na produkcje. Nie no, to tak jakby programista Asembler powiedział że Javy, Cplusplusy sa dla tych co nie umieja programować, bo prawdziwe programowanie to tylko niskopoziomowe.

Nie no dobra, nie to samo... ten od Asemblera brzmi sensowniej niż ten od Delphi