On 07/12/2025 22:00, Marek wrote:
>> To ekspert. Jak by nie był ekspertem, to by o to zapytał kogoś. A że
>> nie zapytał, tylko od razu odpalił nagrywanie, to niewątpliiwe
>> ekspert, który już wiedzy nie potrzebuje, za to zapałał potrzebą
>> dzielenia się swoimi przemyśleniami mając całośc wiedzy.
> Zamiast ironizować mógłbyś zrobić film "w odpowiedzi na". Byłoby ciekawiej.

Ale ja się na C++ nie znam. Jestem w minimum lokalnym krzywej
Dunninga-Krugera.

>> Tak, autor myśli że porównanie JS do C++ to dobry pomysł.
> Częste ironizowanie prowadzi do nabytej ignorancji lub braku rzetelnej
> oceny faktów. Autor filmu nie zawsze i nie wszędzie każdy problem
> kończył porównaniem do JS

Nigdzie nie napisałem, że każdy problem porównał do JS. Porównał jakieś
problemy. Ze szczególnym uwzględnieniem tych najbardziej absurdalnych,
albo z głupoty, albo z clickbaitu.

Choć jeden z nich to dyskwalifikacja całości bredzenia.

> a porównania jak już były dotyczyły wąskiego
> kontekstu danego zagadnienia. Nie jestem apologetą JS ale przywołując
> jedno porównanie z pamięci: jeśli w JS robi się coś w jedną prostą
> jednoznaczną instrukcją gdy to samo w C++ osiąga się skomplikowanum
> niejednoznacznym ciągiem wielu instrukcji podatnych i tak na złe użycie
> to w kontekście tego konkretnego rozwiązania co jest lepsze JS czy C++?
> Tylko tak bez filozofowania.

Koszt "łatwo w JS" zapłacisz w cyklach zegara.

Tam, gdzie template find_if z C++ zredukuje się do prostej pętli w
asemblerze mającej kika cykli, w JS może się skończyć setkami instrukcji
interpretowanych dynamicznie, bo JS nie wie z jakim typem ma do
czynienia i musi to rozkminiać za każdym razem.

Więc jesli chcesz pokazać, ze JS jest łatwiejszy, to jak znalazł.

Ale jesli nie zajmujesz się dicking-around, tylko zależy Ci na
prędkości, rozwiązanie z template generuje lepszy kod do tego jednego
rozwiązania, niż uniwersalny z JS.

Argument, że JS jest lepszy, bo jest łatwiejszy nie ma sensu: ktoś już
wybrał C++ w danym zastosowaniu, bo jest szybszy i zazwyczaj obecnośc
C++ oznacza, że był to właśnie główny powód pisania w C/C++. Nie zawsze,
ale bardzo często. Więc można się tylko popukać w głowę, że co mi po
ładniejszym zapisie, jak potrzebujemy maksymalnej, wręcz optymalnej,
prędkości.

To jak porównanie BMW do traktora. Jednym i drugim zaorasz pole, ale
traktorem wydajniej, choć BMW minimalnie ładniejsze.

>> Dziwne że nie widzisz, skoro bardzo duże i bardzo drogie aplikacje,
>> przy których kod windowsa czy linuxa jest śladowy, napisano w C++. I
>> nie było wyjścia, ze względu na potrzebę ekstrakcji każdego cyklu cpu.
> Nie pytam o wielkość ani o cenę ale o user experience. Jak coś jest już
> wielkie to najczęściej ma słaby user experience.

User experience w mojej branży to np. to, czy symulacja zakończy się po
4 tygodniach, czy po 3.5 tygodnia.

Nie wiem jaki user-experience masz na mysli, ale ja pracuje w branży,
gdzie jest prawdopodobnie biegunowo odległy od Twojego.

Zdefniuj user experience.

>> Jeśli potrzebujesz konkretnego przykładu, to modelsi.Nie da się go
>> napisać
> "Nie da się go napisać" to nie odpowiedź na ocenę czy jest zajebiste wg
> user experience.

Nie jest. Specjalnie go wybrałem. To jeden z najtoporniejszych programów
jakie kiedykolwiek będziesz używał. Nie da się z nim nic porównać, to
nie jest experience, to trauma rozrywająca aż do kości.

I ludzie korzystają.

Bo to, czy to się wygodnie czy nie wygodnie używa, nie ma praktycznego
znaczenia. Ważne, czy przesymulujesz coś w tydzień czy dwa. Jak by go
napisali w JS to byś przesymulował w rok. Może.

Taka nisza.

User experience mierzony jest czasem pracy symulatora.

Taki user-experience masz na myśli? Czy znowu jakieś nieporozumienie?

> Manipulujesz pisząc prawdę i półprawdy.
> Tak wideo jest o C++ i nie porównuje wszystkiego do JS. Jest też dużo o
> całym ekosystemie wokół, bibliotekach, ABI, problemów z .h i

Wszystkie te "problemy" wymagają głębszego omówienia, bo niektóre z nich
dziwnym trafem brzmią przy bliższym poznaniu jak ficzery i zalety. Tylko
trzeba wiedzieć jak z nich korzystać.

Przejdź na pl.c.l.c i zrób wątek o każdym. Bedzie lepszy fokus.

> zaśmiecaniem  podpowiedzi w IDE (zawsze mnie mierziło, że programista
> potrzebuje jakieś podpowiedzi nazw, to on jest programistą i powinien
> wiedzieć co chce napisać) i dużo innych ciekawych rzeczy, może byś się
> odniósł do reszty?

Ale do czego konkretnie?

IDE jest absolutnie niezbędne. Jesli masz milion lini kodu, szczególnie
OOP, to nie jesteś w stanie spamietać wszystkich nazw metod, zwracanych
typów, namespaces. To jest ficzynie niemożliwe, ponadto nie piszesz sam.
Copilot też nie ogarnia, zmyśla metody, bo sam nie wie. Cursor to samo.
Dlatego powstały techniki jak intelisense i cośtam z clanga. To
absultnie niezbędne aby w sytuacji gdy masz projekt składający się z
gigabajta plików źródłowych mieć narzedzie pozwalające na podpowiadanie
nazw. Działą średnio, ale z doświadczenia powiem, że jakośc działania
InteliSense jest proporcjlnana do jakosci architektury kodu. W kodzie
spieprzonym nie działa. A potem często słyszę kwiczenie, jake to IDE bez
sensu.

> Istotne są wnioski z dyskusji a nie jej powód.
Pod warunkiem, że ustalimy już o czym jest dyskusja.

To najłatwiej zrobić otwierając nowy post na grupie i dla zmyłki dać
taką treść, jaką chcemy aby dyskusja przypominała.