W dniu środa, 2 stycznia 2019 08:17:40 UTC+1 użytkownik Tomasz Kaczanowski napisał:

> > Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
> > spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
> > z wykorzystaniem C++".
> [...]
> > Każdy, kto uczył się Pythona z tutoriala Guidona van Rossum,
> > zapewne pamięta, że jedna z początkowych sekcji nosi tytuł
> > "Using Python as calculator". Programiści Pythona raczej
> > nie byliby szczególnie zainteresowani problemem dydaktycznym,
> > który proponuje Stroustrup, ponieważ wiersz poleceń w Pythonie
> > już jest "takim kalkulatorem, tylko lepszym".
>
> Pytanie tylko co z tego. W jednym języku masz przygotowane rzeczy do
> jednych operacje, w innym do innych.

Czasem rzeczywiście jest tak, że masz je "w języku". Na przykład w Perlu
(czy nawet w JavaScripcie) jest specjalna składnia do pracy z
wyrażeniami regularnymi.
W Pythonie czy PHP wyrażenia regularne są dostępne z funkcji bibliotecznej.
I to podejście wydaje się zwyciężać, bo lepiej się skaluje.

> W zasadzie po co pisać proste
> programy, skoro większość z nich był już napisany wielokrotnie.

To zależy. Dla nauki, dla treningu, dla zabawy.
Po co rozwiązywać krzyżówki, skoro ktoś je już rozwiązał?

> A jednak. Swojego czasu (pierwsza połowa lat 90), żeby dobrze zrozumieć
> jak wykorzystać polimorfizm analizowałem sobie napisany program
> przykładowy dołączany do jednego z kompilatorów. Znowu - też nie jakieś
> super skomplikowane rzeczy - ot parser funkcji matematycznych, dzięki
> któremu rysowane były wykresy. Nic zaawansowanego, ale dało trochę do
> myślenia i do analizy jak to działa.

No i bardzo dobrze. Programy pisze się między innymi po to,
żeby można je było czytać.

> Wiele rzeczy pisze się podczas
> nauki nie po to by rozwiązać realny problem, tylko aby na jakimś
> problemie przećwiczyć sposoby rozwiązania.

W porządku. Ja nie mówię, że ten akurat problem nie ma wartości dydaktycznej.
Mówię, że podejście Stroustrupa jest niedobre.

Przeglądam sobie jeszcze raz ten fragment, a tam widzę takie coś:

case '8': // Za pomocą znaku '8' reprezentujemy liczby.

WTF? Dlaczego?!

> Oczywiście można wymyślić
> jakiś problem nie rozwiązany już na 1000 sposobów, tylko po co? Co to da
> w kontekście dydaktycznym poza trudniejszym opisem problemu?

Jakiś czas temu zgłosił się do mnie jakiś student z Czech, żebym mu
pomógł w jakimś projekcie.
Projekt był dość ciekawy. Jego nauczyciel przygotował program, w którym
jakiś ludzik chodził po labiryncie w poszukiwaniu skarbu.
Celem studenta było napisanie programu, który tym ludzikiem posteruje.
To była całkiem fajna zabawa.
Podobnie np. gra "Human Resources Machine", w której układasz z klocków
programy sterujące pnącym się po szczeblach kariery pracownikiem korporacji.
Miłe, przyjemne zadanka.

> > Jak możemy się domyślać, Stroustrup proponuje początkującemu
> > czytelnikowi raczej ciężką i niewdzięczną drogę: oto bowiem
> > zostajemy rzuceni w wir tokenizacji i parsowania (a dodatkowo
> > mistrz wymaga od swoich uczniów, żeby pojedyncze wyrażenia mogły się
> > rozciągać na wiele linii, żeby początkującemu nie było za łatwo).
>
> i bardzo dobrze moim zdaniem, pokazuje, że proste na początku zadanie,
> może mieć dużo dodatkowych wymagań.

Tak, i czasem łatwiej przeformułować wymagania tak, żeby były one
w naszym zasięgu. Ale Stroustrup zamiast powiedzieć np.
"obsługa precedensów operatorów arytmetycznych jest trudna,
w związku z czym użyjmy zamiast tego odwrotnej notacji Polskiej"
albo coś w tym rodzaju, brnie w niezbyt interesującą teorię.

> Czasami proste rozwiązanie może
> okazać się prostackie i dla mnie nieakceptowalne, jak np kiedyś coś tam
> robiąc w PHP, korzystając z funkcji str_getcsv, okazało się, że nie jest
> ona odporna na różność kodowań. Standard csv nie ma takich ograniczeń,
> natomiast jeśli mamy źle lokale ustawione i niekompatybilne z nim
> zakodowany plik, to nagle funkcja nie potrafi prawidłowo podzielić
> rekordów na pola. Koś poszedł na skróty, właśnie nie przeprowadził
> wystarczająco dobrze procesu rozpoznawania problemu i stworzony został
> moim zdaniem potworek.

Ostatnio mieliśmy aplikację od dużej firmy. Była chyba napisana w C#,
i też trzeba było zmieniać język w systemie operacyjnym, bo jakieś tam
pola gdzieś tam miały przecinki zamiast kropek albo na odwrót.

I ważne moim zdaniem jest pytanie, jak unikać tego rodzaju problemów.

Tyle że nie bardzo wiem, jak ma się to do tego, co napisałem wcześniej.

do góry

W dniu środa, 2 stycznia 2019 13:44:21 UTC+1 użytkownik fir napisał:

> > > jak dla mnie te krytyki c++ itp sa malo
> > > sensowne lub istotne, (ale tez zarazem
> > > sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to
obchodzi odbieram to jako nieistotne)
> >
> > Ja mam podobnie z Twoimi tematami.
> > Piszesz o programach w rodzaju "tworzę swój edytor tekstu", "piszę grę
rogue-alike", "opracowuję swój własny asembler" - szczerze powiedziawszy, nie są to
rzeczy bez precedensu.
> > Jeżeli masz ochotę się w to bawić, Twoja sprawa, ale tego rodzaju programów
istnieje już milion czy coś koło tego, i nie wygląda mi na to, żeby te Twoje
rozwiązywały jakieś rzeczywiste problemy.
> >
>
> szczerze mowiac jest to glupia wypowiedz,

dlaczego?

> (pominawszy juz ze nie ma specjalnego zwiazu miedzy pisaniem edytora tekstu a
wywolywaniu dziwnych wojen z c++ z dziwnymi argumentami, nie mowie nawet ze te
argumenty nie sa sluszne czesc moze byc jakos tam sluszna ale nie sa one zbyt istotne
po prostu )

Zgadzam się, że wojny są stratą czasu. Z drugiej strony uważam,
że warto przeprowadzać krytyki i prezentować różne punkty widzenia.

Może przedstawiam swoją perspektywę w nieodpowiedni sposób?

> z tego ze jest duzo edytorow nie wynika ze jak ktos napisze
edytor/asembler/roguelike to nie moze zrobic w tym edytorze nic nowatorskiego..

Masz rację, nie wynika.

> dla mnie akurat te projekty byly nowatorskie (wewnetrznie i zewnetrznie)

Wewnętrzne i zewnętrznie? Co masz na myśli?

> ale to tez gwoli istoty rzeczy nie dotyka sedna istoty najwazniejszych problemow
>
> istota problemu jest nieststy to co opisalem wczesniej w poscie jako 1 i 2B
> (pisze nieststy bo sa to problemy na ogol odbierane przeze mnie dosyc nieprzyjemne,
> byc moze wlasnie powinienem sobie wypracowac jakies pdescie by uczynic je
strawniejszymi ale to nie jest lekka sprawa)

Moim zdaniem programowanie to jest przede wszystkim myślenie
i wypracowywanie dobrych nawyków.
Jak się ma złe nawyki, to można łatwo utonąć w bałaganie, który się zrobi
wokół siebie, i niepotrzebnie trwonić energię.

Być może pewnym problemem jest to, że nie ma jasnych wytycznych
odnośnie tego, które nawyki są dobre, a które złe - jak to mówią,
"po owocach ich poznacie".

W moim odczuciu książki w rodzaju tej omawianej uczą bałaganiarstwa
i nie są dobrym wzorem do naśladowania.
Jest to tym bardziej istotne, że na początku większość osób
uczy się programowania właśnie przez naśladownictwo.
Właśnie w ten sposób dowiadujemy się, jak "się robi rzeczy".

Dla mnie jest trochę tak, że istotnym czynnikiem jest takie sformułowanie
celu, żeby był możliwy do realizacji w trakcie jednego "posiedzenia".

Z reguły mi to nie wychodzi, ale jest pewien rytm, który mi pomaga:
w okresie zimowym dojeżdżam do pracy kolejką ok. 40 minut w każdą
stronę. Jest to dość dużo czasu, żeby spróbować nadgryźć jakiś temat.
Czasem wracając z pracy wkręcę się na tyle mocno, że później jeszcze
w domu coś dokańczam - w ten sposób udało mi się stworzyć zalążek
swojego "edytora edytorów" (czy raczej "edytora struktur").

Jednak w okresie świąteczno-sylwestrowym nie udało mi się do niego
niczego dodać. Wolałbym z pewnością, żeby moje prace szły szybciej.

Może nie powinienem trwonić tyle czasu na te fora.

do góry

W dniu środa, 2 stycznia 2019 15:55:51 UTC+1 użytkownik g...@g...com napisał:
> W dniu środa, 2 stycznia 2019 13:44:21 UTC+1 użytkownik fir napisał:
>
> > > > jak dla mnie te krytyki c++ itp sa malo
> > > > sensowne lub istotne, (ale tez zarazem
> > > > sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to
obchodzi odbieram to jako nieistotne)
> > >
> > > Ja mam podobnie z Twoimi tematami.
> > > Piszesz o programach w rodzaju "tworzę swój edytor tekstu", "piszę grę
rogue-alike", "opracowuję swój własny asembler" - szczerze powiedziawszy, nie są to
rzeczy bez precedensu.
> > > Jeżeli masz ochotę się w to bawić, Twoja sprawa, ale tego rodzaju programów
istnieje już milion czy coś koło tego, i nie wygląda mi na to, żeby te Twoje
rozwiązywały jakieś rzeczywiste problemy.
> > >
> >
> > szczerze mowiac jest to glupia wypowiedz,
>
> dlaczego?
>
> > (pominawszy juz ze nie ma specjalnego zwiazu miedzy pisaniem edytora tekstu a
wywolywaniu dziwnych wojen z c++ z dziwnymi argumentami, nie mowie nawet ze te
argumenty nie sa sluszne czesc moze byc jakos tam sluszna ale nie sa one zbyt istotne
po prostu )
>
> Zgadzam się, że wojny są stratą czasu. Z drugiej strony uważam,
> że warto przeprowadzać krytyki i prezentować różne punkty widzenia.
>
> Może przedstawiam swoją perspektywę w nieodpowiedni sposób?
>

glupie jest bicie piany o nieistotne sprawy... do tego jak sie kogos przekonuje to
powiedzialbym wystepuja dwa rodzaje argumentow, przekonujace i nieprzekonujace -
przekonujace argimenty sa naprawde przekonujace, a czytaie kolegi raczej przypomina
czytania kogos kto wywala z siebie 30 arguimentow ale wszystkie naleza do tej
drugiekj kategorii

a sedno problemu i tak jest gdzi indziej... jak ktos ma buga w kodzie to
wysluchowania dyskucji czy licp jest lepszy czy c++ sie troche mija z celem bo by
buga naprawic trzeba sie zajac czyms innym

kwestai jest taka ze ta gadla lisp a c++ jest ogolnie malo uzyteczna a takie
metaforyczne 'bugi' przeszkadzajace ludziam w programowaniu wstepuja i jak juz ktos
zaczyan dyskusje o tym jak lepiej cos robic w kodowaniu to trzeba by sie skupic na
istocie sprawy

(ostatni raz to raczej mowie bo nie cjhce mi sie powtarzac)

> > z tego ze jest duzo edytorow nie wynika ze jak ktos napisze
edytor/asembler/roguelike to nie moze zrobic w tym edytorze nic nowatorskiego..
>
> Masz rację, nie wynika.
>
> > dla mnie akurat te projekty byly nowatorskie (wewnetrznie i zewnetrznie)
>
> Wewnętrzne i zewnętrznie? Co masz na myśli?
>

za duzo by pisac... napisanie asemblera dalo mi duzo bardzo satysfakcjonujacej wiedzy
czym naprawde tai program jest (bardzo to warto byo zrobic).. z edytorkiem podobnie
choc narazie zrobilem tylko cos w rodzaju notepada (ale wszystko obkodowane samemu, a
wszystko trzeba kodowac np lamanie wierszy itd) i przerwalem ale bylo tez to raczej
ciekawe

zewnetrzenie to jest mzoan wprpadzac tam nowatorskie ficzery.. ale o tym tez mis i
enie chce gadac.. podstawowa idea u mine bylo np oznaczac ostatnio edytowane kawalki
w zrodlach innym kolorem tak by blakly z czasem np edytowane w ostatniej godzinie
jeden odczien te w ciagu ostatniej doby inny te w ciagu tygodnia inny miesiace inny
trzech miesiecy inny i by to blakło - takie cos by bylo fajne, zwlaszcza jesli dac np
pod altem i strzalkami w lewo prawo rotowanie po ostatnio edytowanych miejscach

kiedys o tym pisalem zdaje sie, niezabardzo mis ie chce o tym za duzo pisac bo robie
cos innego ale jak wroce do tego i bede wkrecony moge to cos napisac



> > ale to tez gwoli istoty rzeczy nie dotyka sedna istoty najwazniejszych problemow
> >
> > istota problemu jest nieststy to co opisalem wczesniej w poscie jako 1 i 2B
> > (pisze nieststy bo sa to problemy na ogol odbierane przeze mnie dosyc
nieprzyjemne,
> > byc moze wlasnie powinienem sobie wypracowac jakies pdescie by uczynic je
strawniejszymi ale to nie jest lekka sprawa)
>
> Moim zdaniem programowanie to jest przede wszystkim myślenie
> i wypracowywanie dobrych nawyków.
> Jak się ma złe nawyki, to można łatwo utonąć w bałaganie, który się zrobi
> wokół siebie, i niepotrzebnie trwonić energię.
>
> Być może pewnym problemem jest to, że nie ma jasnych wytycznych
> odnośnie tego, które nawyki są dobre, a które złe - jak to mówią,
> "po owocach ich poznacie".
>
> W moim odczuciu książki w rodzaju tej omawianej uczą bałaganiarstwa
> i nie są dobrym wzorem do naśladowania.
> Jest to tym bardziej istotne, że na początku większość osób
> uczy się programowania właśnie przez naśladownictwo.
> Właśnie w ten sposób dowiadujemy się, jak "się robi rzeczy".
>
> Dla mnie jest trochę tak, że istotnym czynnikiem jest takie sformułowanie
> celu, żeby był możliwy do realizacji w trakcie jednego "posiedzenia".
>
> Z reguły mi to nie wychodzi, ale jest pewien rytm, który mi pomaga:
> w okresie zimowym dojeżdżam do pracy kolejką ok. 40 minut w każdą
> stronę. Jest to dość dużo czasu, żeby spróbować nadgryźć jakiś temat.
> Czasem wracając z pracy wkręcę się na tyle mocno, że później jeszcze
> w domu coś dokańczam - w ten sposób udało mi się stworzyć zalążek
> swojego "edytora edytorów" (czy raczej "edytora struktur").
>
> Jednak w okresie świąteczno-sylwestrowym nie udało mi się do niego
> niczego dodać. Wolałbym z pewnością, żeby moje prace szły szybciej.
>
> Może nie powinienem trwonić tyle czasu na te fora.

do góry

W dniu środa, 2 stycznia 2019 15:55:51 UTC+1 użytkownik g...@g...com napisał:
>
> Z reguły mi to nie wychodzi, ale jest pewien rytm, który mi pomaga:
> w okresie zimowym dojeżdżam do pracy kolejką ok. 40 minut w każdą
> stronę. Jest to dość dużo czasu, żeby spróbować nadgryźć jakiś temat.
> Czasem wracając z pracy wkręcę się na tyle mocno, że później jeszcze
> w domu coś dokańczam - w ten sposób udało mi się stworzyć zalążek
> swojego "edytora edytorów" (czy raczej "edytora struktur").
>
> Jednak w okresie świąteczno-sylwestrowym nie udało mi się do niego
> niczego dodać. Wolałbym z pewnością, żeby moje prace szły szybciej.
>
> Może nie powinienem trwonić tyle czasu na te fora.

mz w programowani enie nalezy sie wkrecac bo imbardziej sie czlowiek wkreca tym
bardziej zmeczony i wypalont sie robi

a u mie osobiscie to wypaleni osiagalo spore stany

z drugiej strony zeby cos zrobic to trzeba sie w to tez wkrecic i teraz powstaje
pytanie czy to sa dwa rozne wkrecenia - taki co meczy i takie co motywuje, czy tez
jest to jedno i to samo

wydaje mi sie ze w jakis sposon to moga byc dwa i wlasine nauczenie sie zarzadzaniem
tym jest barzdzo wazne, niestety w tym momencie z programowania robi sie cos w
rodzaju kawalka psychologii

co do forow to ona sa rzcej dobre jesli przy ich pomocy mozna odwalic kawal jakiejs
powazniejszekj koncepcyjnej roboty (ktora pozniej bardzo przydaje sie w kodowaniu) a
zle wtedy gdy spotykasz jakiegos knajackiego ziutka i czytasz godzinami jego mulenie
ktore malo co daje raczej najwyzej odbiera chec do zycia
(tak ze raz wychodzą na plus raz na minus, z faktu jednak ze czasem wychodza na plus
mozna powiedziec ze bywaja uzyteczne..kiedy indziej zas jest odwrotnie

od paru lat w zyciu nieststy zauwazylem ze troche opowiazuje to co mozna nazwac
dietetycznym podejsciem new-age'owym,
(nieststy bo wydaje sie to nudne, wolalby sie by to moze jakis lepiej dzialalo)
czyli najlepiej jest jak sie bierze troche tego troche tamtego tak jakbys praktyczni
zarzadzal jakas swoaj dietą choc jest to smutne i nudne, tak tez jest chyba z forami
;c

do góry

W dniu środa, 2 stycznia 2019 16:34:57 UTC+1 użytkownik fir napisał:

> > > (pominawszy juz ze nie ma specjalnego zwiazu miedzy pisaniem edytora tekstu a
wywolywaniu dziwnych wojen z c++ z dziwnymi argumentami, nie mowie nawet ze te
argumenty nie sa sluszne czesc moze byc jakos tam sluszna ale nie sa one zbyt istotne
po prostu )
> >
> > Zgadzam się, że wojny są stratą czasu. Z drugiej strony uważam,
> > że warto przeprowadzać krytyki i prezentować różne punkty widzenia.
> >
> > Może przedstawiam swoją perspektywę w nieodpowiedni sposób?
> >
>
> glupie jest bicie piany o nieistotne sprawy... do tego jak sie kogos przekonuje to
powiedzialbym wystepuja dwa rodzaje argumentow, przekonujace i nieprzekonujace -
przekonujace argimenty sa naprawde przekonujace, a czytaie kolegi raczej przypomina
czytania kogos kto wywala z siebie 30 arguimentow ale wszystkie naleza do tej
drugiekj kategorii

Nie sądzę, żeby to były nieistotne sprawy.
Są ludzie, którzy bardzo poważnie traktują kwestię nauki programowania
i upraszczanie go do tego stopnia, żeby było dostępne dla dzieci.

> a sedno problemu i tak jest gdzi indziej... jak ktos ma buga w kodzie to
wysluchowania dyskucji czy licp jest lepszy czy c++ sie troche mija z celem bo by
buga naprawic trzeba sie zajac czyms innym

Ale jeżeli użyjesz narzędzia, które nie ułatwia wprowadzania
bugów do kodu, to nie będziesz miał buga w kodzie.

Pytanie, skąd w kodzie biorą się bugi (i jakich zasad warto się trzymać,
żeby ich unikać albo łatwo wynajdywać), nie jest bezzasadne.

> kwestai jest taka ze ta gadla lisp a c++ jest ogolnie malo uzyteczna a takie
metaforyczne 'bugi' przeszkadzajace ludziam w programowaniu wstepuja i jak juz ktos
zaczyan dyskusje o tym jak lepiej cos robic w kodowaniu to trzeba by sie skupic na
istocie sprawy

Otóż tak, właśnie, chodzi o skupianie się na istocie sprawy.
Rzeczy takie jak parsowanie rzadko kiedy są istotą sprawy, a jeśli
jako takie je uznamy, to moim zdaniem trzeba zapytać, jaką wartość
wnoszą, że poświęcamy im aż tyle czasu.


> > > dla mnie akurat te projekty byly nowatorskie (wewnetrznie i zewnetrznie)
> >
> > Wewnętrzne i zewnętrznie? Co masz na myśli?
> >
>
> za duzo by pisac... napisanie asemblera dalo mi duzo bardzo satysfakcjonujacej
wiedzy czym naprawde tai program jest (bardzo to warto byo zrobic).. z edytorkiem
podobnie choc narazie zrobilem tylko cos w rodzaju notepada (ale wszystko obkodowane
samemu, a wszystko trzeba kodowac np lamanie wierszy itd) i przerwalem ale bylo tez
to raczej ciekawe
>
> zewnetrzenie to jest mzoan wprpadzac tam nowatorskie ficzery.. ale o tym tez mis i
enie chce gadac.. podstawowa idea u mine bylo np oznaczac ostatnio edytowane kawalki
w zrodlach innym kolorem tak by blakly z czasem np edytowane w ostatniej godzinie
jeden odczien te w ciagu ostatniej doby inny te w ciagu tygodnia inny miesiace inny
trzech miesiecy inny i by to blakło - takie cos by bylo fajne, zwlaszcza jesli dac np
pod altem i strzalkami w lewo prawo rotowanie po ostatnio edytowanych miejscach

OK, to brzmi ciekawie.

do góry

> Rozbawiła mnie też mikro-sekcja zatytułowana "uwaga na martwe referencje".
> Wygląda na to, że starym C++owym zwyczajem wyrażenia lambda są po prostu kolejnym
mechanizmem do strzelania sobie w stopę.

I co w tym zabawnego? C++ tradycyjnie oferuje dżentelmeński układ, w którym daje
programiście jakąś wartość dodaną w zamian za udział programisty w upewnieniu się co
do poprawności różnych konstrukcji. W tym wypadku wartością dodaną jest możliwość
korzystania z jakieś ograniczonej formy lambdy, bez konieczności posiadania garbage
collectora. Dzięki temu można tego użyć w tych projektach, gdzie garbage collectora
nie może być z innych powodów i to jest unikalna oferta, której inne języki nie mają.
Inaczej - istnieje pewna klasa projektów, w których nikt[*] nie ma lepszej oferty.
Dla mnie układ jest fair, w każdym razie jest to układ dla świadomego odbiorcy i ta
świadomość jest budowana np. dodatkową sekcją "uwaga na martwe referencje". Co
ciekawe, ten problem jest rozstrzygalny lokalnie i statycznie, tzn. poprawność kodu w
tym zakresie można sprawdzić automatem.

Efekt końcowy jest taki, że takie wyrażenia dopuszcza się w systemach krytycznych np.
w branży motoryzacyjnej, natomiast w ogóle nie da się tam zastosować żadnego z
języków, które tu wspomniałeś.

Kompletnie nie rozumiem, dlaczego tak bardzo starasz się krytykować C++ nie oferując
w jego zastępstwie niczego lepszego.

[*] Najbliżej do tego jest Ada, która ma funkcje lokalne (ale jednak nie anonimowe
lamdy), ale tylko downward-closure, z upward-closure się nie dało zachowując ogólną
kulturę języka jaką jest brak niejawnych zachowań niezdefiniowanych.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu 2019-01-02 o 15:55, g...@g...com napisał:
> W dniu środa, 2 stycznia 2019 13:44:21 UTC+1 użytkownik fir napisał:

>> istota problemu jest nieststy to co opisalem wczesniej w poscie jako 1 i 2B
>> (pisze nieststy bo sa to problemy na ogol odbierane przeze mnie dosyc
nieprzyjemne,
>> byc moze wlasnie powinienem sobie wypracowac jakies pdescie by uczynic je
strawniejszymi ale to nie jest lekka sprawa)
>
> Moim zdaniem programowanie to jest przede wszystkim myślenie
> i wypracowywanie dobrych nawyków.
> Jak się ma złe nawyki, to można łatwo utonąć w bałaganie, który się zrobi
> wokół siebie, i niepotrzebnie trwonić energię.

Trochę masz rację, a trochę nie... Zobacz, przykład z innej dziedziny
Jim Henson, nie znał się na lalkarstwie i dzięki temu stworzył cos
nowego. Sam w pewnym momencie stwierdził, że gdyby był po odpowiedniej
edukacji, gdy zaczynał swoją przygodę z lalkami, pewnie by go to
ograniczało i nie cieszyłyby nas dziś różne odmiany Muppetów.

--
http://kaczus.ppa.pl

do góry

W dniu czwartek, 3 stycznia 2019 10:14:01 UTC+1 użytkownik Maciej Sobczak napisał:
> > Rozbawiła mnie też mikro-sekcja zatytułowana "uwaga na martwe referencje".
> > Wygląda na to, że starym C++owym zwyczajem wyrażenia lambda są po prostu kolejnym
mechanizmem do strzelania sobie w stopę.
>
> I co w tym zabawnego?

Może to kwestia perspektywy.
Dla programistów C++ pewnie nic.

> C++ tradycyjnie oferuje dżentelmeński układ, w którym daje programiście jakąś
wartość dodaną w zamian za udział programisty w upewnieniu się co do poprawności
różnych konstrukcji.

Co w takim razie wnoszą referencje w C++? (oprócz niepotrzebnej komplikacji)
Co takiego staje się możliwe dzięki nim, co nie było możliwe bez nich?

> W tym wypadku wartością dodaną jest możliwość korzystania z jakieś ograniczonej
formy lambdy, bez konieczności posiadania garbage collectora. Dzięki temu można tego
użyć w tych projektach, gdzie garbage collectora nie może być z innych powodów i to
jest unikalna oferta, której inne języki nie mają.

Pierwszy kompilator języka Scheme, ORBIT, dawał ograniczoną
formę lambdy i nie potrzebował garbage collectora.
Więcej, autorzy tej implementacji napisali garbage collector
właśnie w tym ograniczonym podzbiorze.

> Inaczej - istnieje pewna klasa projektów, w których nikt[*] nie ma lepszej oferty.

Jeśli pominiemy takie języki jak np. Rust.

> Kompletnie nie rozumiem, dlaczego tak bardzo starasz się krytykować C++ nie
oferując w jego zastępstwie niczego lepszego.

Przecież na każdym kroku wskazuję na lepsze rzeczy.
W szczególności do nauki programowania wymieniłem kilka
rzeczy, które są o rzędy wielkości lepsze od tego, co
ma do zaoferowania C++.

> [*] Najbliżej do tego jest Ada, która ma funkcje lokalne (ale jednak nie anonimowe
lamdy), ale tylko downward-closure, z upward-closure się nie dało zachowując ogólną
kulturę języka jaką jest brak niejawnych zachowań niezdefiniowanych.

Standard GNU C znosi niepotrzebne ograniczenia języka C.
Pozwala definiować funkcje wewnątrz funkcji (nested functions)
i posiada rozszerzenie "statement expressions", o którym kiedyś
wspominałem. Przy pomocy tych dwóch mechanizmów można sobie robić
anonimowe lambdy przy pomocy makr preprocesora.

https://stackoverflow.com/questions/10405436/anonymo
us-functions-using-gcc-statement-expressions

do góry

On 2019-01-03 16:07, g...@g...com wrote:

> Co w takim razie wnoszą referencje w C++? (oprócz niepotrzebnej komplikacji)
> Co takiego staje się możliwe dzięki nim, co nie było możliwe bez nich?

1. Upraszczaja skladnie z chorego .x->c.d-> na .x.c.d
2. Zapobiagaja bezrefleksyjnemu uzywaniu arytmetyki ponterow
(a ta arytmetyka, poza chorym (void*)cus:) skutecznie eliminuje
mozliwosc rzetelnej/nieprzeklamanej weryfikacji flow programu.)

Slowem. Jestem za. W swych programach starlem sie od zawsze
uzywac wylacznie referencji. Nawet jesi API (narzucone przez
nieprzekonywalna Mlodziez:) stosuje poinery to wewnetrzenie robie
bardzo czesto w stylu:

void fun(const Klasa* o)
{
const Klasa& obj = *o;
}

Wprowadzono wreszcie nullptr (znow po 30 latach:), ale od 30 lat
stosowalem podobna konstrukcję (niestety wspomagana wpierw makrem,
ale pozniej dalo sie szablonem) - zwana zwyczajnie null - do sprawdzania
nothing-owosci referencji.

PS: a taka Simula juz w 67 miala sobie logiczne i proste i w pelni
wystarczajace:

integer a;
ref(integer) ar;

i dwa operatory przypisania

a := 5 # przypisanie "wartosciowe"
ra :- a # przypisanie referencyjne

AK

do góry

> > I co w tym zabawnego?
>
> Dla programistów C++ pewnie nic.

Ogólnie, dla programistów porzebujących narzędzi odzwierciedlających sposób działania
komputera.

> Co w takim razie wnoszą referencje w C++? (oprócz niepotrzebnej komplikacji)

Uwaga: dopiero co usiłowałeś udowodnić, że operator przypisania jest niepotrzebny.

Uwaga na dwie różne rzeczy. Referencje same w sobie to aliasy i służą właśnie do
tego, żeby upraszczać zapis (o tym pisał AK) a nie żeby cokolwiek komplikować. Drugie
zastosowanie referencji to przekazywanie argumentów bez konieczności ich kopiowania.
Służą wydajności i są czytelniejsze, niż wskaźniki a pozwalają nie kombinować z
dodatkowymi "trybami" czy innymi "modami" parametrów podprogramów.

> Co takiego staje się możliwe dzięki nim, co nie było możliwe bez nich?

Pisanie bardziej czytelnego kodu. Widać to bardzo dobrze gdy porówna się API
bibliotek mających osobne wersje dla C i C++.

> > W tym wypadku wartością dodaną jest możliwość korzystania z jakieś ograniczonej
formy lambdy, bez konieczności posiadania garbage collectora.
>
> Pierwszy kompilator języka Scheme, ORBIT, dawał ograniczoną
> formę lambdy i nie potrzebował garbage collectora.

W jaki sposób realizował upward-closure?

> > Inaczej - istnieje pewna klasa projektów, w których nikt[*] nie ma lepszej
oferty.
>
> Jeśli pominiemy takie języki jak np. Rust.

Ciekawe:

https://doc.rust-lang.org/1.1.0/book/closures.html

"So if we returned this closure, the function call would be over, the stack frame
would go away, and our closure is capturing an environment of garbage memory!"

Jest podane rozwiązanie tego problemu, ale nie wiem, czy ten mechanizm jest
stosowalny tak samo wygodnie dla różnych przypadków, które można sobie wyobrazić. W
C++ po prostu dano użytkownikom narzędzie i obowiązek do samodzielnego rozstrzygania
takich problemów. W tym przypadku problem nie jest trudny do rozstrzygnięcia i nie
wiem, czy chcę mieć aż tak dużą dodatkową komplikację na poziomie języka, żeby ten
problem rozwiązać.
Tzn. potrafię nie mieć problemu z wiszącymi referencjami w C++ przy składni
prostszej, niż oferuje Rust, więc w tym konkretnym przypadku Rust jest dla mnie
niepotrzebnym kosztem.

Rust jest ciekawym pomysłem (ogólnie w aspekcie zarządzania czasem życia obiektów),
ale potrzeba jeszcze czasu, żeby ocenić jego przydatność w praktyce.
Pod pojęciem praktyki rozumiem np. system, dla którego istnieje kompilator C++ a dla
którego nie istnieje kompilator Rust. Praktyka to również dostępne narzędzia
pomocnicze w rodzaju analizatorów statycznych. Być może Rust zyska sympatię
użytkowników i stanie się popularny, nie potrafię tego jeszcze rozstrzygnąć.

> Standard GNU C

To tak jakbyś napisał "Standard Visual C".

--
Maciej Sobczak * http://www.inspirel.com

do góry