On 18/11/2021 18:28, Mateusz Viste wrote:
>> Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się
>> błedu w kodzie.
> Nie, nie dostałem. :)
> Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.

Zmniejszyłem je. Z wielu miejsc usunąłem. Na tym polega proces
eliminacji białka.

>>> W konkursie wystartowała natomiast kategoria nowa: "zapomniałem
>>> ustawić scope guard na włączenie przerwań".
>> Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.
> Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.

Branża języków programowania dyskutuje własnie o tym, kiedy mowa o
językach programowania. Szkoda, mogli by rozmawiać o dupach.

>> Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa
>> kodu. Są miejsca, gdzie takie gówno oparte o goto wyleciało by z
>> hukiem na review razem z autorem tego szamba.
> Bo ty tak mówisz?

Tak, z mojej grupy byś wyleciał, dodatkowo z solidym kopniakiem za
niepojmowanie podstaw bezpieczeństwa.

>> Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach
>> miganai diodą nie ma problemu i stąd ten problem z rozumieniem tej
>> wyższości.
> Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu
> przypadkach scope nie powinien być tak rozległy, że autor przestaje nad
> nim panować.

Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".

>> To jeszcze jeden:
>> UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;
>> Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
>> flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7
>> to jest poważny problem.
>> Mogę ten kod napisać sprytnie.
> O, czyli może jednak będzie konstruktywnie.

Już było, tylko jesteś niepełnosprytny.

> No to dajesz.

A ile płacisz?

do góry

On 18.11.2021 18:12, heby wrote:
> [...]
> Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
> review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
> grupach 60+ to może być coding standard.
>

Nie to, żebym się obruszył o 60+ ...

Ale przecież styl projektowania/programowania nie zależy od wieku
autora. Tylko raczej od tego czy gość trafił do zawodu w wyniku
ostatniej łapanki przeprowadzonej w środowisku piekarzy, czy też w
bardziej cywilizowany sposób.

Piotrek

do góry

On 18/11/2021 18:41, Piotrek wrote:
>> Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
>> review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
>> grupach 60+ to może być coding standard.
> Nie to, żebym się obruszył o 60+ ...
> Ale przecież styl projektowania/programowania nie zależy od wieku
> autora.

Zależy. Przykro mi to stwierdzić, ale zalezy. W embedded w szczególności.

Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi, nie
odosobnione.

> Tylko raczej od tego czy gość trafił do zawodu w wyniku
> ostatniej łapanki przeprowadzonej w środowisku piekarzy, czy też w
> bardziej cywilizowany sposób.

Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było goto
w BASICu. I z tym kłopot największy.

do góry

2021-11-18 o 18:38 +0100, heby napisał:
> Zmniejszyłem je. Z wielu miejsc usunąłem.

Za pomocą tego magicznego guard? Wmówiłeś to sobie, uprawiasz tylko
kreatywną księgowość.

> Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
> wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
> zautomatyzować".

Ale ja przecież nie proponuję gapienia się. Objaśniam tylko, że to co
starasz się wypromować jako "argument za C++ w embedded" wcale nie
potrzebuje C++.

> > No to dajesz.
>
> A ile płacisz?

Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
projektu i zainwestowania roboczogodzin? No to ja dziękuję za taki
postęp. Jak ma być skomplikowanie to równie dobrze w C mogę sobie
złożyć system do sprytnego zarządzania flagami.

Mateusz

do góry

On 18/11/2021 19:19, Mateusz Viste wrote:
> 2021-11-18 o 18:38 +0100, heby napisał:
>> Zmniejszyłem je. Z wielu miejsc usunąłem.
>
> Za pomocą tego magicznego guard?

Tak. Wyeliminował wszystkie źrodła błedu "zapomniałem włączyć" teraz i w
przyszłosci, z tej funkcji.

Oczywiście można go usunąć przypadkiem. Można wiele rzeczy zrobić, to
tylko białko. Idę o zakłąd że ilosc takich przypadków będzie o rząd
wielkosci mniejsza, niż przypadków "zapomniałem gdzieś zawołać goto w 30
miejscach".

> Wmówiłeś to sobie, uprawiasz tylko
> kreatywną księgowość.

Dziwnym trafem ta "kreatywna księgowość" jest powszechnie używanym
wzorcem projektowym w całym C++, dając zaskakująco wysoki poziom
bezpieczeństwa transakcji.

Podpowiem kilka generyków: std::mutex::scoped_lock, boost::scoped_ptr,
boost::scoped_array itd.

Każdy da się napisać na goto. I wylecieć kopniakiem za drzwi, bo to nie
lata 60te.

>> Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
>> wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
>> zautomatyzować".
> Ale ja przecież nie proponuję gapienia się.

Dokładnie to oferujesz. Mówisz: "ale uważaj, przed każdym wyjściem z
funkcji musisz zawołać goto". Ja tego nie mówie. Samo prawidłowo zawoła
się to, co ma się zawołać, nie muszę żyć w ciągłym strachu, mam 1
miejsce a nie 30, do popełnienia błedu.

> Objaśniam tylko, że to co
> starasz się wypromować jako "argument za C++ w embedded" wcale nie
> potrzebuje C++.

Zrobiłeś jakiś mechanizm działajacy w podobny sposob na poziomie *tego*
konkretnie przypadku. Po refaktoringu środka funkcji, ja nie muszę się
martwić i mam gwarantowane wywołanie sei(), Ty musisz się męczyć i
przeglądać kod, czy ktoś nie zapomniał zawołać goto. Innymi słowy mój
zysk to bezpieczeństwo refaktoringu tej funkcji, bezpieczeństwo jej
pisania i przejrzystośc kodu.

Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
tak, nie da się tego zrobic w C. Można tylko napisać identyczny przykład
i wymachiwać "nie ma żadnej różnicy". Ona jest, nie widzisz jej, bo nie
piszesz nic więcej niż miganie diodą i nigdy nie przyszło Ci do głowy że
ktoś będzie tą funkcję zmieniał, w czasie jej życia, 100 razy.

>> A ile płacisz?
> Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
> projektu i zainwestowania roboczogodzin?

Tak. Ja inwestuje raz. Kod taki (o podobnej funkcjonalnosci) napisałem
już kilka razy, komercyjnie. Za każdym razem używałem go w setkach, jak
nie tysiącach miejsc. Więc ja zapłaciłem raz, a dobrze.

Niejaki Mateusz, za każdym razem jak robi UART= płaci na nowo koszta
potencjalnych bugów, w kółko używając technik z epoki kamiennej do
podwyższania jakości kodu, czyli cichej modlitwy, że się nie pomylił.

Przykro mi, że kod nie jest za darmo. Jestem znudzony edukowaniem za
friko każdego, kto jest za wielkim ignorantem, aby zrobic to samodzielnie.

> No to ja dziękuję za taki
> postęp.

Nie pojmujesz nawet tego, że ten kod da się napisać generycznie i używać
gdzie chcesz, *zmniejszajac* koszty błedów.

Pisałeś kiedyś coś więcej, niż hello world?

> Jak ma być skomplikowanie to równie dobrze w C mogę sobie
> złożyć system do sprytnego zarządzania flagami.

To złóż i pochwal się. Ale nie zapłacę za niego z prostej przyczyny: nie
będzie mieć śladu zalet względem statycznych checków C++. Wiem to
dlatego, że widziałem ich na pęczki. Każdy gówno wart.

A najbardziej zabawne, że to dopiero początek tego, co C++ pozwala
zrobić dobrego w kodzie embedded, a Ty już nie pojmujesz gdzie zalety,
bo ci assembler przesłania.

do góry

czwartek, 18 listopada 2021 o 17:22:57 UTC+1 heby napisał(a):
> On 18/11/2021 15:52, Dawid Rutkowski wrote:
> >> Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
> >> *bardzo* przydatnym w embedded, bez narzutu wydajności.
> > Napisz choć kilka przykładów.
> Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.

To dość dawno, p.m.e. wnikliwie czytam pewnie z rok czy dwa.

> Np taki:
>
> foo()
> {
> DisableInterruptsInThisScope guard;
>
> [...]
> return;
> [...]
> return;
> [...]
> return;
> }

Hmm, podałeś piękny przykład socjalizmu - ustroju dzielnie i skutecznie (chyba jednak
nie) zwalczającego problemy, które nie występują w kapitaliźmie.
Mechanizm RAII stosowany po to, by "usunąć kategorię bugów", która pojawia się w
wyniku kodowania, które nie jest nawet strukturalne.
Wiem że BASIC ryje beret nieodwracalnie...
I wiem też, że w C można pisać programy FORTRANowe.
Sztuka i nauka w tym, by tego nie robić.

Zaś takie cli() na początku i sei() na końcu funkcji można sobie zrobić za pomocą
__attribute__.
Tylko co, jeśli przerwania musisz włączyć w połowie funkcji?
Np. w ISR w programie bardziej skomplikowanym niż miganie diodą?
Pewnie dałoby się to zrobić lepiej - ale urządzenie musi iść na obiekt jutro, bo za
pół roku to takie oprogramowanie zrobi też Hindus, a może i Chińczyk.

> > Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
> No to masz RIIA.

Słabe. Jeszcze bym chciał coś lepszego.

> >>> Przykład zły,
> >>> bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
> >>> języków.
> >> To dalej oznacza, że jeden z nich na pewno jest w C++.
> > Który? I dlaczego?
> Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.

To może odwrotnie - czy drugi nie skompiluje się gcc?
Przecież nie było tam nawet:
for(int i = 0 ; i < 100 ; ++i )
Czym one się w ogóle różnią?
Pewnie tym, co zwróci
$ echo $_
Ciekawe co będzie w tym drugim przypadku.
Nie powinno być:
void main() {}
?

Rozwiązywałe kiedyś test 50 pytań z Javy i C++ u takiej jednej fajnej "rekruterki"
(rozpraszała, podobnie jak taka jedna fajna z zakładu metod matematycznych
informatyki na egzaminie z prawdopodobieństwa ;)
Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?), C++ koszmarne - ale
to Twoje jest jeszcze trudniejsze.

> >> Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
> >> *klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
> >> dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
> >> nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
> > No to którym kompilatorem "lepiej" się skompiluje program napisany w C -
kompilatorem C czy C++?
> Oba skompilują tak samo.
>
> Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.

Tak samo albo nie.
Jakoś to mocno "akademickie" - czy dobrze odbieram "grupę" i "review"?
I to jeszcze akademickie młodego pokolenia, co pierwszy komputer miało z windows
95...

do góry

On 18.11.2021 18:45, heby wrote:
> On 18/11/2021 18:41, Piotrek wrote:
>> Nie to, żebym się obruszył o 60+ ...
>> Ale przecież styl projektowania/programowania nie zależy od wieku autora.
>
> Zależy. Przykro mi to stwierdzić, ale zalezy. W embedded w szczególności.
>
> Isnieje korelacja między używaniem konstrukcji hackerskich i
> niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
> oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi, nie
> odosobnione.

Przede wszystkim jak ktoś zaczynał w IT 40 lat temu to aktualnie raczej
zajmuje się odcinaniem kuponów od tego co osiągnął w życiu (zawodowym),
a nie kodowaniem.

Tak więc będę się upierał, że w przypadku profesjonalistów problem
zależności jakości kodu od wieku programisty jest IMHO marginalny.

Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
zawodu ;-)

Ale przede wszystkim od doświadczenia zawodowego (przy założeniu, że
gość ma zdefiniowaną ścieżkę kariery, ma mentora, bierze udział w
szkoleniach, etc.)

>
>> Tylko raczej od tego czy gość trafił do zawodu w wyniku ostatniej
>> łapanki przeprowadzonej w środowisku piekarzy, czy też w bardziej
>> cywilizowany sposób.
>
> Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było goto
> w BASICu. I z tym kłopot największy.

?

Nie traktuj tego osobiście ale IMHO masz wypaczone pojęcie o technologii
i zakresie kształcenia (studentów informatyki) w latach 80.

Inną sprawą jest to czy rzeczeni studenci mogli wykorzystać nabytą
wiedzę w pracy zawodowej.

Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym się nie
spodziewał.

Piotrek

do góry

On 18/11/2021 19:55, Dawid Rutkowski wrote:
>> Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.
> To dość dawno, p.m.e. wnikliwie czytam pewnie z rok czy dwa.

Tak, od ~10 lat minimum.

>> Np taki:
>>
>> foo()
>> {
>> DisableInterruptsInThisScope guard;
>>
>> [...]
>> return;
>> [...]
>> return;
>> [...]
>> return;
>> }
> Hmm, podałeś piękny przykład socjalizmu - ustroju dzielnie i skutecznie (chyba
jednak nie) zwalczającego problemy, które nie występują w kapitaliźmie.

Ten przykałd rozwiązuje problem powszechnie występujacy w programach C w
embedded, czyli tansapcyjności flag. Przerwań, bo łatwe, ale masy innych
tez łatwo tym osiągnać.

> Mechanizm RAII stosowany po to, by "usunąć kategorię bugów", która pojawia się w
wyniku kodowania, które nie jest nawet strukturalne.

Mechanizm RAII jest używany tam, gdzie jest przydatny. Tu jest przydatny.

> Wiem że BASIC ryje beret nieodwracalnie...

Tak, dlatego eliminujemy go z C i pojawia się potrzeba użycia czegoś
lepszego. C++ jest za darmo.

> I wiem też, że w C można pisać programy FORTRANowe.
> Sztuka i nauka w tym, by tego nie robić.

Wiec wyjasnij to embedowcom, u których goto jest podstawą wzroców
programowania.

> Zaś takie cli() na początku i sei() na końcu funkcji można sobie zrobić za pomocą
__attribute__.

A takie "enableDisplay()" i "disableDisplay()" też?

Przyczepiłeś się użycia w przypadku 1, ale nie widzisz pozostałych N-1
przypadków, gdzie wzorzec projektowy ...scoped... jest znacznie
wygodniejszy i bezpieczniejszy niż debilizmy z goto.

> Tylko co, jeśli przerwania musisz włączyć w połowie funkcji?

To masz dodatkowy scope w połowie funkcji.

Jesli przerwania musisz wyłączyć pomiędzy scopeami funkcji, to
prawdopodobnie masz coś mocno spieprzone we flow algorytmu i niewiele tu
można pomóc, musi wystarczyć modlitwa.

> Np. w ISR w programie bardziej skomplikowanym niż miganie diodą?

scope stosuje się własnie w programach znacznie bardziej skomplikowanych
niż miganie diodą. Aby w ogóle dało się je utrzymać dalej, niż etap
migania diodą.

> Pewnie dałoby się to zrobić lepiej - ale urządzenie musi iść na obiekt jutro, bo za
pół roku to takie oprogramowanie zrobi też Hindus, a może i Chińczyk.

Mówisz o pisaniu na odpierdol? Łopanie, to oczywiscie goto i nastepny.

Poważne oprogramowanie przeszło by review, testy automatyczne, statyczną
analizę, analizę formalną, linting, akceptację SQA. Ale na odpierdol
nie, ja w ogole nie mówie o takiej kategorii oprogramowania. Być może to
miganie diodą było by w respiratorze, więc wtedy też.

Choć nawet w tym na odpierdol wolałbym RAII, niż 30 goto.

>>> Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
>> No to masz RIIA.
> Słabe. Jeszcze bym chciał coś lepszego.

To proponuj.

>> Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.
> To może odwrotnie - czy drugi nie skompiluje się gcc?
> Przecież nie było tam nawet:
> for(int i = 0 ; i < 100 ; ++i )
> Czym one się w ogóle różnią?

Niczym istotnym. Właśnie odkryłeś że przejście na C++ jest za darmo. A
mimo to dev 60+ broni się rękami i nogami, wymyślając co chwile nowe
debilizmy do obrony epoki kamienia goto-wanego.

> Pewnie tym, co zwróci
> $ echo $_
> Ciekawe co będzie w tym drugim przypadku.
> Nie powinno być:
> void main() {}
> ?

Nie. Nie powinno. Będzie zero. Gwarantowane. ISO 9899:201x 5.1.2.2.3

> Rozwiązywałe kiedyś test 50 pytań z Javy i C++ u takiej jednej fajnej "rekruterki"
(rozpraszała, podobnie jak taka jedna fajna z zakładu metod matematycznych
informatyki na egzaminie z prawdopodobieństwa ;)
> Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?)

Jak sobie wyobrażasz heap na AVR? Java jest językiem, w którym cieżko
się piszę bez allokacji na heapie. Innymi słowy nie jest możliwa do
użycia na AVR w sposób pełny. Co innego C++ - w nim używania heapu nie
ma obowiązku.

Istnieją podzbiory Javy np. na karty SIM, ale nie chciałbyś w tym pisać,
to jest żenujące i przypomnia tortury.

>, C++ koszmarne - ale to Twoje jest jeszcze trudniejsze.

To są podstawy C++. Nie ma nic prostszego niż RAII.

>> Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.
> Tak samo albo nie.
> Jakoś to mocno "akademickie" - czy dobrze odbieram "grupę" i "review"?

"grupa" i "review" nie mają nic wspólnego z "akademickością". Są
normalnymi narzędziami używanymi przez prawie wszystkie firmy zajmujące
się pisaniem programów, a nie dicking around.

Bywają "akademickości" gdzie o nich nie słyszano i dalej uczą Delphi,
dajac na koniec magistry.

> I to jeszcze akademickie młodego pokolenia, co pierwszy komputer miało z windows
95...

Myślę, że przeoczyłeś jakieś ~40 lat rozwoju informatyki.

do góry

2021-11-18 o 19:40 +0100, heby napisał:
> Dokładnie to oferujesz. Mówisz: "ale uważaj, przed każdym wyjściem z
> funkcji musisz zawołać goto". Ja tego nie mówie. Samo prawidłowo
> zawoła się to, co ma się zawołać, nie muszę żyć w ciągłym strachu,
> mam 1 miejsce a nie 30, do popełnienia błedu.

Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.

> muszę się martwić i mam gwarantowane wywołanie sei(), Ty musisz się
> męczyć i przeglądać kod, czy ktoś nie zapomniał zawołać goto.

#define return goto gameover

albo

#define return TUTAJ_UZYWAMY_GOTO

albo

static void func_internal() {
[...]
}

void func() {
_disable();
func_internal();
_enable();
}

Ale znowu - ja nie mam zamiaru wykłócać się z usenetowym krzykaczem.
Wskazuję tylko, że innowacja którą przedstawiasz jest bardzo dyskusyjna.
I nie jest to z mojej strony krytyka C++ (którego znam słabo), tylko
podanego przykładu. Zapytałem o jakiś poważniejszy przykład, ale
wolałeś się obrazić.

> Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
> tak, nie da się tego zrobic w C.

Patrz wyżej.

> Tak. Ja inwestuje raz. Kod taki (o podobnej funkcjonalnosci)
> napisałem już kilka razy, komercyjnie. Za każdym razem używałem go w
> setkach, jak nie tysiącach miejsc. Więc ja zapłaciłem raz, a dobrze.

No fajnie, ale to też nie ma nic wspólnego z C++.

> Pisałeś kiedyś coś więcej, niż hello world?

Już któryś raz zamiast pokazać kod stosujesz argumenty ad personam. To
świadczy zarówno o tobie, jak i o idei którą tak zaciekle bronisz.

Mateusz

do góry

On 18/11/2021 20:03, Piotrek wrote:
>> Isnieje korelacja między używaniem konstrukcji hackerskich i
>> niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
>> oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi,
>> nie odosobnione.
> Przede wszystkim jak ktoś zaczynał w IT 40 lat temu to aktualnie raczej
> zajmuje się odcinaniem kuponów od tego co osiągnął w życiu (zawodowym),
> a nie kodowaniem.

W moim otoczeniu programistów 60+ jest mało, ale istnieją. W embedded
jest ich znacznie wiecej, choć to statystyka subiektywna, ale jak mówie,
sporo znajomych z mojego otoczenia ma podobne.

> Tak więc będę się upierał, że w przypadku profesjonalistów problem
> zależności jakości kodu od wieku programisty jest IMHO marginalny.

Korelacja jest miedzy wiekiem, a nie "od 60+". Przeciętny 50-latek
będzie znacznie bardziej skłonny do używania void* niż 40-latek. A
30-latek znowu, bedzie znał np. C# i nie zdziwi go lambda w C++.

> Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
> zawodu ;-)

Taka występuje oczywiście. Dam Ci jeszcze inny przykład: wśród
programistów z Ukrainy zauważyłem korelacje w preferowanych wzorcach
projektowych. Skłaniających się w okolice antywzorca "golden hammer". I
to nie zależy od miejsca, skad pochodzą, z tej Ukrainy. Tak jak by
problem istniał gdzieś w samym centrum nauczania.

To trochę jak kiedyś Bielecki, mający wpływ na nauczanie (kiepskie)
programowania w PL.

>>> Tylko raczej od tego czy gość trafił do zawodu w wyniku ostatniej
>>> łapanki przeprowadzonej w środowisku piekarzy, czy też w bardziej
>>> cywilizowany sposób.
>> Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było
>> goto w BASICu. I z tym kłopot największy.
> ?

Starsi programiści potrafią rozwiązać każdy problem używając outdated
konstrukcji w języku.

Wyjśc ze scope? Goto! (zamiast poprawnej struktury)
Zawołać pointer? C-style (zamiast std::function/lambda)
Zwrócić dwie zmienne? Przez argumenty!
Polimorfizm? void* i enum cast rozwiązuje wszystkie problemy.

Widać wyraźną alergicznośc na konstrukcje bezpieczniejsze, ponieważ
"lepsze jest wrogiem dobrego" jak mawiają ludzie starający sie ukryć
swoją ignorancję.

> Nie traktuj tego osobiście ale IMHO masz wypaczone pojęcie o technologii
> i zakresie kształcenia (studentów informatyki) w latach 80.

Czy w latach 80 uczono C++ z RAII? Nie. Nie uczy się go, tak na
marginesie, do dzisiaj. Lata od 90 pod 2020 mam zarówno ogarnięte od
strony ucznia/studenta jak i wykładowcy. Natomiast tak, uczono na
uczelniach kiepskich jezyków programowania i zalewano betonem kiepskie
nawyki. O ile człowiek młody, to jest też elastyczny. Znów starszy, z
uwagi na biologie, przyjmuje postawę w opozycji do nowości. To
naturnalne, stwierdzam bardziej fakt, niż narzekam.

> Inną sprawą jest to czy rzeczeni studenci mogli wykorzystać nabytą
> wiedzę w pracy zawodowej.

Zwyczajowo nie, programowanie uC w latach 80/90 w wiekszości odbywało
się w asm i sporadycznie w idiotycznych dialektach C. Po 20 latach
pisania na 8051 trudno się dziwić, że jak ktoś mówi o RAII to pojawia
się natychmiastowa reakcja alergiczna. Mnie to nie dziwi ani torchę i
nie zamierzam tego zmieniać. Ten problem rozwiąże biologia.

> Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym się nie
> spodziewał.

Języki dąża do bycia coraz to bardziej dziadowskimi, ale ciągle
uzytecznymi. JavaScript, jako najgorsze guano obecnie używane, jest nie
dosc że bardo popularny, to również bardzo wysoko płatny.

Całość tego procesu wynika z faktu, że nie ma na rynku zawodowych
programistów. Są jedynie Ci z łapanki, którzy nie pojmą RAII w C++, ale
pojmą jak zrobić obrazek z licznikiem w Node.js.

Ja tego nie zamierzam zmieniać, ale dziadostwo w moim otoczeniu
uprzątam, jesli tylko mam okazję. Jeszcze mi się chce.

do góry