Następca C

2

A po co wymieniles cokolwiek spoza grupy A?

4

Też nie wiem co chciałeś napisać.
Języki powybierane bez ładu i składu - czemu te, a nie setki innych?
Co to są języki trudne, bardzo trudne, a co to łatwe?
C jak assembler - jest bardzo łatwym językiem z punktu widzenia zasad (a czasem ich braku) - tylko trudnym w praktycznym użyciu.

3

Rozwiązanie problemu, który nie istnieje (lub jest nierozwiązywalny bo języki zawsze były tworzone jakoś tak bez ładu i składu). Obawiam się, że ten podział jest subiektywny przez co nie może być użyty w jakikolwiek sposób przez innych

1
KHX napisał(a):

Idziesz sobie do dokumentacji, bierzesz jakąś z pierwszych lekcji, i bum składnia tak przekombinowana, że odechciewa się uczyć.
Moim zdaniem następcą C powinien mieć :
-możliwość i narzędzia do pisania sterowników, mikrokontrolerów, jakiś procesorów, i ogólnie niskopoziomowość,
-Szybkość, oraz instrukcje do matematyki(algorytmów)
[…]
-Możliwość działania przy sieciach komputerowych i bazach danych, oraz rzeczach systemowych typu rozszerzenia plików.

Zarówno Zig jak i Rust mają te właściwości.

-Normalna składnia, mimo silnie typowanego języka.

Co nazywasz "normalną składnią"? Bo to bardzo subiektywny warunek. Ja np. lubię składnię Erlanga, a składnia Pythona niespecjalnie do mnie przemawia. Zapewne w przeciwieństwie do większości osób na forum.

2

Co rozumiesz pod pojęciem "wysłużonego już języka C"? Popsuł się i nie działa? Wysłużony to może być np. samochód, który swoje już przejechał i niedomaga - tu rdzewieje, tam coś stuka i puka. Ale język programowania?

Po co w ogóle go zastępować? Przecież sprawdza się co najmniej dobrze od kilkudziesięciu lat.

Zakładam, że nie programujesz niskopoziomowo. W programowaniu niskopoziomowym potrzebny jest prosty i oczywisty język bez jakichś dziwnych zawiłości, nieoczywistości i pseudoudoskonaleń. Ma być prosty do translacji elementarnych operacji niskopoziomowych np. na rejestrach sprzętowych na kod maszynowy po to żeby efektywnie komunikować się ze sprzętem.

Poza tym aspekt debugowania programu - nieraz miałem tak że trzeba zejść na poziom języka maszynowego, żeby znaleźć przyczynę błędu z tzw. calltrace'a Linuxowego. Zwykle pojedynczą linijkę kodu C da się przedstawić w postaci kilku rozkazów maszynowych w miarę łatwych do interpretacji. Wbrew pozorom jest to istotne.

Po to stosuje się modele warstwowe jak np. ISO/OSI, żeby im bliżej sprzętu tym bardziej elementarne zasady panowały, a im wyższy poziom w modeul ISO/OSI tym wyższy poziom abstrakcji możesz stosować.

1

Po co w ogóle go zastępować? Przecież sprawdza się co najmniej dobrze od kilkudziesięciu lat.

Bo o ile C jest stosunkowo proste w definicji, tak pisanie bezpiecznego kodu w C wcale do prostych nie należy. Wystarczy przejrzeć listę CVE i widać, że większość z nich jest związana z błędami w obsłudze wskaźników.

Ma być prosty do translacji elementarnych operacji niskopoziomowych np. na rejestrach sprzętowych na kod maszynowy po to żeby efektywnie komunikować się ze sprzętem.

Gdyby to był jedyny wyznacznik, to wszyscy pisali by w asemblerach, a nie w C.

0

Język C jest nieśmiertelny - https://www.tiobe.com/tiobe-index/

2

Wydaje mi się, że do niektórych języków trzeba dorosnąć. Z mojego doświadczenia, C++ jest takim językiem. Jeśli zgadzamy się, że o następcy C jest sens rozmawiać w kontekście systemów operacyjnych i firmware to myślę, że argument, że C++ jest duży trudny i skomplikowany nie jest dobrym argumentem, bo to praca dla wyjadaczy. Też kiedyś za to nie lubiłem C++. Lisp wyleczył mnie z takiego użalania się nad swoimi niskimi zdolnościami. Teraz cenię C++, zwłaszcza C++11, choć dla moich celów Common Lisp jest lepszy. :)

C++ jest nie gorszy pod względem dostępu do niskopoziomowych funkcji ani wydajności od C, za to pozwala na pisanie znacznie lepszego jakościowo kodu. A, że można pisać w nim znacznie gorszy kod niż w C, cóż, w Common Lispie można pisać jeszcze gorszy kod. Taka jest cena mocy — odpowiedzialność. Jak w życiu.

0
elwis napisał(a):

Wydaje mi się, że do niektórych języków trzeba dorosnąć. Z mojego doświadczenia, C++ jest takim językiem. Jeśli zgadzamy się, że o następcy C jest sens rozmawiać w kontekście systemów operacyjnych i firmware to myślę, że argument, że C++ jest duży trudny i skomplikowany nie jest dobrym argumentem. Też kiedyś za to nie lubiłem C++. Lisp wyleczył mnie z takiego użalania się nad swoimi niskimi zdolnościami. Teraz cenię C++, zwłaszcza C++11, choć dla moich celów Common Lisp jest lepszy. :)

Często samo myślenie o języku umiejscawia człowieka między "studentką przed okresem" (mowa o paniach, które na studiach się nie przykładały) a twórcą języka. Czasem nawet tu, na forum 4p, mamy przypadki, w których ktoś nie rozumie języka, bo "nie, bo nie i już!".

2

@elwis: lubie C++ i stosuje go jako glowny jezyk do projektow domowych, ale nie powiedzialbym ze ten jezyk nadaje sie jako zastepnik C.

Co powinien miec nastepca:
1) skladnie na ktorej mozna polegac - operator overloading, TMP, regula 5/0 powoduja ze C++ nie jest czytelne i nie jest jezykiem w ktorym patrzac na kod bez uruchomienia wiesz co on robi

2) proste i pewne tablice - w C/C++ sa one konwertowalne do wskaznika, a ten do int-a, tablice w C nie maja kontroli rozmiaru, a tablice deklarowane dynamicznie nie maja rozmiaru

3) lancuchy - powinny byc immutable, automatycznie zwalniane i posiadac kontrole dlugosci oraz mozliwosc jej sprawdzenia, w C masz tylko mozliwosc obliczenia dlugosci, w C++ masz do stringow co najmniej 4 rozne skladnie (wskaznik na znak, tablica znakow, std::string, std::string_view), kazda z nich ma swoje zastosowanie

4) dobrze zdefiniowane moduly, niezalezne od miejsca uzycia - w C++ dopiero od C++20

5) listy, slowniki/mapy jako elementy jezyka - patrz Python, PHP - czas pokazal ze te elementy bardzo ulatwiaja tworzenie oprogramowania w danym jezyku

6) cos na wzor Either / Optional (niekoniecznie obiektowe)

7) twarde typowanie by default z opcja konwersji - jak mozna pisac oprogramowanie systemowe bez tego?

8) korutyny ew. watki (w C++ od C++11 watki, korutyny od C++20)

C++ ma wiele fajnych ficzerow ktore ulatwiaja programowanie ...w C++. Ale jakbys chcial pisac cos niezawodnego to zaczynasz eliminowac tyle rzeczy ze wychodzi Ci gole C czyli wracamy do pkt wyjscia.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0