> 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

Dlaczego?
Pytam, bo analizuję i może coś źle robię.

> - trzeba zaprzęgać inne środki
> analizy.

Jakie?
Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty?

> Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na
> "czystych funkcjach"

To ja chyba czytałem inną książkę.

> > Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych
konstrukcji, to zwyczajowo była nią maszyna Turinga

> Jeśli zapytamy, jaki model obliczeń jest współcześnie
> najbardziej rozpowszechniony

Zdecydowanie nie jest nim programowanie funkcjonalne.

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

Brniesz.

https://www.google.com/search?q=Excel+assign+value+t
o+cell

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

I po długiej dyskusji, w której gdzieś tam wcześniej wspomniałeś o złych nawykach z
C++, nadal nie wiem, gdzie w C++ nie jest to konieczne.

> Programy, które nie polegają na globalnym stanie, analizuje
> się łatwiej

Jesteś pierwszy, który wspomniał o globalnym stanie. Po co?

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

A taki tam przypominacz, że nawet u źródeł SICP traci autorytet.

> Owo ustalenie, że stosowanie operatora przypisania (oraz operatów
> wyrażających przepływ sterowania) komplikuje
> środki analizy programu,

W jaki sposób komplikuje?

> > > 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ł ;]

Link w sygnaturze.

> Akurat dla mnie ciekawie byłoby się dowiedzieć,
> czego się można nauczyć od Ady, bo nie miałem z nią żadnej styczności.

Kultury tworzenia fizycznej struktury kodu, nacisku na projekt używanych typów
danych, paru fajnych idiomów w okolicy programowania wielowątkowego oraz ciekawej
obserwacji, jak dużo można zrobić bez używania jawnie oraz niejawnie (!) pamięci
dynamicznej (np. prawie wszystkie wzorce projektowe GoF). Jeżeli masz zacięcie
teoretyczne, warto wiedzieć, że na podzbiorze Ady wysósł SPARK, czyli język
zintegrowany z metodą formalną do weryfikacji jego poprawności. Last but not least,
bardzo sensowny podzbiór Ady (w tym cały potrzebny dla SPARKa) ma profil tzw. Zero
FootPrint Run-Time, czyli nie wymaga wsparcia żadnej dodatkowej warstwy kodu.
Wszystkie powyższe pozwoliły mi inaczej spojrzeć na prace robione w innych językach
(w szczególności w C++).
Interesują mnie systemy wbudowane (w tym krytyczne) i powyższe cechy, zwłaszcza ZFP,
są dla mnie wyjątkowo cenne. Polecam.

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

Dlaczego?

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