On Thursday, August 24, 2017 at 6:23:30 PM UTC-4, g...@g...com wrote:
> W dniu czwartek, 24 sierpnia 2017 23:48:16 UTC+2 użytkownik Adam M napisał:
>
> > >
> > > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę
> > > nad sprzętem, to dobra rzecz.
> > > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów
> > > język może wiedzieć o systemie, na którym jest uruchamiany, tym
> > > lepszą robotę mogą odwalić narzędzia uruchomieniowe.
> >
> > Widzę że wszyscy tutaj wieszaja psy na tych biednych krzyżowcach
>
> nie "wieszają psy", tylko używają argumentów.
>
> > - ale jak mówi przsłowie - Jak trwoga to do Boga
> > - i tak jeśli musisz napisac program który musi rozmawiac
> > ze sprzętem to masz tak naprawdę tylko trzy jezyki popularne
> > do dyspozycji: Macro Assembler (nazwywanie tego językiem to
> > dość duże naciągniecie - ale niech bedzie), C lub C++
> > (przez miłosierdzie nie wspominam tu ADY ;-) )
> >
> > Osobiście uważam ze ignorowanie sprzetu prowadzi braku
> > zrozumienia dlaczego oprogramowanie zachowuje sie w ten
> > a nie inny sposób.
>
> często właśnie ignorowanie sprzętu jest zbawienne dla twojego programu.
> dlatego jak uruchamiasz program napisany w clojure czy erlangu
> na 16-rdzeniowym komputerze, to działa prawie 16 razy szybciej
> niż na 1-rdzeniowym. A w C++, o ile nie użyjesz jakichś bibliotek,
> to raczej nie masz co liczyć na tego rodzaju przyspieszenie (a jeśli
> nawet użyjesz, to pewnie i tak masz błędy)

To jest przyklad tzw. magicznego myslenia - napisze program w Erlangu (to nic ze
dziadowski algorytm i jest tylko jedno-watkowy) ale uruchomie go na 16-to rdzeniowym
procesorze i to spowoduje magiczne ulepszenie algorytmu i 16-kroty przyrost
predkosci. Czysta magia. Amdahl sie w grobie przewraca jak slyszy takie nonsensy na
temat przyrostu predkosci na systemach wieloprocesorowych.
Dodakowo ten biedny Erlang wie w jakis magiczny sposob jak ma to uruchomic na tym
16-rdzeniowym procesorze.
>
> > Jeśli kolega zadaje takie pytanie to tutaj jest link który
> > może się przydać aby zrozumieć za automatyczne zwalnianie
> > i odśmiecanie nie zawsze jest dobrym rozwiązaniem:
> > https://www.dynatrace.com/resources/ebooks/javabook/
impact-of-garbage-collection-on-performance/
>
> problem z tą lekturą jest taki, że niewiele z niej wynika.
> proponuję zerknąć np, tutaj
> https://scholarship.rice.edu/bitstream/handle/1911/1
6127/8900220.PDF?sequence=1&isAllowed=y
> albo tu
> https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertat
ion.pdf
> albo tu
> http://www.pipeline.com/~hbaker1/Share-Unify.html
> albo tu
> https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a1
6fe1b969678c8ee3b1a461.pdf
>
> zasadniczo możliwością, którą brak automatycznego odśmiecania
> przed Tobą otwiera, jest możliwość robienia wycieków pamięci.

Nie uwazam że ośmiecanie jest całkowicie złe - w wielu przpadkach daje bezpieczeństwo
(zwłaszcza niedoświadczonym programistom). Moim nawi ększym problemem jest podejście
wszystko albo nic do automatycznego zwalniania pamięci i odśmiecania - zabiera to
wolnosc programiscie w decydowaniu jak program ma sie zachowywac. Podjeście ze
alternatywą do automatycznego zwalniania i odśmiecania sa wycieki pamięci jest jak
proponowanie wprowadzenia zakazu sprzedazy nozy - no bo przecież można kogoś zadzgać.

do góry

W dniu piątek, 25 sierpnia 2017 16:04:09 UTC+2 użytkownik Adam M napisał:

> To jest przyklad tzw. magicznego myslenia - napisze program
> w Erlangu (to nic ze dziadowski algorytm i jest tylko jedno-watkowy)
> ale uruchomie go na 16-to rdzeniowym procesorze i to spowoduje
> magiczne ulepszenie algorytmu i 16-kroty przyrost predkosci.

To jest przykład tzw. programowania deklaratywnego, w którym
mówisz komputerowi co chcesz mieć, a nie -- jak chcesz to
uzyskać, dzięki czemu twórcy narzędzi uruchomieniowych mają
dużo większą swobodę w interpretacji twojego programu.

> > > Jeśli kolega zadaje takie pytanie to tutaj jest link który
> > > może się przydać aby zrozumieć za automatyczne zwalnianie
> > > i odśmiecanie nie zawsze jest dobrym rozwiązaniem:
> > > https://www.dynatrace.com/resources/ebooks/javabook/
impact-of-garbage-collection-on-performance/
> >
> > problem z tą lekturą jest taki, że niewiele z niej wynika.
> > proponuję zerknąć np, tutaj
> > https://scholarship.rice.edu/bitstream/handle/1911/1
6127/8900220.PDF?sequence=1&isAllowed=y
> > albo tu
> > https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertat
ion.pdf
> > albo tu
> > http://www.pipeline.com/~hbaker1/Share-Unify.html
> > albo tu
> > https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a1
6fe1b969678c8ee3b1a461.pdf
> >
> > zasadniczo możliwością, którą brak automatycznego odśmiecania
> > przed Tobą otwiera, jest możliwość robienia wycieków pamięci.
>
> Nie uwazam że ośmiecanie jest całkowicie złe - w wielu
? przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym
> programistom). Moim nawi ększym problemem jest podejście
> wszystko albo nic do automatycznego zwalniania pamięci
> i odśmiecania - zabiera to wolnosc programiscie w decydowaniu
> jak program ma sie zachowywac.

Tzn. czy ma mieć wyciek pamięci, czy nie mieć?

do góry

W dniu piątek, 25 sierpnia 2017 16:28:00 UTC+2 użytkownik g...@g...com
napisał:
> W dniu piątek, 25 sierpnia 2017 16:04:09 UTC+2 użytkownik Adam M napisał:
>
> > Nie uwazam że ośmiecanie jest całkowicie złe - w wielu
> ? przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym
> > programistom). Moim nawi ększym problemem jest podejście
> > wszystko albo nic do automatycznego zwalniania pamięci
> > i odśmiecania - zabiera to wolnosc programiscie w decydowaniu
> > jak program ma sie zachowywac.
>
> Tzn. czy ma mieć wyciek pamięci, czy nie mieć?

Język C również zawiera pewną formę odśmiecania pamięci: po wyjściu
z funkcji pamięć zajmowana przez zmienne automatyczne (utworzone
na stosie) jest zwalniana poprzez przesunięcie wskaźnika stosu.

Dlaczego programistom C odbiera się wolność w swobodnym operowaniu
wskaźnikiem stosu? Przecież wiedzą co robią, i mogliby sami sobie
przesuwać tyle, ile trzeba.

do góry

Użytkownik <g...@g...com> napisał:

> Jaki spor?! Stwierdzilem po prostu fakt.
> To Ty zaprzeczales faktom podanym przez slawka.

> Jakim faktom?

Takim, ze oryginalnie uzywalo sie rekursja, rekursyjnie, rekursywnie, a rekurencja to
nowomowa.
Tak napisal slawek i mial racje (czy Ci/mi sie to podoba czy nie).

> PS: Co nie zmienia faktu ze akurat dzisiejsze rekurencyjne jest rownie
> dobre/stosowne co oryginalne rekursyjne czy rekursywne

> Właśnie. To jest fakt.

Owszem. Tez.

AK

do góry

Użytkownik "slawek" <f...@f...com> napisał:

>> PS: Nie. Nie FORTRAN. To okropny jezyk
>
> I za to go lubię. Pisanie w Fortranie daje emocje nieporównywalnie z niczym innym.
No może Forth
> jeszcze, rep dup i takie tam.

To prawda, ale do czasu.
Sam lepiej ode mnie wiesz ze od F90+ to _calkiem inny_ (o niebo
lepszy/nowoczesniejszy) jezyk.
Ja "myslowo" bylem nawet nie przy F77 ale przy oryginalnym F4. Syf jakich malo :)

> W dodatku gdy napisze się coś w Fortranie, to jest 99% szansa że Seby i Adrianki
będą czuły się
> wykluczone z zabawy. A to też ma wartość.

No fakt niezaprzeczalny :)

PS: za to kompilatory nawet F4 mial ok. Ostatecznie jakis Cray czy inny Lahey to
nie marne PCtowo.
PS: pisalem troche w Microway NDP, pozniej (niestety) w MS F77.
Nie mowie ze MS byl strasznie zly, ale NDP na PC-tach IMHO jakoscia kodu wymiatal.

AK

do góry

W dniu piątek, 25 sierpnia 2017 17:42:34 UTC+2 użytkownik AK napisał:

>
> > Jaki spor?! Stwierdzilem po prostu fakt.
> > To Ty zaprzeczales faktom podanym przez slawka.
>
> > Jakim faktom?
>
> Takim, ze oryginalnie uzywalo sie rekursja, rekursyjnie, rekursywnie, a rekurencja
to nowomowa.
> Tak napisal slawek i mial racje (czy Ci/mi sie to podoba czy nie).

Nie wiem, czy warto poświęcać temu zagadnieniu czas. Według mojego czytnika
niusów napisał ,,w PL nie ma czegoś takiego jak "rekurencja"'',
i według mojego słownika nie miał racji (oczywiście "PL" można rozumieć
różnie -- ja zrozumiałem jako "język polski" -- ale z tego co czytałem
nawet PL/I wspierał rekurencję, wobec czego nie miał racji w żadnym
wyobrażalnym dla mnie sensie)

do góry

Użytkownik "slawek" <f...@f...com> napisał w wiadomości
news:almarsoft.8146424402203245070@news.v.pl...
> On Fri, 25 Aug 2017 06:04:57 +0200, "AK" <n...@n...net> wrote:

> Primo, pojedynczy znak równości to notacja przypisania także w C, które było
/trochę/ wcześniej.

Tak tylko ze C nie posiadal referencji wiec nie psulo to sprawy.

> Secundo, pierwotna notacja z let w Basic została wsparta przez uproszczoną bez let.
I to też
> nastąpiło znacznie wcześniej niż C++.

Zgadza sie. Chyba na PDP-11 pisalem bez let ok 1976 roku.

> Tertio, Fortran też używa od zawsze znaku równości jako postawienia. Tak samo
Snobol.

Wiem, ale nie zmienia to faktu ze Simulowe podejscie (dwoistosc przypisania) bylo
o wiele lepsze.

PS: Wiele bym dal aby w Fortranie pisac := zamiast = , ale za to operatory boolowskie
byly normalne zamiast A.eg.B , B.let.C itp Syf !

AK

do góry

Użytkownik "slawek" <f...@f...com> napisał:

> Kłopoty są z Basic. Bo nazwa Basica wygląda jak odmiana przez przypadek, a w
istocie to w
> mianowniku nazwa dialektu języka Basic.
> Kłopoty są z Basic. Bo nazwa Basica wygląda jak odmiana przez przypadek, a w
istocie to w
> mianowniku nazwa dialektu języka Basic.

Ja pamietam: Basicu, COBOLu
PS: Dla "polepszenia zycia" pisalo sie BasicA ale sie nie przyjelo

AK

do góry

Użytkownik "fir" <p...@g...com> napisał:

> ja ostatnio piszac w c zauwazylem ze umiem kodowac nie myslac

Zauwazylimy to juz daaaawno: ))

AK

do góry

Użytkownik "fir" <p...@g...com> napisał:

> robie switcha (drzewko ifow)

.. i tu lezysz wydajnosciowo ze swym assemblerem przed byle kompilatorem C...

AK

do góry