On Thu, 3 Jan 2019 05:34:40 -0800 (PST), g...@g...com wrote:

>>> > Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty?
>>>
>>> Myślę, że jedyną odpowiedzią, jakiej mogę udzielić, jest
>>> "to zależy".
>>
>> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od
czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
>
> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
> czy "C++ kreuje złe nawyki" jesteś Ty.

Zgadnij kto to napisał:

"ja sam musiałem oduczać się różnych złych nawyków, których
nabrałem, ucząc się programowania poprzez takie języki
jak C czy C++"

--
pozdrawiam
Roman Tyczka

do góry

On 2019-01-03 14:34, g...@g...com wrote:
> W dniu czwartek, 3 stycznia 2019 09:57:06 UTC+1 użytkownik Maciej Sobczak napisał:
>> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od
>> czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
>
> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
> czy "C++ kreuje złe nawyki" jesteś Ty.

No to bede drugi.
C++ jest zly.
Tak: jest zwyczajnie zly, bo nie tylko kreuje zle nawyki
(a kreuje i to bardzo), ale tez dlatego, ze nawet w "doswiadczonych
rekach" jest zwyczajnie nieprzewidywalny.
Nie pomoga tu zadne MISRY, ani chor Ayatolahow.
Po prostu taka jest rzeczywistosc, bo... (jak wszystko) istnieja
jezyki prog. _obiektywnie_ lepsze i gorsze.
Do tych zlych naleza na pewno: C++, Perl, Tcl, stary Fortran (IV
a nawet 77), takze stary Cobol itd itd.

PS: Na poczatku dyskusji wymieniles IMHO najwazniejsze kryterium
"zlosci" C++. Po tym dalsza dyskusje mozna by spokojnie zamknac :)
Aatollahow i tak NIC nie przekona.
Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie
(w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a
mnie ze... mam za duze :) i skostnialem/nie umiem calosci C++...
i nie przekona ich to ze wlasnie pisze/rozwijam parser C++14, aby moc...
automatem przekonwertowywac programy z chorego dzis C++ na cos
innego/lepszego (glownie C#).
Zeby nie bylo: doceniam zmiany wprowadzone przez C++11/14/17
tyl ze ja myslalem ze nastapia po ~5 latach, a nastapily po ponad
30stu.W dodatku wymuszone przez dawno istniejace/okrzeple "ficzery"
w innych jezykach (dalej jednak nie wprowadzono do standardu properties,
ani finally - i nie pomoze tu zadne RAI bo.. nawet standardowe std
tegoz RA nie wspiera/wymusza.

PS0: Nie twierdze ze Lisp-owatosc jest super. O nie! Wada tego jezyka
jest po pierwsze nieczytelna/trudna do ogarniecia skladnia.
Druga wada (ktora Ty uwazasz za zalete) jest dogmat funcyjnosci i
"bezstanowosci". Swiat jednak jest obiektowy a obiety stany posiadaja
(nie zawsze sa wyliczane/wyliczalne). Oczywiscie rozumiem znaczenie
czystej funcyjnosci Lispa - przeciez to jego glowna/immanentna cecha -,
ale w obszarze/niszy jaka jest inzynieria programowania.
W normalnym swiecie rzemieslniczego programowania jest to jednak
za malo. Czlek mysli/swiat jest zbudowany bardziej obiektowo/stanowo,
a nie funcyjnie zawsze bedzie "ciagnal" do czegos co to myslenie dobrze
odzwiercedla, niz "przestawi sie" na myslenie o wszytskim jako wyniku
chain-a funkcji. CZyli: doceniam elegancje Lispa, ale niestety nie
nie moge docenic praktycznosci Lispa w zwyklym zyciu programistycznym.
Czlek nie mysli odwrotną notacją polską

AK

do góry

W dniu czwartek, 3 stycznia 2019 17:15:08 UTC+1 użytkownik Roman Tyczka napisał:

> > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
> > czy "C++ kreuje złe nawyki" jesteś Ty.
>
> Zgadnij kto to napisał:
>
> "ja sam musiałem oduczać się różnych złych nawyków, których
> nabrałem, ucząc się programowania poprzez takie języki
> jak C czy C++"

Nie muszę zgadywać, bo to ja to pisałem.
I nie jest tam napisane ani "C++ jest zły",
ani "C++ kreuje złe nawyki".

Jest tam napisane, że ja uczyłem się programowania w oparciu
o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków.

Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej
części tego wątku. I podkreśliłem tam, że nie napisałem,
że "C++ stworzył jakieś nawyki".

Czego jeszcze nie rozumiesz?

do góry

On 2019-01-03 17:30, g...@g...com wrote:
>> Zgadnij kto to napisał:
>>
>> "ja sam musiałem oduczać się różnych złych nawyków, których
>> nabrałem, ucząc się programowania poprzez takie języki
>> jak C czy C++"
>
> Nie muszę zgadywać, bo to ja to pisałem.

...i bardzo slusznie napisales:)
To swieta prawda/rzeczywistosc.

> I nie jest tam napisane ani "C++ jest zły",
> ani "C++ kreuje złe nawyki".

Jesli kreuje zle nawyki to po prostu jest zly! :).

AK

do góry

W dniu czwartek, 3 stycznia 2019 17:24:12 UTC+1 użytkownik AK napisał:

> >> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od
> >> czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
> >
> > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
> > czy "C++ kreuje złe nawyki" jesteś Ty.
>
> No to bede drugi.
> C++ jest zly.
> Tak: jest zwyczajnie zly, bo nie tylko kreuje zle nawyki
> (a kreuje i to bardzo), ale tez dlatego, ze nawet w "doswiadczonych
> rekach" jest zwyczajnie nieprzewidywalny.

Ja się z Tobą zgadzam.
Ale stwierdzenie, że "C++ jest zły", jest nieprecyzyjne.
Zły do czego?
Moim zdaniem C++ jest np. doskonały jako przykład tego,
w jaki sposób nie należy projektować języków programowania.
Również w kwestii kreowania nawyków, owo stwierdzenie jest
skrótem myślowym.
Wiele materiałów dydaktycznych napisanych wokół C++ bardzo
moim zdaniem pomaga w kreowaniu złych nawyków.
Ale wyobrażam sobie, że być może można by było stworzyć
materiały dydaktyczne, które korzystałyby z C++ (czy jakiegoś
podzbioru C++), a które nie propagowałyby tych złych nawyków.

Nie znam takich materiałów, ale to nie znaczy, że takie
nie mogą istnieć. (Może "Effective C++" jest czymś takim?
Nie wiem, nie czytałem. Na pewno materiały Stroustrupa,
z którymi miałem styczność, nie były dobre)

> Nie pomoga tu zadne MISRY, ani chor Ayatolahow.
> Po prostu taka jest rzeczywistosc, bo... (jak wszystko) istnieja
> jezyki prog. _obiektywnie_ lepsze i gorsze.
> Do tych zlych naleza na pewno: C++, Perl, Tcl, stary Fortran (IV
> a nawet 77), takze stary Cobol itd itd.

Jeżeli idzie o Perla, to w niektórych zastosowaniach jest
wygodnym narzędziem, ale istotnie nie jest dobrym językiem
do pisania dużych programów.

> PS: Na poczatku dyskusji wymieniles IMHO najwazniejsze kryterium
> "zlosci" C++. Po tym dalsza dyskusje mozna by spokojnie zamknac :)
> Aatollahow i tak NIC nie przekona.
> Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie
> (w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a
> mnie ze... mam za duze :) i skostnialem/nie umiem calosci C++...
> i nie przekona ich to ze wlasnie pisze/rozwijam parser C++14, aby moc...
> automatem przekonwertowywac programy z chorego dzis C++ na cos
> innego/lepszego (glownie C#).

Kolega, z którym pracowałem przez ostatni rok, rozwijał kiedyś język
programowania Ć, dający się transformować do różnych innych platform
(C, C#, Java, Perl, JavaScript, ActionScript i D):
http://cito.sourceforge.net/

> Zeby nie bylo: doceniam zmiany wprowadzone przez C++11/14/17
> tyl ze ja myslalem ze nastapia po ~5 latach, a nastapily po ponad
> 30stu.W dodatku wymuszone przez dawno istniejace/okrzeple "ficzery"
> w innych jezykach (dalej jednak nie wprowadzono do standardu properties,
> ani finally - i nie pomoze tu zadne RAI bo.. nawet standardowe std
> tegoz RA nie wspiera/wymusza.
>
> PS0: Nie twierdze ze Lisp-owatosc jest super. O nie! Wada tego jezyka
> jest po pierwsze nieczytelna/trudna do ogarniecia skladnia.

Myślę, że Lisp jest tak samo nieczytelny dla osób nieprogramujących
w Lispie, jak chiński dla osób nieposługujących się chińskim.
Pewnie przed typografią programów komputerowych jest jeszcze długa droga,
i pewnie dużo dałoby się zrobić, żeby Lisp był czytelniejszy.

Ale składnia Lispa jest bardzo łatwa do opanowania. Piszesz:

(operator argumenty ...)

i to wszystko.

> Druga wada (ktora Ty uwazasz za zalete) jest dogmat funcyjnosci i
> "bezstanowosci".

To nie jest dogmat. To jest podejście promowania promowane
może w Schemie i Clojure. Programiści Common Lispa raczej go nie uznają.

> Swiat jednak jest obiektowy a obiety stany posiadaja
> (nie zawsze sa wyliczane/wyliczalne). Oczywiscie rozumiem znaczenie
> czystej funcyjnosci Lispa - przeciez to jego glowna/immanentna cecha -,
> ale w obszarze/niszy jaka jest inzynieria programowania.
> W normalnym swiecie rzemieslniczego programowania jest to jednak
> za malo. Czlek mysli/swiat jest zbudowany bardziej obiektowo/stanowo,
> a nie funcyjnie zawsze bedzie "ciagnal" do czegos co to myslenie dobrze
> odzwiercedla, niz "przestawi sie" na myslenie o wszytskim jako wyniku
> chain-a funkcji.

Nie zgadzam się. Człowiek jest przyzwyczajony do tego, że myślenie
nie ma w świecie żadnych skutków ubocznych (poza upływającym czasem).
Jest przyzwyczajony do rozróżniania myślenia i działania. Przynajmniej
od czasów Kartezjusza jest przyzwyczajony do rozróżniania myślenia
i działania.

Zgadzam się, że programowanie funkcyjne nie jest uniwersalne w tym
sensie, że nie wszystko da się w nim zrobić. Ale warto go używać
wszędzie tam, gdzie się nadaje (czyli np. w data science, narzędziach
do przetwarzania języków programowania czy algorytmach kombinatorycznych,
ale już nie w programowaniu systemowym czy do tworzenia interfejsów
graficznych), bo to pozwala uniknąć wielu niepotrzebnych pułapek.

Przykład, który lubię dawać na różnych prezentacjach, to program
liczący sumę kwadratów początkowych siedmiu liczb pierwszych.

Imperatywnie zapisalibyśmy go tak:

1: licznik := 7
2: liczba := 0
3: suma := 0
4: dopóki (licznik > 0):
5: jeżeli jest_pierwsza(liczba):
6: suma := suma + liczba^2
7: licznik := licznik - 1
8: liczba := liczba + 1

i jeszcze musieli dopowiedzieć, że po wykonaniu programu
wynik znajdziemy w zmiennej "suma".

Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
znaczeniowe w nawiasy:

(suma (kwadraty (początkowe 7 liczby-pierwsze)))

Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
czym są (kwadraty elementów), co to jest (początkowe N elementy)
i czym są liczby-pierwsze.

To jest kod, który bardzo łatwo się komponuje, i który
bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
gdzie należy szukać wyniku)

wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie

(suma (kwadraty (początkowe 7 liczby-pierwsze)))

jest równoważne wyrażeniu

(suma (kwadraty '(2 3 5 7 11 13)))

które jest równoważne wyrażeniu

(suma '(4 9 25 49 121 169))

i tak dalej.

Zgodzę się, że przy projektowaniu systemów czasu rzeczywistego
jest dużo kodu, którego nie da się "wepchnąć" w ten schemat.

Ale nawet wtedy można zrobić dużo, żeby pozostać
blisko tego modelu (warto przyjrzeć się np. modelowi
aktorów z Erlanga/Elixira)

> CZyli: doceniam elegancje Lispa, ale niestety nie
> nie moge docenic praktycznosci Lispa w zwyklym zyciu programistycznym.
> Czlek nie mysli odwrotną notacją polską

Odwrotna notacja polska jest w języku Forth.
Tutaj masz "w pełni onawiasowaną notację polską"
(czasem nazywaną Cambridge-Polish)

I jest moim zdaniem wartościowym narzędziem do myślenia.
(ja dla zarobku też programuję głównie w C, ale od Lispa
nauczyłem się bardzo dużo)

do góry

W dniu czwartek, 3 stycznia 2019 17:24:12 UTC+1 użytkownik AK napisał:
> Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie
> (w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a
> mnie ze... mam za duze :)

A w ogóle dzięki za miłe słowa :)
Mam wrażenie, że jakoś strasznie mało tutaj serdeczności.
Dla Ciebie również szacunek!

do góry

W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik g...@g...com
napisał:
>
> Przykład, który lubię dawać na różnych prezentacjach, to program
> liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
>
> Imperatywnie zapisalibyśmy go tak:
>
> 1: licznik := 7
> 2: liczba := 0
> 3: suma := 0
> 4: dopóki (licznik > 0):
> 5: jeżeli jest_pierwsza(liczba):
> 6: suma := suma + liczba^2
> 7: licznik := licznik - 1
> 8: liczba := liczba + 1
>
> i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> wynik znajdziemy w zmiennej "suma".
>
> Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> znaczeniowe w nawiasy:
>
> (suma (kwadraty (początkowe 7 liczby-pierwsze)))
>
> Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> czym są (kwadraty elementów), co to jest (początkowe N elementy)
> i czym są liczby-pierwsze.
>
> To jest kod, który bardzo łatwo się komponuje, i który
> bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> gdzie należy szukać wyniku)
>
> wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
>
> (suma (kwadraty (początkowe 7 liczby-pierwsze)))
>
> jest równoważne wyrażeniu
>
> (suma (kwadraty '(2 3 5 7 11 13)))
>
> które jest równoważne wyrażeniu
>
> (suma '(4 9 25 49 121 169))
>
> i tak dalej.
>
lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten przyklad
w pseudkodzie, by to rzeczywiscie porownac?

bo to jest raczej istotnie


w c taki programik nie wyglada zbyt tragicznie


int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
{

int dodano_pierwszych =0;
int suma = 0;

for(int i=0;;i++)
{
if(jest_liczba_pierwsza(i))
{
suma+=i*i;
dodano_pierwszych++;
if(dodano_pierwszych==ilu) return suma;
}
}
}

to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika
raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by
bylo tak szybko moze podzielic na te fazy


chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest

do góry

W dniu czwartek, 3 stycznia 2019 21:51:47 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik g...@g...com
napisał:
> >
> > Przykład, który lubię dawać na różnych prezentacjach, to program
> > liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
> >
> > Imperatywnie zapisalibyśmy go tak:
> >
> > 1: licznik := 7
> > 2: liczba := 0
> > 3: suma := 0
> > 4: dopóki (licznik > 0):
> > 5: jeżeli jest_pierwsza(liczba):
> > 6: suma := suma + liczba^2
> > 7: licznik := licznik - 1
> > 8: liczba := liczba + 1
> >
> > i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> > wynik znajdziemy w zmiennej "suma".
> >
> > Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> > sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> > ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> > znaczeniowe w nawiasy:
> >
> > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> >
> > Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> > czym są (kwadraty elementów), co to jest (początkowe N elementy)
> > i czym są liczby-pierwsze.
> >
> > To jest kod, który bardzo łatwo się komponuje, i który
> > bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> > gdzie należy szukać wyniku)
> >
> > wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
> >
> > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> >
> > jest równoważne wyrażeniu
> >
> > (suma (kwadraty '(2 3 5 7 11 13)))
> >
> > które jest równoważne wyrażeniu
> >
> > (suma '(4 9 25 49 121 169))
> >
> > i tak dalej.
> >
> lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten
przyklad w pseudkodzie, by to rzeczywiscie porownac?
>
> bo to jest raczej istotnie
>
>
> w c taki programik nie wyglada zbyt tragicznie
>
>
> int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> {
>
> int dodano_pierwszych =0;
> int suma = 0;
>
> for(int i=0;;i++)
> {
> if(jest_liczba_pierwsza(i))
> {
> suma+=i*i;
> dodano_pierwszych++;
> if(dodano_pierwszych==ilu) return suma;
> }
> }
> }
>
> to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika
raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by
bylo tak szybko moze podzielic na te fazy
>
>
> chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest

Ogólnie derywację tego programu mam dość dogłębnie opisaną
w pierwszym rozdziale "Pamphletu":
https://github.com/panicz/pamphlet/raw/master/pamphl
et.pdf

W praktyce zapisałbym go raczej np. tak (jeżeli język
wspierałby leniwą ewaluację):

(sum (map square (initial 7 (only prime? numbers))))

gdzie "map", "only" i "initial" są zdefiniowane tak:

(define (map f list)
(if (null? list)
'()
;else
(cons (f (first list)) (map f (rest list)))))

(define (initial n elements)
(if (= n 0)
'()
;else
(cons (first elements) (initial (- n 1) (rest elements))))))

(define (only satisfying? elements)
(if (null? elements)
'()
;else
(if (satisfying? (first elements))
(cons (first elements) (only satisfying? (rest elements)))
;else
(only satisfying? (rest elements)))))

W Haskellu może jest nieco zwięźlej i czytelniej:

map f [] = []
map f (h:t) = (f h):(map f t)

initial 0 elements = []
initial n (first:rest) = first:(initial (n-1) rest)

only satisfying [] = []
only satisfying (first:rest) = if (satisfying first)
then first:(only satisfying rest)
else only satisfying rest

Teraz, w języku z leniwą ewaluacją możemy zbudować nieskończoną listę liczb:

(define (numbers-from n)
(cons n (numbers-from (+ n 1))))

(define numbers (numbers-from 0))

albo w Haskellu:

numbersFrom n = n:(numbersFrom (n+1))

numbers = numbersFrom 0

Sumę definiujemy następująco:

(define (sum list)
(if (null? list)
0
;else
(+ (first list) (sum (rest list)))))

albo w Haskellu:

sum [] = 0
sum (first:rest) = first + (sum rest)

W jezyku bez leniwej ewaluacji jest nieco ciężej (ten wariant jest
opisany w Pamphlecie)

Jeżeli idzie o "wydajność", to kompilator Haskella wspiera technikę
kompilacji zwaną "fuzją" albo "deforestacją", i efektywnie wynikowy
kod będzie z grubsza równoważny temu, co Ty napisałeś (nie będą
tworzone żadne dodatkowe struktury w pamięci, tylko będzie pętla
iterująca po jakichś tam zmiennych)

do góry

W dniu czwartek, 3 stycznia 2019 22:21:26 UTC+1 użytkownik g...@g...com
napisał:
> W dniu czwartek, 3 stycznia 2019 21:51:47 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik g...@g...com
napisał:
> > >
> > > Przykład, który lubię dawać na różnych prezentacjach, to program
> > > liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
> > >
> > > Imperatywnie zapisalibyśmy go tak:
> > >
> > > 1: licznik := 7
> > > 2: liczba := 0
> > > 3: suma := 0
> > > 4: dopóki (licznik > 0):
> > > 5: jeżeli jest_pierwsza(liczba):
> > > 6: suma := suma + liczba^2
> > > 7: licznik := licznik - 1
> > > 8: liczba := liczba + 1
> > >
> > > i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> > > wynik znajdziemy w zmiennej "suma".
> > >
> > > Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> > > sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> > > ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> > > znaczeniowe w nawiasy:
> > >
> > > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> > >
> > > Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> > > czym są (kwadraty elementów), co to jest (początkowe N elementy)
> > > i czym są liczby-pierwsze.
> > >
> > > To jest kod, który bardzo łatwo się komponuje, i który
> > > bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> > > gdzie należy szukać wyniku)
> > >
> > > wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
> > >
> > > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> > >
> > > jest równoważne wyrażeniu
> > >
> > > (suma (kwadraty '(2 3 5 7 11 13)))
> > >
> > > które jest równoważne wyrażeniu
> > >
> > > (suma '(4 9 25 49 121 169))
> > >
> > > i tak dalej.
> > >
> > lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten
przyklad w pseudkodzie, by to rzeczywiscie porownac?
> >
> > bo to jest raczej istotnie
> >
> >
> > w c taki programik nie wyglada zbyt tragicznie
> >
> >
> > int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> > {
> >
> > int dodano_pierwszych =0;
> > int suma = 0;
> >
> > for(int i=0;;i++)
> > {
> > if(jest_liczba_pierwsza(i))
> > {
> > suma+=i*i;
> > dodano_pierwszych++;
> > if(dodano_pierwszych==ilu) return suma;
> > }
> > }
> > }
> >
> > to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika
raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by
bylo tak szybko moze podzielic na te fazy
> >
> >
> > chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam
jest
>
> Ogólnie derywację tego programu mam dość dogłębnie opisaną
> w pierwszym rozdziale "Pamphletu":
> https://github.com/panicz/pamphlet/raw/master/pamphl
et.pdf
>
> W praktyce zapisałbym go raczej np. tak (jeżeli język
> wspierałby leniwą ewaluację):
>
> (sum (map square (initial 7 (only prime? numbers))))
>
> gdzie "map", "only" i "initial" są zdefiniowane tak:
>

jakos nie wyglada mi to na prostsze niz wersja w c

a co to jest tam wyzej sum square (inty?) prime? (funkcja?) i numbers (???)

nie wyglada to na prostsze od c (dlugie jakies) a w to ze to bedzie tak szybkie tez
nie do konca wierze ale powiedzmy ze to mniej istotne, przydaloby sie jednak by bylo
choc prostsze a nie wyglada

sam ten kod w c chyab w sumie mozna napisac prsciej


int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
{
int i = 0, dodano = 0, suma = 0;

for(;;)
if(jest_liczba_pierwsza(++i))
{
suma += i*i ;
if(++dodano==ilu) return suma;
}
}

to i tak jest przydlugie, niepodobaja mi sie zwlaszcza te niepotrzebne jakby
deklaracje.. no i jest trioche kryptyczne, no ale tak to sie pisze w c


> (define (map f list)
> (if (null? list)
> '()
> ;else
> (cons (f (first list)) (map f (rest list)))))
>
> (define (initial n elements)
> (if (= n 0)
> '()
> ;else
> (cons (first elements) (initial (- n 1) (rest elements))))))
>
> (define (only satisfying? elements)
> (if (null? elements)
> '()
> ;else
> (if (satisfying? (first elements))
> (cons (first elements) (only satisfying? (rest elements)))
> ;else
> (only satisfying? (rest elements)))))
>
> W Haskellu może jest nieco zwięźlej i czytelniej:
>
> map f [] = []
> map f (h:t) = (f h):(map f t)
>
> initial 0 elements = []
> initial n (first:rest) = first:(initial (n-1) rest)
>
> only satisfying [] = []
> only satisfying (first:rest) = if (satisfying first)
> then first:(only satisfying rest)
> else only satisfying rest
>
> Teraz, w języku z leniwą ewaluacją możemy zbudować nieskończoną listę liczb:
>
> (define (numbers-from n)
> (cons n (numbers-from (+ n 1))))
>
> (define numbers (numbers-from 0))
>
> albo w Haskellu:
>
> numbersFrom n = n:(numbersFrom (n+1))
>
> numbers = numbersFrom 0
>
> Sumę definiujemy następująco:
>
> (define (sum list)
> (if (null? list)
> 0
> ;else
> (+ (first list) (sum (rest list)))))
>
> albo w Haskellu:
>
> sum [] = 0
> sum (first:rest) = first + (sum rest)
>
> W jezyku bez leniwej ewaluacji jest nieco ciężej (ten wariant jest
> opisany w Pamphlecie)
>
> Jeżeli idzie o "wydajność", to kompilator Haskella wspiera technikę
> kompilacji zwaną "fuzją" albo "deforestacją", i efektywnie wynikowy
> kod będzie z grubsza równoważny temu, co Ty napisałeś (nie będą
> tworzone żadne dodatkowe struktury w pamięci, tylko będzie pętla
> iterująca po jakichś tam zmiennych)

do góry

On 2019-01-03 21:51, fir wrote:
>
> w c taki programik nie wyglada zbyt tragicznie
>
>
> int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> {
>
> int dodano_pierwszych =0;
> int suma = 0;
>
> for(int i=0;;i++)
> {
> if(jest_liczba_pierwsza(i))
> {
> suma+=i*i;
> dodano_pierwszych++;
> if(dodano_pierwszych==ilu) return suma;
> }
> }
> }
>

Jakto nie? Koszmar po prostu.

> to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika
raczej z tego ze
> pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by bylo tak szybko
moze podzielic
> na te fazy

Ciezki niereformowalny betonie (zakalo tej grupy):
Wbij sobie do twego asemblerowatego lba ze mozna i szybko i z
eleganckim rozdzialem na etapy.
Oczywiscie w porzdiejzych jezykach od tego syfu C/C++.
W dodatku wcale nie funkcyjnych, bo to raczez nie stricte funkcyjnosc
jezyka jest zrodlem sukcesu, ale cos co w C++ nie wystepuje, a zwie
sie generateory/wyrazenia generatorowe.
Idea znana od dziesiecioleci (ale nie Ayatollahom C/C++).

W Pythonie wyglada ona np tak (pisane "z palca" o 15 min:):

from itertools import count, islice

N = 15000

pierwsze = []
def jest_pierwsza(liczba, pierwsze=pierwsze):
czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze)
if czy_pierwsza: pierwsze.append(liczba)
return czy_pierwsza

pierwsze = (liczba for liczba in count(2) if jest_pierwsza(liczba))
pierwszeN = (liczba for liczba in islice(pierwsze, N))
kwadraty = (liczba**2 for liczba in pierwszeN)
suma = sum(kwadraty)

print(suma)


No to teraz czekam palancie az usyskasz cos chocby zblizonego
w C (w C++ jest latwiej, ale bez zewnetrzych bibliotek
"metaprogramowania" sie nei obejdze, a i ta bedzie to potworek
w stosunku do w/w w Pythonie.

PS: Od lat 90tych istnieje jezyk w ktorym w/w bedzie jeszcze
prostrze/czytelniejsze (o ktorym oczywiscie tez nie masz pojecia,
jak kazdy"zakochany" w bitach:) i ktory wcale nie jest funkcyjny,
ale jak najbardziej (jak i Python) imperatywny (zwal jak zwal).

> chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest

Sam se napisz leniu i niedouku!

AK

do góry