> > 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.
>
> Toteż chyba zamiast kodu będziesz się musiał zadowolić śmiesznym obrazkiem:
> https://xkcd.com/1425/

Nie, jednak poproszę o kod. Napisałeś program, który dodaje kwadraty pierwszych
siedmiu liczb pierwszych. Ja proszę o implementację dodatkowego wymagania:

"a te liczby, które nie są pierwsze, też można do siebie dodać"

W czym problem?

> To nie jest "zmiana wymagania".
> To jest inny program

W Twoim języku. I to jest właśnie jego ograniczenie.
Ale w imperatywnym przykładzie Fira to nie byłby inny program, tylko ten sam program,
z dodatkowym kodem implementującym to dodatkowe wymaganie.
I dlatego to jest przykład na ukryty koszt (do zapłacenia w przyszłości, czyli
normalny dług techniczny) rozwiązań, które promujesz.

Dlatego dziękuję, ale nie, dziękuję.

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

do góry

> > > > 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ć?
>
> Na przykład, jaki ten program da wynik dla argumentu "7".

Uruchamiamy program i mamy wynik. Co ciekawe, są programy, których wykonania nie da
się pominąć.

I nie całkiem to miałem na myśli pisząc o analizie - bardziej mnie interesuje np. czy
program nie wykona niewłaściwej operacji (jak dzielenie przez zero). Tutaj metody
analizy mają podobną moc.

https://www.hillelwayne.com/post/theorem-prover-show
down/

"I keep hearing that it's easier to analyze pure functional code than mutable
imperative code. But nobody gives rigorous arguments for this and nobody provides
concrete examples. Nobody actually digs into why assignments and transitions are so
much harder to reason about than pure functions ..."

Ciekawe? to czytaj dalej. Człowiek zrobił konkurs i zaprosił do niego zwolenników obu
obozów, żeby pokazali siłę swoich rozwiązań.

Wiesz, kto wygrał?

Nikt nie wygrał. Wszyscy robili tak samo źle (!).

Z "Final thoughts":

"the claim "it's easier to reason about FP than imperative" is wrong"

Ale polecam całość, bo oczywiście problem jest wielowymiarowy.

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

do góry

> > 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ą.
>
> Zgodnie z czyją intuicją?

Z Twoją. Przecież to Ty podałeś ten przykład jako prezentację problemu. Więc
zakładam, że to Ty uważasz, że w tym przykładzie jest jakiś problem.

> Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.

"Każda potwora znajdzie swego amatora." :-)

> > Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.
>
> "Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie?

To Ty pokazałeś ten przykład, pamiętasz? Czy może jest Was więcej?

Ale ja też mogę pokazać przykład w Pythonie:

x = 0

def fun1():
y = x

def fun2():
x = x

print("calling fun1")
fun1()
print("calling fun2")
fun2()

Jedna funkcja działa a druga nie działa. I ta druga robi błąd, którego nie da się
wyjaśnić na podstawie specyfikacji języka. Tak było od zawsze, zarówno w 2.x jak i w
3.x. Zabawka, nie język.

[Wolfram Alpha]

> Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do
programowania.

Bo tu chodziło o to, żeby nie trzeba było programować. Sam to napisałeś - lepiej
problem ominąć, niż go rozwiązywać.

> Formalne notacje są dużo precyzyjniejsze

Pytanie teraz, które. Bo właśnie o to się od początku kłócimy. :-)

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

do góry

W dniu czwartek, 10 stycznia 2019 11:56:03 UTC+1 użytkownik Maciej Sobczak napisał:
> > > 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ą.
> >
> > Zgodnie z czyją intuicją?
>
> Z Twoją. Przecież to Ty podałeś ten przykład jako prezentację problemu. Więc
zakładam, że to Ty uważasz, że w tym przykładzie jest jakiś problem.

Tak, uważam że jest.
Ale nie uważam, że tym problemem jest to, że Python to robi w taki
a nie inny sposób. Uważam, że problemem jest to, że masz dwie dopuszczalne
interpretacje, i żadna nie jest bezwzględnie lepsza od innej, tzn.
można sensownie bronić każdej z nich.

> > Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.
>
> "Każda potwora znajdzie swego amatora." :-)
>
> > > Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.
> >
> > "Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie?
>
> To Ty pokazałeś ten przykład, pamiętasz?

Pamiętam. I pamiętam też, że od razu zwróciłem uwagę, że możliwe są
(przynajmniej) dwa zachowania, których można bronić.

> Ale ja też mogę pokazać przykład w Pythonie:

No ja jeszcze lubię np. takie coś:

>>> def f(x={}):
... return x

>>> a = f()
>>> a
{}
>>> a['x'] = 5
>>> a
{'x':5}
>>> b = f()
>>> b
{'x':5}

### W T F

> > Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do
programowania.
>
> Bo tu chodziło o to, żeby nie trzeba było programować. Sam to napisałeś - lepiej
problem ominąć, niż go rozwiązywać.
>
> > Formalne notacje są dużo precyzyjniejsze
>
> Pytanie teraz, które. Bo właśnie o to się od początku kłócimy. :-)

Chyba Ty się kłócisz ;P

do góry

On 2019-01-10 11:56, Maciej Sobczak wrote:
> To Ty pokazałeś ten przykład, pamiętasz? Czy może jest Was więcej?
>
> Ale ja też mogę pokazać przykład w Pythonie:
>
> x = 0
>
> def fun1():
> y = x
>
> def fun2():
> x = x
>
> print("calling fun1")
> fun1()
> print("calling fun2")
> fun2()
>
> Jedna funkcja działa a druga nie działa. I ta druga robi błąd, którego nie da się
wyjaśnić na podstawie specyfikacji języka. Tak było od zawsze, zarówno w 2.x jak i w
3.x.

Otoz da sie wyjasnic bardzo latwo wlasnie na podstawie specyfikacji Py.
Tak bedzie rowniez w Py3.8+

Przeklenstwe Python a(jak i wszytskich
> Zabawka, nie język.

Heh :) Zabawka to jest Wolfram (jako jezyk - nie srodowisko).
Trudno mi sobie wybarazic dziesiejszy jezyk programowania ktory
nie posiada obiektow, a programowanie "obiektawe" w nim wyglada
tak:
https://github.com/antononcube/MathematicaForPredict
ion/blob/master/Documentation/Implementation-of-Obje
ct-Oriented-Programming-Design-Patterns-in-Mathemati
ca.pdf
To juz assembler jest czytelniejszy!.
Przypominam ze watek jest o jezyky programowania dla poczatkuacych :)

> [Wolfram Alpha]
>
>> Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do
programowania.

Czasami sie nadaje (if then else itp) czasam nie.
Zgadzam sie w pelni, ze slawetna notacja infixowa w Lisp to jest po
prostu kooooszmaaaar!
(no chyba ze ze zaczniemy w szkole uczyc innej/innego zapisu
podstawowej matematyki).
Tak jak koszmarem bylo w np. starym COBOLu:
ADD A TO B.
ADD A TO B GIVING C.
SUBTRACT A FROM B.
SUBTRACT A FROM B GIVING C.
MULTIPLY A BY B.
MULTIPLY A BY B GIVING C.
DIVIDE A INTO B.
DIVIDE A BY B GIVING C.
szybko zastapiono to:
COMPUTE X = A + B * C / D - Y.
bo programisci dostawali kociokwiku, a proste "obliczenia"
rozrastaly sie do min strony:)

AK

do góry

W dniu czwartek, 10 stycznia 2019 11:49:03 UTC+1 użytkownik Maciej Sobczak napisał:
> > > > > 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ć?
> >
> > Na przykład, jaki ten program da wynik dla argumentu "7".
>
> Uruchamiamy program i mamy wynik. Co ciekawe, są programy, których wykonania nie da
się pominąć.

No właśnie tu jest sedno problemu.
Program funkcyjny mogę wyjaśnić w terminach podstawiania wartości
za wyrażenia, a programu imperatywnego nie mogę.
Mogę w najlepszym razie przesymulować przebieg jakiejś maszyny.
Jest to możliwe, ale jest trudniejsze (ma większy narzut kognitywny)

> I nie całkiem to miałem na myśli pisząc o analizie - bardziej mnie interesuje np.
czy program nie wykona niewłaściwej operacji (jak dzielenie przez zero). Tutaj metody
analizy mają podobną moc.
>
> https://www.hillelwayne.com/post/theorem-prover-show
down/
>
> "I keep hearing that it's easier to analyze pure functional code than mutable
imperative code. But nobody gives rigorous arguments for this and nobody provides
concrete examples. Nobody actually digs into why assignments and transitions are so
much harder to reason about than pure functions ..."
>
> Ciekawe? to czytaj dalej. Człowiek zrobił konkurs i zaprosił do niego zwolenników
obu obozów, żeby pokazali siłę swoich rozwiązań.
>
> Wiesz, kto wygrał?
>
> Nikt nie wygrał. Wszyscy robili tak samo źle (!).
>
> Z "Final thoughts":
>
> "the claim "it's easier to reason about FP than imperative" is wrong"
>
> Ale polecam całość, bo oczywiście problem jest wielowymiarowy.

Tak, jest.
I ja też się zgadzam z wieloma obserwacjami Hillela.
Uważam że on i ten jego kolega, Ron Pressler, prezentują
bardzo wyważone podejście do tego zagadnienia.

Też spotykam się z osobami, które twierdzą, że programowanie funkcyjne jest lepsze,
bo tak, albo że używanie monady IO to programowanie funkcyjne.

Programowanie funkcyjne ma tę zaletę, że takie programy można sobie analizować,
podstawiając wartości za wyrażenia.
I na tym, być może, kończy się lista zalet.
(Może nie. Może też systemy typów pozwalają wyrażać jakieś własności, co ma pewną
dodatkową wartość w niektórych przypadkach. Może też niektóre problemy znajdują
elegantszy wyraz w językach funkcyjnych. No ale inne pewnie nie).

Ja nie mówię - i to od początku tego nie mówię - że nie należy stosować operatora
przypisania.
Mówię, że tam, gdzie nie jest to konieczne, lepiej tego unikać.

do góry

On 2019-01-10 12:30, g...@g...com wrote:
>
>> Ale ja też mogę pokazać przykład w Pythonie:
>
> No ja jeszcze lubię np. takie coś:
>
>>>> def f(x={}):
> .... return x

Przeciez pisza wyraznie w _kazdej ksiazce do Pythona_,
ze takie uzycie to jest to blad, gdy "metkowanie"
argumentow domyslych jest wykonywane w momencie _definicji_,
a nie wywolania funkcji.
To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
w Py, a kazdy byle Pythonista zna idiom w rodzaju.

def f(x=None):
x = x or {}
return x

AK

do góry

W dniu czwartek, 10 stycznia 2019 12:56:02 UTC+1 użytkownik AK napisał:

> >> Ale ja też mogę pokazać przykład w Pythonie:
> >
> > No ja jeszcze lubię np. takie coś:
> >
> >>>> def f(x={}):
> > .... return x
>
> Przeciez pisza wyraznie w _kazdej ksiazce do Pythona_,
> ze takie uzycie to jest to blad, gdy "metkowanie"
> argumentow domyslych jest wykonywane w momencie _definicji_,
> a nie wywolania funkcji.

Nie czytałem każdej książki do Pythona, to się nie mogę
zgodzić ani nie zgodzić (ale wystarczy znaleźć jedną, w której
o tym nie piszą, żeby sfalsyfikować to stwierdzenie,
a żeby je zweryfikować, trzeba przeczytać wszystkie)

> To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
> w Py, a kazdy byle Pythonista zna idiom w rodzaju.
>
> def f(x=None):
> x = x or {}
> return x

Czyli zamiast rozwiązać problem dobrze, rozwiązuje się go źle,
a potem wymyśla się idiomy na obejście tego złego rozwiązania.

No, można i tak.

do góry

On 2019-01-10 13:00, g...@g...com wrote:
> Nie czytałem każdej książki do Pythona, to się nie mogę
> zgodzić ani nie zgodzić (ale wystarczy znaleźć jedną, w której

Wiesz co?
Nie wymyslaj. To wiedza na poziomie np w C: "co to jest pointer"

> o tym nie piszą, żeby sfalsyfikować to stwierdzenie,
> a żeby je zweryfikować, trzeba przeczytać wszystkie)
>
>> To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
>> w Py, a kazdy byle Pythonista zna idiom w rodzaju.
>>
>> def f(x=None):
>> x = x or {}
>> return x
>
> Czyli zamiast rozwiązać problem dobrze, rozwiązuje się go źle,
> a potem wymyśla się idiomy na obejście tego złego rozwiązania.
>
> No, można i tak.

Ano mozna.
Zwlaszcza, ze jest to zgodne ze z podstawowa logika i
specyfika Pythona (metkowanie).
Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
- choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
przydatne czesto) jest dyskusyjna.

PS: Innym podejsciam jest zastosowanie czegos w rodzaju:

def f(x=on_the_call(None)):
return x

AK

do góry

On 2019-01-10 14:02, AK wrote:
> def f(x=on_the_call(None)):
>     return x

def f(x=on_the_call({})):
return x

AK

do góry