W dniu czwartek, 24 sierpnia 2017 11:38:34 UTC+2 użytkownik g...@g...com
napisał:
> W dniu czwartek, 24 sierpnia 2017 10:25:26 UTC+2 użytkownik Maciej Sobczak napisał:

> > > Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
> > > np. tak:
> > >
> > > for instance in range(ticks_per_second):
> > > for sector in sectors:
> > > sector.update(0.07)
> >
> > A gdzieś tak od pół dekady C++ pozwala tak:
> >
> > for (Sector & s : sectors)
> > s.update(0.07);
>
> Niestety, owe przeboje miały miejsce ponad dekadę temu.
> Z tego co widziałem, w późniejszym kodzie zrobiłem sobie
> coś takiego:
>
> for_every(body , bodies)
> (*body)->update(0.07);
>
> gdzie for_every zdefiniowałem sobie jako następujące makro:
>
> #define for_every(ITERATOR, COLLECTION) \
> for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
> ITERATOR != COLLECTION.end(); ++ITERATOR)
>
> aż się dziwię, że byłem wtedy na tyle mądry, żeby nie napisać
>
> #define in ,
>
> Ale to był już okres schyłkowy, po którym dałem sobie spokój z C++em
> (poza tym, że czasem go trochę używałem, jak potrzebowałem np. tablicy
> haszującej albo innej kolekcji odmiennej od tablicy i ew. listy linkowanej)

Jeszcze w międzyczasie miałem drobny romans z biblioteką boost.
Pamiętam też, że robiłem w owym czasie jakiś projekt uczelnię,
i kolega z mojej grupy, który był odpowiedzialny za stworzenie GUI
do projektu, użył Twojej biblioteki C++/Tcl do napisania swojej
części programu :)

do góry

On Thursday, August 24, 2017 at 1:02:09 PM UTC+2, g...@g...com wrote:
> W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał:
> > On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, g...@g...com wrote:
> > > Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
> > Każdy ma takie prawo.
> >
> >
> > > W moim odczuciu to nie jest dobry język do formułowania myśli.
> > W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i
> > funkcji, można utworzyć sobie "język", może nie do formułowania
> > myśli, ale do zwięzłego rozwiązania problemu.
>
> W książce "Lekcja Programowania" był taki cytat:
>
> "Dobry programista poradzi sobie z ubogim językiem
> czy pokracznym systemem operacyjnym, ale nawet
> najlepsze środowisko programistyczne nie uratuje
> słabego programisty"
>
> i oczywiście w jakimś sensie jest to truizm. Tyle
> że może wytwarzać fałszywe przeświadczenie, że
> jakość języka programowania nie ma żadnego znaczenia,
> a jakość programisty ma wyłączne znaczenie.
> Wydaje mi się, że przykład Allena Newella i Alana Kaya
> pokazuje, że tak nie jest.

Rozumiem. Ale powiedz mi jeszcze, co myślisz o dobrych
bibliotekach w C++, które w praktyce są dostępne od
wielu lat. Czy te biblioteki nie czynią z C++ właśnie
dobrego środowiska? W sumie o tym pisałem wcześniej,
tylko nie użyłem słowa "biblioteka". Pewnie że nie
zawsze chce mi się pisać w C++ wyrażeń regularnych, ale
kiedyś miałem przypadek, w którym program słabo działał
na gotowacach. Problemem była wydajność. Wyrzeźbiłem
ręcznie jakiś podzbiór funkcjonalności regexp i mógł
działać. C++ to język który daje dwie możliwości na
raz - ręcznie rzeźbienie z którym poradzi sobie tylko
dobry programista, albo dobre biblioteki przy
pomocy których każdy programista stosunkowo szybko
napisze działającą aplikację.


> Dobry programista poradzi sobie z C++ -- z czasem nauczy
> się omijać pułapki i obchodzić jego ograniczenia.
Zastanawiam się, czy w moim przypadku nie było inaczej.
Na początku, gdy po ludzku programowałem w C++, nie
wpadałem zbyt często w zbyt duże pułapki. Potem przyszła
Java, w Javie programowałem w bardzo podobny stylu jak w
C++. Ale jeszcze potem napotykałem często na problemy
wydajnościowe i musiałem wrócić do C++, tyle że w C++
już po ludzku nie programowałem - a to powodowało że
czasami doprowadzałem aplikację do stanu w którym była
mało podatna na rozwój - ale dzialała szybko na tanim
sprzęcie. W zasadzie w pułapki wpadałem częściej jako
doświadczony programista, jako początkujący nie
prowokowałem sytuacji prowadzących w ślepe uliczki.


> Wytworzy
> "swój własny" sposób programowania w C++, w którym będzie
> się w stanie bez problemu poruszać. Wytworzy sobie swoją
> własną bibliotekę klas, metod i definicji, w którym będzie
> w stanie "rozwiązywać problemy" czy budować systemy. Jeśli
> będzie musiał.
Tak, coś takiego mialem na myśli, albo po prostu weźmie QT.
W co większych firmach mają swoje gotowe i bardzo dobre
biblioteki.


> Tyle że moim zdaniem to nie jest dobra droga dla rozwoju
> przemysłu i programisty. Lepiej mieć wspólny język, którym
> możemy się bez problemu porozumieć -- tym bardziej, że
> często samo sformułowanie problemu jest już jego rozwiązaniem
> (albo jego kluczową częścią).
Że wspólny się zgadzam. Jestem za tym, aby rozbudować bibliotekę
QT np. 10 razy pod względem funkcjonalności. Jestem też za tym,
aby dodać wersje klas nastawione na wydajność, a nie na wygodę
programisty. Potem niech komitet wykupi prawa do tej biblioteki i
ustali bibliotekę QT jako bibliotekę standardową. A różni
producenci niech dostarczają swoje implementacje. Pewnie że
lepiej byłoby, gdyby wszyscy na Ziemie gadali w jednym języku, ale
czy angielski jest lepszy od hiszpańskiego, to nie wiem.



> > > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> > > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> > > nie ma błędu, którego projektanci C++ by nie popełnili.
> > C++ to asembler obiektowy. Dużo lepiej nie da się takiego
> > języka zaprojektować.
>
> Nie rozumiem. Co to jest "asembler obiektowy"?

To powszechnie znana drwina z obiektowości-wskaźnikowej jaką
wprowadza C++ :D


> > Ja czasami też bym chciał w C++ programować
> > ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest.
> >
> > Projektanci C++ mogli zrobić dwa języki wywodzące się z C:
>
> Projektanci C++ nie są jedynymi osobami na świecie, które
> mogą robić języki programowania. (często mam wrażenie, że
> sukces C++ wziął się stąd, że było wiele osób, którym wydawało
> się, że jest inaczej)

Jakiś język programowania kompilowany do C można napisać :)




>
> > > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
> > > to może ten apel powinienem skierować do entuzjastów tego
> > > języka. Ktoś się podejmie?
> > W wielu praktycznych zastosowaniach nie ma alternatywy.
>
> Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć
> nieco pracy, żeby jej poszukać.

Ale chodzi o sensowne alternatywy. Czasami chciałbym język javo-podobny,
kompilowany, bez wywoływania metod po nazwie, bez automatycznego
zwalniania pamięci, bez plików nagłówkowych, bez sieczki składniowej w
szablonach, bez wskaźników... Ale ostatnio... mało używam malloc i new,
wskaźników używam tylko w gorącej pętli, za to mam 3-4-krotnie
zagnieżdżone szablony i edytor głupieje, zamiast mnie wspierać.

Zobacz kod drzewa i testu które niedawno wrzuciłem, tam bezposrednio
nie operuję na new i malloc, a wskaźniki są tylko w tych pętelkach,
które są ważne dla wydajności.

https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-programu-testujacego.html

https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-c-drzewa-czerwono-czarne.html

Używanie tego drzewa nie jest strasznie trudne, a daje bardzo dużą
wydajność. Jak w haskelu i lispie używa się drzew czerwono-czarnych?

Pozdrawiam

do góry

W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
>
> Jakiś język programowania kompilowany do C można napisać :)
>

org-asm juz prawi zrobiony tak ze
niedlugo bede mogl robic wlasne kompilatory kompilujace do exe, firr nie chodzi na
kompromisy ;c

do góry

> W języku Wolfram można tak:
>
> oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]]

A w języku Wolfram napiszę web serwis z api po http? A aplikację
desktopową? A skrypt systemowy co mi z sysloga wyciągnie i przeparsuje
dane, po czym wyśle stosownego maila?

To w jakim kontekście "najlepszego języka" występuje ten zawodnik?

--
Pozdrawiam,
Mateusz Bogusz

do góry

W dniu czwartek, 24 sierpnia 2017 18:10:55 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
> >
> > Jakiś język programowania kompilowany do C można napisać :)
> >
>
> org-asm juz prawi zrobiony tak ze
> niedlugo bede mogl robic wlasne kompilatory kompilujace do exe, firr nie chodzi na
kompromisy ;c

ok no i oto ultrapierwsza wersja mojego asemblera zfinalizowana

minddetonator.htw.pl/organic.zip

na razie mie kompilowac prawie wylacznie to


.code

push note
call msvcrt.printf

push 0
push str_zero
push hello
push 0
call user32.MessageBoxA


push 0
call kernel32.ExitProcess

.data

note: "assembled" 32 "by" 32 "fir" 0 0 0 0
str_zero: 0
hello: "hello" 32 "asm" 32 "world" 32 "!" 0 0 0 0 0 0

tj mozna dodawac dowolne wywolania z dowolnej dll-ki ale nie wpisalem innych
menemonickow poza podstawowym push i call ;c

jutro pewnie dodam pare podstawowych instrukcji i jakakolwiek obsluge bledow etc, bo
na razie jestem chyba zbyt zmeczony ale ok ze dziala, rozszerzenie tego to juz pikus
w porownanu z dlubaniem by to wogole zaczelo dzialac

do góry

W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:

> > i oczywiście w jakimś sensie jest to truizm. Tyle
> > że może wytwarzać fałszywe przeświadczenie, że
> > jakość języka programowania nie ma żadnego znaczenia,
> > a jakość programisty ma wyłączne znaczenie.
> > Wydaje mi się, że przykład Allena Newella i Alana Kaya
> > pokazuje, że tak nie jest.
>
> Rozumiem. Ale powiedz mi jeszcze, co myślisz o dobrych
> bibliotekach w C++, które w praktyce są dostępne od
> wielu lat. Czy te biblioteki nie czynią z C++ właśnie
> dobrego środowiska?

Zależy do czego. Rzecz z bibliotekami ma się tak,
że ich użyteczność ogranicza się zazwyczaj do celu,
w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
szlaki, i do rozwiązania typowych problemów z reguły
pewnie wystarczą.
Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
to jak najbardziej korzystaj z niego.
Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
"najlepszy", tak jak niektóre osoby by chciały. Być może
w niektórych sytuacjach rzeczywiście będzie najlepszy,
ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
-- bo akurat nikt nie zrobił lepszych bibliotek dla innych
języków. C++ jako abstrakcyjna notacja do komunikowania
i zapisywania idei raczej się nie nadaje. Nie jest dobrym
narzędziem dla umysłu (choć może jest dobrym narzędziem
dla przemysłu)

> W sumie o tym pisałem wcześniej,
> tylko nie użyłem słowa "biblioteka". Pewnie że nie
> zawsze chce mi się pisać w C++ wyrażeń regularnych, ale
> kiedyś miałem przypadek, w którym program słabo działał
> na gotowacach. Problemem była wydajność. Wyrzeźbiłem
> ręcznie jakiś podzbiór funkcjonalności regexp i mógł
> działać. C++ to język który daje dwie możliwości na
> raz - ręcznie rzeźbienie z którym poradzi sobie tylko
> dobry programista, albo dobre biblioteki przy
> pomocy których każdy programista stosunkowo szybko
> napisze działającą aplikację.

Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że
na pierwszym roku studiów miał za zadanie zrobienie kalkulatora
GUI na Windows. Powiedział, że męczył się z tym zadaniem
3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C#
w 3 godziny.

Z C++ jest taki problem, że to nie jest język, tylko
worek różnych ficzerów, które czasem do siebie pasują,
a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
tak, jakby to było C, to też możesz. Niektórzy powiedzą,
że to dobrze, bo "język daje wolność". Jednak ja nie
uważam, że to jest dobra wolność, bo jeżeli masz w zespole
programistów z różnym backgroundem, to każdy będzie mógł
pisać po swojemu.

Dla odmiany, wydaje mi się, że języki, które narzucają
na programistę więcej ograniczeń, jak np. Clojure, w którym
wszystko jest niemutowalne, w rezultacie dają kod dużo
lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
prezentacji, której tytuł mówi już dość wiele: "Constraints
Liberate, Liberties Constrain":
https://www.youtube.com/watch?v=GqmsQeSzMdw

> > Dobry programista poradzi sobie z C++ -- z czasem nauczy
> > się omijać pułapki i obchodzić jego ograniczenia.
> Zastanawiam się, czy w moim przypadku nie było inaczej.
> Na początku, gdy po ludzku programowałem w C++, nie
> wpadałem zbyt często w zbyt duże pułapki. Potem przyszła
> Java, w Javie programowałem w bardzo podobny stylu jak w
> C++. Ale jeszcze potem napotykałem często na problemy
> wydajnościowe i musiałem wrócić do C++, tyle że w C++
> już po ludzku nie programowałem - a to powodowało że
> czasami doprowadzałem aplikację do stanu w którym była
> mało podatna na rozwój - ale dzialała szybko na tanim
> sprzęcie. W zasadzie w pułapki wpadałem częściej jako
> doświadczony programista, jako początkujący nie
> prowokowałem sytuacji prowadzących w ślepe uliczki.

Pytanie, skąd się uczyłeś C++a

> > Wytworzy
> > "swój własny" sposób programowania w C++, w którym będzie
> > się w stanie bez problemu poruszać. Wytworzy sobie swoją
> > własną bibliotekę klas, metod i definicji, w którym będzie
> > w stanie "rozwiązywać problemy" czy budować systemy. Jeśli
> > będzie musiał.
> Tak, coś takiego mialem na myśli, albo po prostu weźmie QT.
> W co większych firmach mają swoje gotowe i bardzo dobre
> biblioteki.

I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
świadomość, że to jest w dużej mierze owoc tego, co się im
jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
Pytanie, ile te próby i błędy kosztowały.

> > Tyle że moim zdaniem to nie jest dobra droga dla rozwoju
> > przemysłu i programisty. Lepiej mieć wspólny język, którym
> > możemy się bez problemu porozumieć -- tym bardziej, że
> > często samo sformułowanie problemu jest już jego rozwiązaniem
> > (albo jego kluczową częścią).
> Że wspólny się zgadzam. Jestem za tym, aby rozbudować bibliotekę
> QT np. 10 razy pod względem funkcjonalności. Jestem też za tym,
> aby dodać wersje klas nastawione na wydajność, a nie na wygodę
> programisty.

Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
optymalizujące.

> Potem niech komitet wykupi prawa do tej biblioteki i
> ustali bibliotekę QT jako bibliotekę standardową.


To też jest problem, że jak chcesz mieć kontener, to musisz
wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
nie da się rozwiązać, zachowując kompatybilność wsteczną.

> A różni
> producenci niech dostarczają swoje implementacje. Pewnie że
> lepiej byłoby, gdyby wszyscy na Ziemie gadali w jednym języku, ale
> czy angielski jest lepszy od hiszpańskiego, to nie wiem.

Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać,
bo wszystkie są raczej złożone i idiosynkratyczne.

> > > > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> > > > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> > > > nie ma błędu, którego projektanci C++ by nie popełnili.
> > > C++ to asembler obiektowy. Dużo lepiej nie da się takiego
> > > języka zaprojektować.
> >
> > Nie rozumiem. Co to jest "asembler obiektowy"?
>
> To powszechnie znana drwina z obiektowości-wskaźnikowej jaką
> wprowadza C++ :D

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.

> > > Ja czasami też bym chciał w C++ programować
> > > ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest.
> > >
> > > Projektanci C++ mogli zrobić dwa języki wywodzące się z C:
> >
> > Projektanci C++ nie są jedynymi osobami na świecie, które
> > mogą robić języki programowania. (często mam wrażenie, że
> > sukces C++ wziął się stąd, że było wiele osób, którym wydawało
> > się, że jest inaczej)
>
> Jakiś język programowania kompilowany do C można napisać :)

Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą
C++ też tak zaczynał.

> > > > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
> > > > to może ten apel powinienem skierować do entuzjastów tego
> > > > języka. Ktoś się podejmie?
> > > W wielu praktycznych zastosowaniach nie ma alternatywy.
> >
> > Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć
> > nieco pracy, żeby jej poszukać.
>
> Ale chodzi o sensowne alternatywy. Czasami chciałbym język javo-podobny,
> kompilowany, bez wywoływania metod po nazwie, bez automatycznego
> zwalniania pamięci, bez plików nagłówkowych, bez sieczki składniowej w
> szablonach, bez wskaźników... Ale ostatnio... mało używam malloc i new,
> wskaźników używam tylko w gorącej pętli, za to mam 3-4-krotnie
> zagnieżdżone szablony i edytor głupieje, zamiast mnie wspierać.

Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?

> Zobacz kod drzewa i testu które niedawno wrzuciłem, tam bezposrednio
> nie operuję na new i malloc, a wskaźniki są tylko w tych pętelkach,
> które są ważne dla wydajności.
>
> https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-programu-testujacego.html
>
> https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-c-drzewa-czerwono-czarne.html
>
> Używanie tego drzewa nie jest strasznie trudne, a daje bardzo dużą
> wydajność. Jak w haskelu i lispie używa się drzew czerwono-czarnych?

Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
do wersji korzystających z mutacji.
Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
transformacji programów napisanych funkcyjnie w wydajniejsze
programy stosujące mutację.

do góry

On Thursday, August 24, 2017 at 3:32:50 PM UTC-4, g...@g...com wrote:
> W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
>
> > > i oczywiście w jakimś sensie jest to truizm. Tyle
> > > że może wytwarzać fałszywe przeświadczenie, że
> > > jakość języka programowania nie ma żadnego znaczenia,
> > > a jakość programisty ma wyłączne znaczenie.
> > > Wydaje mi się, że przykład Allena Newella i Alana Kaya
> > > pokazuje, że tak nie jest.
> >
> > Rozumiem. Ale powiedz mi jeszcze, co myślisz o dobrych
> > bibliotekach w C++, które w praktyce są dostępne od
> > wielu lat. Czy te biblioteki nie czynią z C++ właśnie
> > dobrego środowiska?
>
> Zależy do czego. Rzecz z bibliotekami ma się tak,
> że ich użyteczność ogranicza się zazwyczaj do celu,
> w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> szlaki, i do rozwiązania typowych problemów z reguły
> pewnie wystarczą.
> Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
> to jak najbardziej korzystaj z niego.
> Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
> "najlepszy", tak jak niektóre osoby by chciały. Być może
> w niektórych sytuacjach rzeczywiście będzie najlepszy,
> ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
> -- bo akurat nikt nie zrobił lepszych bibliotek dla innych
> języków. C++ jako abstrakcyjna notacja do komunikowania
> i zapisywania idei raczej się nie nadaje. Nie jest dobrym
> narzędziem dla umysłu (choć może jest dobrym narzędziem
> dla przemysłu)
>
> > W sumie o tym pisałem wcześniej,
> > tylko nie użyłem słowa "biblioteka". Pewnie że nie
> > zawsze chce mi się pisać w C++ wyrażeń regularnych, ale
> > kiedyś miałem przypadek, w którym program słabo działał
> > na gotowacach. Problemem była wydajność. Wyrzeźbiłem
> > ręcznie jakiś podzbiór funkcjonalności regexp i mógł
> > działać. C++ to język który daje dwie możliwości na
> > raz - ręcznie rzeźbienie z którym poradzi sobie tylko
> > dobry programista, albo dobre biblioteki przy
> > pomocy których każdy programista stosunkowo szybko
> > napisze działającą aplikację.
>
> Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że
> na pierwszym roku studiów miał za zadanie zrobienie kalkulatora
> GUI na Windows. Powiedział, że męczył się z tym zadaniem
> 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C#
> w 3 godziny.
>
> Z C++ jest taki problem, że to nie jest język, tylko
> worek różnych ficzerów, które czasem do siebie pasują,
> a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
> Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
> tak, jakby to było C, to też możesz. Niektórzy powiedzą,
> że to dobrze, bo "język daje wolność". Jednak ja nie
> uważam, że to jest dobra wolność, bo jeżeli masz w zespole
> programistów z różnym backgroundem, to każdy będzie mógł
> pisać po swojemu.
>
> Dla odmiany, wydaje mi się, że języki, które narzucają
> na programistę więcej ograniczeń, jak np. Clojure, w którym
> wszystko jest niemutowalne, w rezultacie dają kod dużo
> lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
> prezentacji, której tytuł mówi już dość wiele: "Constraints
> Liberate, Liberties Constrain":
> https://www.youtube.com/watch?v=GqmsQeSzMdw
>
> > > Dobry programista poradzi sobie z C++ -- z czasem nauczy
> > > się omijać pułapki i obchodzić jego ograniczenia.
> > Zastanawiam się, czy w moim przypadku nie było inaczej.
> > Na początku, gdy po ludzku programowałem w C++, nie
> > wpadałem zbyt często w zbyt duże pułapki. Potem przyszła
> > Java, w Javie programowałem w bardzo podobny stylu jak w
> > C++. Ale jeszcze potem napotykałem często na problemy
> > wydajnościowe i musiałem wrócić do C++, tyle że w C++
> > już po ludzku nie programowałem - a to powodowało że
> > czasami doprowadzałem aplikację do stanu w którym była
> > mało podatna na rozwój - ale dzialała szybko na tanim
> > sprzęcie. W zasadzie w pułapki wpadałem częściej jako
> > doświadczony programista, jako początkujący nie
> > prowokowałem sytuacji prowadzących w ślepe uliczki.
>
> Pytanie, skąd się uczyłeś C++a
>
> > > Wytworzy
> > > "swój własny" sposób programowania w C++, w którym będzie
> > > się w stanie bez problemu poruszać. Wytworzy sobie swoją
> > > własną bibliotekę klas, metod i definicji, w którym będzie
> > > w stanie "rozwiązywać problemy" czy budować systemy. Jeśli
> > > będzie musiał.
> > Tak, coś takiego mialem na myśli, albo po prostu weźmie QT.
> > W co większych firmach mają swoje gotowe i bardzo dobre
> > biblioteki.
>
> I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> świadomość, że to jest w dużej mierze owoc tego, co się im
> jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> Pytanie, ile te próby i błędy kosztowały.
>
> > > Tyle że moim zdaniem to nie jest dobra droga dla rozwoju
> > > przemysłu i programisty. Lepiej mieć wspólny język, którym
> > > możemy się bez problemu porozumieć -- tym bardziej, że
> > > często samo sformułowanie problemu jest już jego rozwiązaniem
> > > (albo jego kluczową częścią).
> > Że wspólny się zgadzam. Jestem za tym, aby rozbudować bibliotekę
> > QT np. 10 razy pod względem funkcjonalności. Jestem też za tym,
> > aby dodać wersje klas nastawione na wydajność, a nie na wygodę
> > programisty.
>
> Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> optymalizujące.
>
> > Potem niech komitet wykupi prawa do tej biblioteki i
> > ustali bibliotekę QT jako bibliotekę standardową.
>
>
> To też jest problem, że jak chcesz mieć kontener, to musisz
> wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
> nie da się rozwiązać, zachowując kompatybilność wsteczną.
>
> > A różni
> > producenci niech dostarczają swoje implementacje. Pewnie że
> > lepiej byłoby, gdyby wszyscy na Ziemie gadali w jednym języku, ale
> > czy angielski jest lepszy od hiszpańskiego, to nie wiem.
>
> Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać,
> bo wszystkie są raczej złożone i idiosynkratyczne.
>
> > > > > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
> > > > > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
> > > > > nie ma błędu, którego projektanci C++ by nie popełnili.
> > > > C++ to asembler obiektowy. Dużo lepiej nie da się takiego
> > > > języka zaprojektować.
> > >
> > > Nie rozumiem. Co to jest "asembler obiektowy"?
> >
> > To powszechnie znana drwina z obiektowości-wskaźnikowej jaką
> > wprowadza C++ :D
>
> 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 - 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. To tak jak by lekarz powiedzial
po co mam uczyc sie calej anatomii czlowieka jesli bede okulista.

>
> > > > Ja czasami też bym chciał w C++ programować
> > > > ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest.
> > > >
> > > > Projektanci C++ mogli zrobić dwa języki wywodzące się z C:
> > >
> > > Projektanci C++ nie są jedynymi osobami na świecie, które
> > > mogą robić języki programowania. (często mam wrażenie, że
> > > sukces C++ wziął się stąd, że było wiele osób, którym wydawało
> > > się, że jest inaczej)
> >
> > Jakiś język programowania kompilowany do C można napisać :)
>
> Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą
> C++ też tak zaczynał.
>
> > > > > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
> > > > > to może ten apel powinienem skierować do entuzjastów tego
> > > > > języka. Ktoś się podejmie?
> > > > W wielu praktycznych zastosowaniach nie ma alternatywy.
> > >
> > > Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć
> > > nieco pracy, żeby jej poszukać.
> >
> > Ale chodzi o sensowne alternatywy. Czasami chciałbym język javo-podobny,
> > kompilowany, bez wywoływania metod po nazwie, bez automatycznego
> > zwalniania pamięci, bez plików nagłówkowych, bez sieczki składniowej w
> > szablonach, bez wskaźników... Ale ostatnio... mało używam malloc i new,
> > wskaźników używam tylko w gorącej pętli, za to mam 3-4-krotnie
> > zagnieżdżone szablony i edytor głupieje, zamiast mnie wspierać.
>
> Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?

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/

>
> > Zobacz kod drzewa i testu które niedawno wrzuciłem, tam bezposrednio
> > nie operuję na new i malloc, a wskaźniki są tylko w tych pętelkach,
> > które są ważne dla wydajności.
> >
> > https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-programu-testujacego.html
> >
> > https://drzewa-czerwono-czarne.blogspot.com/p/kod-zr
odowy-c-drzewa-czerwono-czarne.html
> >
> > Używanie tego drzewa nie jest strasznie trudne, a daje bardzo dużą
> > wydajność. Jak w haskelu i lispie używa się drzew czerwono-czarnych?
>
> Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
> Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> do wersji korzystających z mutacji.
> Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> transformacji programów napisanych funkcyjnie w wydajniejsze
> programy stosujące mutację.

do góry

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)

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

do góry

W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:

> Zależy do czego. Rzecz z bibliotekami ma się tak,
> że ich użyteczność ogranicza się zazwyczaj do celu,
> w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> szlaki, i do rozwiązania typowych problemów z reguły
> pewnie wystarczą.
No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku.
Część zadań rozwiązuje się przy pomocy środków jakie są
dostarczane na poziomie języka, a drugą część na poziomie
środków z bibliotek. Jeśli jest więcej na poziomie
języka i język umożliwia bardziej zwartą składnię, to
można odnieść wrażenie, że język jest lepszy do danego
zadania. Lepszy w sensie że trzeba mniej kodu wpisać,
zapewne jest. Poza tym to nie wiem... Napisałeś kilka
postów powyżej, że niektóre języki nie są tylko językami
programowania, ale językami myślenia. Jeśli się myśli
algorytmami, to pewnie masz rację, chociaż... napiszę poniżej
coś o pewnym programie do gry w szachy. Ale jeśli myśli się
optymalnym rozwiązaniem danego problemu, to może język
C++ jest językiem myślenia?

> Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
> to jak najbardziej korzystaj z niego.
> Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
> "najlepszy",
Bez kontekstu powiedzenie o czymś że jest najlepsze w ogóle
nie ma sensu.


> tak jak niektóre osoby by chciały. Być może
> w niektórych sytuacjach rzeczywiście będzie najlepszy,
> ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
> -- bo akurat nikt nie zrobił lepszych bibliotek dla innych
> języków. C++ jako abstrakcyjna notacja do komunikowania
> i zapisywania idei raczej się nie nadaje.
Pewnie że nie, bo do tego celu najlepszy jest metakod.

Miałem napisać coś o programie do gry w szachy. Otóż
był on napisany w C++ i procedura alpha-beta nie odbiegała
dużo od meta-kodu - ale oczywiście metakodem nie była.


> Nie jest dobrym
> narzędziem dla umysłu (choć może jest dobrym narzędziem
> dla przemysłu)
Może zależy jaki umysł? Jeśli umysł jest nastawiony na
optymalizację kodu, to może jest dobrym językiem dla
umysłu?


> Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że
> na pierwszym roku studiów miał za zadanie zrobienie kalkulatora
> GUI na Windows. Powiedział, że męczył się z tym zadaniem
> 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C#
> w 3 godziny.
Jeden wygenerował kod GUI, a drugi wklepał - stąd różnice.
Jeśli trzeba szybko napisać program, to C++ nie jest
dobrym wyborem, poza sytuacją gdy do danego problemu są
dobre biblioteki. Do C++ dziś jest wiele dobrych bibliotek,
co powoduje, że C++ do wielu zadań jest w miarę dobrym
wyborem nawet jeśli kryterium jest czas utworzenia programu.
W QT też zdarzało mi się wyklikać w 3 dni dużą aplikację,
której czas wykonania był szacowany na 1-2 miesiące. Fakt
że to zdarzało się bardzo rzadko.


> Z C++ jest taki problem, że to nie jest język, tylko
> worek różnych ficzerów, które czasem do siebie pasują,
> a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
> Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
> tak, jakby to było C, to też możesz. Niektórzy powiedzą,
> że to dobrze, bo "język daje wolność". Jednak ja nie
> uważam, że to jest dobra wolność, bo jeżeli masz w zespole
> programistów z różnym backgroundem, to każdy będzie mógł
> pisać po swojemu.

Ja się wykłócałem i to w innych językach o sposób nazywania
zmiennych, pól, metod i klas. I to nie o to że nazwa jest
zbyt skrótowa i za mało mówi, czy zbyt rozwlekła i odciąga
uwagę od istoty kodu, tylko o to, kiedy duża litera, kiedy
znak podkreślenia. Każdy ma jakiś swój background. W zespole
trzeba przyjąć jakieś zasady. Ja z reguły nastawiałem się
solidny szkielet aplikacji, w ramach szkieletu były moduły, a
moduł oznaczał cokolwiek. W ramach modułu była duża wolność,
ryzyko wywalenia całego modułu było akceptowalne, natomiast
zazębianie się modułu z całą aplikacją było według bardzo
rygorystycznych zasad.


> Dla odmiany, wydaje mi się, że języki, które narzucają
> na programistę więcej ograniczeń, jak np. Clojure, w którym
> wszystko jest niemutowalne, w rezultacie dają kod dużo
> lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
> prezentacji, której tytuł mówi już dość wiele: "Constraints
> Liberate, Liberties Constrain":
> https://www.youtube.com/watch?v=GqmsQeSzMdw
Żałuję teraz że nie znam tego języka, byśmy porozmawiali.

> Pytanie, skąd się uczyłeś C++a
Z literatury.

> I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> świadomość, że to jest w dużej mierze owoc tego, co się im
> jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> Pytanie, ile te próby i błędy kosztowały.

Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są
gotowe biblioteki, nie jest najlepszym języku do szybkiego
wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca"
aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż
mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach
by padło przy 100GB, a może przy 20GB. W rozwiązaniu
pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło.


> Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> optymalizujące.
Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach.
A potem narzędzi optymalizacyjnych nie było i dupa. Pewnie że
ja też bym chciał programować tylko w Javie, bo się zakochałem w
tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać
po takie języki.

> To też jest problem, że jak chcesz mieć kontener, to musisz
> wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
> nie da się rozwiązać, zachowując kompatybilność wsteczną.
Gdy wydajność nie jest ważna, to się bierze pierwszy z
brzegu i potem konwertuje, jeśli np. biblioteka gui nie
akceptuje std::vector. Gdy jest ważna, to szablon się
parametryzuje szablonem sparametryzowanym przez jeszcze trzy
inne szablony i sprawdza każdy wariant - i mamy typową
sieczkę optymalizacyjną, a nie kod podatny na refaktoryzację i
rozwój.


> Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać,
> bo wszystkie są raczej złożone i idiosynkratyczne.
hmmm


> 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.
Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję
do kompilowania kodu w językach wysokiego poziomu. Kompilator
musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić
poprawne wyjście dla wszystkich dozwolonych wejść.


> Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą
> C++ też tak zaczynał.
No tak.

> Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?
Dlatego że wierzę, że dla takiego języka i sposobu programowania
jaki taki język pociąga za sobą, można w praktyce jeszcze napisać
kompilator generujący bardzo efektywny kod. A programowanie byłoby
wygodniejsze niż w C++.


> Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
Ok.

> Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> do wersji korzystających z mutacji.
> Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> transformacji programów napisanych funkcyjnie w wydajniejsze
> programy stosujące mutację.
Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji,
spadła złożoność algorytmiczna? Jakby to działało, gdybyś od razu w
C++ lub Javie napisał?

Pozdrawiam

do góry

Użytkownik "Maciej Sobczak" <s...@g...com> napisał:

>> oraz to, dlaczego do wyrażenia tożsamości
>> użyto symbolu powszechnie używanego w informatyce w roli przypisania.

> Bo to jest przypisanie. Tak się właśnie definiuje funkcje.

NIE! (koljne skrzywienie "wartosciowym" C++ i przeinaczanie historii).

Oryginalnie (Algol, Pascal. Modula) = oznaczalo porownanie
a <- (jedna strzalka w lewo), := :- oznaczaly przypisanie.
W dodatku Simula rozrozniala dwa rodzaje przypisania:
:= - "wartosciowe" (kopiowanie wartosci)
:- - "referencyjne" (odwolanie do, metka)

Istnialy obok siebie i bylo super dopuki nie nastapil "wspanialy"
C++ i nie "ujednolicil" przypisania do = (wylewajac dziecko z kapiela
bo jednoczesnie uwalil przypisywanie referencyjne).
W dodaktu wprowadzil koszmarek & jako oznaczenie referencji (inicjowalne
jedynie, a nie przypisywalne).

A w Simuli bylo normalnie (zarowno deklaracja jak i uzycie):

integer a
ref(integer) ra
Klasa obj
ref(Klasa) robj

a := 3
ra := a
obj := Klasa(arg1, arg2, ...)
robj :- new Klasa(arg1, arg2, ...)

PS: No ale przyszedl C++ i "wyrownal"..

AK

do góry