W dniu czwartek, 3 stycznia 2019 17:24:12 UTC+1 użytkownik AK napisał:

> >> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od
> >> czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
> >
> > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
> > czy "C++ kreuje złe nawyki" jesteś Ty.
>
> No to bede drugi.
> C++ jest zly.
> Tak: jest zwyczajnie zly, bo nie tylko kreuje zle nawyki
> (a kreuje i to bardzo), ale tez dlatego, ze nawet w "doswiadczonych
> rekach" jest zwyczajnie nieprzewidywalny.

Ja się z Tobą zgadzam.
Ale stwierdzenie, że "C++ jest zły", jest nieprecyzyjne.
Zły do czego?
Moim zdaniem C++ jest np. doskonały jako przykład tego,
w jaki sposób nie należy projektować języków programowania.
Również w kwestii kreowania nawyków, owo stwierdzenie jest
skrótem myślowym.
Wiele materiałów dydaktycznych napisanych wokół C++ bardzo
moim zdaniem pomaga w kreowaniu złych nawyków.
Ale wyobrażam sobie, że być może można by było stworzyć
materiały dydaktyczne, które korzystałyby z C++ (czy jakiegoś
podzbioru C++), a które nie propagowałyby tych złych nawyków.

Nie znam takich materiałów, ale to nie znaczy, że takie
nie mogą istnieć. (Może "Effective C++" jest czymś takim?
Nie wiem, nie czytałem. Na pewno materiały Stroustrupa,
z którymi miałem styczność, nie były dobre)

> Nie pomoga tu zadne MISRY, ani chor Ayatolahow.
> Po prostu taka jest rzeczywistosc, bo... (jak wszystko) istnieja
> jezyki prog. _obiektywnie_ lepsze i gorsze.
> Do tych zlych naleza na pewno: C++, Perl, Tcl, stary Fortran (IV
> a nawet 77), takze stary Cobol itd itd.

Jeżeli idzie o Perla, to w niektórych zastosowaniach jest
wygodnym narzędziem, ale istotnie nie jest dobrym językiem
do pisania dużych programów.

> PS: Na poczatku dyskusji wymieniles IMHO najwazniejsze kryterium
> "zlosci" C++. Po tym dalsza dyskusje mozna by spokojnie zamknac :)
> Aatollahow i tak NIC nie przekona.
> Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie
> (w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a
> mnie ze... mam za duze :) i skostnialem/nie umiem calosci C++...
> i nie przekona ich to ze wlasnie pisze/rozwijam parser C++14, aby moc...
> automatem przekonwertowywac programy z chorego dzis C++ na cos
> innego/lepszego (glownie C#).

Kolega, z którym pracowałem przez ostatni rok, rozwijał kiedyś język
programowania Ć, dający się transformować do różnych innych platform
(C, C#, Java, Perl, JavaScript, ActionScript i D):
http://cito.sourceforge.net/

> Zeby nie bylo: doceniam zmiany wprowadzone przez C++11/14/17
> tyl ze ja myslalem ze nastapia po ~5 latach, a nastapily po ponad
> 30stu.W dodatku wymuszone przez dawno istniejace/okrzeple "ficzery"
> w innych jezykach (dalej jednak nie wprowadzono do standardu properties,
> ani finally - i nie pomoze tu zadne RAI bo.. nawet standardowe std
> tegoz RA nie wspiera/wymusza.
>
> PS0: Nie twierdze ze Lisp-owatosc jest super. O nie! Wada tego jezyka
> jest po pierwsze nieczytelna/trudna do ogarniecia skladnia.

Myślę, że Lisp jest tak samo nieczytelny dla osób nieprogramujących
w Lispie, jak chiński dla osób nieposługujących się chińskim.
Pewnie przed typografią programów komputerowych jest jeszcze długa droga,
i pewnie dużo dałoby się zrobić, żeby Lisp był czytelniejszy.

Ale składnia Lispa jest bardzo łatwa do opanowania. Piszesz:

(operator argumenty ...)

i to wszystko.

> Druga wada (ktora Ty uwazasz za zalete) jest dogmat funcyjnosci i
> "bezstanowosci".

To nie jest dogmat. To jest podejście promowania promowane
może w Schemie i Clojure. Programiści Common Lispa raczej go nie uznają.

> Swiat jednak jest obiektowy a obiety stany posiadaja
> (nie zawsze sa wyliczane/wyliczalne). Oczywiscie rozumiem znaczenie
> czystej funcyjnosci Lispa - przeciez to jego glowna/immanentna cecha -,
> ale w obszarze/niszy jaka jest inzynieria programowania.
> W normalnym swiecie rzemieslniczego programowania jest to jednak
> za malo. Czlek mysli/swiat jest zbudowany bardziej obiektowo/stanowo,
> a nie funcyjnie zawsze bedzie "ciagnal" do czegos co to myslenie dobrze
> odzwiercedla, niz "przestawi sie" na myslenie o wszytskim jako wyniku
> chain-a funkcji.

Nie zgadzam się. Człowiek jest przyzwyczajony do tego, że myślenie
nie ma w świecie żadnych skutków ubocznych (poza upływającym czasem).
Jest przyzwyczajony do rozróżniania myślenia i działania. Przynajmniej
od czasów Kartezjusza jest przyzwyczajony do rozróżniania myślenia
i działania.

Zgadzam się, że programowanie funkcyjne nie jest uniwersalne w tym
sensie, że nie wszystko da się w nim zrobić. Ale warto go używać
wszędzie tam, gdzie się nadaje (czyli np. w data science, narzędziach
do przetwarzania języków programowania czy algorytmach kombinatorycznych,
ale już nie w programowaniu systemowym czy do tworzenia interfejsów
graficznych), bo to pozwala uniknąć wielu niepotrzebnych pułapek.

Przykład, który lubię dawać na różnych prezentacjach, to program
liczący sumę kwadratów początkowych siedmiu liczb pierwszych.

Imperatywnie zapisalibyśmy go tak:

1: licznik := 7
2: liczba := 0
3: suma := 0
4: dopóki (licznik > 0):
5: jeżeli jest_pierwsza(liczba):
6: suma := suma + liczba^2
7: licznik := licznik - 1
8: liczba := liczba + 1

i jeszcze musieli dopowiedzieć, że po wykonaniu programu
wynik znajdziemy w zmiennej "suma".

Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
znaczeniowe w nawiasy:

(suma (kwadraty (początkowe 7 liczby-pierwsze)))

Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
czym są (kwadraty elementów), co to jest (początkowe N elementy)
i czym są liczby-pierwsze.

To jest kod, który bardzo łatwo się komponuje, i który
bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
gdzie należy szukać wyniku)

wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie

(suma (kwadraty (początkowe 7 liczby-pierwsze)))

jest równoważne wyrażeniu

(suma (kwadraty '(2 3 5 7 11 13)))

które jest równoważne wyrażeniu

(suma '(4 9 25 49 121 169))

i tak dalej.

Zgodzę się, że przy projektowaniu systemów czasu rzeczywistego
jest dużo kodu, którego nie da się "wepchnąć" w ten schemat.

Ale nawet wtedy można zrobić dużo, żeby pozostać
blisko tego modelu (warto przyjrzeć się np. modelowi
aktorów z Erlanga/Elixira)

> CZyli: doceniam elegancje Lispa, ale niestety nie
> nie moge docenic praktycznosci Lispa w zwyklym zyciu programistycznym.
> Czlek nie mysli odwrotną notacją polską

Odwrotna notacja polska jest w języku Forth.
Tutaj masz "w pełni onawiasowaną notację polską"
(czasem nazywaną Cambridge-Polish)

I jest moim zdaniem wartościowym narzędziem do myślenia.
(ja dla zarobku też programuję głównie w C, ale od Lispa
nauczyłem się bardzo dużo)