W dniu sobota, 14 grudnia 2019 20:02:41 UTC+1 użytkownik Maciej Sobczak napisał:
> > > W sensie - jaka jest wartość dodana tego języka Ć?
> >
> > Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.
>
> Sam chwilę temu pisałem, że moduł napisany w C++ mogę załadować do Javy i .NETa.
> Więc jeśli celem jest napisanie takiego modułu, to wiem, jak to zrobić bez
konieczności sięgania po nowe (niedopracowane?) narzędzia.
> Więc pytam, jaka jest wartość dodana, skoro bez tego narzedzia nie mam problemu z
osiąganiem swoich celów.

Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się
musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą
interesującą Cię platformę. Czyli najważniejszą cechę Javy - przenośność pomiędzy
platformami - wyrzucasz do kosza.
Dodatkowo wołanie kodu natywnego jest na JVM kosztowne, i stosując je, tracisz JVMowe
optymalizacje.
Więc chociażby taka.

> > > To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
> >
> > Tylko skąd będę wiedział, który podzbiór jest tym właściwym?
>
> Zapytasz na grupie dyskusyjnej? Podpatrzysz implementację innego produktu z tej
samej lub zbliżonej dziedziny?
> A może przy takich poszukiwaniach niechcący nauczysz się całego języka i wtedy sam
będziesz mógł taki podzbiór wybrać?

Się uśmiałem.
C++ jest językiem, którego nie ogarniają sami jego twórcy, więc nie sądzę, żeby
osobie łażącej po grupach dyskusyjnych było dane nauczyć się "całego" języka.

> > Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez
Google?
>
> A co w ogóle jest miarą sukcesu języka programowania? Bo skoro twierdzisz, że
Python osiągnął ten sukces po inwestycji ze strony Googla, to chyba masz jakiś pogląd
na to, czym ten sukces jest?

Tak. W przypadku języków programowania sukcesem jest popularność.
I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python
zaczął się na nim pojawiać w okolicach 2000-2001 roku.
Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten tekst:
https://norvig.com/python-lisp.html

> > Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre
narzędzia.
>
> Super! Dobre narzędzia to kolejny powód, żeby się tym językiem zainteresować.
> Po co tracić czas na języki, do których nie ma dobrych narzedzi?

Zdecydowanie nie warto.
Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.

> > W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż
utrzymanie produktu.
>
> Nie dostrzegam tego clou. Nie widzę sensu rozwijania produktu w jakimś języku,
który nie będzie się nadawał do dalszego utrzymania tego produktu - chociażby
dlatego, że skazałbym się na koszt przepisywania tego produktu.

Paul Graham swego czasu pisał dużo na temat wyboru Common Lispu do swojego start-upu.
Jego zdaniem to właśnie użycie tego języka dawało im przewagę nad konkurencją, bo
mogli bardzo szybko dodawać do swojego produktu nowe ficzery, tym samym prześcigając
konkurencję. Innymi słowy, zdaniem Grahama, jeśli by wybrali inny język, to produkt
albo nigdy by nie powstał, albo by przegrał.
I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego produkt.
I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś na
przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się
spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z
przyjemnością. (I z dotychczasowych wypowiedzi wynika, że Osobliwy Nick nie był
szczególnie zadowolony z C++, więc pewnie w jego przypadku warto rozejrzeć się za
jakimiś alternatywami)

Natomiast w tej historii to nie Graham i nie Persson poniósł koszty przepisywania,
tylko - odpowiednio - Yahoo i Microsoft. Z tego co wiem, autorzy kodu byli raczej
zadowoleni z transakcji, a przepisanie go na C++ było czymś, co miało sens z
perspektywy nabywców (a dlaczego tak było? Bo może mieli u siebie zatrudnionych wielu
doświadczonych programistów C++, w związku z czym przepisanie kodu na ten język miało
dla nich sens)

Dlatego jeśli miałbym wybierać pomiędzy tym, czy projekt ma być zrealizowany, a tym,
czy do realizacji projektu mam użyć C++, i nigdy go nie ukończyć, to raczej bym się
nie zastanawiał.

> Praktyka pokazuje, że rozwiązania tymczasowe mają zdumiewającą zdolność
przetrwania, więc najlepiej ich z góry uniknąć i od razu zrobić dobrze (o ile w ogóle
mamy długofalową wizję co to ma oznaczać - ale jeżeli plan jest komercyjny, to jakaś
wizja najwyraźniej jest).

Jasne, że lepiej robić dobrze, niż źle, ale problem jest taki, że o tym, co w danym
przypadku znaczy "dobrze", a co "źle", dowiadujemy się dopiero po fakcie.