W dniu niedziela, 30 grudnia 2018 00:21:16 UTC+1 użytkownik Maciej Sobczak napisał:
> > > [operator przypisania]
> > >
> > > > W większości miejsc nie jest konieczne.
> > > > A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> > > > środków analizy programów
> > >
> > > Nie, nie zwiększa.
> >
> > Owszem, zwiększa.
>
> To tak, jakbyś powiedział, że silnik zwiększa koszt samochodu.
> Otóż nie zwiększa, bo jest jego integralną częścią. Klima albo automat może
zwiększać, ale nie silnik.
> Podobnie jest z operatorem przypisania w językach imperatywnych. On niczego nie
zwiększa, bo nie może go nie być.

Nie. Programy, które nie posiadają instrukcji przypisania,
można analizować, po prostu zastępując wyrażenia ich wartościami.
Programów, w których używa się instrukcji przypisania, nie
można analizować w taki sposób - trzeba zaprzęgać inne środki
analizy. Oczywiście można ostrożnie wprowadzać instrukcje
przypisania, otrzymując modele, które wciąż mają dobre właściwości.
I oczywiście obowiązkowy link do Quory ;]
https://www.quora.com/What-is-your-opinion-on-purely
-functional-programming/answer/Panicz-Godek

> > Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
> > - spróbował przeczytać tę książkę, i dopiero wtedy się
> > wypowiedzieć.
>
> Czytałem. Tylko jakoś nie uległem czarowi języków funkcjonalnych do tego stopnia,
żeby uznać je jako teoretyczną podstawę do czegokolwiek.
> I mam wrażenie (również z poprzednich naszych dyskusji), że tak właśnie sądzisz -
że języki funkcjonalne są podstawą, z której można budować inne konstrukcje. Dlatego
zastanawiasz się, jaki jest koszt dodania operatora przypisania.

Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na
"czystych funkcjach" - to jest budulec, z którego tworzy się
semantyki denotacyjne dla języków programowania.

> Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji,
to zwyczajowo była nią maszyna Turinga (i nie widzę powodu, żeby miała stracić ten
status) a akurat tam jest już koncepcja modyfikacji wartości. Głowica zapisująca nową
wartość w tym samym miejscu to właśnie operator przypisania.

Jeśli zapytamy, jaki model obliczeń jest współcześnie
najbardziej rozpowszechniony i najlepiej zrozumiany, to prawdopodobnie
tym modelem obliczeń będzie arkusz kalkulacyjny: jest bardzo duża
rzesza osób, które umieją korzystać z arkuszy kalkulacyjnych,
a które nawet nie wiedzą, że to jest programowanie.
Ten model obliczeń charakteryzuje się tym, że nie ma w nim
przepływu sterowania ani operacji przypisania. Jest dużo
prostszym modelem od maszyny von Neumanna, choć oczywiście
nie wszystko da się w nim zrealizować. (Ale można w nim robić
np. takie programy, jak sieci neuronowe. I wspiera obliczenia na
GPGPU)

Model podstawieniowy jest bardziej złożony od arkusza
kalkulacyjnego. Ale jest też bardziej uniwersalny w tym sensie,
że umożliwia tworzenie odrębnych komponentów i łączenie ich
ze sobą na różne sposoby.

Dobrym przykładem tego rodzaju kompozycjonalności są
potoki UNIXa. Co prawda programy, które łączy się w potoki,
takie jak sed czy grep, są napisane w sposób imperatywny,
ale same te programy nie polegają w żaden sposób na globalnym
stanie.

> W tym kontekście zamiast pytać, jaki jest koszt dodania operatora przypisania do
czegokolwiek, należałoby zapytać, jaki jest koszt udawania, że go może nie być.
> Otóż ten koszt to jest między innymi ta dyskusja. :-)

Tutaj nie chodzi o to, że operatora przypisania ma nie być.
Chodzi o to, żeby nie używać go wtedy, kiedy to nie jest konieczne.

Programy, które nie polegają na globalnym stanie, analizuje
się łatwiej - i to przede wszystkim analizuje się je łatwiej
osobom, które muszą pracować z zastanym kodem, czyli
programistom. W językach takich jak C istnieją idiomy, które
pozwalają ograniczać zasięg instrukcji przypisania do
minimum (np. pętle for z iteratorem), ale one istnieją
właśnie dlatego, że modyfikacje globalnego stanu są
kłopotliwe.

> > To dobra książka, naprawdę.
>
> https://cemerick.com/2009/03/24/why-mit-now-uses-pyt
hon-instead-of-scheme-for-its-undergraduate-cs-progr
am/

Nie wiem co miałoby z tego linka wynikać dla tej dyskusji.

> Wracając do tematu: jeżeli operator przypisania jest problemem w Scheme, to jest to
problem w Scheme. W językch imperatywnych ten operator nie jest problemem, tylko
integralną częścią języka. A narzędzi analitycznych to w ogóle nie komplikuje,
naprawdę.

Owo ustalenie, że stosowanie operatora przypisania (oraz operatów
wyrażających przepływ sterowania) komplikuje
środki analizy programu, dotyczy wszystkich języków, w których
procedury mogą przyjmować argumenty i zwracać wartości.
Dotyczy zatem takich języków, jak Java, C++, JavaScript,
Pascal, PHP, Perl, Python i wielu innych.

> > > Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej.
> >
> > Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać
> > w C++ kodu tak, żeby być z niego zadowolonym.
>
> Mi się zdarzyło.

A to z chęcią bym zobaczył ;]

> Natomiast przyznam, że moje własne niezadowolenie z języka C++ skierowało mnie ku
nauce Ady. I paradoksalnie, mój C++ się wtedy też poprawił.

Nie wiem co miałoby w tym być paradoksalnego - nauka nowych języków
programowania daje nam nowe perspektywy na to, czym ogólnie jest
programowanie. Akurat dla mnie ciekawie byłoby się dowiedzieć,
czego się można nauczyć od Ady, bo nie miałem z nią żadnej styczności.

W quorowym artykule, który wcześniej podlinkowywałem ("what are some
examples of bad code"), dlatego nie zawarłem dobrej implementacji
w C++, że naprawdę nie wiedziałbym, jak się za to zabrać.
Mógłbym napisać "Haskella w C++", ale nie wiem, czy to by było
zgodne z "duchem C++" (jeżeli ten język w ogóle ma jakiegoś ducha)

> > Wydaje mi się, że pytanie "czy C++ jest dobry do nauki"
> > to trochę mało. Raczej należałoby zapytać, czy dane materiały
> > dydaktyczne są dobre, albo czy określona metodologia nauczania
> > jest skuteczna.
>
> Tak, to prawda. Ale znam ludzi, którzy twardo stosują C++ jako platformę do nauki
programowania i struktur danych. Myślę, że przy odpowiednim prowadzeniu to nie jest
zły pomysł.
> Ale sam osobiście poleciłbym nowicjuszom język Wolfram. Również dzieciom, jak im
się już Scratch znudził. C++ nie jest dobrym pierwszym językiem, chociaż może być
bardzo praktycznym językiem w późniejszej pracy czy innym realnym projekcie.

Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.