Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32197 > unrolled thread

Uwagi odnośnie książki Stroustrupa

Back to article view | Back to pl.comp.programming

Contents

  Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 07:15 -0800
    Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-01 17:28 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 22:13 -0800
        Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 03:42 -0800
        Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 04:44 -0800
          Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 06:55 -0800
            Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 07:34 -0800
              Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 08:39 -0800
            Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 07:59 -0800
            Re: Uwagi odnośnie książki Stroustrupa Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-01-03 10:43 +0100
    Re: Uwagi odnośnie książki Stroustrupa szykcech@gmail.com - 2019-01-01 21:41 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 22:40 -0800
        Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 01:14 -0800
          Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-03 07:07 -0800
            Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-03 17:41 +0100
            Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 23:15 -0800
              Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-04 00:53 -0800
                Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-06 22:59 -0800
                  Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-07 01:34 -0800
                    Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 00:46 -0800
                      Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 09:51 +0100
                        Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 10:05 +0100
                          Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 01:51 -0800
                            Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 13:33 +0100
                      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-08 02:15 -0800
    Re: Uwagi odnośnie książki Stroustrupa Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-01-02 08:17 +0100
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 06:25 -0800
    Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-02 01:37 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 03:44 -0800

Page 1 of 2  [1] 2  Next page →

#32197 — Uwagi odnośnie książki Stroustrupa

Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
z wykorzystaniem C++".

Choć swoimi pierwszymi wrażeniami już się zdążyłem podzielić,
pomyślałem sobie, że nie zaszkodziłoby przedstawić nieco bardziej
dogłębną analizę moich przekonań dotyczących podejścia, jakie
Stroustrup w niej reprezentuje.

Przykładowy rozdział, który można podejrzeć na stronie Helionu,
a konkretniej rozdział szósty, zatytułowany "Pisanie programu",
dotyczy "prezentacji procesu myślowego, który ma miejsce
podczas wytwarzania oprogramowania".

Stroustrup twierdzi (skądinąd słusznie), że pisanie programu
należy zacząć od sformułowania probelmu, który program ma rozwiązać.
Problemem, jaki Stroustrup stawia, jest domniemana niewiedza
czytelnika, zaś jako rozwiązanie proponuje "program zmuszający
komputer do wykonywania typowych działań arytmetycznych
na wyważeniach, które mu podamy".

Stroustrup nalega również, żeby program działał w "oknie konsoli",
ponieważ wyjaśniał we wcześniejszych rozdziałach "jak posługiwać się
strumieniami `cin` i `cout`, a graficzne interfejsy użytkownika (GUI)
zostaną opisane dopiero w rozdziale 16".

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".

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).

Innymi słowy, Stroustrup chce, żebyśmy na początku naszej drogi
programistycznej nauczyli się w lichy sposób rozwiązywać szereg
problemów, które nie są ani trochę interesujące z perspektywy
zastosowania komputera, których lichość będzie nas prześladować
w przyszłości, i których można by było w ogóle uniknąć.

Nietrudno się domyślić, skąd bierze się takie przekonanie.
Twórcy języka C byli jednocześnie autorami systemu operacyjnego
UNIX. Mieli świadomość, że opracowany przez nich system jest
kompromisem, którego główną cechą ma być przede wszystkim
prostota implementacji i przenośność. Stąd też w UNIXie "wszystko
jest plikiem", zaś pliki to po prostu ciągi bajtów, które
można odczytywać i zapisywać wywołaniami systemowymi "read"
i "write". Dotyczy to w takim samym stopniu danych zapisanych
lokalnie na dysku, jak i urządzeń czy innych komputerów.

Najbardziej rozpowszechniona forma grupowania bajtów
polega na oddzielaniu ich znakiem nowej linii. Na tym
założeniu opiera się większość narzędzi uniksowych, takich
jak `grep`, `sed` czy `tail`. Niestety, to założenie nie pozwala
nam tworzyć "złożonych złożoności". Do tego celu służą jednak
takie pomysły, jak zgrupowany hierarchicznie system plików.

Używanie tego mechanizmu jest jednak do wielu rzeczy
niewygodne. Czasem wolimy zapisać złożoną teksturę w pliku
tekstowym, ponieważ taki plik łatwiej wyświetlić na ekranie,
przesyłać i edytować.

Jednak jeśli zdecydujemy się na taki krok, doświadczymy
pewnych komplikacji:
- musimy mieć sposób konwersji danych z pliku tekstowego
do postaci drzewa (parser)
- dajemy sobie możliwość budowania wadliwych struktur (błędów
składniowych)

Pomimo tych niedogodności, taki model dobrze się rozpowszechnił.

Stroustrup natomiast uznał go za ostateczną prawdę, i wybudował
mu ołtarz w postaci języka C++.

Jeśli ktoś poszukuje całościowego modelu alternatywnego względem
tego z UNIXa, to dobrym przykładem jest środowisko Smalltalka
(np. Pharo albo Squeak). Stworzenie aplikacji kalkulatora dla takiego
środowiska jest znacznie przyjemniejszym ćwiczeniem dla początkujących
osób, niż studiowanie gramatyk BNF (i z funkcjami graficznymi
nie trzeba czekać "do rozdziału 16").

Warto też zapoznać się z s-wyrażeniami języka LISP: jest to składnia
dużo prostsza do parsowania nawet od tego głupiego kalkulatorka,
któremu Stroustrup poświęca tak dużo miejsca, a jej dodatkową
zaletą jest to, że jest to lekki i uniwersalny format serializacji,
którego można używać np. wszędzie tam, gdzie stosuje się XML
(stanowi uniwersalne rozwiązanie zagadnienia "złożonych złożoności").
A co najważniejsze, można ten problem parsowania rozwiązać raz
i dobrze i się nim więcej nie przejmować, a nie wmawiać początkującym,
że to na tym polega programowanie. (Można też ten problem całkowicie
zignorować, i od początku skupić się na bardziej interesujących
zagadnieniach, jak choćby nawet różniczkowanie symboliczne - Stroustrup
nie konstruuje przecież w swojej książce parsera dla C++a, tylko
dla wyrażeń arytmetycznych.)

Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.
Podobnie jak tę książkę.

Najlepszego wszystkim w nowym roku.

[toc] | [next] | [standalone]

#32201

W dniu wtorek, 1 stycznia 2019 16:15:42 UTC+1 użytkownik godek....@gmail.com napisał:
> Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
> spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
> z wykorzystaniem C++".
> 
> Choć swoimi pierwszymi wrażeniami już się zdążyłem podzielić,
> pomyślałem sobie, że nie zaszkodziłoby przedstawić nieco bardziej
> dogłębną analizę moich przekonań dotyczących podejścia, jakie
> Stroustrup w niej reprezentuje.
> 
> Przykładowy rozdział, który można podejrzeć na stronie Helionu,
> a konkretniej rozdział szósty, zatytułowany "Pisanie programu",
> dotyczy "prezentacji procesu myślowego, który ma miejsce
> podczas wytwarzania oprogramowania".
> 
> Stroustrup twierdzi (skądinąd słusznie), że pisanie programu
> należy zacząć od sformułowania probelmu, który program ma rozwiązać.
> Problemem, jaki Stroustrup stawia, jest domniemana niewiedza
> czytelnika, zaś jako rozwiązanie proponuje "program zmuszający
> komputer do wykonywania typowych działań arytmetycznych
> na wyważeniach, które mu podamy".
> 
> Stroustrup nalega również, żeby program działał w "oknie konsoli",
> ponieważ wyjaśniał we wcześniejszych rozdziałach "jak posługiwać się
> strumieniami `cin` i `cout`, a graficzne interfejsy użytkownika (GUI)
> zostaną opisane dopiero w rozdziale 16".
> 
> 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".
> 
> 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).
> 
> Innymi słowy, Stroustrup chce, żebyśmy na początku naszej drogi
> programistycznej nauczyli się w lichy sposób rozwiązywać szereg
> problemów, które nie są ani trochę interesujące z perspektywy
> zastosowania komputera, których lichość będzie nas prześladować
> w przyszłości, i których można by było w ogóle uniknąć.
> 
> Nietrudno się domyślić, skąd bierze się takie przekonanie.
> Twórcy języka C byli jednocześnie autorami systemu operacyjnego
> UNIX. Mieli świadomość, że opracowany przez nich system jest
> kompromisem, którego główną cechą ma być przede wszystkim
> prostota implementacji i przenośność. Stąd też w UNIXie "wszystko
> jest plikiem", zaś pliki to po prostu ciągi bajtów, które
> można odczytywać i zapisywać wywołaniami systemowymi "read"
> i "write". Dotyczy to w takim samym stopniu danych zapisanych
> lokalnie na dysku, jak i urządzeń czy innych komputerów.
> 
> Najbardziej rozpowszechniona forma grupowania bajtów
> polega na oddzielaniu ich znakiem nowej linii. Na tym
> założeniu opiera się większość narzędzi uniksowych, takich
> jak `grep`, `sed` czy `tail`. Niestety, to założenie nie pozwala
> nam tworzyć "złożonych złożoności". Do tego celu służą jednak
> takie pomysły, jak zgrupowany hierarchicznie system plików.
> 
> Używanie tego mechanizmu jest jednak do wielu rzeczy
> niewygodne. Czasem wolimy zapisać złożoną teksturę w pliku
> tekstowym, ponieważ taki plik łatwiej wyświetlić na ekranie,
> przesyłać i edytować.
> 
> Jednak jeśli zdecydujemy się na taki krok, doświadczymy
> pewnych komplikacji:
> - musimy mieć sposób konwersji danych z pliku tekstowego
> do postaci drzewa (parser)
> - dajemy sobie możliwość budowania wadliwych struktur (błędów
> składniowych)
> 
> Pomimo tych niedogodności, taki model dobrze się rozpowszechnił.
> 
> Stroustrup natomiast uznał go za ostateczną prawdę, i wybudował
> mu ołtarz w postaci języka C++.
> 
> Jeśli ktoś poszukuje całościowego modelu alternatywnego względem
> tego z UNIXa, to dobrym przykładem jest środowisko Smalltalka
> (np. Pharo albo Squeak). Stworzenie aplikacji kalkulatora dla takiego
> środowiska jest znacznie przyjemniejszym ćwiczeniem dla początkujących
> osób, niż studiowanie gramatyk BNF (i z funkcjami graficznymi
> nie trzeba czekać "do rozdziału 16").
> 
> Warto też zapoznać się z s-wyrażeniami języka LISP: jest to składnia
> dużo prostsza do parsowania nawet od tego głupiego kalkulatorka,
> któremu Stroustrup poświęca tak dużo miejsca, a jej dodatkową
> zaletą jest to, że jest to lekki i uniwersalny format serializacji,
> którego można używać np. wszędzie tam, gdzie stosuje się XML
> (stanowi uniwersalne rozwiązanie zagadnienia "złożonych złożoności").
> A co najważniejsze, można ten problem parsowania rozwiązać raz
> i dobrze i się nim więcej nie przejmować, a nie wmawiać początkującym,
> że to na tym polega programowanie. (Można też ten problem całkowicie
> zignorować, i od początku skupić się na bardziej interesujących
> zagadnieniach, jak choćby nawet różniczkowanie symboliczne - Stroustrup
> nie konstruuje przecież w swojej książce parsera dla C++a, tylko
> dla wyrażeń arytmetycznych.)
> 
> Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.
> Podobnie jak tę książkę.
> 
> Najlepszego wszystkim w nowym roku.

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)

wielokroc chyba juz mowilem jak to widze:
to jak cos szybko i sprawnie zrobisz zalezy juz bardziej od biblioteki niz od jezyka i od jej znajomosci, no i od umiejetnosci klecenia programu...sama jakosc docelowa moze zalezec od jezyka/platformy ale to nie ma tez takiego znaczenia bo ew mozna przeportowac

co ma znaczenie pierwszorzedne wobec 
tego? chyba to co stanowi nawieksze problemy i jest realna przeszkoda by zrobic cos dobrego

a co to jest? to jest wlasnie moim zdaniem dobre pytanie (w tym sensie ze odpowiedz na nie moglaby duzo dac)

ja na nie zwykle odpowiadam tak ze sa to
w moim wypadku
1) przeszkody psychologiczne (czy tez moze raczej mentalno energetyczne).. moze nie tyle ciezko mi sie za cos wziac, (bo wziac sie za cos w kodowaniu jest mi dosyc latwo), ale ciezko mi sie zmusic 
by to dlugo robic i sie nie wypalic ..
a jak sie wypale by jakos w miare szybko do tego wrocic


2) problemy 'koncepcyjne' 

A]
- niektore rzeczy sa dosyc latwe do pisania, [wystarczyla by wiac ta energia z punktu 1 i by sie nie meczyc i by miec ogromna ilosc czasu i sie nie starzec itd itd i mozna pisac (chyba bo nawet tego nie jestem pewien)]

[
a1) przykldem takiego programu ktory sam sie niemal pisze byl np edytor tekstu jaki troche pisalem w zeszlym roku, zasadniczo bralo sie to i pisalo, pozatym bezprobloemowo..natrafilem co prawda na pewne problemy zwiazane z tym jak dziala gdi do rysowania fontow (chodzilo o to ze
nie wiem jak zrobic tak by przeplatanie rysowanie fontow na ekranie i rysowań per pixel na tym samym ekranie bylo 'naturalnie' wydajne, bo to co znalazlem 
wymagalo blitowania w tą i z prwrotem przy kazdym takim przeplocie wiec w ogolnosci by zarznelo program -- nie znalazlem czy da sie to obejsc bo nie chcialo mi sie tracic czasu na dlugie czytania -- ale zakladam ze pewni ejest jakis sosob by to zadzialalo jak trzeba,
w najgorszym wypadku musialbym sobie generowac fonty bitmapowe ofscreen tym gdi i wtedy rysowac je jak sprity)
a2) innym przykladem bylo pisanie gry roguelike - tez zasadniczo sie bralo i pisalo.. nie kojarze jakichs wiekszych koncepcyjnych problemow..
a3) moglbym podac wiecej taich przykladow ale mi sie nie chce na to tracic czasu naw ymienienie tego (... doodam ze chyba nawet pisaie kompilatora poprawionego c trafia do tej 'latwej' kategorri.. "sie bierze i sie pisze")

]

B]

 - ale niektore programy do pisania takie nie są..czesc tez byc moze nalezy do takiej kategorii ze z poczatku sie bierze i sie pisze a pozniej przechodza w druga kategorie

ta druga kategoria to co takiego ze "sie bierze ale sie nie pisze" ew "sie nie bierze bo sie nie chce (?)" 

mozna by sie zastanowic na czym to polega bo te przypadki mnie conieco przygnebialy 
czy wprowadzaly w jakis miks zlego humoru

co prawda jest juz nieco pozno jak to pisze i nie wiem czy to jest dobry moment by to probowac wymianiac, ale moze w jakims cienkim szkicu 

b1) pewne rzeczy bym ew mogl napisac ale mi sie nie chce tego robic bo widze to jakos zbyt malo konkretnie..ew wydaje mi sie ze to za duzo roboty na ktora nie mam nastroju..problem jest moze w tym ze wydaje mi sie ze niektore rzeczy moze i daloby sie zrobic ale nie ma gwarancji ze to dobrze wyjdzie i mi si enie chce tegio robic i zarazem jest to chyba sporo roboty.. troche mi sei nie chce wymieniac co to jest ale moze np
-) powiedzmy ze chce zrobic gre oparta na animacjach, te operacje tzreba rysowac i trzeba tez zrobic tai system przejsc miedyz jej roznymi odnogami bo nei chialbym by onebyly zbyt kanciaste tylko takie berdziej realistyczne... to niby jest do zrobienia ale dla mnie jaos nie nalezy do kategori A tylko wlasnie do B
(ze wzgledu jedna bardziej na 'duzo roboty brak gwarancji' niz na scisle 'nie wiadomo co zrobic')
-) sa pewne rzeczy ktorych zrobienie tez nie zakrawa na ciezkie do wykoncypowania ale wymaga czytania np na msdnie czy gdzies (np o tym przpelataniu fontow, albo o raw input do myszy, albo o socketach) a mi sie tego nie che robic
bo uwazam to za troche malo atrakcyjne, ew o czyms z matematyki jak np kiedys chciaem zgrac swoje wyniki z rasteryzacji z wynikami z raytracingu bo wyszlo mi ze to sie bedzie lekko rozjeżdzac, ze wzgledy na przyblizenia w perspektywie w rasteryzerze (cyba, moge troche nie pamietac) i tego tez mi si eni chcialo robic (i ciagle nie chce)... to moze nie jest scisle kategoria B ale troche na nia wchodzi ..kaegoria AB powiedzialbym
b2) sa pewne rzeczy ktorych realnie nie wiem jak zrobic choc wiem ze ludzi to rozgryzli, musialbym sie jednak douczyc.
konkretnie np w zeszlym roku costa dlubalem prosta symulacje z odbijaniem sie kulek ale taka ze mogly sie sklejac 
w takie sprezyste dosyc czasteczki..okazalo sie ze oja metoda licznie tego mimo ze z grubsza dzial wyjebscie tak jak chcialem scilse nie zachowuje energii - by to zglebic musialbym sie porzadniej tej fizyki anuczyc a mi sie nie chce (nie chcodzi o to ze nie moglbym tylko ze cenie swoj czas bo czas mojego zycia jest ograniczony) - moze ten przypadek wyglada 
w sumie podobnie do tego AB wczesniej wymienionego (typu "zrobilbym ale mi sie nie chce czytac") ale tutaj moze mam na mysli troche trudniejsza klase problemow gdzie te studia by cos zrobic musialybybyc powiedzmy dluzsze (niz nawet 2 czy 3 tygodnie studiowania artylkow w necie)
b3) bywaja jeszcze gorsze problemy bo w tych wyzej przynajmniej z grubsza wiadomo 
ze jak cos potestuje narobie sie i ew przeczytam kupe googla to cos zrobie (placac za to jakims wiekszym kosztem czasowym typu miesiac czy dwa) ale sa problemy bardziej mgliste gdzie problem polega chyab na tym ze nie wystarczy czytac jakies papiery na dany temat tylko samemmu trzeba cos 'zresearchowac' obadac i wytworzyc takie papiery... dla mnie np robenie ai zakrawalo troche o takie cos..
byuc moze widzialem to zwykle nieco zyt pesymistycznie ale by ai dzialalo jak tzreba wydawalo mi sie trzebbylo nawymyslac jakies reguly (czym te postaci maja byc ograniczane) pozniej jak maja w ich ramach dzialac i to nie jest cos na co jest prosty przepis bo jak sie zrobi poprstu cos co przyjdzie do glowy to toz adziala ale spektakularnosc tego bedzie bliska zeru
jak sie nie wie o czym mowie to moze nie wydaje sie takie ciezkie ale problem jest naprawde trudny - to cos takiego jak by ktos powiedzial "napisz dobry maly sceneriusz filmu dla hollywood" niby proste ale tak naprawde troche ciezko z tym

tu sie troche wlasnie chyab gubie z tym wyliczaniem, gdy robis ie trudniej bu tu te problemy pewnie mozna podzilic a wiecej roznych przypadkow..no ale wlasnie tosa problematyczne kwestie i urwe moze te wylicznie i opisywanie zwlaszcza ze pozno sie zrobilo

generalnie chodzi wlasnie o to ze to sa wlasnie istatnie problemy (zwlaszcza ta kategoria pzniejszego B zdaje sie) a nie raczej bzdurne problemiki jaki to jezyk jest lepszy, albo straszliwe problemy z debugowaniem i inne malo wazne bzdury

[toc] | [prev] | [next] | [standalone]

#32203

W dniu środa, 2 stycznia 2019 02:28:38 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.

Jeśli cokolwiek, to z rzeczy, które robisz, bardziej interesowałoby mnie to C2.
Moim zdaniem używane przez nas języki programowania mają kolosalny wpływ na nasze myślenie o problemach, zaś perspektywa, którą prezentuje Stroustrup, poniekąd wymusza błędne myślenie o problemach, albo rozwiązywanie nie tych problemów, co trzeba.

Obszar badań, który mnie interesuje, to zwiększanie ekspresywności pracy z komputerem - żeby móc łatwo i szybko przechodzić od pomysłów do działających programów.

Lubię refren tej piosenki:

https://www.youtube.com/watch?v=hHdvmblt948

[toc] | [prev] | [next] | [standalone]

#32211

W dniu środa, 2 stycznia 2019 07:13:45 UTC+1 użytkownik godek....@gmail.com napisał:
> W dniu środa, 2 stycznia 2019 02:28:38 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. 

lol, roznica nie dotyczy tego kto robi tylko "nieistotnych argumentow" w "dziwnych klotniach" ;c

> 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.
> 
> Jeśli cokolwiek, to z rzeczy, które robisz, bardziej interesowałoby mnie to C2.

sporo wymyslilem w tym temacie i C2
przy okazji przemianowalem n "hipermodulowe c" 

te druga nazwa jest z pewnych wzgledow lepsza, mianowicie z tgo ze ja w sumie zawsze chcialem robic cos jakby rozwiniecie c trzymajace sie jego glebokiego ducha, [[z drugiej strony 
uwazam obecnie ze nie nalezy  'przejmowac' ani naruszac starego c 
(tak jak robia ludzi produkujac nowa wersje czegostam, za duzo tych wersji i upgradow w swiecie programowani)
bo to by powiekszalo wersjacyjny smiernik,]] nazwa hipermodulowe c jakos laczy jedno z drugim (tj ze to jest c i ze to jest inne c), nieco lepiej niz C2
(z nazwa C2 tez sie calkiem nie pozegnalem ale poki co raczej egzystuje ona jako nazwa tego co wczesniej okreslalem jako C2)

o hipermodulowym c narazie nie che mi sie za duzo pisac, ale z grubsza chodzi o to ze szitowata objektowosc tutaj w tym jezyku zostala jakby wyparta/zniszczoan przez naturalną "encjalnosc" jak w c,
tj to co w c++ i in jest clasa i obiektem tutaj jest tak naturalne i wbudowane jak int i jak importowany modul z drugiej strony

moduel, czyli binarnie i zrodlowo odzielny kawalek kodu z wlasnymi zmiennymi stanu i wlasnymi funkcjami 
jest tu zunifilowany ze strukturą z
c (modul i struktura jest tym samym, struktura to modul a modul to struktura)
a to wszystko jest z kolei zunifikowana z typami prostymi jak np int czy float

module X
{
  int n;
  void f00() { n++; }
}


znaczy to m.in. ze do struktury mozesz dodawac funkcje jak do modulu, z drugiej strony mozesz ja jakby z automatu zamienic na odzielna dllke (jak modul),
z trzeciej strony mozesz to traktowac jak typ prsty (i uzywac jak inta, tj np zdefiniowac operatory, albo napisac sobie wlasnego inta, albo np zrobic sobie tablice modulow w naturalny sposob)

X tabx[100]; //tablica stu modoluw X


roznica miedzy szit klasami jest znaczna chodzi np o to ze widzialnosci miedzy tymi modulami masz jak w c tj nie przekazyjesz wskaznikow i nei budujesz jakis kretynicznych grafow tylko widzisz to wszystko 'normalnie' tak jak struktury w kodzie

to jest znaczaca cecha tego jezyka przez to ze te moduly nabraly tych znacznych dodatkowych opcji (tj zachowuja sie jak typy wbudowane) zwiekszajacych ich mozliwosci uznalem ze nazwa hipermodulowe c jest adekwatna

ciegle sie tym co nieco zajmuje choc w ostatnim roku mniej, ale i nawet w ostatnim roku costam ciekawego bylo

na przyklad ta opcja do zajmowani sie bledami o ktroej tu psialem byla ciekawa

int foo(int x, int y) 
{
  if(y==0) error;
  return x/y;
}

int main()
{
  int x = foo(3,0) on_error { printf("err")}

}
to jest calkiem porzadne bo duzo mowi o tym jak nalezy podchodzic do bledow w c

a zupelnie ostatnio pisane byla opcja do definiowania sobie konstrukcji jezyka np ten compactowy-for jako cos w stylu


void deformed_for(block setup; 
                block condition; 
                   block loop_epilogue) { block content; } : 
{ 
  steup; 
  while(condition) 
  { 
     content; 
     loop_epilogue; 
  } 

} 

chodzi o to ze mozna tu definiowac po prostu swoje konstrukcje jezyka podobne do for(;;) switcha itd -a le to nowy wynalazek i jeszcze nie rpzemsylalem jakie powinny byc scisle reguly budowania
kodow z tych blokow 

inna wazna rzecz to wieksze opracowanie
resizowalnych tablic do prostej tes skladni typu

void foo()
{
 int tab[10];

 tab.size+=10; //tab ma rozmiar 20

}

mozna takie tablice robic na stosach (ale jezyk powinien wtedy raczej dostarczac wiecej stosow programiscie) lub na reallocu lub na statycznym ramie z rezerwą... w kazdym razie taka tabka resizowalna w tej milusiej skladni to jest cos przyjemnego


> Moim zdaniem używane przez nas języki programowania mają kolosalny wpływ na nasze myślenie o problemach, zaś perspektywa, którą prezentuje Stroustrup, poniekąd wymusza błędne myślenie o problemach, albo rozwiązywanie nie tych problemów, co trzeba.
> 

ta persopektywa stroustrupa jest dosyc licha ale to o czym ja mowie to ze nie ma to zbytniego znaczenia bo roznic w jezykach to nie sa glowne problemy..wiekszym problemem juz chocby niezajmowanie sie glownymi problemami

> Obszar badań, który mnie interesuje, to zwiększanie ekspresywności pracy z komputerem - żeby móc łatwo i szybko przechodzić od pomysłów do działających programów.
> 

to mniej zalezy od jezyka co raczej od bibliotek - ale i to nie jest glownym problemem 

> Lubię refren tej piosenki:
> 
> https://www.youtube.com/watch?v=hHdvmblt948

[toc] | [prev] | [next] | [standalone]

#32215

W dniu środa, 2 stycznia 2019 07:13:45 UTC+1 użytkownik godek....@gmail.com napisał:
> W dniu środa, 2 stycznia 2019 02:28:38 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,
(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 )
z tego ze jest duzo edytorow nie wynika ze jak ktos napisze edytor/asembler/roguelike to nie moze zrobic w tym edytorze nic nowatorskiego..
dla mnie akurat te projekty byly nowatorskie (wewnetrznie i zewnetrznie)
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)

[toc] | [prev] | [next] | [standalone]

#32218

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.

[toc] | [prev] | [next] | [standalone]

#32219

W dniu środa, 2 stycznia 2019 15:55:51 UTC+1 użytkownik godek....@gmail.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.

[toc] | [prev] | [next] | [standalone]

#32221

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.

[toc] | [prev] | [next] | [standalone]

#32220

W dniu środa, 2 stycznia 2019 15:55:51 UTC+1 użytkownik godek....@gmail.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

[toc] | [prev] | [next] | [standalone]

#32227

W dniu 2019-01-02 o 15:55, godek.maciek@gmail.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

[toc] | [prev] | [next] | [standalone]

#32202

Wystarczy spojrzeć na spis treści by stwierdzić, że programowanie grafiki to rozdziały 12-16 a nie sam 16. Tym nie mniej nie jest jasne co to za biblioteka została zaprezentowana. W każdym razie jest to zgodne z jakąś manierą "z dala od Qt". No i dodatek C: Visual Studio...
Ja tak że dziękuję...
W moich czasach (20 lat temu) standardem nauki C++ była "Symfonia C++" dr. Jerzego Grębosza (fizyka). Obecnie jej nowe wcielenie jest od ponad roku sprzedawane jako "Opus Magnum". Aktualizacja obejmuje uwzględnienie standardu C++11. 1696 stron bez bibliotek graficznych.

[toc] | [prev] | [next] | [standalone]

#32204

W dniu środa, 2 stycznia 2019 06:41:19 UTC+1 użytkownik szyk...@gmail.com napisał:
> Wystarczy spojrzeć na spis treści by stwierdzić, że programowanie grafiki to rozdziały 12-16 a nie sam 16. Tym nie mniej nie jest jasne co to za biblioteka została zaprezentowana. W każdym razie jest to zgodne z jakąś manierą "z dala od Qt". No i dodatek C: Visual Studio...
> Ja tak że dziękuję...
> W moich czasach (20 lat temu) standardem nauki C++ była "Symfonia C++" dr. Jerzego Grębosza (fizyka). Obecnie jej nowe wcielenie jest od ponad roku sprzedawane jako "Opus Magnum". Aktualizacja obejmuje uwzględnienie standardu C++11. 1696 stron bez bibliotek graficznych.

Spojrzałem sobie na "próbny" rozdział 30 "Wyrażenia lambda i wysyłanie kodu do innych funkcji": https://www.ifj.edu.pl/private/grebosz/Opus_C++11_lambda_fragment.pdf

Znamienne, że w "Strukturze i Interpretacji Programów Komputerowych" wyrażenia lambda pojawiają się już w pierwszym rozdziale, ponieważ funkcje stanowią podstawowy mechanizm abstrakcji (i to nie tylko w językach takich jak Scheme czy JavaScript, ale również abstrakcji jako takiej, o czym pisałem tutaj: https://www.quora.com/What-is-the-difference-between-simplification-and-abstraction/answer/Panicz-Godek)

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ę.

[toc] | [prev] | [next] | [standalone]

#32226

> 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

[toc] | [prev] | [next] | [standalone]

#32230

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/anonymous-functions-using-gcc-statement-expressions

[toc] | [prev] | [next] | [standalone]

#32234

On 2019-01-03 16:07, godek.maciek@gmail.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

[toc] | [prev] | [next] | [standalone]

#32243

> > 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

[toc] | [prev] | [next] | [standalone]

#32246

W dniu piątek, 4 stycznia 2019 08:15:55 UTC+1 użytkownik Maciej Sobczak napisał:

> > Co w takim razie wnoszą referencje w C++? (oprócz niepotrzebnej komplikacji)
> 
> Uwaga: dopiero co usiłowałeś udowodnić, że operator przypisania jest niepotrzebny.

Tak?
W którym miejscu próbowałem "udowodnić coś takiego"?

Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
które napisałem, zamiast do tych, które wydaje Ci się,
że napisałem, obaj byśmy na tym skorzystali.

> 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ć.

A jednak coś komplikują.

> 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.

Kwestia tego, czy występuje "konieczność kopiowania" argumentów, ma
sens tylko w kontekście, w którym dokonujemy modyfikacji argumentó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++.

Dzięki. Lubię konkrety, a w szczególności obiektywne sformułowania
w rodzaju "bardziej czytelny kod".

> > > 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?

Używając garbage collectora napisanego w Schemie bez 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".

Być może. Takie użycie sugeruje sam komplikator, do którego podaje się
flagę -std=gnu99 (zamiast np. -std=c99).

[toc] | [prev] | [next] | [standalone]

#32274

> Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
> które napisałem, zamiast do tych, które wydaje Ci się,
> że napisałem, obaj byśmy na tym skorzystali.

Przecież się nie da. Muszę odnosić się do tego, co mi się wydaje. Potem Ty musisz się denerwować tym, co Ci się wydaje, że ja się odniosłem. Żeby było śmieszniej, żaden z nas nie jest w stanie udowodnić, że tego nie robi. Taka już nasza niedoskonałość.

> Kwestia tego, czy występuje "konieczność kopiowania" argumentów, ma
> sens tylko w kontekście, w którym dokonujemy modyfikacji argumentów.

Nie, to jest też kwestia miejsca wywołania (nie wszystko co wołający chciałby przekazać można przekazać przez referencję), wydajności, semantyki wyjątków oraz wielowątkowości. W C++ te rzeczy są ważne. Oczywiście, są też języki, gdzie te rzeczy nie są ważne.

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

Nic, czego by się nie dało zrobić maszyną Turinga. Ale ludzie jednak wolą to mieć, niż nie mieć.

> Dzięki. Lubię konkrety, a w szczególności obiektywne sformułowania
> w rodzaju "bardziej czytelny kod".

Ja nie mam żadnego problemu z subiektynymi sformułowaniami. Zwłaszcza po Twojej deklaracji z innego postu, że przedstawiasz tutaj swoje wrażenia i opinie nt. 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?
> 
> Używając garbage collectora napisanego w Schemie bez upward-closure.

Rozumiem. W C++ też nie ma garbage-collectora właśnie po to, żeby można było go sobie samemu napisać.

> > > Standard GNU C
> > 
> > To tak jakbyś napisał "Standard Visual C".
> 
> Być może. Takie użycie sugeruje sam komplikator, do którego podaje się
> flagę -std=gnu99 (zamiast np. -std=c99).

Ja trochę inaczej rozumiem słowo "standard". Subiektywnie, oczywiście.

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

[toc] | [prev] | [next] | [standalone]

#32276

W dniu poniedziałek, 7 stycznia 2019 07:59:29 UTC+1 użytkownik Maciej Sobczak napisał:
> > Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
> > które napisałem, zamiast do tych, które wydaje Ci się,
> > że napisałem, obaj byśmy na tym skorzystali.
> 
> Przecież się nie da. Muszę odnosić się do tego, co mi się wydaje. Potem Ty musisz się denerwować tym, co Ci się wydaje, że ja się odniosłem. Żeby było śmieszniej, żaden z nas nie jest w stanie udowodnić, że tego nie robi. Taka już nasza niedoskonałość.

Pomijając może ekstremalne filozoficzne eksperymenty myślowe w rodzaju
"demona Kartezjusza" czy sceptycyzmu Berkeleya, w tzw. 
"zdroworozsądkowej" metafizyce nie ma powodów, żeby uznać, 
że nie masz całkowitego wglądu w to, co napisałem.

Możesz nie mieć wglądu w to, co miałem na myśli (a właściwie
to według mojej wiedzy raczej nie możesz mieć w to wglądu),
ale to, co napisałem, jest raczej obiektywnie (bądź co najmniej
intersubiektywnie) weryfikowalne.

I tak na przykład, pisałem, żeby unikać operacji przypisania tam,
gdzie to nie jest konieczne. Możesz to sprawdzić, przeglądając
historię naszej rozmowy.
Możesz też sprawdzić (ponieważ dziedzina naszej rozmowy jest
skończona), że nigdzie tam nie pisałem, że "operator
przypisania jest niepotrzebny".

Oczywiście nie chodzi o to, żeby być obsesyjnym formalistą
w komunikacji: każdy ma przecież prawo do wyciągania swoich
własnych wniosków z tego, co mówię i tego, co mówią inni.

Ale w takiej sytuacji, jeżeli wyciągasz jakiś własny wniosek
z czyjejś wypowiedzi, i ten wniosek jest dość daleki od
oryginalnych słów, to zamiast atakować rozmówcę w oparciu
o ten wniosek, możesz powiedzieć coś w rodzaju:

"Powiedziałeś X. Z mojego rozumowania wynika, że pociąga to za sobą Y,
ale być może wplatam w to jeszcze jakieś swoje dodatkowe przesłanki.
Czy zgodziłbyś się ze stwierdzeniem, że Y?"

Ja domniemywam, że po żadnej ze stron nie ma złej woli.
Mam też wrażenie, że "zimność" komunikacji internetowej mocno
zaburza przekaz emocjonalny (czasem nawet jak rozmawiam ze swoimi
bliskimi znajomymi na czacie internetowym, to przekaz emocjonalny
tak się zniekształca, jakbyśmy byli najgorszymi wrogami, którzy
chcą się pozabijać)

Ale moja percepcja Twoich słów jest taka, że nie wypowiadasz
ich po to, żeby dowiedzieć się, co mam na myśli, tylko po to,
żeby udowodnić mi, że nie mam racji.
Może Twoja prawdziwa motywacja jest inna - to akurat wiesz
tylko Ty - ale ja nie mam ani czasu, ani siły, ani ochoty do tego,
żeby bronić się przed atakami, bo nie przyszedłem tutaj
po to, żeby walczyć, tylko po to, żeby wymieniać się
doświadczeniami.

Jeżeli zarzuciłbyś mi, że wypowiadam się nieprecyzyjnie, to
oczywiście musiałbym się z tym zarzutem zgodzić. Mam wrażenie,
że nieprecyzyjność jest naturalną cechą języka naturalnego,
i próby używania go w sposób hiper-precyzyjny są skazane na porażkę
(między innymi dlatego cenię sobie języki programowania, bo
pozwalają się komunikować w sposób hiper precyzyjny bez żadnego
miejsca na niejednoznaczność)

[toc] | [prev] | [next] | [standalone]

#32282

> I tak na przykład, pisałem, żeby unikać operacji przypisania tam,
> gdzie to nie jest konieczne.

I od samego początku ta teza nie została poparta żadnym przykładem. Zmienne statyczne omówiliśmy, ale czy ich przykładowe nadużycie jest jedynym takim miejscem? Gdzie jeszcze nie jest konieczne?

> nigdzie tam nie pisałem, że "operator
> przypisania jest niepotrzebny".

Przepraszam za skrót myślowy. Łączę tą kwestię z ogólną niechęcią zwolenników programowania funkcjonalnego do modyfikowalnego stanu.

> Ale moja percepcja Twoich słów jest taka, że nie wypowiadasz
> ich po to, żeby dowiedzieć się, co mam na myśli, tylko po to,
> żeby udowodnić mi, że nie mam racji.

Inaczej: mając wrażenie, że dowiedziałem się już, co masz na myśli, udowadniam, że nie masz racji. :-) Jest bardzo możliwe, że gdzieś się mijamy w naszych wrażeniach, ale ponieważ dziedzina jest techniczna, to zawsze staram się odwoływać do przykładów (albo prosić o przykłady) z kodem.

> (między innymi dlatego cenię sobie języki programowania, bo
> pozwalają się komunikować w sposób hiper precyzyjny bez żadnego
> miejsca na niejednoznaczność)

Właśnie.

A skoro i tak weszliśly już w tym podwątku na poziom miękki, to pozwolę sobie na drobne wyjaśnienie. Być może masz wrażenie, że się Ciebie czepiam dla samego czepiania, ale moja perspektywa jest inna. Otóż padło tutaj w dyskusji N zarzutów wobec różnych rzeczy (książki, języka, paradygmatu, itd.) cieszących się w miarę szerokim poważaniem i wśród tych zarzutów jest M, z którymi się nie zgadzam. A ponieważ na tej grupie jest bardzo mało okazji do dyskusji, więc korzystam z tych M. Gdyby te N zarzutów było napisanych przez N różnych grupowiczów, to również wtedy nie zgodziłbym się z M z nich i odniósłbym się do nich (z grubsza) w taki sam sposób.
Tymczasem zupełnym przypadkiem te M dyskusyjnych kwestii pochodzi od jednego grupowicza. Tak, jesteś jedyną osobą, która w ostatnim czasie konsekwentnie forsuje tutaj pewien nurt techniczny, który z racji swojej dzisiejszej niszowości jest kontrowersyjny (co nie znaczy, że nowatorski a przez to nieznany). Inaczej mówiąc, fakt, że spada na Ciebie cały ogień obrony jest z mojego punktu widzenia wyłącznie przypadkiem, jeśli nie Twoją winą, skoro jesteś jedynym atakującym. :-)

To rzekłszy, dawno temu był tu grupowicz podpisujący się jako Qrczak. Forsował mniej więcej te same poglądy a nawet popełnił własny język programowania o nazwie Kogut (http://kokogut.sourceforge.net/kogut.html). Nie wykluczam, że go znasz. Niestety nie zagląda już tutaj, ale jestem przekonany, że świetnie byście się dogadali, na pewno z korzyścią dla grupy.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pl.comp.programming

csiph-web