Co sprawia, że ​​C jest tak popularny w erze OOP? [Zamknięte]


91

Dużo koduję zarówno w C, jak i C ++, ale nie spodziewałem się, że C będzie drugim najpopularniejszym językiem, nieco za Javą.

Indeks społeczności programistycznych TIOBE

Ciekawe, dlaczego w tym wieku OOP C jest nadal tak popularny? Zauważ, że 4 z 5 najpopularniejszych języków programowania to „nowoczesne”, zorientowane obiektowo języki.

Teraz zgadzam się, że możesz do pewnego stopnia używać OOP w C, ale jest to trochę bolesne i nieeleganckie (przynajmniej w porównaniu z C ++, jak sądzę). Co sprawia, że ​​C jest tak popularny? Czy to wydajność; będąc na niskim poziomie; zdecydowana większość bibliotek, które już istnieją, czy coś jeszcze?


18
gry wideo, systemy wbudowane, programowanie sprzętowe (oprogramowanie układowe), systemy operacyjne itp.

25
Pamiętaj, że otrzymujesz tylko to, co mierzysz - w przypadku TIOBE liczbę trafień +"<language> programming"w popularnych wyszukiwarkach. W blogu „Dlaczego nikt już nie programuje C” liczy się C w tym indeksie. Cholera, nawet to pytanie może zrobić, gdy tylko Google go odbierze.

40
Wiek OOP? to dość odważne stwierdzenie.
Mahmoud Hossam

57
Masz złudzenie, że OOP jest srebrną kulą, powinieneś szybko stracić, nie ma nic specjalnego ani „dobrego” w OOP, to tylko jedna z wielu strategii organizacji kodu.
Raynos

23
@DeadMG: Garnek, poznaj czajnik. Dane TIOBE mogą nie być wiarygodne, ale twoje łysy twierdzenie, że „nie jest popularny”, nie ma żadnego źródła ani cytowania. Jeśli zamierzasz zakwestionować założenie stojące za pytaniem, przynajmniej przedstaw dowody na poparcie tego.
Daniel Pryden

Odpowiedzi:


143

Kilka czynników, które przyczyniają się:

  • C jest wszechobecny. Niezależnie od platformy, C jest prawdopodobnie dostępny.
  • C jest przenośny. Napisz kawałek czystego C, a kompiluje się z minimalnymi modyfikacjami na innych platformach - czasami nawet działa po wyjęciu z pudełka.
  • C jest już od jakiegoś czasu. W czasach, gdy UNIX podbił świat, C (wybrany język programowania UNIX) podzielił się swoją dominacją nad światem i stał się lingua franca świata programowania. Można oczekiwać, aby jakikolwiek poważny programista przynajmniej uczynić pewne poczucie kawałkiem C; tego samego nie można powiedzieć o większości innych języków.
  • C jest nadal domyślnym językiem dla systemów UNIX i UNIX. Jeśli chcesz, aby biblioteka odniosła sukces w środowisku typu open source, potrzebujesz dość dobrych powodów, aby nie używać C. Jest to częściowo spowodowane tradycją, ale więcej, ponieważ C jest jedynym językiem, który możesz bezpiecznie założyć, że jest obsługiwany w dowolnym systemie podobnym do UNIX system. Pisanie biblioteki w C oznacza, że ​​możesz zminimalizować zależności.
  • C jest proste. Brakuje w nim wyrazistości zaawansowanych OOP lub funkcjonalnych języków, ale jego prostota oznacza, że ​​można go szybko odebrać.
  • C jest wszechstronny. Jest odpowiedni dla systemów wbudowanych, sterowników urządzeń, jąder systemu operacyjnego, małych narzędzi wiersza poleceń, dużych aplikacji komputerowych, DBMS, implementacji innych języków programowania i wielu innych rzeczy, o których można pomyśleć.
  • C jest szybki. Większość implementacji C kompiluje się bezpośrednio do kodu maszynowego, a programista ma pełną kontrolę nad tym, co dzieje się na poziomie maszyny. Nie ma interpretera, kompilatora JIT, maszyny wirtualnej ani środowiska wykonawczego - tylko kod, kompilator, linker i goły metal.
  • C jest „wolny” (zarówno w sensie piwa, jak i mowy). Nie ma jednej firmy, która jest właścicielem i kontroluje standard, istnieje kilka wdrożeń do wyboru, nie ma problemów z prawami autorskimi, patentami ani znakami towarowymi do korzystania z C, a niektóre z najlepszych wdrożeń są typu open source.
  • C ma duży rozpęd. Język jest popularny od dziesięcioleci, więc istnieje ogromna liczba aplikacji, bibliotek, narzędzi, a przede wszystkim społeczności, które obsługują ten język.
  • C jest dojrzały. Ostatnim standardem, który wprowadził duże zmiany, jest C99 i jest on w większości kompatybilny wstecz z poprzednimi standardami. W przeciwieństwie do nowszych języków (np. Python), nie musisz się martwić, że wkrótce zmienisz zmiany.
  • C jest kompatybilny. Większość języków ma powiązania umożliwiające rozmowę z C. Oznacza to, że można stworzyć bibliotekę w C przy użyciu standardowych konwencji wywoływania i mieć pewność, że prawie jakikolwiek inny język może połączyć się z tą biblioteką. Aby wymienić kilka popularnych języków w powszechnym użyciu: C #, Java, Perl, Python, PHP mogą bez problemu łączyć się z bibliotekami C.
  • C jest potężny: jeśli język nie jest w stanie nic zrobić, wszystkie popularne kompilatory pozwalają na osadzanie kodu asemblera, który może zrobić wszystko, co może zrobić sprzęt. Przejściowo w połączeniu z powyższym punktem dotyczącym zgodności, oznacza to, że C może działać jako łącznik między językami wyższego poziomu a „gołym metalem” asemblera.

9
Myślę, że nie wszystkie twoje argumenty są poprawne. 1) C jest wszechobecny. C ++ jest tak samo ubiquitos jak C, ponieważ istnieją kompilatory od C ++ do C. 2) C jest przenośny. To samo z C ++. 3). C jest już od jakiegoś czasu. To samo z C ++. 4). C jest wszechstronny. To samo z C ++. 5) C jest szybki. To samo z C ++. 6). C jest „darmowy”. To samo z C ++. 7). C ma duży rozpęd. To samo znowu z C ++. 8) C jest dojrzały. To samo z C ++. Więc właściwie nie odpowiadasz na pytanie.
Konstantin Solomatov

19
C11 to najnowszy standard, a nie C99. Nie znaczy to, że to naprawdę ważne, ponieważ wszyscy używają 89.
Pubby

53
@KonstantinSolomatov: Jeśli piszesz bibliotekę, która będzie konsumowana przez inne osoby, wyświadcz światu przysługę i napisz ją w C zamiast w C ++. Jeśli nie możesz tego zrobić, przynajmniej napisz C API. Wszystko we wszechświecie może w jakiś sposób łączyć się z kodem C, zwykle przy minimalnym wysiłku. W przeciwieństwie do tego często będziesz miał poważne problemy z ABI podczas próby wywołania kodu C ++ z innego kodu C ++ , a tym bardziej z innych języków.
Daniel Pryden

37
@KonstantinSolomatov - fakt, że istnieje potrzeba kompilatora C ++ do C dowodzi, że C jest tym, który jest wszechobecny.
detly

11
@KonstantinSolomatov: Przestań myśleć, że C to C ++. C nie ma zamknięć. Niektóre rozszerzenia C tak robią (takie jak te zaimplementowane przez rodzinę kompilatorów gcc), ale samo C nie ma (tj. Nie ma go w oryginalnej specyfikacji K&R ani w żadnym ze sfinalizowanych standardów C).
Donal Fellows

88

Zawsze obwiniałem popularność C o potrzebę uniwersalnego języka asemblera. Jego połączenie specyfiki na poziomie maszyny, standaryzacji i ekstremalnej przenośności pozwala C funkcjonować jako de facto uniwersalny język asemblerowy i z tego powodu podejrzewam, że jego rola będzie istnieć w nieskończoność.

Powinienem wspomnieć, że zawsze jestem nieco zaskoczony, gdy OOP jest prezentowany na kursach programistycznych jako rodzaj „ostatecznego modelu”, który jest jedynym możliwym punktem końcowym dobrego programowania. Podobnie jak wiele innych aspektów programowania, wartość OOP stanowi kompromis między wieloma konkurującymi ze sobą czynnikami, w tym sposobem, w jaki mózg ludzki organizuje informacje, jak grupy społeczne wspierają oprogramowanie w dłuższej perspektywie, a w przypadku programowania obiektowego niektóre dość głębokie aspekty jak działa sam wszechświat.

I ten ostatni punkt warto trochę wbić. Czytaj dalej, jeśli jesteś zainteresowany badaniem na poziomie fizyki, dlaczego istnieją pewne style programowania, jak one działają razem i gdzie może zmierzać świat w przyszłości, gdy będziemy dalej rozwijać takie koncepcje ...

Obiekt w fizyce to wszystko, co utrzymuje rozpoznawalną spójność w czasie. To z kolei pozwala prostym stworzeniom, takim jak my, uciec przed przedstawieniem obiektu przy użyciu tylko niewielkiej liczby bitów, bez narażania naszego życia na zbyt duże straty. Ale jeśli chodzi o fizykę w ogóle, liczba rzeczy, które musisz dokładnie zrobić, aby uprościć i uprościć tego rodzaju uproszczenia, jest niezwykle duża. Jako ludzie nie myślimy o tym tyle, ponieważ szczerze mówiąc, nie byłoby nas tutaj, gdyby to nie była prawda.

Brzmi zbyt abstrakcyjnie? To naprawdę nie jest. Wyobraź sobie na przykład, że próbujesz nawigować drogą do domu znajomego, jeśli zamiast samochodów napotkasz gwałtownie oscylujące pola plazmy i chwilowe kondensacje materii poruszającej się z ogromnym zakresem prędkości. Taki scenariusz mógłby raczej głęboko wpłynąć na możliwości socjalizacji, tak? Musimy obiekty, my obiekty, oraz istnienie obiektów daje nam ogromną i krytycznie ważny poziom uproszczenia otoczenia wokół nas.

Wróćmy więc do oprogramowania. Co obiekty w świecie rzeczywistym mają do powiedzenia na temat obiektów w zakresie programowania?

Cóż, z jednej strony oznacza to, że to, co definiuje „dobry” obiekt w oprogramowaniu, powinno naprawdę oznaczać, czy rodzaj danych, którymi się posługujesz, z łatwością wspiera ideę rozpoznawalnego uporczywości w czasie .

Dzięki tej definicji najłatwiejsze formy OOP są łatwe do rozpoznania. Są to te, które trochę sobie radzą, używając tylko danych, które są już „dołączone” lub zdefiniowane przez jakiś rzeczywisty, prawdziwie fizyczny obiekt, taki jak osoba, dom lub samochód. Nawet dzisiaj jest to zbyt często jedyna definicja obiektów, które ludzie zdobywają na kursach oprogramowania. To niedobrze, ponieważ nawet trywialne programy obiektowe potrzebują szerszej definicji niż to.

Druga i znacznie bardziej interesująca kategoria obiektów obejmuje to, co nazywam unieśmiertelnionymi wydarzeniami ze świata rzeczywistego . Przez „unieśmiertelniony” rozumiem rzeczy, które przynajmniej krótko istnieją jako dobrze zdefiniowane byty lub kolekcje w realnym świecie, ale które następnie rozpraszają się i przestają istnieć jako kolekcje mające znaczenie fizyczne. Sympozjum jest doskonałym przykładem: sympozjum istnieje przez krótki czas jako przyzwoicie dobrze zdefiniowana kolekcja miejsc i ludzi. Ale niestety nawet najlepsze konferencje muszą się zakończyć, a poszczególne części, które je stworzyły, przechodzą do innych działań.

Ale za pomocą komputerów i sieci możemy sprawić, że takie przejściowe sympozjum będzie wyglądać jak obiekt długoterminowy, przechwytując i utrzymując jego pamięć jako obiekt oprogramowania. Wiele rzeczy, które robimy z komputerami i bazami danych, sprowadzają się do tego rodzaju unieśmiertelnienia zdarzeń przejściowych, w których w rzeczywistości staramy się wzbogacić nasz prawdziwy wszechświat, wychwytując go i rozszerzając w sposób, który nie mógłby istnieć fizycznie. Np. Czy widziałeś ostatnio prawdziwą Pandorę? Takie przechwytywanie i rozszerzanie realnych dzieł pomaga wzbogacić i przedłużyć nasze życie, ekonomię i wybory w niezwykły sposób. To jest dla mnie centrum programowania obiektowego, miejsce, w którym wywarło i nadal ma najbardziej niezwykłe skutki.

Ostatnia kategoria OOP składa się z obiektów, które nie mają ścisłego związku ze zdarzeniami zewnętrznymi, ale są infrastrukturąpotrzebne do wspierania naszego ciągłego rozszerzania rzeczywistości za pomocą unieśmiertelnionych obiektów ze świata rzeczywistego. To tutaj możesz zejść aż do (pół) metalu komputera, tworząc kawałki trwałej rzeczywistości, które podobnie jak pierwiastki chemiczne w prawdziwym świecie można szybko łączyć i w ciekawy sposób budować nowe światy wewnętrzne. Komputery mobilne pomogły promować rozwój tego rodzaju wysoce rekombinacyjnego podejścia, które ponownie na wiele sposobów naśladuje rekombinacyjne cechy świata fizycznego. Jest to również trudne: to, co może wydawać się dobrym wyborem, może z czasem okazać się nieoczekiwanie złe, zwykle dlatego, że zamiast blokować, blokuje różnorodność i ekspansję.

Ta ostatnia kategoria wskazuje również na ryzyko związane z użyciem tylko jednego modelu do programowania, ponieważ podobnie jak świat rzeczywisty, światy programowane również potrzebują procesów, które niedobrze odpowiadają względnie niezmiennym przedmiotom. Ziemia jest pełna obiektów, ale słońce jest pełne bardzo dynamicznych przepływów energii, które ostatecznie są potrzebne do „napędzania” obiektów i działań na ziemi o niższej energii. Podobnie przy tworzeniu światów obliczeniowych zdarzają się przypadki, w których trzeba sobie radzić z przepływami i transformacjami oraz szybko zmieniającymi się kontekstami, które, choć same w sobie nie są bardzo podobne do obiektów, są jednak absolutnie niezbędne do umożliwienia prostszych, bardziej przyjaznych człowiekowi obiektów używanych na wyższych poziomach. . To nie przypadek, że znaczna część programowania wykonywanego na poziomie jądra nie jest wyraźnie podobna do obiektów lub że w dużej mierze opiera się na językach takich jak C, które są bardziej zorientowane na przetwarzanie. Są to głębsze dziedziny, które uzupełniają fascynującą różnorodność, którą widzimy wyżej w światach generowanych komputerowo.

Innym obszarem, w którym OOP może się nie udać, jest zbytnie skupianie się na starych koncepcjach obiektów.

Przedmioty w świecie rzeczywistym, a zwłaszcza żywe , mają absolutnie zadziwiający poziom umiejętności interakcji ze środowiskiem w skomplikowany i subtelny sposób. Widżety nadające się do wzajemnego przeglądania, sprawdzające zgodność i sprawdzanie poprawności, a może nawet wymyślające nowe sposoby interakcji są bardzo zbliżone do rzeczywistej koncepcji biologicznej obiektów niż proste ramy i schematy dziedziczenia, które mamy tendencję skupić się (zwykle z konieczności!) na poziomie kodu. Jest to jeden z obszarów wzrostu obiektów w świecie cybernetycznym, im bardziej „agresywne” podejście, w którym reaktywność na środowisko jest normą nawet w ramach samego programowania.

I tyle za moją „krytykę” OOP! Mam jednak nadzieję, że wskazałem, dlaczego stworzenie bogatszego cyberprzestrzeni oznacza uwzględnienie różnorodności stylów programowania, zamiast zakładać, że „tylko jeden” jest wszystkim, czego potrzeba. Mam wrażenie, że naprawdę interesujące rzeczy dopiero nadejdą, bez względu na to, jak przyziemna jest większość naszych działań!


18
Jestem pewien, że sporo osób zrezygnowało z części „Czytaj dalej tylko, jeśli jesteś zainteresowany eksploracją na poziomie fizyki”. Cieszę się, że nie. Jest to sposób myślenia, który wstrząsa fundamentami naszego zrozumienia i prawdopodobnie jedyny sposób, w jaki możemy zrobić znaczący postęp. Dzięki za świetną lekturę.
Matt Esch

@Raynos, $ MattEsch, dziękuję wam obojgu za miłe słowa i cieszę się, że uważacie to za interesujące!
Terry Bollinger

1
Zapisałem się na stronie, aby móc głosować na tę głęboko przemyślaną, wspaniałą odpowiedź. =)
sgorozco

2
Zgodnie z twoimi myślami, programowałem już od dłuższego czasu i stałem się fanatykiem OOP, ponieważ naprawdę zauważyłem, że moje umiejętności kodowania dramatycznie się poprawiły, kiedy je adoptowałem. Jednak doświadczenie pokazało mi, że zmuszanie wszystkiego, aby stało się przedmiotem, może być naprawdę szkodliwe. Nie mogę się doczekać narzędzi mapowania obiektowo-relacyjnego (co za bałagan) lub schematów serializacji z wykorzystaniem wykresów obiektowych, które zużywają 1000% przepustowości w porównaniu z prostym protokołem binarnym, który po prostu przesyła przewodowo odpowiednią ilość danych binarnych potrzebnych na chwila. Dzięki za świetną lekturę.
sgorozco

2
Ta odpowiedź jest również odpowiedzią na pytanie, dlaczego nadal potrzebujemy SQL!
HLGEM,

25

Po pierwsze, nie potrzebujesz OOP do wszystkiego, pomimo wszelkich dogmatów na ten temat, które zostały spopularyzowane. W przeciwieństwie do Java, C pozwala na wskaźniki funkcji, a nawet zamknięcia, które otwierają drzwi do programowania funkcjonalnego i rozwiązują dość część uchwytów OOP przestrzeni problemowej, ponieważ zapewniają środki wstrzykiwania zależności. Również ostrożne stosowanie makr może faktycznie stworzyć kilka bardzo ciekawych rzeczy, jak sglib dowodzi.

W dziwny sposób można postrzegać C jako dobry kompromis między Javą a C ++. Pamiętaj, że nie mówię, że C jest w jakikolwiek sposób mieszanką obu. Ale w przeciwieństwie do Javy, jest to dość potężny język, podczas gdy w przeciwieństwie do C ++ ma złożoną obsługę.

Jest to stary język, który stał się niezawodny i spójny, a jednocześnie nie bardziej skomplikowany. Poza tym ma gigantyczny ekosystem i po prostu działa wszędzie.


11
Programowanie funkcjonalne jest świetne, bez zastrzeżeń. Ale C to raczej zły język do programowania funkcjonalnego. Zamknięcia / bloki są nieprzenośnymi hackami i mają brzydką składnię (jak również gotchas, założę się). Nawet ignorując to wszystko, nadal musisz dbać o zarządzanie pamięcią. C jest przydatnym językiem, ale jak w każdym innym języku, po prostu utrudniasz sobie życie, niż musisz, jeśli nadużywasz go, aby użyć paradygmatu, dla którego nie został stworzony. Możesz także emulować programowanie funkcjonalne w Javie (zobacz Guava ), ale to też nie jest miłe.

7
Bardzo trudno jest programować w funkcjonalnym stylu bez pojemnika na śmieci.
Konstantin Solomatov

@KonstantinSolomatov: Po pierwsze, to bardzo subiektywne. Po drugie, możesz dodać zbieranie śmieci do C, jeśli to konieczne.
back2dos

Jeśli potrzebujesz kompromisu między Javą a C ++, wypróbuj Obj-C :) Zdecydowanie coś, co powinien spróbować każdy programista C / C ++.
Sułtan

21

C ma ABI (Application Binary Interface), a C ++ nie. To sprawia, że ​​C jest bardziej użyteczny niż C ++ w niektórych przypadkach. Jeśli mam napisać bibliotekę i móc wysyłać pliki binarne do użytku innych osób, C ++ jest niewłaściwym narzędziem do tego zadania. Jeśli mam zamiar napisać biblioteki, które będą używane przez inny język, C jest właściwym narzędziem do tego zadania. Nigdy nie słyszałem o języku, który nie obsługiwał FFI (Interfejs funkcji zagranicznej) do C, z drugiej strony C ++ nie będzie działał z bibliotekami napisanymi w C ++, jeśli zostaną użyte różne kompilatory.

Zasadniczo sprowadza się do C, wypełniając rolę, dla której C ++ nie jest odpowiedni.


2
Mmm .. rolka C, pomidorowa i serowa!
DeadMG

3
C ++ ma ABI. Po prostu C ABI jest solidny jak skała, podczas gdy C ++ zmienia się o wiele za często. Ponadto wiele C ++ to szablony wkompilowane w używaną aplikację, więc nie można jej zaktualizować. Gdy cała funkcjonalność jest ukryta za wywołaniami funkcji, można naprawić bibliotekę i utrzymać działanie aplikacji.
Jan Hudec

12

Jedną z zalet używania C w językach takich jak C ++ lub Java jest to, że pod maską nie dzieje się wiele magii. Żadne konstruktory nie są uruchamiane, gdy elementy są przydzielane, i nie są uruchamiane żadne destruktory, gdy obiekty wykraczają poza zakres. Nie ma mangowania nazw ani vtabeli. Wydajność jest łatwiejsza do przewidzenia; nie musisz się martwić o to, że śmieciarz zakłóci rutynę i skróci czas jej działania.

Konstruktory, destruktory, zmienianie nazw, vtable, śmieciarze itp. Mogą złagodzić złożoność kodu, który tworzysz, ale wtedy złożoność ta staje się częścią samego języka, w którym nie masz nad nim żadnej kontroli . Możesz skończyć z dłuższym czasem kompilacji (irytującym, ale znośnym), większym obciążeniem pamięci środowiska wykonawczego (może być lub nie być tolerowanym) lub wolniejszym działaniem. Dzięki C możesz zmniejszyć część tej złożoności, dopóki nie pozostaniesz z potrzebną funkcjonalnością .

Na przykład stringtyp danych C ++ jest o lata świetlne łatwiejszy do pracy niż ciągi w stylu C, ale jest to dość ciężki fragment kodu i dodaje pewnej wagi do rozmiaru obrazu. Rzadko widuję, by ktokolwiek w pełni korzystał z stringmożliwości dowolnego programu. Ciągi w stylu C, choć trudniejsze do pracy, nakładają mniejszą karę pod względem czasu działania i rozmiaru obrazu, a dla konkretnego problemu mogą być z tego powodu bardziej atrakcyjne.


2
Kara za czas pracy jest nonsensem. Ciągi C (zakończone zerem) są znacznie mniej wydajne niż ciągi C ++. Ponadto klasa strun może być tak zwarta jak C, o ile nie przeciągniesz całości std.
Pubby

1
Łańcuch narzędzi, który nie usuwa nieużywanych funkcji string, które nie są używane, jeśli statycznie łączysz CRT, to łańcuch narzędzi, który nie jest tego wart.
Billy ONeal

10
Głupie jest to, że pracuję z biblioteką, która std::stringnie jest wystarczająco wyrafinowana . Jeśli naprawdę poważnie podchodzisz do łańcuchów, zarówno pod względem wydajności, jak i możliwości, wrócisz do korzystania z C i robienia tego wszystkiego samemu, choć char*na pewno nie używasz zwykłych starych s. (Struny są zaskakująco skomplikowane, nawet jeśli oczekujesz, że będą skomplikowane.)
Donal Fellows

1
@DonalFellow Ciekawe. Właśnie dlatego standard C zawsze przepuszczał takie rzeczy jak ciągi znaków i tabele skrótów, chociaż ich brak czasami mnie denerwuje.
Inżynier

@ArcaneEngineer: Podstawowym brakującym typem danych w C jest „wycinek typu T []”, który łączyłby T * i size_t, mógłby być indeksowany jak tablica, mógłby rozpadać się na T * i mógłby być niejawnie konwertowany z dowolny typ T [n] (przy czym rozmiar jest automatycznie dostarczany przez kompilator). Taki typ może pozwolić na automatyczne sprawdzanie granic w wielu przypadkach, w których jest inaczej niemożliwe, jednocześnie czyniąc wiele rodzajów kodu o wiele czystszymi i bardziej czytelnymi.
supercat

11

Systemy osadzone i sterowniki są zwykle programowane w C. Oprócz tego istnieje mnóstwo starszych systemów C, które są nadal utrzymywane i rozbudowywane.


2
Tak, C działa na wszystko. Jest to dość łatwy do nauczenia się język (w porównaniu do c ++).
BenjaminB

10

To samo, co sprawia, że ​​młot ręczny jest popularny w czasach młotów pneumatycznych (młotów pneumatycznych): C jest nadal właściwym narzędziem do niektórych prac.


6

Prostota, spójność i precyzja.

To proste - nie potrzebujesz złożonego środowiska programistycznego, obszernych bibliotek ani maszyny wirtualnej.

Jest spójny - większość C napisanych 10 lat temu mogłaby się dziś skompilować.

Precyzja - pozwala zejść na poziom maszyny, znając w razie potrzeby lokalizację pamięci. Jest to świetne rozwiązanie dla wydajności i wbudowanego sprzętu.

To nie jest na wszystko, ale nadal jest to przydatne narzędzie.


5
Co więcej, istnieje spora szansa, że ​​kod skompilowany 10 lat temu mógłby dziś zostać wykonany .
Donal Fellows

@DonalFellows: A w przypadku aplikacji korzystających z wtyczek istnieje spora szansa, że ​​aplikacja napisana, zbudowana i wydana (w formie wykonywalnej) będzie mogła dziś korzystać z wtyczek skompilowanych z narzędziami do budowania, które jeszcze nie były zaprojektowane jeszcze.
supercat

6

Przytaczam dwa punkty z innej odpowiedzi, ponieważ zawierają dokładne powody, dla których wciąż używam C od czasu do czasu (chociaż nie jest to mój główny język wyboru):

  • C jest proste. Brakuje w nim wyrazistości zaawansowanych OOP lub funkcjonalnych języków, ale jego prostota oznacza, że ​​można go szybko odebrać.
  • C jest dojrzały. Ostatnim standardem, który wprowadził duże zmiany, jest C99 i jest on w większości kompatybilny wstecz z poprzednimi standardami. W przeciwieństwie do nowszych języków (np. Python), nie musisz się martwić o zerwanie zmian w najbliższym czasie.

Myślę, że to bardzo prawda. Nauczyłem się C we wczesnych latach nocnych: było proste, mało słów kluczowych i konstrukcji, większość pracy wykonywanej przez biblioteki. Potem nie używałem C przez kilka lat. Około 2002 roku potrzebowałem szybkiej implementacji algorytmu, zainstalowałem kompilator C i zaimplementowałem go. Znam język, wiem do czego służy, do czego nie jest odpowiedni ( nigdy nie wdrożyłbym aplikacji internetowej w C!) I jest tam, kiedy jej potrzebuję. Bez niespodzianek.

Z C ++ miałem inne doświadczenie. Nauczyłem się go około 1995 roku i oznaczało to dużą zmianę paradygmatu z trybu imperatywnego na OOP. Wspaniały! Używałem go do kilku projektów do 1999 roku. Przez kilka lat nie używałem C ++, a kiedy go ponownie wziąłem (2008), znalazłem wiele nowych funkcji już w języku, a nawet bardziej planowanych (tymczasem wprowadzonych w C ++ 11). Mam wrażenie, że muszę znów nauczyć się języka.

Jako programista wolę dojrzałe, stabilne języki. Lubię raz nauczyć się języka, rozumieć jego zasady projektowania, do czego jest dobry, i używać go, gdy uważam, że jest to właściwe narzędzie do pracy. Lubię też uczyć się różnych języków i wybierać język, który odpowiada moim potrzebom (C, C ++, Java, Scala, Haskell i tak dalej). Nie podoba mi się to, że muszę ciągle uczyć się tego samego języka, ponieważ rozwija się on coraz bardziej i nigdy nie osiąga dojrzałości.

IMHO, język programowania powinien mieć przejrzysty, spójny i stabilny wygląd. Lubię podejście projektantów takich jak Niklaus Wirth: za każdym razem, gdy odczuwał potrzebę innego języka, projektował nowy (Pascal, Modula-2, Modula-3, Oberon). Nie lubię języków, które przechodzą ważne zmiany co 5–10 lat: są jak ruchome cele i nigdy nie uważam, że warto poświęcić swój czas na ich dogłębną naukę, ponieważ wersja, której się teraz uczę, prawdopodobnie stanie się przestarzała w każdym razie lata.

W tym sensie C jest zwycięzcą IMO: jest dobre dla niektórych aplikacji i mniej odpowiednie dla innych, ale ma tę zaletę, że jest proste i względnie stabilne.


4

Dziwi mnie, że nikt jeszcze nie wspominał o gorszej jakości . W tej chwili ma ponad 20 lat, ale nadal jest warty przeczytania. Niekiedy wprawia w osłupienie, ale bardzo dobrze opisuje, w jaki sposób i dlaczego celownik często wygrywa z ideałem, używając C (w porównaniu z LISP) jako jednego z głównych przykładów.


Rzeczy, które umieściłem w kategorii „gorzej, ale lepiej”: angielski, PHP, Windows. .. może McDonalda. Chociaż nadal zazdroszczę / wolę hiszpański, Python, Linux i Artisan French Cooking; tak dużo, jak to możliwe, jeśli nie jest to zwykle możliwe.
ThorSummoner,

1

Prawdopodobnie chciałeś zapytać, dlaczego ludzie używają C zamiast C ++, mimo że gdy masz kompilator C, zwykle masz też kompilator C ++.

  • Język C jest znacznie prostszy niż C ++. Nie znam żadnej firmy, która używa pełnego standardu C ++ w swojej konwencji kodowania. Spójrz na styl kodu Google C ++ jako przykład: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
  • Kompilacja C jest znacznie szybsza. Dzięki brakowi trudnych do skompilowania konstrukcji.

Ten link jest zepsuty.
ar2015

0

Nic. TIOBE jest bezwartościowym indeksem. Jeśli faktycznie spojrzysz na ich pomiar, to w najlepszym razie absolutne przypuszczenie.


10
Fakt, że TIOBE jest bezwartościowy, nie oznacza, że ​​C nie jest popularny
Raynos

Zdecydowanie jednak pokonuje argument przedstawiony w PO-, że C jest popularny i dlatego musi się przydać.
DeadMG

2
Lepszym miernikiem popularności C jest to, że prawie każda platforma ma kompilator C
Raynos

@Raynos: To wcale nie jest pomiar. Jedyną rzeczą, która oznacza, że ​​jest łatwa do wdrożenia. Nie mówi nic o tym, ile osób go używa i dlaczego.
DeadMG

2
Nie do końca, z radością akceptuję przeciwne punkty widzenia. Wydaje się, że twoja odpowiedź na jedną linię była mało przemyślana, a twoje odpowiedzi są kłótliwe i niekonstruktywne.
mattnz

0

Dużo starszego oprogramowania

Wiele firm nie może zmienić, natychmiast cały swój kod na C ++ lub podobny.

Wiele firm nie stać na zmianę kodu.

Wiele firm może sobie pozwolić na zmianę kodu, ale nie obchodzi ich to, że są „tanie”.

Wiele firm jest w trakcie migracji, ale jeszcze się nie zakończyło.

Orientacja ukrytych obiektów

(Non Object Oriented) Kod źródłowy C zaprojektowany jako kod źródłowy Object Oriented C, aplikacje, które są modelowane za pomocą Object Orientation i kodowane za pomocą „czystego C” lub narzędzia, które tłumaczą z „C ++” lub innego programu OO. lang do C.

Słyszałem, że niektóre gry wideo są robione w ten sposób. Niektóre narzędzia między platformami oraz biblioteka wizualnego interfejsu GTK (GObject, GLibrary) dla dystrybucji GNOME Linux OS.


3
Druga połowa tej odpowiedzi wymaga odtajnienia.
aramis

@aramis. Druga część oznacza: Wiele kodów wydaje się być donde bezpośrednio w „C”, ale w rzeczywistości w innym języku i przetłumaczonych na „C”
umlcat,

0

Widzę, że niektórzy respondenci podają, dlaczego C jest najbardziej popularny, istnieje już od dłuższego czasu, jest dostępny na większości platform, bezpłatny itp.

To samo można powiedzieć o innych językach, na przykład darmowym Pascalu - jest bezpłatny i obsługiwany przez prawie wszystkie platformy.

Pascal został wynaleziony około 1970 roku, C został wynaleziony około 1972 roku, więc myślę, że Pascal istnieje już od C.

Osobiście uważam, że C jest najpopularniejszym językiem, ponieważ dostępny jest po prostu więcej otwartego kodu źródłowego do ponownego wykorzystania przez każdego. I tak, jest na niższym poziomie niż Pascal, więc zbliża się do złożenia, ale jest o wiele bardziej czytelny niż montaż.

Myślę, że jest po prostu zbyt wiele języków programowania. Jako programiści musimy znać większość najważniejszych, ale na koniec nie powinno być takiej potrzeby. W tym celu można wdrożyć jeden język programowania, od tworzenia stron internetowych po gry komputerowe na iOS.

C wydaje się być globalnym językiem, ale chciałbym, żeby był to coś w rodzaju Object Pascal. Dlaczego Object Pascal, jest to bardziej czytelny język programowania, kod OOP jest zwykle bardziej przydatny i mniej podatny na błędy (moim zdaniem) niż C.

Bardzo duże aplikacje są łatwiejsze w zarządzaniu dzięki Object Pascal niż C / C ++.

Co do posiadania języka programowania, który był taki od lat 70., i nie lubienia języków, które zmieniają się co 5 lub 10 lat. Z biegiem czasu postęp technologiczny i metody programowania są ulepszane. Jeśli język zmienia się drastycznie co kilka lat, to prawdopodobnie nie został dobrze przemyślany przez jego projektanta. Ale lata 1970–2012 to prawie pół wieku, w tym czasie można wprowadzić zmiany w języku, aby uwzględnić postępy w rozwoju oprogramowania.

Samo C zostało kilkakrotnie poprawione. Nie jest to więc lepsze niż inne języki z tego punktu widzenia.


3
Jednym z problemów z Pascalem było to, że w „oficjalnej” wersji języka pominięto kilka bardzo niezbędnych funkcji. Przez pewien czas zarówno PC, jak i Macintosh miały kompilatory Pascal, które były znacznie bardziej użyteczne niż jakiekolwiek kompilatory C istniejące w tym czasie, ale takie kompilatory dodały rozszerzenia językowe, które nie były obsługiwane przez żaden „oficjalny” standard. Wydaje mi się, że gdyby podjęto próbę opracowania oficjalnego standardu, który kodyfikowałby takie rozszerzenia, Pascal mógłby zastąpić ten hack języka znanego jako „C”.
supercat

0

Ponieważ C ma ogromną bazę użytkowników. Tak, to trochę kłopot 22, ale kiedy zadaję pytanie o C w StackOverflow, otrzymuję odpowiedź prawie natychmiast. Odpowiedzi na to samo pytanie dotyczące Pythona mogą zająć godziny.

W przypadku C ++ nauka IMO jest trudniejsza. Co więcej, po wypróbowaniu OOP przez 10 lat uważam, że nie zawsze jest to przydatne i często łatwiej jest zamiast tego korzystać z programowania procedur.


Czy porównałeś zadawanie pytań SO dla C # lub Java?
komara

@gnat był to izolowany przykład C v Python (który, nawiasem mówiąc, ma więcej pytań!). Nie mam doświadczenia z C # (zauważyłeś, że nie zadaję SO pytań do C # lub jav?)
puk

Heh, uważam, że społeczność #python na StackOverflow jest prawie zawsze bardzo szybka. Byłbym jednak zaskoczony, gdyby społeczność C przewyższyła społeczność javascript pod względem szybkości odpowiedzi. (Głównie z powodu objętości)
ThorSummoner,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.