W dniu piątek, 13 grudnia 2019 21:06:19 UTC+1 użytkownik Maciej Sobczak napisał:

>
> > Programy nim napisane można tłumaczyć do C, C++, C#, Javy, JavaScriptu, i zdaje
się że nawet D i Perla.
>
> Obrazki w UMLu też można tłumaczyć. Nic z tego nie wynika od 30 lat.
>
> Ale tak konkretnie - jaką wadę języka C++ można ominąć pisząc program w języku Ć i
tłumacząc go potem do C++ i jednocześnie nie rezygnując z zalet, z których można by
było skorzystać od razu pisząc w C++?
>
> 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.

> > Można użyć.
>
> Pytanie, jaki jest cel tego ćwiczenia. Bo jeśli komercjalizacja jakiegoś pomysłu,
to nie chodzi o to, że "można użyć", tylko czego użyć, żeby jak najlepiej osiągnąć
zamierzony efekt. Hasło "można użyć" jest zupełnie z innej płaszczyzny. Dokładnie na
tej samej zasadzie niektórzy zbierają klej do znaczków. Można zbierać.

To życzę udanych zbiorów.

> > Być może. Nie zmienia to jednak faktu, że C++ jest językiem bardzo złożonym
>
> To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
>
> Teza: dla każdego problemu/zadania istnieje sensownie niezłożony podzbiór języka
C++, w którym można ten problem/zadanie rozwiązać/zrealizować.

To bardzo fajnie.
Tylko skąd będę wiedział, który podzbiór jest tym właściwym?

> Język polski też jest jednym z bardziej złożonych, ale żeby się skutecznie pokłócić
na usenecie, wystarczy jego mały podzbiór.

Żeby się porozumieć, trzeba mieć wolę porozumienia.

> > Źródło sukcesu TensorFlow jest takie samo, jak źródło sukcesu Pythona, mianowicie
to, że oba projekty zostały mocno doinwestowane przez firmę Google.
>
> Błąd. Firma Google zainteresowała się Pythonem dopiero po tym, jak Python osiągnął
sukces.

Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez Google?

> Możliwe, że z punktu widzenia managementu trochę niewygodny był fakt, że każda inna
duża firma miała jakiś "swój" język. Zatrudnienie Guido mogło się wydawać
"rozwiązaniem" tego marketingowego problemu. Tak czy inaczej - najpierw był sukces,
potem adopcja.
>
> > Podobnie C++ został mocno doinwestowany przez korporacje.
>
> I tu się wyłożyłeś używając słowa "korporacje" zaraz po tym, jak w innym kontekście
podałeś konkretne nazwy. Słowo "korporacje" oznacza tyle samo, co "oni", albo
"wszyscy".

Nie. Oznacza instytucje, które dysponują zasobami. Jeżeli pytasz o jakie korporacje
chodzi, to przede wszystkim Microsoft z Visual C++, oraz Intel, któty raz że ma
produkt w postaci ICC, a dwa że kontrybuuje do GCC, bo mu to zwiększa sprzedaż
procesorów.

> Czyli sukces C++ wynikał z tego, że wszyscy go używali? Oczywiście.


Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre
narzędzia.

> Dlatego też zachodzi podejrzenie, że do zadania z tego wątku też będzie to dobry
wybór.

Może będzie. Trzymam kciuki.

> > Ja znam jeszcze dwie inne historie: Viaweb Paula Grahama i Minecraft Markusa
Perssona. Obie zostały napisane w różnych językach (odpowiednio: Common Lispie i
Javie), a następnie wykupione za duże pieniądze przez wielkie korporacje
(odpowiednio: Yahoo i Microsoft) i przepisane na C++.
>
> Ciekawe. Ale to fajne przykłady.
>
> > Ta droga jest ważna, bo pokazuje, że C++ jest raczej językiem do
'zacementowywania' istniejących projektów, niż do dostarczania innowacji.
>
> Mam inną tezę. Wykupienie tych produktów wiązało się z założeniem, że będą
dostarczone na masowy rynek (w przypadku projektów sieciowych oznacza to masowe
obciążenia) a najwyraźniej na komercyjnym rynku C++ jest właściwym narzędziem, żeby
sprostać komercyjnym wymaganiom. "Zacementowanie" jest celem, któro nie dość, że
niczego nie oznacza, to jeszcze trudno taki cel uzasadnić koniecznymi kosztami.
Natomiast poniesienie kosztów, żeby dostarczyć użytkownikom niezawodny produkt, jest
jak najbardziej racjonalne. I to również jest powód, żeby się tym językiem
zainteresować.

Sądzę, że raczej bierze się to stąd, że łatwiej znaleźć developerów C++ niż Common
Lispa (w pierwszym przypadku) i łatwiej uzyskać dobrą wydajność w C++ niż w Javie (w
drugim przypadku).
W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż
utrzymanie produktu.

> Oczywiście można też wysunąć argumentację, że "oni" (korporacje?) robią źle, bo są
źli, więc skoro robią coś w C++, to na pewno C++ też jest zły.

Zupełnie nie rozumiem tego co napisałeś (ani po co).