W dniu piątek, 11 stycznia 2019 21:31:56 UTC+1 użytkownik AK napisał:

> >> Metkowanie.
> >> 1. Obiekty w Pythonie sa wylacznie "metkowane".
> >> Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).
> >
> > Tzn. przekazywane przez referencję?
>
> Nie. To jednak nie jest to samo co referencja w C++ czy innej
> Javie.

A czym się różni?

> >> 2. definicja funkcji to jest _statement_ wiec wszystko co podlega
> >> ewaluacji, jest _wlasnie wtedy_ ewaluowane.
> >> Stad wartosci domyslne sa ewaluowane w momencie wykonania
> >> _statementu_ def function().
> >
> > A jakie są pozostałe "statementy"?
>
> Takie jak w manualu.

Zobaczyłem w manual. Wprowadza rozróżnienie na "compound statement"
i "simple statement". Reguły, o której pisałeś wcześniej, nigdzie
nie znalazłem.

> >> wiec w ten sposob tworzy sie w Pythonie wlasnie zmienne statyczne
> >> nie zasmiecajac wyzszego namespace.
> >
> > Można też użyć do tego celu "domknięcia", albo klasy.
>
> Po co ?
> PS: Owszem, Przy wiekszej ilosci danych/atrybutow uzywa sie w Py klasy,
> named tuple, slownika, domkniec itp itp.

Po co ?

> > Przekazanie parametru rekurencyjnie do funkcji to nic trudnego
>
> Po co przekazywac "z gory" jesli mozna to samo uzyskac
> w lokalnym scope ? No po co ? Bo?

Globalnych obiektów lepiej unikać (zwłaszcza mutowalnych globalnych obiektów)
A jeżeli chce się już z nich korzystać, to lepiej wprowadzać je jawnie,
niż niejawnie i mimochodem.

> > Sam powiedziałeś, że "bywa mylące".
> > Ja uważam, że jest mylące z dobrych powodów.
>
> No jesli sie nie czyta wpierw nic o jezyku/manuali
> to wszytsko bywa mylace :)

Jest różnica pomiędzy "nie czyta się nic",
a "zagląda się w egzotyczne zakamarki".
Dobrze zaprojektowany język pozwala łatwo wywnioskować z pierwotnych reguł jakie
będzie zachowanie złożonych wyrażeń.

> >> Zwlaszcza w stosunku do expr w takim Lisp gdzie nawet priorytet
> >> opeatorow poszedl do kosza wiec trzeba go wymuszac odpowiednia
> >> kolejnoscia ewaluacji i/lub nawiasami (a nawet trzeba wymuszac/okreslac
> >> tymiz lewo-prawo-lacznosc operatorow).
> >> Np: (* A (* B (* C D))) to co innego niz (* (* (* C D) B) A)
> >> Przecie to nieskonczone zrodlo pomylek.
> > ?
> > Jakich pomyłek?
> > W każdym języku f(x, f(y, f(z, w))) to raczej coś innego niż
> > f(f(f(z, w), y, x).
>
> Tyle ze przy mnozeniu jest to to samo.

No to hyc:
octave> a = [ 1 2 3; 4 5 6 ]
octave> b = [ 7 ; 8 ; 9 ]
octave> a * b
ans =

50
122
octave> b * a
error: operator *: nonconformant arguments (op1 is 3x1, op2 is 2x3)

> Chodzi o to ze trzeba ciagle pilnowac priorytetow operatorow
> (czy kolejnisci) przez odpowednie konstrukcje - czyli na bakier
> normalnej metematyce.

"pilnować"?
Równie dobrze można by powiedzieć, że trzeba "pilnować kolejności wywołania
funkcji". No tak, na tym polega programowanie, że programista wie, co
chce napisać, i to pisze.

> Notacja Lisp akurat wyrazeniom arytmetycznym
> wyraznie szkodzi i nie ma co tego tlumaczyc "elegancja" czy
> "czystoscia" paradygmatow jezyka. To syf w uzyciu i tyle!

Ja nie miałem z tym nigdy problemu.

> > I to nie jest "wymuszanie nawiasami lewo-prawo-łączności operatorów",
> > bo w Lispie syntaktyczine w ogóle nie ma czegoś takiego.
> > Akurat operator mnożenia jest (semantycznie) łączny i przemienny,
> > toteż nie ma znaczenia, czy napiszesz tak, czy inaczej.
>
> Ma znaczenie bo w jezykach programowania _istnieja efekty
> uboczne_ i kolejnosc ewaluacji (od lewa do prawa) MA
> znaczenie.

Efekty uboczne nie istnieją "w językach programowania", tylko
w programach. (Co więcej, istnieją języki programowania, w których
efektów ubocznych nie ma)

> > Możesz też napisać (* A B C D) albo (* C D B A).
>
> Moge. Tylko czy to wyglada na zapis matematyczny?
> Toz to zwykla lista :)

To "iloczyn A B C i D".

Zresztą (+ (* a b) (/ c d)) to też
"suma iloczynu a z b oraz ilorazu c przez d".
Czyta się prawie tak samo, jak się pisze.

> >> PS: Tylko mi nie probuj mowic, ze jest inaczej bo drzewiej
> >> pisywalem (fakt ze rzadko, nie umialem sie przekonac:) w AutoLispie
> >> makra do AutoCADa "cus tam" liczace i... to dla numeryka byl
> >> istny koszmar :(
> >
> > Co ja mam Ci próbować wmówić?
> > Jak czegoś nie lubisz, to to Twoja sprawa.
>
> Nie lubie dlatego, ze nie lubie.
> Nie lubie, bo sprawia tak wiele niedogodnosci,
> ze odciaga od domeny na rzecz młotka.

Programuję w Lispie dużo, i nie mam takiego wrażenia.
Przeciwnie: to, że operacje matematyczne są mało poręczne
w użyciu, zachęca do nadawania nazw, przez co kod staje się
bliższy domenie. Np.

(define (euclid-distance x y)
(sqrt (apply + (map square (map - x y)))))

(define (average items)
(/ (apply + items)
(length items)))

itd.

> >> Oczywiscie C/C++ to popsul bo w nim stwierdzono (z wydumanych wzgledow
> >> wydajnosciowych oczywscie:) ze kolejnosc ewaluacji czesci wyrazen jest
> >> .. dowolna co rowniez jest zrodlem niekiedy koszmarow (gdy
> >> funckcje maja efekty uboczne - a miewaja czesciej niz sie wydaje:).
> >
> > W "normalnej matematyce" funkcje nie mają efektów ubocznych.
>
> Programowanie "realne" to nie matematyka i efekty uboczne
> sa "immanentna czescia" nie tylko C++.

Ciekawe, że najpierw zarzucasz Lispowi, że notacja nie jest
"jak w normalnej matematyce", ale to, że Pythonowe funkcje nie
są "jak w normalnej matematyce", już jest OK.
Dlaczego pierwsze jest nie OK, a drugie jest OK?

> W "moich czasach" nie mowilo sie "funkcje" ale "procedury".

I ja jestem za tym.
(no i w językach w rodzaju Haskella też masz funkcje).

To, że C, a po nim JavaScript, PHP i inne języki, zawłaszczyło słowo
"funkcja", jest zdecydowanie mylące.

> > No i bardzo dobrze.
> > Przynajmniej zniechęca ludzi do pisania takich programów.
>
> Masz Ty pojecie o produkcyjnym rzemiosle?
> Jesli mozna, to ludzie pisza zle i tyle.

Jak są źle nauczeni, to piszą źle.