Marek <f...@f...com> wrote:
> On Sun, 7 Dec 2025 20:15:38 +0100, heby <h...@p...onet.pl> wrote:
>
>> Jakich chcesz dowodow i na co?
>
> Dowodów w postaci zajebistego softu w ocenie końcowego użytkownika
> softu. Mnie nie interesują programiści, jacy są i czy język jest
> zajebisty bo umożliwia to czy tamto. Ja
> chcę zachwycić się nad softem, który spełnia moje oczekiwania, jest
> szybki (i mały objętościowo) i po prostu działa (najchętniej bez
> ciągłej schizofrenicznej aktualizacji).

Soft może być mały tylko wtedy jak rozwiązuje prosty problem.
Jak chcesz przykład relatywnie małej rzeczy z szablonami to
możesz popatrzeć na biblitekę NTL. Jest szybka w sensie że
zrobienie czegoś co działa z porównywalną szybkością to dużo
roboty (z której większość to nie jest programowanie, po prostu
trzeba zrozumieć potrzebne algorytmy). Jest bibliteka w C
z podobnymi funkcjami (flint) i szybkością. flint zamiast
szablonów używa makra preprocesora C. Tak że w przypadku
NTL nie działa argument "nie da się zrobić w innym języku".
Ale to są małe rzeczy. Jak wejdziesz na 10 mln linii kodu,
to nawet jakby się dało zrobić w innym języku to nikt
nie będzie ryzykował konwersji C++ na powiedzmy C. Konwersje
z C na C++ są dość powszechne. heby może pisać że to daje
marny C++, ale główna motywacja takich kowersji to dostępność
w C++ mechanizmów których nie ma w C, a po konwersji używa
się tych mechanizmów.

Jak rozumiem projekt Carbon chce być "lepszym C++", w
szczególności chcą żeby kowersja z C++ na Carbon była
w dużym stopniu automatyczna. Ale jak/jeśli Carbon
stanie się poważną alternatywą dla C++ to większość
twojej krytyki powinna się dalej stosować, tzn.
udany nowy język będzie się mocno zmieniał, będzie
używany do dużych i trudnych projektów (czyli duży
kod wynikowy i duży czas wykonania). Zgodność z
C++ będzie powodowała komplikacje i nieoptymalną
semantykę (tak jak zgodność z C psuje C++).

> Niestety jak na razie ja
> takowego nie widzę, a to co widzę to w ogromnej większości bloat
> I/lub crap. Dlatego pytam. A zauważyłem dość ciekawą często (jak nie
> zawsze) relacje, że jak syf to się okazuje napisany w C++.

Nie wiem na co typ patrzysz, ja widę sporo syfu, ale w różnych
językach. Powiedziałbym że PHP i JS przodują, Python z nimi
mocno konkuruje. C++ też, ale biorąc pod uwagę że soft w
C++ jest często używany, to propocja "złych" programów może
być dużo mniejsza.

> Wiec wybacz, ale na końcową ocenę użytkownika nie wypłynie
> zajebistość C++ z pkt. widzenia programisty.
> Punkt widzenia użytkownika to nie tylko ocena końcowego produktu
> (efektu).
> Przykład sprzed paru dni.
> Mam klaster kilkunastu maszyn, które od 25 lat coś tam liczą. Do tego
> liczenia nie potrzeba aktualizacji, zmian w sofcie. Liczy się tylko
> liczenie i dostępność i od lat nie wolno tego ruszać. Ostatnio
> chciałem coś przećwiczyć w llamie i wykorzystać klaster jedynie jako
> bazę uruchomieniową bimarek bo tam jest dużo ram. Oczywiście trzeba
> skompilować, ściągam patrzę w źródła "o ja pierdole C++ będzie cyrk".
> I był, całkiem podobny jak w pythonie. Zaczynając od problemów z
> kompilacją (nietypowe wymogi) a kończąc na problemach z uruchomieniem
> (invalid instruction).
> Tak wiem, tego typu problemy to nie wina C++ ale i tak niesmak
> pozostaje.

Jeśli masz ten sam soft co 25 lat temu to nie myśl o kompilowaniu
współczesnych źródeł sciąganych z sieci. Nawet w C są nowe
konstrukcje i nikt nie będzie ich unikał. Przy tym jakieś 20
lat temu to faktycznie był z C++ problem, tzn. pod rząd pojawiało
się kilka wersji g++, każda niezgodna binarnie z poprzednią.
Na poziomie źródłowym też były zmiany i mogło się okazać że
programu w praktyce nie da się użyć bez dużego cyrku w stylu
nowych bibiotek + specjalnych scieżek dostępu by je użyć.
Ale to (chyba) mineło.

Ja mam sporo sympati do używania starego softu. Ale musisz
się liczyć z tym że rynek na wieloletnią zgodność wstecz
jest mały, jak chesz to dostać to musisz płacić naprawdę
dużo a towar będzie powiedzmy "niezupełnie świeży", tzn.
mogą być problemy które są rozwiązane w nowszym sofcie.

--
Waldek Hebisch