-
Data: 2017-08-24 17:32:33
Temat: Re: Co jest nie tak z C++ (było: Rust)
Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 24.08.17 18:10 fir
- 24.08.17 20:11 Mateusz Bogusz
- 24.08.17 21:24 fir
- 24.08.17 21:32 g...@g...com
- 24.08.17 23:48 Adam M
- 25.08.17 00:23 g...@g...com
- 25.08.17 01:12 M.M.
- 25.08.17 06:04 AK
- 25.08.17 06:05 AK
- 25.08.17 06:06 AK
- 25.08.17 06:07 AK
- 25.08.17 06:08 AK
- 25.08.17 06:14 AK
- 25.08.17 06:29 AK
- 25.08.17 06:37 AK
Najnowsze wątki z tej grupy
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-01-08 Warszawa => Spedytor Międzynarodowy <=
- 2025-01-08 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-01-08 Gdańsk => Specjalista ds. Sprzedaży <=
- 2025-01-08 Katowice => Key Account Manager (ERP) <=
- 2025-01-08 Warszawa => Programista Full Stack .Net <=
- 2025-01-08 Podłączenie DMA 8257 do 8085
- 2025-01-08 Warszawa => System Architect (background deweloperski w Java) <=
- 2025-01-08 Warszawa => Solution Architect (Java background) <=
- 2025-01-08 Wrocław => Application Security Engineer <=
- 2025-01-08 Warszawa => International Freight Forwarder <=
- 2025-01-08 Mińsk Mazowiecki => Area Sales Manager OZE <=
- 2025-01-08 Lublin => Inżynier Serwisu Sprzętu Medycznego <=
- 2025-01-08 Bieruń => Spedytor Międzynarodowy (handel ładunkami/prowadzenie flo
- 2025-01-08 Gliwice => Business Development Manager - Network and Network Security
- 2025-01-08 Warszawa => Spedytor Międzynarodowy <=