W dniu niedziela, 13 sierpnia 2017 05:17:23 UTC+2 użytkownik M.M. napisał:
> On Saturday, August 12, 2017 at 11:07:20 PM UTC+2, g...@g...com wrote:
> > W dniu sobota, 12 sierpnia 2017 15:59:27 UTC+2 użytkownik s...@g...com
napisał:
>
> > I z pewnością, żeby odpowiedzieć na to pytanie, najpierw
> > należałoby ustalić nasze oczekiwania względem danego języka,
> > żeby można było zastosować jakieś kryteria, a nie prowadzić
> > dyskusji na poziomie "język X jest zły, bo nie ma ficzera Z",
> > albo "język X jest zły, bo nie jest językiem Y".
> Kryterium porównawcze to dobra rzecz.

Mógłbyś doprecyzować, co masz na myśli, używając frazy
"kryterium porównawcze"? (ja ją rozumiem w taki sposób,
że to jest "kryterium, względem którego porównujemy",
ale to ma sens dopiero wtedy, kiedy porównujemy, a nie
kiedy próbujemy ustalić, jakie coś ma wady)

> > Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście
> > środków do tego, żeby mógł go używać stosownie do swoich
> > upodobań -- oczywiście w niektórych kontekstach można by to
> > było uznać za zaletę, jednak "w ogólności" wydaje się to raczej
> > wadą.
> Tutaj pozwolę sobie trochę się nie zgodzić. W C++ generalnie
> jest dużo środków i można w nich przebierać. No chyba chodzi o
> biblioteki, w przypadku bibliotek trzeba brać albo taką jaka
> jest, albo se napisać swoją.

Nie chodzi o biblioteki. Chodzi o to, że jako programista
nie możesz sobie napisać pętli for(iterator : kolekcja),
tylko musisz poczekać, aż przyjdzie Komitet i Ci to zrobi.

Tzn. ostatnio odkryłem, że jakieś 10 lat temu się bawiłem w takie
rzeczy, i sobie sam zrobiłem (dla gcc)

#define for_every(ITERATOR, COLLECTION) \
for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
ITERATOR != COLLECTION.end(); ++ITERATOR)

ale niewykluczone, że od takich rzeczy głupieją narzędzia w rodzaju IDE.

> Właśnie kolekcje do uporządkowanych
> zbiorów mi nie odpowiadają ani w QT, ani w STD, więc napisałem
> swoją. Ale to jest wada każdego języka. Chociaż taka Java od
> razu była nastawiona na prostotę i standaryzację ogromnej
> biblioteki...

Dla mnie wygląda tak, jakby C++ był ofiarą swojego procesu
standaryzacyjnego, który jest kumulatywny -- ficzery do języka
są tylko dodawane, i kompatybilność wsteczna jest świętością.
(Z Javą zresztą jest podobnie).
Proces standaryzacyjny np. w Haskellu nie miał problemów z tym,
żeby eksperymentować i zrywać z różnymi decyzjami projektowymi,
które były uważane za błędne. Użytkownicy może trochę na tym
ucierpieli, co z pewnością odbiło się na popularności tego systemu,
ale wpływ na sam projekt języka miało dobry.

> > Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++
> > były domyślnie zadeklarowane jako "const", i tylko te, które
> > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"),
> > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego
> > zachowania.
> Ale takiego efektu w żadnym języku nie można uzyskać, o ile
> zrozumiałem co masz na myśli. Jeśli zostanie przewidziane
> przed pisaniem kodu, to można sprytne define zrobić, jeśli nie,
> to w żadnym języku tak się nie da.

W Scali masz zasadniczo coś podobnego -- deklarujesz, czy określona
zmienna jest "var", czy "val", tzn. czy jest mutowalna czy niemutowalna.
W Scheme mógłbym bez problemu przesłonić operator przypisania, żeby
sprawdzał, czy dana zmienna posiada deklarację pozwalającą na jej zmianę.

> > Podobnie, interfejsy dostarczane przez STL są bardzo dziwne.
> > Jest sobie chociażby taki kontener "stack". Jak można się spodziewać,
> > stack<T> ma funkcję push(T element), która kładzie element na stosie,
> > oraz pop(), która zdejmuje element ze stosu.
> Idzie z tym żyć. Ja na tę sprawę mam inny pogląd. W innych językach,
> jest mniej możliwości. Naturalne dla innych języków jest to, że
> biblioteka zazwyczaj jest taka jaka powinna być w danym języku. A w
> C++ jest bardzo dużo środków wyrazu. Zazwyczaj z biblioteką taką jak
> STL czy QT można żyć. Problem w tym, że czasami chce potrzeba
> biblioteki "skrojonej na miarę" do danego programu. Przy czym
> skrojona na miarę oznacza albo wygodę programowania, albo
> bezpieczeństwo, albo przejrzysty kod, albo ekstremalną wydajność.
> W innych językach nie tylu środków wyrazu, więc inne języki
> nie dają okazji do dzielenia włosa na czworo. W Javie nigdy w
> życiu nawet bym nie pomyślał o pisaniu swojego kontenera, bo
> po co? W C++ zazwyczaj używam swoich drzew, tablic hashujących, itd,
> ponieważ (w moim przypadku najczęściej) to skraca czas obliczeń.


> > Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu.
> > Uzasadnienie autorów biblioteki jest takie, że w ten sposób można
> > uzyskać większą wydajność, i że STL jest projektowany w taki sposób,
> > żeby "nie płacić za to, czego się nie używa" -- jednak brak
> > ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy
> > programiści przyzwyczają się, że zepsute interfejsy to norma.
> Zazwyczaj jest bardzo wysoka cena za bardzo małe zwiększenie wydajności.
> Stos ma metodę top która zwraca. Można wywołać top a potem pop. I
> pewnie w konkretnym przypadku będzie efekt przeciwny do zamierzonego,
> pewnie wydajność będzie gorsza dla dwóch wywołań niż dla jednego z
> odpowiednim typem zwracanym. A jakby dziedziczyć po stosie i sobie
> napisać taką metodę pop? W QT chyba nazywa się taka metoda take.

możliwości są różne. projektanci C++ mogliby zrobić "dispatch on return
value" (Haskell ma coś takiego), i wówczas stack mógłby dostarczać dwóch
implementacji "pop" -- jednej z typem void, a drugi z typem T.

> > Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest
> > ten gość, Scott Meyers, który najpierw pisał dużo książek o C++,
> > a później zaczął jeździć po konferencjach, narzekając na dziwność
> > interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy
> > w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno
> > było ich używać niepoprawnie), i teraz zdaje się zajmuje się
> > rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć
> > np. tutaj
> Nie, mam dosyć swojego narzekania ;-)
>
> > Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne
> > również są pewną ceną, którą programiści C++ muszą płacić.
> Kompilacje można zrównoleglać w make. Komunikaty diagnostyczne...
> nie wiem.. zazwyczaj wiem co kompilator do mnie mówi, czasami
> tylko muszę chwilę się zastanowić.

to musisz spróbować boosta ;]

> > W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony,
> > to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie
> > duży stopień komplikacji tego języka (np. skomplikowana
> > składnia i różne założenia utrudniające formułowanie wniosków
> > dotyczących programów napisanych w C++) są na tyle poważnym problemem,
> > że jeśli nie muszę, raczej staram się z niego nie korzystać.
> Dla mnie to co nazywasz komplikacją, jest bogactwem możliwości.
> Ale jeśli nie muszę, to też wolę np. Jave, PHP.

Raczej miałem na myśli n. to, o czym wspominał Meyers w prezentacji.
Że poziom skomplikowania C++ doprowadził do tego, że dające się
używać narzędzia do refaktoryzacji kodu dla C++ pojawiły się
w środowiskach IDE o dekadę później, niż dla innych języków.

Co do owego "bogactwa możliwości" to C++ w istocie daje dużą kontrolę
nad tym, co będzie robił komputer w trakcie wykonywania programu.
Osobiście nie sądzę, żeby taka kontrola była potrzebna. Raczej
wolałbym mieć narzędzie, które samo dobierze optymalne struktury
danych do mojego programu, żebym mógł korzystać tylko z jednego
prostego interfejsu do kolekcji (interfejsy w STLu wołają o pomstę
do nieba). Sądzę, że takie podejście na dłuższą metę miałoby lepszy
wpływ na wydajność programów, niż to, co oferuje C++.