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