Następca C

Od lat są próby zastąpienia wysłużonego już języka C. Moje przemyślenia na temat tego, które nowe języki błędnie interpretowano jako następce C. Podzielę języki na cztery grupy, wy oceńcie, który język powinienem wstawić do odpowiedniej grupy.

Grupa A - języki systemowe niskiego poziomu podobne do C trudne:
Odin - https://odin-lang.org/
Jai - https://inductive.no/jai/
Beef - https://www.beeflang.org/
Vlang - https://vlang.io/
Muon - https://github.com/nickmqb/muon

Grupa B - języki systemowe niskiego poziomu podobne do C++ bardzo trudne:
C++
Rust
Zig - https://ziglang.org/

Grupa C - języki aplikacji wykorzystujące GC łatwe:
Nim
Crystal
Elixir
Elm
Idris
D
Go
Dart
C#, F#
wszystkie na JVM

Grupa D - języki skryptowe bardzo łatwe:
Ruby, Python, Perl, JS, TS, PHP etc etc.

Ale o co chodzi? Po co ta zabawa? Nie wiem do czego nam potrzebne takie grupowanie języków. C, C++, Java, C# i inne mają się dobrze.

Dla początkujących, bo i tak będą musieli poznać żeby dostać zaliczenie, to będzie Cormen Pseudocode.
Są różnice w wydaniach 2, 3
http://www.cs.utsa.edu/~wagner/CS3343/cormen/pseudo.html

Do internetowych dyskusji na start
https://en.wikipedia.org/wiki/List_of_programming_languages
https://en.wikipedia.org/wiki/List_of_programming_languages_by_type
https://en.wikipedia.org/wiki/Comparison_of_programming_languages

Pomijając to, że można dyskutować nad tymi listami - czy wszystkie języki są dobrze przydzielone, czy czegoś nie zabrakło itp, jedna rzecz mnie zastanawia. Czy uważasz, że PHP miał być następcą C? Really? Nie no, bez jaj :D

Tak samo nie wiem, co Perl albo JavaScript robią w zestawieniu konkurentów/następców języka C. To jakby w liście alternatyw dla samochodu, poza rowerem i autobusem, wstawić jeszcze krzesło i palmę :D

@cerrato: No właśnie to chciałem wyjaśnić, ale autor się upiera, że nie.

cerrato napisał(a):

nie wiem, co JavaScript robią w zestawieniu konkurentów/następców języka C.

Już była podobna dyskusja, poszukałem, znalazłem AFAIR system operacyjny napisany w JS i linux-distro w JS.
Jeżeli JavaScript nie działa jeszcze na Marsie to znaczy tylko tyle, że żaden komputer jeszcze nie wylądował na Marsie. :)

frida napisał(a):

Od lat są próby zastąpienia wysłużonego już języka C. Moje przemyślenia na temat tego, które nowe języki błędnie interpretowano jako następce

Można na siłę szukać egzotycznych non-GC alternatyw dla C ale po co?
Od zastępowania C/C++ jest od dawna Rust. I dyskusje gorące jak gender-drama

@BraVolt: Rust moim skromnym zdaniem jest zbyt skomplikowany do tworzenia systemu operacyjnego. Jest taki system Redox OS, ale to zabawka i na różnych stronach programiści piszą, że został, źle zaprojektowany. Jeden z głównych programistów Microsoftu też napisał, ze Rust jest zbyt skomplikowany i chcą go wykastrować z pewnych rzeczy i na jego podstawie stworzyć nowy język systemowy o nazwie Verona. Będzie mały, łatwy i prosty jak C, ale z ułatwieniami jakie daje Rust w zarządzaniu pamięcią i dobrym bezpieczeństwem.

frida napisał(a):

@BraVolt: Rust moim skromnym zdaniem jest zbyt skomplikowany do tworzenia systemu operacyjnego. Jest taki system Redox OS, ale to zabawka i na różnych stronach programiści piszą, że został, źle zaprojektowany. Jeden z głównych programistów Microsoftu też napisał, ze Rust jest zbyt skomplikowany i chcą go wykastrować z pewnych rzeczy i na jego podstawie stworzyć nowy język systemowy o nazwie Verona. Będzie mały, łatwy i prosty jak C, ale z ułatwieniami jakie daje Rust w zarządzaniu pamięcią i dobrym bezpieczeństwem.

Gdzie w takim razie miejsce na nasze zdanie?

BTW, ciekawy wątek.
Ale do rzeczy. Moim zdaniem z rustem trochę jak z komunizmem. W teorii super przyszlosciowy jezyk, embeddedy, naukowy trochę niskopoziomowy itd, itp.
Super, ale trochę haczyk.
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)
-Normalna składnia, mimo silnie typowanego języka.
-Możliwość działania przy sieciach komputerowych i bazach danych, oraz rzeczach systemowych typu rozszerzenia plików.
Taki język byłby na pewno lepszy od C.

Następcą C jest D. Po D jest E.

Pozdrawiam

Ktoś tu wymienił, ze systemy napisano w JS i PHP. Takich zabawek było więcej w Javie i C# i zapowiadały się naprawdę na poważne projekty. COSMOS, Signularity, SharpOS, JavaOS.
https://www.gocosmos.org/

frida napisał(a):

systemy napisano w JS i PHP. Takich zabawek było więcej w Javie i C# i zapowiadały się naprawdę na poważne projekty.

Te projekty JS/PHP-OS nie zapowiadały się na nic więcej jak tylko fun/ego zapaleńców

Moim zdaniem zig ma zbyt mało niskopoziomowych elementów by zastąpić c.

Aczkolwiek, może sprawdziłby się jako alternatywa dla c++.

Myślę, że nie ma co pchać Javy, c# i php jako języki niskopoziomowe, ale do innych zastosowań są spoko.

Uncle Bob o językach, jak @katakrowa o polityce: "kawałki zebrane"

Określenie „następca C” jest trochę nieprecyzyjne. Przez długi czas, C był głównym językiem programowania, kropka. Teraz rynek IT jest inny, mamy różne języki do różnych zadań. Mamy języki, takie jak Java i C#, do projektów mało wymagających wydajnościowo. Mamy C++ do projektów wymagających wydajnościowo (jak gry, przetważanie sygnałów). Są języki skryptowe, dedykowane aplikacjom internetowym — javascript, PHP, python, perl itp. Są wreszcie języki powłoki: bash, PowerShell. W takim sensie, nie będzie następycy.

Do niedawna, C miało jeszcze swoją niszę: systemy operacyjne, firmware i systemy wbudowane, więc w tym kontekście ewntualnie można szukać. Myślę, że C++ jest całkiem niezłym kandydatem, zwłaszcza C++11 i z tego co wiem, zaczyna co raz bardziej wypierać. Już dawno, kompilatory C++ są porównywalne wydajnością produkowanych programów z C, a nowy standard pozwala na całkiem nowoczesne programowanie. Zwłaszcza podoba mi się,
że ma wreszcie wyrażenia lambda. Dla niskopoziomowych rozwiązań są jeszcze dwaj główni konkurenci dla C. Pierwszym jest Rust. Nowoczesny, bardzo popularny ostatnio język. Drugim jest Go, ale ten raczej nie zajmie miejsca C, bo trudno go użyć na bare-metalu. Z tego co wiem, wymaga dość rozbudowanego środowiska.

Co rozumiesz przez "następce C"? C to jest asembler wysokiego poziomu. Jeśli gdzieś pisze się w czystym C to właśnie jako zamiennik dla pisania w asemblerze. Pod tym względem w zasadzie nie ma języka który mógłby go zastąpić i te twojego kategorie w ogóle nie mają sensu.

Idris jako {n,z}astępca C? Przecież te języki od strony praktycznej nie mają ze sobą nic wspólnego…

Oczywiście, że JavaScript, przeciez idealny język który moze zastąpić wszystko, co nie? Lolol

Z tych ktore znam jedynie Nim sie nadaje do tego watku.

https://nim-lang.org/docs/gc.html
https://hackaday.com/2018/09/25/nim-writes-c-code-and-more-for-you/

Tlumaczy sie do C, C++, Objective C, JS.

Sorry że z innego nicka, ale zmieniłem hasło na silniejsze i nie mogę się teraz zalogować na poprzedni nick frida. Nie mogę edytować pierwszego postu, jednak chciałem w nim tylko dopisać, ze języki które mogą być następcami C to wyłącznie języki które wymieniłem w grupie A. Czyli Odin, Jai, Beef, Vlang, Moun, Clay. Kolejne grupy podzieliłem na języki takie jak C++, Zig, Rust które są za bardzo rozbudowane i według mojej opinii są słabym wyborem do tworzenia systemów operacyjnych. Następna grupa to języki kompilowane wykorzystujące GC, są co prawda szybkie, ale nie dość szybkie do stworzenia systemu operacyjnego. Ostatnia grupa to języki skryptowe, które całkowicie nie nadają się do tworzenia systemów operacyjnych. Posiadają GC, są powolne, wszystkim poza TS brak statycznego typowania.

A po co wymieniles cokolwiek spoza grupy A?

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.

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

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.

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ć.

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.

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

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.

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ż!".

@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.