On 2019-01-08 09:08, Wojciech Muła wrote:
> On Monday, January 7, 2019 at 11:23:26 AM UTC+1, g...@g...com wrote:
>> Może. Ale może też problem, na który się powołujesz, jest bardzo
>> specyficzny (również ze względu na kontekst swojego powstawania).
>> Większość programistów, jakich znam, nie implementuje swojego MD5.
>
> Nawet nie wiesz, jakie to jest śmieszne w wątku, gdzie na
> poważnie dyskutuje się o sumowaniu kwadratów n początkowych
> liczb pierwszych. :)
>
> w.

1. W tym watku _nie dyskutuje sie_ o sumowaniu kwadratow
poczatkowych liczb perwszych. To klasyczny "learning by example".
PS: Smieszne to rzeczywiscie bylo (w innym watku) podnoszenie (przez
Szanownych Ayatollahow badziewia zwanego C++) sprawy niemoznosci
zrobienia listy/standardowej kolekcji prymitywow Javowych jako niby
wada samej Javy jako jezyka. Tymczasem jest to wylacznie sprawa
takiej a nie innej implementacji biblioteki, a implementacji
nie majacych tej "wady" co niemiara (ze wspomne chocby o
https://www.eclipse.org/collections/ - ze "niestandardowa"?
heh, o wiele bardziej standardowa dla Javy niz boost czy Qt dla C++.
Nie spotkalem Javovca ktory nie bylby za pan brat z Eclipse
i jego srodowiskiem).
2. W tym watku dyskutuje sie o badziewnosci i trupowatosci C++
w stosunku do innych jezykow programowania.
PS:Az dziw mnie bierze, ze Szanowna Mlodziezy - tak przecie z
natury "Nowoczesna" i "do przodu" tak broni tego emeryta i kołtuna
zwanego C++ :).

AK

do góry

> > Rozumiem. Mamy więc (niezaskakujący) wniosek, że różne języki są właściwe do
różnych problemów.
>
> Pytanie, jaki dalszy wniosek możemy wyciągnąć z tego wniosku.
> Może na przykład taki, że rozsądnie byłoby eksplorować języki,
> które ułatwiają projektowanie języków.

Zgadzam się. Dlatego, jak już wspomniałem, podoba mi się język Wolfram, bo dzięki
swojej umiarkowanej lispowatości świetnie nadaje się do tworzenia tzw.
Domain-Specific Languages. Zastanawiam się nad możliwością użycia tego do opisu
wymagań, które można weryfikować albo z których można generować właściwy kod (albo
testy).
Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego
odbiorcy.

> Możesz zerknąć w przykłady programów liczących sumę kwadratów
> początkowych siedmiu liczb pierwszych, które przewinęły się
> przez ten wątek (to było w odpowiedzi na post AK).
> Tam dokładnie pokazałem przykład rozumowania podstawieniowego.

Ależ ja go rozumiem i od początku staram się tu zrobić konfrontację tych koncepcji.
"Przykład rozumowania podstawieniowego" nie pokazuje żadnej przewagi nad tym
imperatywnym oryginałem, z dwóch powodów:

1. Nie widać w nim długoterminowych zalet w aspekcie utrzymania kodu. Wyobraź sobie,
że klient dostał ten program i jest zadowolony, ale przecież jesteśmy agile, więc
klient od razu wpada na nowy pomysł: "a jeszcze tak sobie pomyślałem, że te liczby,
które nie są pierwsze, też by można do siebie dodać".
Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe*
wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał,
że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji
imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać,
bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program
i napisać go od nowa (pokażesz?). To jest potencjalnie poważny problem i nie tylko
dlatego, że klient nie zrozumie, dlaczego tak ma się stać.
Ten przykład w całości jest sztuczny (serio: nikt nie rozwiązuje takich problemów),
ale nie wynika z niego, że powyższy problem nie wystąpi w większej (ilościowo albo
czasowo) skali. Ciekawym aspektem do rozważenia jest to, że to, co Ty traktujesz jako
wymagania ("dodaj ... itd.") to nie są jedyne wymagania, z jakimi musi się zmierzyć
inżynier. Niejawnymi wymaganiami są też kwestie wydajności (sam widziałeś) i
utrzymanie projektu w długim terminie. "Paradygmat podstawieniowy" tych problemów sam
z siebie nie adresuje a przez to jest rozwiązaniem nie tylko niekompletnym ale może
być wręcz ograniczającym.

2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej.
Analizatory kodu (np. takie, które sprawdzają statycznie, czy ktoś nie wyjeżdża poza
tablicę albo nie dzieli przez zero) wykonują weryfikację właśnie przez podstawienia i
przez rozwiązywanie równań.

> Większość programistów, jakich znam, nie implementuje swojego MD5.

To samo mogę powiedzieć o każdym zaproponowanym przez Ciebie przykładzie.
A jednak ktoś coś immplementuje, inaczej nie mielibyśmy roboty. Pytanie, w którym
momencie trafię na taki (lub należący do tej klasy) problem.

> Być może z dydaktycznego punktu widzenia lepiej jest, żeby
> programiści najpierw uczyli się języków, które realizują prostsze
> modele obliczeń, a dopiero później (jeśli zajdzie taka potrzeba)
> takich, które pozwalają na ścisłą kontrolę sprzętu.
> (Wiele wskazuje na to, że tak właśnie jest)

Ja bym się nawet z tym zgodził. I tu możemy wrócić do Twojej tezy, że początkujący
programiści powielają nawyki z prostych przykładów w większej skali. A może warto ich
uczyć na językach, których nie da się zastosować w większej skali? Wtedy nie będą
niczego powielać. Scratch, Logomocja, itp. - a potem, jak już się wyszaleją na
piramidkach i ciuchciach, pokazać im prawdziwy język, od razu w dużej skali. Np. C++.
:-D

> Czasem się spotykam z takim sformułowaniem, że dobry
> język powinien robić tak, żeby łatwe rzeczy były w nim
> łatwe, a trudne przynajmniej możliwe.

Zgadzam się. Ale to może być też kwestią ekspozycji - tzn. można pokazywać język
kawałkami, zaczynając od tych łatwych.

> > > Operator przypisania w językach takich jak C czy Python jest
> > > łatwo dostępny, i sprawia wrażenie, że jest prostą operacją.
> >
> > Bo jest. To jest podstawowa operacja.
>
> Podstawowa dla jakiego problemu?

Jak niewiasta chce przemalować włosy to je maluje a nie robi swojego klona z innymi
włosami. Jak mam kapcia w samochodzie to pompuję oponę a nie kupuję nowe napompowane
koło (przepraszam: nowy samochód, bo przecież do starego nie da się nowego koła
założyć). Jak mam gorzką kawę, to ją dosładzam a nie robię nową słodką. A jak chcę
zmienić kolor ściany, to ją maluję a nie buduję nowy dom. I nie zakładam nowego konta
(w nowym banku), żeby móc dostać wypłatę.
Tak ma moje oko, operacja przypisania jest podstawowa w sensie uniwersalnym. To
właśnie udawanie, że tej operacji nie ma, jest dla mnie kosztem.

> Załóżmy, że zmienimy linijkę
>
> if(++dodano==ilu) return suma;
>
> na
>
> if(dodano++==ilu) return suma;
>
> Już mamy błąd.

To jest problem kolejności operacji a nie samego przypisania (w tym przypadku
modyfikacji). Funkcje też można zaaplikować w złej kolejności.

> > > i właśnie z tego powodu w pierwszych dwóch rozdziałach SICP
> >
> > A z jakiego powodu teraz używają Pythona do nauki?
>
> Wyjaśniają w tekście, który podlinkowałeś wcześniej.

Czyli jednak można pokazywać uczniom operację przypisania od samego początku nauki?

> Polecam ten wykład:
> https://www.youtube.com/watch?v=uEFrE6cgVNY

Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to nie
musi być równanie?

Ludzie, którzy zawodowo zajmują się matematyką biegle posługują się narzędziami
takimi jak Mathematica, Matlab, Octave, itp. (zależność kulturowa) i zdumiewająco
wszystkie te trzy są imperatywne i korzystają z pojedynczego znaku "=" jako operacji
przypisania, czyli:

x=5;
x=x+1;

we wszystkich tych narzędziach oznacza to samo.
Czyli najwyraźniej ludzie zajmujący się matematyką nie mają z tym problemu.

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

do góry

On Tuesday, January 8, 2019 at 9:42:25 AM UTC+1, AK wrote:
> 1. W tym watku _nie dyskutuje sie_ o sumowaniu kwadratow
> poczatkowych liczb perwszych. To klasyczny "learning by example".

Jest to problem skrajnie niepraktyczny, w przeciwieństwie do MD5.
Fajnie, że można zabawkowe rzeczy napisać szybko, ale to tylko
zabawki. Rzeczywistość boleśnie pokazuje, że fajne języki są
fajne tylko na slajdach, nikt ich na poważnie nie stosuje.
Oczywiście nie można odmówić fajnym językom zalet. Można o nich
napisać pracę magisterską, a nawet dorobić się doktoratu, czy
pojawiać na konferencjach ze stosownie mądrymi odczytami i
ogólnie być ponad tą masą debili piszących w mainstreamowych
językach. Ale to wszystko tak naprawdę jest bez znaczenia.

> PS: Smieszne to rzeczywiscie bylo (w innym watku) podnoszenie (przez
> Szanownych Ayatollahow badziewia zwanego C++) sprawy niemoznosci
> zrobienia listy/standardowej kolekcji prymitywow Javowych jako niby
> wada samej Javy jako jezyka.

Nie, to jest wada Javy, bo nie można pogodzić starych typów z
nowymi z powodu maszyny wirtualnej, której z kolei nie można
zmienić "bo kompatybilność". Maszyna wirtualna została
zaprojektowana 25 lat temu i jest przestarzała od jakiś 20 lat.
Co nie wpływa na fakt, że Java nie zdechnie przez następne
150 lat, tyle kodu w niej powstało.

> 2. W tym watku dyskutuje sie o badziewnosci i trupowatosci C++
> w stosunku do innych jezykow programowania.

Słaba ta dyskusja, miałka niestety. Mnie, jako wieloletniego
krytyka C++[1] i jednocześnie praktyka nic tutaj nie przekonuje.
Daleko tu do mojego ulubionego https://yosefk.com/c++fqa/.
Niestety, Yosef wymiękł i nie kontynuuje dzieła wytykania głupot
w C++11, C++14, czy C++17, a byłoby tego sporo. Co ciekawe, dużo
można by dodać np. z konferencji CppCon, bo wbrew opiniom
programiści C++ są krytyczni. Np. Stroustrup mówił, że "auto"
jest używane wbrew intencjom --- nie chwaląc się, przewidziałem
ten efekt 4 lata temu.

[1] Na przykład:
http://0x80.pl/notesen/2019-01-07-cpp-read-file.html
http://0x80.pl/notesen/2018-04-28-be-careful-with-di
r-iterator.html
http://0x80.pl/notesen/2018-03-16-awful-part-of-cpp.
html
http://0x80.pl/notesen/2015-11-22-another-cpp-nasty-
feature.html

> PS:Az dziw mnie bierze, ze Szanowna Mlodziezy - tak przecie z
> natury "Nowoczesna" i "do przodu" tak broni tego emeryta i kołtuna
> zwanego C++ :).

Pochlebiasz mi, ale ja już jestem na tyle stary, że
zrozumiałem na czym polega inercja. Można napisać 1 gigabajt
tekstów o tym, że C++ jest badziewiem, ale co to niby
zmieni? Badziewie zadziwiająco dobrze się trzyma i
zadziwiająco dużo kasy w niego idzie z różnych stron. Staje
się mniej badziewne nawet, o czym jednak trudno się
przekonać bez praktyki.

Szczęśliwie już jestem na tym etapie, że mało mnie interesują
języki programowania, to dość nudny kawałek IT. Naprawdę
ciekawe są kompilatory, ale tylko ta cześć za frontendem. :)

w.

do góry

On 2019-01-08 17:21, Wojciech Muła wrote:
> Jest to problem skrajnie niepraktyczny, w przeciwieństwie do MD5.
> Fajnie, że można zabawkowe rzeczy napisać szybko, ale to tylko
> zabawki. Rzeczywistość boleśnie pokazuje, że fajne języki są
> fajne tylko na slajdach, nikt ich na poważnie nie stosuje.
> Oczywiście nie można odmówić fajnym językom zalet. Można o nich
> napisać pracę magisterską, a nawet dorobić się doktoratu, czy
> pojawiać na konferencjach ze stosownie mądrymi odczytami i
> ogólnie być ponad tą masą debili piszących w mainstreamowych
> językach. Ale to wszystko tak naprawdę jest bez znaczenia.

10 lat temu zrywaliscie boki jak nie gdze indziej niz tu "promowalem"
Pythona. 10 lat temu wieli glowny Mufti C++ niejaki Sekator van Skijlen
zarykiwal sie gdy "promowalem" tu .NET-a/C#.
No ze pojade klasykiem: i kto mial racje ?
A gdzie bylo C++ w tym czasie? Ano (do czasu C++14, choc to tez
przegadany syf...) byl w d... gdy inne jezyki sie rozwijaly.

>> PS: Smieszne to rzeczywiscie bylo (w innym watku) podnoszenie (przez
>> Szanownych Ayatollahow badziewia zwanego C++) sprawy niemoznosci
>> zrobienia listy/standardowej kolekcji prymitywow Javowych jako niby
>> wada samej Javy jako jezyka.
>
> Nie, to jest wada Javy, bo nie można pogodzić starych typów z
> nowymi z powodu maszyny wirtualnej, której z kolei nie można
> zmienić "bo kompatybilność". Maszyna wirtualna została
> zaprojektowana 25 lat temu i jest przestarzała od jakiś 20 lat.
> Co nie wpływa na fakt, że Java nie zdechnie przez następne
> 150 lat, tyle kodu w niej powstało.

Wumyslane problemy.
W zyciu mi sie nie zdarzylo miec problemy ze stosowaniem i wydajnoscia
koekcji Integer vs int, czy Double vs double.
Moze w czasach 16bit/1MB to tak ale dzis gdy RAM na 1000 x wiecej
miejsca niz wtedy najwiekszy HDD ?

>> 2. W tym watku dyskutuje sie o badziewnosci i trupowatosci C++
>> w stosunku do innych jezykow programowania.
>
> Słaba ta dyskusja, miałka niestety. Mnie, jako wieloletniego
> krytyka C++[1] i jednocześnie praktyka nic tutaj nie przekonuje.

Przeciez nikt tu nie bedzie przedyskutowywal calego raportu C++ :)
Szkoda zycia na cus takiego.

> [1] Na przykład:
> http://0x80.pl/notesen/2019-01-07-cpp-read-file.html
> http://0x80.pl/notesen/2018-04-28-be-careful-with-di
r-iterator.html
> http://0x80.pl/notesen/2018-03-16-awful-part-of-cpp.
html
> http://0x80.pl/notesen/2015-11-22-another-cpp-nasty-
feature.html
>
>> PS:Az dziw mnie bierze, ze Szanowna Mlodziezy - tak przecie z
>> natury "Nowoczesna" i "do przodu" tak broni tego emeryta i kołtuna
>> zwanego C++ :).
>
> Pochlebiasz mi, ale ja już jestem na tyle stary, że
> zrozumiałem na czym polega inercja. Można napisać 1 gigabajt
> tekstów o tym, że C++ jest badziewiem, ale co to niby
> zmieni?

Nic :) Po prostu C++ badziewne jest i tyle :)
Trzeba umiec dazyc do "prawdy obektywnej" a nie opierac sie
na wlasnych "uwazaniach"/fanatyzmie.

> Badziewie zadziwiająco dobrze się trzyma i
> zadziwiająco dużo kasy w niego idzie z różnych stron. Staje
> się mniej badziewne nawet, o czym jednak trudno się
> przekonać bez praktyki.
>

Chinskie wyroby tez trzymaja sie dobrze, ale czy to znaczy ze
sa "obiektywnie dobre" ?.

> Szczęśliwie już jestem na tym etapie, że mało mnie interesują
> języki programowania, to dość nudny kawałek IT.

Baaardzo ciekawy :). Zwlaszac ich historia i ewolucja (czesciej
degradacja niestety).

> Naprawdę ciekawe są kompilatory, ale tylko ta cześć za frontendem. :)

Zeby taki kompilator byl ciekawy, musi byc naprawde dobry jezyk.
Jesli to jest cus w rodzaju C++ to jest to raczej malo ciekawa
mordega. (Poza tym dla rzezbiarza niusne produkcji dluta sa/powinny byc
raczej malo ekscytujace. Jak i dla wirtuoza skrzypiec nie sa
najwazniejsze niuanse lutnicze ale mozliwosci brzmieniowe konkretnych
skrzypiec. Co innego dla innego lutnika:) To fakt).

AK

do góry

On 2019-01-08 17:21, Wojciech Muła wrote:
> On Tuesday, January 8, 2019 at 9:42:25 AM UTC+1, AK wrote:
>> 1. W tym watku _nie dyskutuje sie_ o sumowaniu kwadratow
>> poczatkowych liczb perwszych. To klasyczny "learning by example".
>
> Jest to problem skrajnie niepraktyczny, w przeciwieństwie do MD5.
> Fajnie, że można zabawkowe rzeczy napisać szybko, ale to tylko
> zabawki.

Ze niby generatory/wyrazenia generatorowe/iteratorowe sa zabawka?
Ze lazy jest zabawka?

No to pokaz jak uzywac generatorow/wyrazen generatorowych w C++

AK

do góry

W dniu wtorek, 8 stycznia 2019 10:42:29 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Rozumiem. Mamy więc (niezaskakujący) wniosek, że różne języki są właściwe do
różnych problemów.
> >
> > Pytanie, jaki dalszy wniosek możemy wyciągnąć z tego wniosku.
> > Może na przykład taki, że rozsądnie byłoby eksplorować języki,
> > które ułatwiają projektowanie języków.
>
> Zgadzam się. Dlatego, jak już wspomniałem, podoba mi się język Wolfram, bo dzięki
swojej umiarkowanej lispowatości świetnie nadaje się do tworzenia tzw.
Domain-Specific Languages. Zastanawiam się nad możliwością użycia tego do opisu
wymagań, które można weryfikować albo z których można generować właściwy kod (albo
testy).
> Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego
odbiorcy.

Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?
Dyskutowałem kiedyś z jednym gościem na Quorze. Gość pracował kiedyś dla Wolframa i
był chyba w jakimś stopniu entuzjastą Mathematiki (nazywa się Jon Harrop, jeśli to
coś mówi)
Zadałem mu małe wyzwanie związane z tematem, którym się akurat zajmowałem w ramach
pracy magisterskiej.
Temat był raczej niszowy, bo dotyczył konwersji programów z rekurencją do takich, w
których rekurencja się nie pojawiała (zamiast tego używa się tzw. kombinatora punktu
stałego).
Konwersję mam przedstawioną w dodatku do swojej pracy magisterskiej:

https://github.com/panicz/master-thesis/blob/master/
chapters/B.tex

Jon napisał swój odpowiednik w języku Wolframa, i choć nie zdołałem go przekonać do
Lispa, sam określił swoje rozwiązanie mianem bełkotu

https://www.quora.com/Why-is-Haskell-not-homoiconic/
answer/Jon-Harrop-2/comment/31109783

> > Możesz zerknąć w przykłady programów liczących sumę kwadratów
> > początkowych siedmiu liczb pierwszych, które przewinęły się
> > przez ten wątek (to było w odpowiedzi na post AK).
> > Tam dokładnie pokazałem przykład rozumowania podstawieniowego.
>
> Ależ ja go rozumiem i od początku staram się tu zrobić konfrontację tych koncepcji.
"Przykład rozumowania podstawieniowego" nie pokazuje żadnej przewagi nad tym
imperatywnym oryginałem, z dwóch powodów:
>
> 1. Nie widać w nim długoterminowych zalet w aspekcie utrzymania kodu. Wyobraź
sobie, że klient dostał ten program i jest zadowolony, ale przecież jesteśmy agile,
więc klient od razu wpada na nowy pomysł: "a jeszcze tak sobie pomyślałem, że te
liczby, które nie są pierwsze, też by można do siebie dodać".
> Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe*
wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał,
że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji
imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać,
bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program
i napisać go od nowa (pokażesz?).

Nie rozumiem przykładu i nie wiem, skąd bierze się Twój wniosek. Ja mam w tej kwestii
zupełnie inne doświadczenia.
Programowanie funkcyjne polega przede wszystkim na definiowaniu pojęć, przy pomocy
których wyrażasz rozwiązanie problemu.
Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań
klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego
aparatu pojęciowego, to wówczas trzeba ten aparat rozszerzyć, tzn. podefiniować nowe
pojęcia. Ale nic nie trzeba wyrzucać.

> To jest potencjalnie poważny problem i nie tylko dlatego, że klient nie zrozumie,
dlaczego tak ma się stać.
> Ten przykład w całości jest sztuczny (serio: nikt nie rozwiązuje takich problemów),
ale nie wynika z niego, że powyższy problem nie wystąpi w większej (ilościowo albo
czasowo) skali.

Tzn. jaki przykład?

> Ciekawym aspektem do rozważenia jest to, że to, co Ty traktujesz jako wymagania
("dodaj ... itd.") to nie są jedyne wymagania, z jakimi musi się zmierzyć inżynier.
Niejawnymi wymaganiami są też kwestie wydajności (sam widziałeś) i utrzymanie
projektu w długim terminie. "Paradygmat podstawieniowy" tych problemów sam z siebie
nie adresuje a przez to jest rozwiązaniem nie tylko niekompletnym ale może być wręcz
ograniczającym.

Ja nie twierdzę, że programowanie funkcyjne to panaceum na wszystkie problemy. Sam
dużo programuję imperatywnie, i jakoś sobie z tym radzę.
Ja mówię przede wszystkim o uczeniu się programowania: o dostrzeżeniu, że niemożność
analizy programu w terminach podstawień też jest pewnym kosztem (który może czasem
można zamortyzować, a czasem warto ponieść).

> 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej.
Analizatory kodu (np. takie, które sprawdzają statycznie, czy ktoś nie wyjeżdża poza
tablicę albo nie dzieli przez zero) wykonują weryfikację właśnie przez podstawienia i
przez rozwiązywanie równań.

Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam,
jak by dla niego taka analiza podstawieniowa wyglądała.

> > Większość programistów, jakich znam, nie implementuje swojego MD5.
>
> To samo mogę powiedzieć o każdym zaproponowanym przez Ciebie przykładzie.
> A jednak ktoś coś immplementuje, inaczej nie mielibyśmy roboty. Pytanie, w którym
momencie trafię na taki (lub należący do tej klasy) problem.

Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał
na pęczki.
Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie
bilansu zysków i strat albo kwoty wolnej od podatku.

> > Być może z dydaktycznego punktu widzenia lepiej jest, żeby
> > programiści najpierw uczyli się języków, które realizują prostsze
> > modele obliczeń, a dopiero później (jeśli zajdzie taka potrzeba)
> > takich, które pozwalają na ścisłą kontrolę sprzętu.
> > (Wiele wskazuje na to, że tak właśnie jest)
>
> Ja bym się nawet z tym zgodził. I tu możemy wrócić do Twojej tezy, że początkujący
programiści powielają nawyki z prostych przykładów w większej skali. A może warto ich
uczyć na językach, których nie da się zastosować w większej skali? Wtedy nie będą
niczego powielać. Scratch, Logomocja, itp. - a potem, jak już się wyszaleją na
piramidkach i ciuchciach, pokazać im prawdziwy język, od razu w dużej skali. Np. C++.
:-D

Tylko wtedy mamy dydaktyczny problem zmiany skali.

> > Czasem się spotykam z takim sformułowaniem, że dobry
> > język powinien robić tak, żeby łatwe rzeczy były w nim
> > łatwe, a trudne przynajmniej możliwe.
>
> Zgadzam się. Ale to może być też kwestią ekspozycji - tzn. można pokazywać język
kawałkami, zaczynając od tych łatwych.

Moim zdaniem pokazywanie języka to zachowanie na poziomie przedszkolnym.
Dlatego cenię książki Lispowe, o których wspominałem, że w nich język w ogóle nie
jest kwestią, i zamiast na nim i na "językowych ficzerach" można się skupić po prostu
na przykładach użycia języka, czyli na wypowiedziach.
C++ przyzwyczaja pokolenia programistów do "językowych ficzerów".
Natomiast książki pokroju SICP czy PAIP uczą się, że możemy najpierw próbować wyrazić
problem w dogodny dla nas sposób, a dopiero później wykombinować, co z owym
wyrażeniem ma robić komputer.

> > > > Operator przypisania w językach takich jak C czy Python jest
> > > > łatwo dostępny, i sprawia wrażenie, że jest prostą operacją.
> > >
> > > Bo jest. To jest podstawowa operacja.
> >
> > Podstawowa dla jakiego problemu?
>
> Jak niewiasta chce przemalować włosy to je maluje a nie robi swojego klona z innymi
włosami. Jak mam kapcia w samochodzie to pompuję oponę a nie kupuję nowe napompowane
koło (przepraszam: nowy samochód, bo przecież do starego nie da się nowego koła
założyć). Jak mam gorzką kawę, to ją dosładzam a nie robię nową słodką. A jak chcę
zmienić kolor ściany, to ją maluję a nie buduję nowy dom. I nie zakładam nowego konta
(w nowym banku), żeby móc dostać wypłatę.
> Tak ma moje oko, operacja przypisania jest podstawowa w sensie uniwersalnym. To
właśnie udawanie, że tej operacji nie ma, jest dla mnie kosztem.

Wydaje mi się, że nie rozumiesz jednej rzeczy.
Ta rzecz jest może trudna do wyjaśnienia, bo jest bardzo abstrakcyjna, wszędobylska,
a przez to trudna do uchwycenia.
Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare informacje
nie znikają.
Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.
To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając
błędu segmentacji pamięci.
Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie
sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe
użycia słowa "jabłko" będą dla wszystkich oznaczać konie.
Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie
zamazujesz wszystkich swoich notatek.

Trudno to sobie uświadomić, bo to są rzeczy, które się nie dzieją. Jesteśmy
przyzwyczajeni do tego, że się nie dzieją.
Operator przypisania nie ma swojego odpowiednika w świecie językowym czy pojęciowym,
w którym żyjemy na co dzień.
Unikanie go sprawia, że programowanie staje się równie proste i naturalne, co
mówienie.

Właśnie dlatego nie kupuję Twojego argumentu: kiedy ja mówię o niemutowalności, to Ty
mówisz "świat taki nie jest". Ale my nie mówimy teraz o świecie, tylko o języku, i ja
odpowiadam na Twój obraz świata: "język taki nie jest".

Wprowadzenie operatora przypisania rodzi bardzo wiele nieoczywistości w różnych
sytuacjach.
Choćby w Pythonie mamy coś takiego: możemy być przyzwyczajeni traktować zapis "x +=
y" jako skrót dla "x := x + y".
Jest tak na przykład wtedy, kiedy x i y odnoszą się do liczb całkowitych:

>>> x = 5
>>> y = x
>>> y += 2
>>> y
7
>>> x
5

ale jeśli napisalibyśmy
>>> x = [1,2,3]
>>> y = x
>>> y += [4,5]
to oczywiście
>>> y
[1,2,3,4,5]
ale - co już mniej oczywiste
>>> x
[1,2,3,4,5]

Jedni mogą twierdzić, że to jest dobre zachowanie, inni że złe, ale dla mnie to jest
jeden z tych problemów, które wolę obejść, niż rozwiązywać, bo którego nie można
dobrze rozwiązać a priori.

I owszem, jeżeli jesteśmy przyzwyczajeni do tego, że programowanie to "mówienie
komputerowi, co ma robić", to takie programowanie, o którym ja tutaj mówię, można
uznać za iluzję - często trudniej sprawić, żeby efekt działał wydajnie, co - w
zgodzie z tym, co piszesz, można widzieć jako pewien koszt. Prostota, o której ja
piszę, nie jest prostotą implementacyjną, ale prostotą pojęciową, bądź też prostotą
mentalnego modelu programowania.

> > > > i właśnie z tego powodu w pierwszych dwóch rozdziałach SICP
> > >
> > > A z jakiego powodu teraz używają Pythona do nauki?
> >
> > Wyjaśniają w tekście, który podlinkowałeś wcześniej.
>
> Czyli jednak można pokazywać uczniom operację przypisania od samego początku nauki?

Nie wiem, w jaki oni sposób uczą Pythona, ale podejrzewam, że nadal są pod tym
względem ostrożni.

> > Polecam ten wykład:
> > https://www.youtube.com/watch?v=uEFrE6cgVNY
>
> Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to
nie musi być równanie?

Właśnie w taki sposób, że na podstawie badań empirycznych wyszło im, że wyjmując
operator przypisania z języka unikają bardzo wielu nieporozumień.

do góry

On 2019-01-08 23:24, g...@g...com wrote:
> Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to
nie musi być równanie?

W "moich czasach" bylo jednak normalniej :).

= to bylo: rowna sie
<- to bylo: podstawienie

Pozniej jednak jakis debil usunal <- z klawiatury :(

ICL1900 Algol:

integer procedure silnia(n):
integer n;
begin
silnia <- if n = 1 then 1 else silnia(n - 1) * n;
end

AK

do góry

> > Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla
końcowego odbiorcy.
>
> Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?

Np. to, że jego składnia jest ukłonem w stronę parserów a nie w stronę użytkowników.
Ja naprawdę wolę napisać a*b+c, niż (+ (* a b) c), i nie cieszy mnie kończenie
wyrażeń serią nawiasów tak długą, że nie sposób ich policzyć. Wolfram jest o tyle
ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i pozwala posłużyć się
taką, jaka jest w danym miejscu odpowiednia. Jest to ważne zwłaszcza wtedy, gdy
chcemy w języku wyrazić coś nowego, np. wymagania albo zbiór danych.

[o przykładzie z dodawaniem kwadratów liczb pierwszych]

> > Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe*
wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał,
że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji
imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać,
bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program
i napisać go od nowa (pokażesz?).
>
> Nie rozumiem przykładu

Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg,
którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym
"projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów.

> Ja mam w tej kwestii zupełnie inne doświadczenia.

Poproszę o implementację nowego wymagania w istniejącym projekcie.
W wersji imperatywnej jest to oczywiste - dodatkowa zmienna, być może gałąź else. Jak
to będzie w Twojej wersji?

> Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań
klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego
aparatu pojęciowego

Ale właśnie jest. "Te liczby, które nie są pierwsze, też można by do siebie dodać".
Co tu jest pojęciowo nowego? Liczby pierwsze, dodawanie - te pojęcia już masz, bo już
ich używałeś w programie. Teraz odwołując się do tych istniejących pojęć ja chcę mieć
też dodane do siebie te liczby, które nie były pierwsze.

> Ale nic nie trzeba wyrzucać.

Pokaż.

> > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej.
>
> Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż
nam, jak by dla niego taka analiza podstawieniowa wyglądała.

A na jakie pytanie chciałbyś taką analizą odpowiedzieć?

> Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał
na pęczki.

Weź dowolny system, który czegoś pilnuje albo czymś steruje.
Jeszcze nie mówiliśmy o wymaganiach czasowych. Np. "woda w kranie w toalecie ma
przestać lecieć po 5s od ostatniej aktywacji czujnika zbliżeniowego". To wymaganie
jest pojęciowo bardzo proste.

> Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie
bilansu zysków i strat albo kwoty wolnej od podatku.

Ale nawet w takim systemie wyobrażam sobie nowe wymaganie typu "a to coś co nie
spełniało warunku, to coś tam". I mam ten sam problem co z sumowaniem kwadratów.

> A może warto ich uczyć na językach, których nie da się zastosować w większej skali?
>
> Tylko wtedy mamy dydaktyczny problem zmiany skali.

A może to nie jest problem nauki języka, tylko nauki inżynierii programowania? Może
właśnie tego brakuje adeptom powielającym złe nawyki z prostych przykładów? Ale język
jest wtedy drugorzędny.
Przecież ten sam problem wystąpi w każdej innej dziedzinie - nie można oczekiwać, że
się nauczy kogoś architektury albo budownictwa na klockach. Tymczasem tak właśnie
ludzie podchodzą do nauki programowania - biorą książkę "Python w 24h" i jazda.

> Wydaje mi się, że nie rozumiesz jednej rzeczy.

> Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare
informacje nie znikają.

A jeśli są wyświetlane na ekranie smartfona? Stare muszą zniknąć, bo rozmiar ekranu
jest ograniczony.

> Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.

Ale możesz edytować tego nowego, gdy się pomylisz.

> To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając
błędu segmentacji pamięci.

Ale żółwika z nim nie przybijesz.

> Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie
sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe
użycia słowa "jabłko" będą dla wszystkich oznaczać konie.

Ten przykład jest dla mnie za trudny.

> Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie
zamazujesz wszystkich swoich notatek.

A jeśli piszę na tablecie?

> Trudno to sobie uświadomić,

Znowu mnie nie przekonałeś?

> Choćby w Pythonie mamy coś takiego:
[...]

Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją
przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z
intuicją. Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała
poprawnie.

> Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą
pojęciową

I to jest dobre określenie. Podoba mi się i zgadzam się z nim. Za wyjątkiem
oczywiście tego, że pomijanie aspektów implementacyjnych jest zwykle krótkowzroczne i
sprawdza się tylko w prostych albo jednorazowych (często te cechy są razem)
przykładach.
Zgodzę się jednak, że prostota pojęciowa to dobry cel w wielu zastosowaniach. Myślę
jednak, że proponowane przez Ciebie rozwiązania zostaną kiedyś zastąpione przez coś w
rodzaju asystentów AI, jak Wolfram Alpha:

https://www.wolframalpha.com/input/?i=sum+of+first+s
even+prime+numbers

Jest prostota pojęciowa? Jest. Właściwie prościej się nie da.
Pozostaje zastosować to w większej skali, np. systemu finansowego. Nie mam
wątpliwości, że taki jest właśnie kierunek rozwoju.

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

do góry

> Spróbuj sformułować problem liczenia MD5 bez odwoływana się
> do istniejących implementacji i dokumentów. Czekam.

Źle. Jeśli ograniczasz swoją perspektywę tylko do problemów, które można wytłumaczyć
przez telefon, to sam sobie budujesz szklany sufit. Jednocześnie sam sobie
zaprzeczasz, bo twierdziłeś tutaj, że bardziej od słów cenisz sobie hiper-precyzyjny
zapis w postaci kodu. Dlaczego teraz przed tym uciekasz?

Algorytm MD5 jest opisany np. tutaj:

https://en.wikipedia.org/wiki/MD5

Jest tam sekcja Algorithm a pod nią Pseudocode.

Istnieje spora szansa, że nie da się tego wyrazić prościej.
Pytanie teraz, jak to zaprogramować. I w czym.

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

do góry

On Tuesday, January 8, 2019 at 10:51:30 PM UTC+1, AK wrote:
> On 2019-01-08 17:21, Wojciech Muła wrote:
> > On Tuesday, January 8, 2019 at 9:42:25 AM UTC+1, AK wrote:
> >> 1. W tym watku _nie dyskutuje sie_ o sumowaniu kwadratow
> >> poczatkowych liczb perwszych. To klasyczny "learning by example".
> >
> > Jest to problem skrajnie niepraktyczny, w przeciwieństwie do MD5.
> > Fajnie, że można zabawkowe rzeczy napisać szybko, ale to tylko
> > zabawki.
>
> Ze niby generatory/wyrazenia generatorowe/iteratorowe sa zabawka?

Tak, to tylko lukier składniowy, który nie wnosi nic do
semantyki. O wiele istotniejsze, jeśli jesteśmy przy pythonie,
jest context management protocol.

Co do wyrażeń generatorowych to owszem, używam na co dzień w
pythonie, ale mógłbym żyć bez tego. Nie boli mnie pisanie pętli,
ja się nawet goto nie boję. :) Bardziej skomplikowane wyrażenia i
tak zamykam w funkcji/metodzie, bo mi etyka zawodowa nie pozwala
pisać jednolinijkowców na 150 znaków.

> Ze lazy jest zabawka?

Nie, leniwe liczenie to wyłącznie środek do celu (który ma swój
ukryty koszt, o czym lepiej nie pamiętać). Okazało się np., że
genialne w swojej prostocie parsowanie za pomocą pochodnych
wyrażeń regularnych dużo zyskuje dzięki temu podejściu, jeśli
nawet nie staje możliwe dzięki niemu. No i to w sumie jedyne
praktyczne zastosowanie leniwego wartościowania o jakim
słyszałem.

> No to pokaz jak uzywac generatorow/wyrazen generatorowych w C++

Przecież nie ma czegoś takiego w C++, po co na siłę udawać?
Generator w języku imperatywnym to będzie stan + funkcja która
liczy następną wartość ze stanu (tak jest zresztą fizycznie
w pythonie robione). I przypominam sobie dokładnie jeden
przypadek, kiedy musiałem coś takiego napisać. To była
implementacja interfejsu generatora w rozszerzeniu do Pythona
napisanym w C. :)

w.

do góry