Czy C++ desktop upadnie?

Witam wszystkich,

Od początku kariery programuję wyłącznie w C++. Kiedy szef poprosił o przepisanie jednego z małych projektów, które zamknąłem wcześniej na C#, postanowiłem spróbować. Nie mogłem się nadziwić jak szybko i bezproblemowo to poszło.

W C++ samo pisanie kodu to połowa roboty. Jazda zaczyna się przy dołączaniu jakichś bibliotek. Cały dzień siedzenia w necie i szukania rozwiązania które będzie dobre dla twojego systemu i kompilatora. Kiedy już znajdziesz odpowiednie rozwiązanie musisz kompilować libki lokalnie. Kilkaset błędów kompilacji za względu na źle ustawione flagi, później kilkaset błędów linkera bo ta biblioteka używa .def, a nie jak w twoim projekcie _dllipmort(). Kiedy już przebrniesz przez cały ten syf i napiszesz swoje 5 linijek kodu okazuje się, że na innym komputerze to nie działa.

w C# + .Net wpisujesz jedno "using" i wszystko działa na wszystkim. Przynajmniej takie moje odczucia, może jakby projekt był większy to więcej problemów bym napotkał, ale korzystałem tam z wielu modułów i zawsze odpalało od pierwszego kopa.

Projektów w których szczególnie zależy klientowi na wydajności jest już mało i wraz z rozwojem sprzętu będzie coraz mniej. Czy programowanie w C++ dla PC, nie traci sensu? Czy może to czas żeby przytomnie przerzucić się na inny język? Czy ktoś z was już podjął podobną decyzję?

Może i upadnie, ale nigdy nie miałem takich doświadczeń z pisaniem w Qt. Wszystko jest bardzo bezproblemowe.

I cały czas tworzę nowe aplikacje w Qt (z widgetami) - idzie to szybko i jestem zadowolony z efektów.

Desktop w C++ (czy dowolnym języku) nie potrzebuje skrajnych szybkości, i tak nie ma sensu szybciej niż ludzka percepcja.
Algorytmika oczywiście inaczej.

Nawiasem mówiąc kod w GUI jest w bardzo dużym stopniu (jakby) interpretowany, ogromna ilość wszelkiego typu wskaźników funkcyjnych / metod wirtualnych, interpretacja stringów, tablic mapujących we frameworkach itd...

Desktop pisany natywnie na pewno nie upadnie, przyrost wydajności sprzętu wyraźnie wyhamowuje i jeśli nie wymyślimy czegoś lepszego od krzemu to z czasem wszyscy programiści będą musieli zacząć oglądać się na wydajność.

Pytanie, czy wtedy C++ będzie najlepszym wyborem? Ciężo powiedzieć.

bilborrd napisał(a):

W C++ samo pisanie kodu to połowa roboty. Jazda zaczyna się przy dołączaniu jakichś bibliotek.

Myśle że następcą będzie Rust. Podobno manager pakietów Cargo działa tam bardzo dobrze

Wszyscy mają już powoli dość C/C++, ale historia uczy nas, że żadna nowa technologia nie wypchnie starej z jej istniejącej niszy.

Wysoko-wydajne aplikacje na desktopy pisze się w C++ i koniec. Nie zmieni się to, nawet jak powstanie lepsza technologia.

Co innego, jeżeli same desktopy zostaną wyparte przez jakiś nowy paradygmat używania komputerów. To będzie okazja do wymiany technologii.

Jest implementacja microPython, na mikrokontrolery. Można w Pythonie nawet pisać handlery przerwań. Python zajmuje miejsce języka wybitnie niskopoziomowego, jakim był C. Ale wiąże się to z ekspansją RaspberryPi i innych podobnych rzeczy. Python nie wyparł C z istniejących mikrokontrolerów, ale wszedł na nową rozwijającą się działkę. I skoro już się tam zagnieździł, to raczej nic go nie wyprze, nawet jak ktoś wymyśli coś lepszego.

Kolejny wątek na podstawie doświadczenia paru osób. Weźcie pod uwagę to, że C++ używają nie tylko producenci przeglądarek, komunikatorów itp. Mogą być firmy, które używają różnych narzędzi na wewnętrzne potrzeby i się tym nie chwalą - tego nie możemy zweryfikować. Zwróciłem na to uwagę kiedy spotkałem się z taką sytuacją: okienkowa apka w C++ do przetwarzania tekstu robiła całkiem sporo.
Decyzja o każdym projekcie jest indywidualna. Mają na to wpływ różne czynniki, np. czas życia projektu, czas wdrożenia, wydajność, licencja bibliotek i narzędzi. Jeśli programista mówi, że to bez sensu, niech wytłumaczy czemu tak myśli. Nie pamiętam kiedy ostatnio słyszałem, żeby szeregowy programista przekonał biznes, że coś jest bez sensu.

Myśle że następcą będzie Rust.

Nie prędko. borrow checker jest jeszcze za głupi i za wolny (EDIT: sprawdź komentarze). Sytuacje w których wiesz, że kod jest bezpieczny a borrow checker raportuje błąd nie są rzadkie. Jak to naprawią to może może.

W tej chwili to wygląda tak, że musisz się nauczyć, jak zadowolić to narzędzie zamiast skupić się na programowaniu, co jest bez sensu bo w tym czasie mógłbyś się nauczyć jak faktycznie obsługiwać pamięć samemu i nie czekać wieczność na kompilację.

@part

Teraz technologie pokroju unity wypychają C++, chociaż cpp zawsze ma bastion w AAA.

Dzięki czemu mamy całe pokolenie wysoko poziomowych game developerów, którzy nie potrafia sami wyświetlić bitmapy w oknie bez pomocy gotowego silnika. Nie podoba mi się ten trend.

Native desktop cały czas traci na popularności. Zamiast tego wchodzą technologie webowe, bo te są mocno osandboxowane i przez to chętniej wypróbowywane. Prędzej wejdę na przypadkową stronę w Internecie niż zainstaluję przypadkowy program na komputerze. WebAssembly zyskuje na popularności, a niektórzy ludzie mocno się nim jarają, bo ma niby osiągać prędkości bliskie aplikacjom natywnym.

several napisał(a):

Dzięki czemu mamy całe pokolenie wysoko poziomowych game developerów, którzy nie potrafia sami wyświetlić bitmapy w oknie bez pomocy gotowego silnika. Nie podoba mi się ten trend.

Tak samo można mówić, że mamy webdevów, którzy nie umieją składać ramek tcp. Trend jest taki, żeby biznesowi się podobał.

A co do tematu, to nie widzę jakiś rozsądnych alternatyw do C++ jeżeli chodzi o desktopy. C# jest fajny, ale tylko na windowsa (jeżeli chodzi o desktopowe apki). Java ujdzie ale swing jest stary a javafx martwa.

Ale faktem też jest, że ludzie często piszą jakieś wewnętrzne toole w C++ nawet jeżeli ich firma działa tylko na windowsie. Ihmo ktoś kto chce pisać w C++ sam powinien przedstawić poważne powody "czemu nie wybrać bardziej produktywnej technologi?"

@several: przez analogie, mamy cale pokolenie kierowcow ktorzy nie potrafia zbudowac samemu samochodu...

@WhiteLightning: To niezbyt trafiona analogia. Ani mechanik, ani kierowca z założenia nie budują samochodów tak jak game developer z założenia powinien umieć zbudować grę. Poprawna analogia wygląda tak: mamy całe pokolenie mechaników, którzy nie potrafią rozłożyć i złożyć z powrotem silnika - i ta sytuacja również mi się nie podoba.

EDIT
Inna sprawa, że ja pisałem o wyświetleniu bitmapy w oknie a nie budowaniu całej gry od zera, ale to już mniejsza.

COBOL nie chce umrzeć, a ludzie się pytają, czy C++ przeżyje.

No to trzeba zmienić pytanie na inne: czy C++ podzieli los COBOLa?

No to trzeba zmienić pytanie na inne: czy C++ podzieli los COBOLa?

Jak na moje, to powoli tak. Wolniej niż COBOL, bo tego drugiego programiści zwyczajnie nie chcieli i był robiony przez biznes, ale stopniowo tak. C się utrzyma zdecydowanie dłużej i lepiej, ale w C++ powoli będzie powstawało coraz mniej nowego softu na rzecz innych języków programowania - Rust, Zig, Swift, C#, Go, Kotlin. Te języki zapewnią większą szybkość niż web, ale będą znacznie bardziej przyjazne programiście.

To w Rust mozna pisac obiektowo, generycznie i robic obliczenia w czasie kompilacji?

Wg mnie desktop moglby byc robiony w dowolnym jezyku jesli bedzie zapewniona infrastruktura. Komponenty wizualne, narzedzia - budowanie, pakowanie, testowanie.

C# mialby duze szanse zastapic C++ na desktopie gdyby nie mial wadliwego (w oczach spolecznosci OSS) pochodzenia. Wg mojej wrozki skonczy jako kolejny COBOL czy Visual Basic - z mocnym poparciem biznesu, ale coraz mniejszym zaangazowaniem programistow.

Na desktopie wewnetrzne korporacyjne toole calkiem spoko robi sie w Javie SE + Swing + Netbeans.
Nie wyglada to rewelacyjnie, ale jest za darmo i zawsze sie ktos znajdzie kto to zna.

To w Rust mozna pisac obiektowo, generycznie i robic obliczenia w czasie kompilacji?

3x tak.

C# mialby duze szanse zastapic C++ na desktopie gdyby nie mial wadliwego (w oczach spolecznosci OSS) pochodzenia.

Większym problemem był brak oficjalnego wsparcia na innych platformach niż MS. Obecnie z Core się to trochę zmienia i zobaczymy jak wyjdzie, ale nie sądzę by się mocno przebiło na innych platformach, ale kto wie. Może GNOME zainwestuje w to czas zamiast Vale.

vpiotr napisał(a):

To w Rust mozna pisac obiektowo, generycznie i robic obliczenia w czasie kompilacji?

W Ruscie istnieją oczywiscie generyki (Typy parametryczne) oraz jest mozliwy polimorfizm za pomocą Traitów. Ale nie jest to klasyczne OOP. Podobno przypomina Type Classy z Haskella. Nie rozumiem co masz ma myśli pisząc obliczenia w czasie kompilacji

Są aplikacje tzw. havy duty - gdzie dosłownie milisekundy mają znaczenie. Chodzi o np. panie pracujące z fakturami. One dochodzą do takiej wprawy, że dosłownie w mgnieniu oka otwierają i zamykają okna. Aplikacje sa budowane z dziesiątkami paneli i zakładek. Wiem, że zaraz odezwie się ktoś od UI, ale tak jest i takie aplikacje są i są potrzebne. Dla nich na razie zostaje tylko C++ - wszystko inne jest jeszcze bardziej niedopracowane (no, jeszcze Delphi jest, ale VCL, to też nie jest demon prędkości, szczególnie jak dynamicznie budujemy formy... fmx nie znam). Może Rust dorobi się czegoś takiego jak QT i będzie mógł zastąpić C++, ale to jeszcze nie teraz, na pewno nie zmigruje się aplikacjami które są napisane już w C++, a devovie tych apek będą kolejne raczej też w C++ robić. Aha, żadna aplikacja webowa nie ma startu do wyspecjalizowanych, wysokowydajnych aplikacji natywnych.

To w Rust mozna pisac obiektowo [...]?

Czy w dowolnym obecnie popularnym języku można pisać obiektowo? :-P

http://loup-vaillant.fr/articles/deaths-of-oop

Patryk27 napisał(a):

To w Rust mozna pisac obiektowo [...]?

Czy w dowolnym obecnie popularnym języku można pisać obiektowo? :-P

http://loup-vaillant.fr/articles/deaths-of-oop

Bojownicy SmallTalka i ich alternatywne definicje :D
Chociaż prawda jest że większość programistow których spotkałem gdy mowi obiektowość ma na myśli polimorfizm działający w czasie wykonania czyli zwykle subtyping lub duck typing w ostatecznosci statyczny duck typing czyli structured typing jak w Typescripcie lub Go

vpiotr napisał(a):

To w Rust mozna pisac obiektowo, generycznie i robic obliczenia w czasie kompilacji?

Teraz to nawet w Javie się da :] native-image z GraalVMa potrafi wiele statycznego kodu wykonać w czasie kompilacji i taki już obliczony wynik wrzucić do EXEka, przez co czas startu aplikacji się skraca.

WPF to nie jest to samo co WindowsForms. W WPF każdy element okna rysowany jest przez bibliotekę DIRECTX przy użyciu procesora graficznego. W trakcie wykonania programu kod C#->IL kompiluje się do kodu natywnego.

@ple właśnie dlatego, WPF jest wolniejszy nieco od WF bo jest bardziej skomplikowany. Jakby jeszcze WPF był multiplatformowy to spoko.... ale jest tylko na Windows a traci zalety Windowsa - m.in. to, że wszystko jest oknem, bo tam Handler jest tylko na okno i ew. okno modalne komunikatu.

Na desktopy, w sensie typowej aplikacji używanej przez użytkownika, to C++ może i upadnie, ale jeśli chodzi o biblioteki i aplikacje serwerowe, to zapotrzebowanie może jeszcze wzrosnąć. Odkąd komputeryzacja weszła w taką fazę, że przetwarzanie dużych ilości danych (od setek GB w górę) zaczęło być wykonywalne, to otworzyła się droga dla nowych zastosowań obliczeniowych związanych z uczeniem maszynowym, symulacjami, czy przetwarzaniem chmur punktów. I tu znowu potrzeba szybkości. I nawet jeśli istnieją języki równie szybkie co C++, to C++ ma przewagę dobrze rozwiniętych narzędzi, które wspierają te zastosowania, np. OpenCV do przetwarzania zdjęć i video czy Ceres do optymalizacji nieliniowej. C++ jest też dobrym językiem do współpracy z GPU dzięki CUDA, albo tensorRT, co powoduje, że jeśli mam naprawdę ogromne ilości danych do przetworzenia, które można zrównoleglić, to wciąż najszybciej zrobię to narzędziami napisanymi w C++.

Jest jeszcze FORTRAN, np cuda-fortran: https://developer.nvidia.com/cuda-fortran Pewnie jeszcze szybsze niż C i C++ :]

Niezłą dyskusję wywołałem :) widzę, że przewija się czasem twierdzenie, że są języki szybsze niż C/C++. Nie do końca rozumiem to stwierdzenie. Są to języki kompilowane do kodu maszynowego nie może być szybszych języków. Oczywiście, dużo zależy od umiejętności programisty ale teoretycznie, skoro nie mamy żadnej warstwy abstrakcji, mamy maksymalne możliwości optymalizacji i inne języki mogą być tylko równie szybkie. Może się mylę?

Chyba, że chodzi wam o to, że pewne domyślne rozwiązania jak np. polimorfizm, są lepiej zrealizowane w innych.

bilborrd napisał(a):

Nie do końca rozumiem to stwierdzenie. Są to języki kompilowane do kodu maszynowego nie może być szybszych języków. Oczywiście, dużo zależy od umiejętności programisty ale teoretycznie, skoro nie mamy żadnej warstwy abstrakcji, mamy maksymalne możliwości optymalizacji i inne języki mogą być tylko równie szybkie. Może się mylę?

Czasami ze względu na konstrukcję języków może się okazać, że niektóre rzeczy kompilator może założyć, że są spełnione. Przykładowo jeśli kod jest w safe Rust to możesz założyć, że przekazane referencje nie będą się na siebie nakładały (aliasing). Przez co kompilator może poczynić pewne założenia i zoptymalizować kod odpowiednio. Dodatkowo czasem konstrukcje w języku pozwalają Ci łatwiej zapanować nad niektórymi konstrukcjami, np. napisanie Servo w Ruście, a zwłaszcza równoległego renderingu, było łatwiejsze niż w C/C++, bo borrow checker i ownership pozwalał na łatwiejsze ogarnięcie kto może w danym momencie gdzie pisać, co redukuje miejsca gdzie potrzebujesz kontroli sekcji krytycznej "na wszelki wypadek". Całe mnóstwo małych rzeczy składa się na to, że często zarówno programiście jest łatwiej przedstawić niektóre koncepty jak i kompilator może mieć więcej informacji nt. samego kodu, co może pozwolić na lepsze optymalizacje.

Ostatnią rzeczą jest to, że języki bez "naleciałości historycznej" mogą być "naturalniejsze". Przykładowo funkcję z Rusta:

fn gen_arr_4(n: usize) -> [usize; 4] {
    [n, n + 1, n + 2, n + 3]
}

W C++ trzeba zapisać przy pomocy "mniej naturalnego" (a i tak nie wiem czy to jest poprawny zapis):

std::array<int, 4> gen_arr_4(int n) {
	return {n, n + 1, n + 2, n + 3};
}

Dodatkowo nawet mając większość "zabezpieczeń i bajerów" z nowych wersji C++ to nie zawsze stary kod będzie ich używał z różnych powodów (np. bo jest stary i nikt nie miał czasu ani chęci go przepisać lub musi wspierać również starsze kompilatory).

bilborrd napisał(a):

Niezłą dyskusję wywołałem :) widzę, że przewija się czasem twierdzenie, że są języki szybsze niż C/C++. Nie do końca rozumiem to stwierdzenie. Są to języki kompilowane do kodu maszynowego nie może być szybszych języków. Oczywiście, dużo zależy od umiejętności programisty ale teoretycznie, skoro nie mamy żadnej warstwy abstrakcji, mamy maksymalne możliwości optymalizacji i inne języki mogą być tylko równie szybkie. Może się mylę?

Chyba, że chodzi wam o to, że pewne domyślne rozwiązania jak np. polimorfizm, są lepiej zrealizowane w innych.

Golang jest kompilowany do kodu natywnego, a w np w tym benchmarku wypada dość niekorzystnie względem C++: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html

Javę do kodu natywnego można było kompilować już od dawna. Kiedyś było GCJ (GNU Compiler for Java), ale to nigdy nie działało dobrze. Przez długi czas (aż do niedawna) był Excelsior JET, ale firma zamknęła biznes, prawdopodobnie z powodu konkurencji ze strony native-image z GraalVMa.

trochę klepałem ostatnio w ML, opencv i pythonie ostatnio trochę hobby trochę komercyjny produkt. Wszystko naklepałem w python(gui w qt, przetwarzanie w opencv + imageai/keras). I powiem wam że jak bym miał to jeszcze raz pisać wziąłbym C++ na gui, ogarnianie ustawień, obsługa bazy sql itp. a jako proces odpalałbym skrypt pythonowy który ma jeden wątek i tylko mieli dane z kamery, przerzuca do opencv i ml a po IPC zwraca wynik. Niech mówią co chcą o C++ ma swoje wady ale osobiście wolałbym taką architekturę. C++ aczkolwiek C# + Keras kusi. Muszę obadać czy na jetson hula. Podsumowując wywód C++ na pewno utrzyma się na jakiś komputerach przemysłowych czy innym "ebmedded". I myślę na linuxowym desktop, tu jednak sporo się w C/C++ klepie nadal.