A komu to potrzebne - czyli zapotrzebowanie na programistów C++

wydaje mi się, że za jakiś czas procesory typu CISC zostaną wyparte przez RISC, lista wszystkich kodów maszynowych będzie niewiele bardziej złożona, niż najprostsza maszyna Turinga w stylu języka BF

A gdzie tam, różnica między CISC a RISC od dłuższego czasu (~20 lat?) sprowadza się tylko do tego, czy odczyty z/zapisy do pamięci można połączyć z operacjami arytmetyczno-logicznymi, jak to ma miejsce na x86, czy wymagają osobnych instrukcji, a instrukcje arytmetyczno-logiczne operują tylko na rejestrach, czego przykładem jest większość innych architektur.

Chyba najlepszym przykładem tego, że działa to w przeciwną stronę, są nowoczesne procesory ARM – w teorii RISC – które mają tak proste instrukcje, jak wykonanie rundy AES lub SHA-2, czy mnożenie wielomianów w GF(2).

Są urządzenia wykonujące bytecode Javy "prawie natywnie"

Są, ale to albo technologie przestarzałe (ARMowe Jazelle), albo bardzo niszowe. W praktyce JIT działa po prostu lepiej.

Ajć, źle się wyraziłem. Chodziło mi o to, że wszystko, co powstaje, jest na początku dość proste i działa względnie szybko. Z biegiem czasu każdy chce rozbudowywać, co tylko się da. Efektem są takie twory, jak C++ (który na samym początku nie był aż tak przeładowany).

tak proste instrukcje, jak wykonanie rundy AES lub SHA-2

Właśnie o to mi chodzi (przykład z RISC był faktycznie nietrafiony, bo tam też są takie instrukcje, mój błąd). Wszystkie języki się rozwijają, powstają nowe kody maszynowe, nowe mechanizmy w różnych językach i nowe style programowania. Ostatecznie wiele starych narzędzi traci na popularności przez to, że są zbyt złożone. A przy wydzielaniu przydatnych mechanizmów powstają nowe języki, które nagle zyskują chwilową sławę, dopóki znów ktoś ich nie zacznie rozbudowywać, i tak w kółko. Myślę, że za jakiś czas nazbiera się tyle różnych podejść, że powstaną sensowne fundamenty, które po prostu muszą wystąpić i na tym będzie oparta cała reszta.

_Dopisano:

Są, ale to albo technologie przestarzałe (ARMowe Jazelle), albo bardzo niszowe. W praktyce JIT działa po prostu lepiej.

Zdaję sobie z tego sprawę. Chodziło mi o to, że mając jakąś zupełnie inną architekturę XYZ może się okazać, że wyniki wszelkich testów mających znaleźć "genialny język, w którym powstają najszybsze programy" mogą dać zupełnie inne wyniki. C++ nie musi być najszybsze, wiele zależy od kompilatora. Java nie musi być wolna, może korzystać z dodatkowych mechanizmów, chociażby wspomnianej kompilacji Just-In-Time. A zawsze można wymyślić nową architekturę, gdzie język X będzie szybszy, niż wszystko inne, ponieważ taki był cel podczas tworzenia języka X przeznaczonego specjalnie do obsługiwania architektury XYZ. Nie wspominając już o błędnym używaniu języków Y i Z oraz twierdzeniu, że "Y oraz Z strasznie muli". A biorąc pod uwagę fakt, że różne firmy tworzą nowe języki i nowy sprzęt, to kto wie, w czym będziemy pisali programy choćby za 10 lat.

Kto wie czy C++ nie wróci do łask, jak nadrobi okres stagnacji między standardami 98 i 11. Taka Java jest dobrze napchana komponentami dostępnymi w JRE w standardzie.

@jankowalski25:
Sądzę, że się nieco mylisz, że problemem jest 'złożoność C++ i dlatego obrano inny kierunek'. Problemem C++ było to, że przez ponad 20 lat standard języka nie był zmieniany. Przez te 20 lat konkurencja nie spała tylko tworzyła nowe rozwiązania, całą masę bibliotek itd. Moim zdaniem zaniedbanie standardu języka C++ doprowadziło do zmniejszenia jego roli. Gdybyś 15 lat temu miał w standardzie C++ dostępne to co jest w C++17 to sądzę, że tamte języki nieco mniej by miały do powiedzenia, bowiem w praktyce całkiem sporo narzędzi zostało dodanych do standardu, które powinny być od dawna i do tego są crossplatformowe.

/edit:
A dołączony obrazek przez pekfosa w zasadzie ewidentnie pokazuje jak bardzo podstawowych bibliotek nie było do tej pory w standardzie i do tego jeszcze sporo mu brakuje.

Problemem C++ było to, że przez ponad 20 lat standard języka nie był zmieniany.

To też, ale spójrz chociażby na to, jak powstają poszczególne fazy translacji (może właśnie na tym należy oprzeć formatowanie kodu?) i ile jest "szczególnych przypadków", które w "szczególnych przypadkach" działają "wyjątkowo". Od jakiegoś czasu zagłębiam się w poszczególne bity, kody maszynowe, czytam instrukcje asemblera i "patrzę, co jest pod maską", bo mój samochód o nazwie C++ na 99% dróg zachowuje się bezawaryjnie. Zawsze jest ten 1%, na który trafiają tacy "testerzy-amatorzy", jak ja. I potem się okazuje, że objdump nie rozróżnia "31 c0" od "33 c0", z czego pierwsze to "xor ax,ax", a drugie to "xorl ax,ax". Znajdą się sytuacje, gdzie takie drobiazgi mają znaczenie.

_Dopisano:
Jakby przetrząsnąć nieco forum, to pewnie okaże się, że takie dyskusje już były, z czego część ("święte wojny"?) poszła do kosza, chociażby Temat usunięty. Coraz częściej mam wrażenie, że trzeba zacząć powiązywać tematy.

_Dopisano:

Powiązane tematy

• C, C++, czy C# - który język lepszy?
• Ruby czy C++

I potem się okazuje, że objdump nie rozróżnia "31 c0" od "33 c0", z czego pierwsze to "xor ax,ax", a drugie to "xorl ax,ax". Znajdą się sytuacje, gdzie takie drobiazgi mają znaczenie.

Tak z ciekawości, jakie znaczenie ma to, czy wynik xor eax, eax zostanie zapisany do lewego eax, czy prawego eax? To nie musi być nierozróżnianie, to może być ujednolicanie. Ta sama operacja może być zapisana na różne sposoby i wtedy jest dowolność.

Ta sama operacja może być zapisana na różne sposoby i wtedy jest dowolność.

Czyli redundancja rośnie i to jest między innymi to, o czym piszę. Po co dwie osobne instrukcje, które robią dokładnie to samo? Po co instrukcje liczące SHA? Mam wrażenie, że wszędzie działa taki mechanizm:
1. Mamy język, który prawidłowo realizuje funkcjonalność A za pomocą B.
2. Potrzebujemy zrobić C.
3. Naszym pierwszym pomysłem jest dorzucenie nowego mechanizmu D do języka, dzięki czemu zrobienie C będzie trywialne.
4. Okazuje się, że inni użytkownicy korzystają z tego samego języka i chcą zrobić E.
5. Ktoś stosuje D do zrobienia E.
6. Okazuje się, że D może zostać zastąpione przez B.
7. Mamy język, w którym E można zrobić za pomocą B oraz D.
8. Okazuje się, że można byłoby wprowadzić F, które jest w stanie obsłużyć wszystkie przypadki, gdzie korzystamy z B lub D.

Jak jest?

Co robimy?	Za pomocą czego?
A	B
C	D
E	B
E	D

Jak być powinno?

Co robimy?	Za pomocą czego?
A	F
C	F
E	F

Czy zawsze musi być jeden sposób na zrobienie A, C oraz E? Nie, ale jeśli to się za mocno rozrasta, to nagle mamy "szczególne przypadki", których żaden człowiek nie jest w stanie zrozumieć.

Tak z ciekawości, jakie znaczenie ma to, czy wynik xor eax, eax zostanie zapisany do lewego eax, czy prawego eax?

Po żmudnym grzebaniu w różnych niskopoziomowych mechanizmach okazało się, że między innymi dlatego podczas startu BIOSa w 1% przypadków klawisz 'S' jest ignorowany, bo nie zawsze obok "31" i "33" występuje "c0". Inne zawartości rejestrów sprawiają, że procesor wykonuje odrobinę inny kod w kolejnych instrukcjach. Od razu zaznaczam: ten 1% to są "patologiczne" przypadki, więc ciężko taką wiedzę wykorzystać jakoś szerzej, ale to jest strasznie denerwujące, że to, co u innych działa od razu, u mnie rusza dopiero po odłączeniu od prądu i ponownym uruchomieniu po co najmniej 30 sekundach.

Dorzucę swoje trzy grosze do tematu.

Język C++ traci na popularności z powodu jego złożoności oraz braku odpowiednich bibliotek.

Również dlatego, że coraz mniej ludzi uczy się języka C++. Nauczenie się C#, Javy czy JavaSciprtu jest prostsze i efekty widać od razu, szczególnie że języki są dostarczone z bibliotekami, które pozwalają pisać aplikacje okienkowe. Za językami C# czy Java stoją duże korporacje, które mogą pchać czas i zasoby w rozwijanie danego języka, jego bibliotek czy środowisk programistycznych. Zarobki też są spoko ponieważ jest dużo klientów a programistów dalej mało.

Jeżeli technologia jest wystarczająca wydajnościowo, pozwala zredukować ilość pojawiających się błędów, pozwala łatwo i wydajnie się debuggować, dostarcza dużo świeżych programistów, wymaga niewiele czasu na stworzenie aplikacji, instalowanie nowych bibliotek to chwilka a system budowania jest prosty i szybki to taki język będzie zyskiwał na popularności w większości projektów, ponieważ w większości projektów wydajność języka nie jest wąskim gardłem.

Język C++ ma bardzo wiele wad, ale ma zaletę w postaci prędkości i niektóre projekty po prostu nie mają alternatywy.

Oczywiście systemy czasu rzeczywistego czy systemy działające pod dużym obciążeniem będą dalej pisane w językach natywnych. Projektów w C++ nie będzie dużo mniej, po prostu projekty w innych językach są tańsze przez co coraz mniej wymagający klienci mogą sobie na nie pozwolić. C++ traci na popularności, ale więcej przegrywa na tym polu, że nie zyskuje jej jak inne technologie.

Zrobienie responsywnej aplikacji okienkowej w C# załatwisz ucząc się trochę WPFa czy Windows Forms i async/await i gotowe. W C++ będziesz musiał nauczyć się C++a a potem wybrać odpowiednią bibliotekę, która i tak będzie wyglądać brzydko a potem nauczyć się obsługi wielowątkowości. Responsywną stronę internetową zrobisz w JS z CSSem po kilku tutorialach a w C++ nawet nie myślę co trzeba by było zrobić.

Po prostu Java i C# są bardziej odpowiednie dla 99% projektów, które się aktualnie wykonuje na rynku, jednak te projekty nigdy nie były jakimś super celem C++a. Można przyjąć nieśmiałe założenie, że tak, popularność języka C++ spada, jednak ilość projektów jakie się w nim wykonuje w miarę się trzyma.

W języku C i C++ wciąż będą powstawać rozwiązania dla przemysłów, które się rozwijają np:
- automotive
- systemy operacyjne
- oprogramowanie dla sprzętów o niedużej ilości RAMu
- oprogramowanie telekomunikacyjne

Nawet jeżeli wejdą tam inne języki to C++ dalej będzie miał duży kawałek tortu tych branży, gdzie projekty idą w miliardy dolarów.

http://www.stroustrup.com​/applications.html