OOP 시대에 C가 왜 그렇게 인기가 있습니까? [닫은]


91

나는 C와 C ++로 많이 코딩했지만 C가 Java보다 약간 두 번째로 인기있는 언어라고는 생각하지 않았다.

TIOBE 프로그래밍 커뮤니티 인덱스

이 OOP 시대에 C가 왜 그렇게 인기가 있는지 궁금합니다. 가장 많이 사용되는 5 가지 프로그래밍 언어 중 4 개는 "현대"객체 지향 언어입니다.

이제 C에서 OOP를 어느 정도 사용할 수 있다는 데 동의하지만 고통스럽고 우아하지 않습니다 (적어도 C ++과 비교할 때). 그렇다면 C가 왜 그렇게 인기가 있습니까? 효율성입니까? 저수준; 이미 존재하는 대다수의 라이브러리 또는 다른 것?


18
비디오 게임, 임베디드 시스템, 하드웨어 프로그래밍 (펌웨어), 운영 체제 등

25
TIOBE의 경우 +"<language> programming"인기있는 검색 엔진 의 히트 수인 측정 값 만 얻을 수 있습니다 . 이 인덱스에서 "C 프로그래밍을 더 이상 수행하지 않는 이유"라는 블로그 게시물이 C에 포함됩니다. 도대체,이 질문조차도 구글이 그것을 선택하자마자 할 수 있습니다.

40
OOP의 나이? 그것은 대담한 진술입니다.
Mahmoud Hossam

57
당신은 OOP가 은총 알이라는 환상을 가지고 있습니다. OOP에 대해 특별하거나 "좋은"것은 없으며, 그것은 많은 코드 구성 전략 중 하나 일뿐입니다.
Raynos

23
@DeadMG : 주전자, 주전자를 만나십시오. TIOBE의 데이터는 신뢰할 수 없지만 "인기가 없다"는 대머리 주장은 출처 나 인용이 전혀 없습니다. 질문 뒤에있는 가정에 이의를 제기하려면 최소한이를 뒷받침 할 증거를 제공하십시오.
Daniel Pryden

답변:


142

기여하는 몇 가지 요소 :

  • C는 어디에나있다. 플랫폼이 무엇이든 C를 사용할 수 있습니다.
  • C는 휴대가 가능합니다. 깨끗한 C 조각을 작성하고 다른 플랫폼에서는 최소한의 수정으로 컴파일하며 때로는 기본적으로 작동합니다.
  • C는 잠시 동안 주변에 있었다. 유닉스가 세상을 정복했던 시절, C (유닉스 프로그래밍 언어 선택)는 세계 지배를 공유 하고 프로그래밍 세계 의 언어 가되었습니다 . 어떤 심각한 프로그래머는 최소 할 것으로 예상 할 수 있습니다 어떤 C의 덩어리의 감각을; 대부분의 다른 언어에 대해서도 마찬가지입니다.
  • C는 여전히 UNIX 및 UNIX 맛 시스템의 기본 언어입니다. 라이브러리가 오픈 소스 토지에서 성공하기를 원한다면 C를 사용 하지 않는 상당히 좋은 이유가 필요 합니다. 이것은 부분적으로 전통 때문이지만 C는 유닉스 계열과 같이 안전하게 지원되는 유일한 언어이기 때문에 더 큽니다. 체계. 라이브러리를 C로 작성하면 종속성을 최소화 할 수 있습니다.
  • C는 간단하다. 정교한 OOP 또는 기능적 언어의 표현력이 부족하지만 단순성으로 인해 신속하게 선택할 수 있습니다.
  • C는 다목적입니다. 임베디드 시스템, 장치 드라이버, OS 커널, 작은 명령 줄 유틸리티, 큰 데스크톱 응용 프로그램, DBMS, 다른 프로그래밍 언어 구현 및 기타 생각할 수있는 모든 것에 적합합니다.
  • C는 빠르다. 대부분의 C 구현은 머신 코드로 직접 컴파일되며 프로그래머는 머신 레벨에서 발생하는 모든 것을 능가합니다. 인터프리터, JIT 컴파일러, VM 또는 런타임이 없습니다. 코드, 컴파일러, 링커 및 베어 메탈 만 있습니다.
  • C는 '무료'입니다 (맥주와 언어 감각 모두). 표준을 소유하고 통제하는 단일 회사는 없으며, 선택할 수있는 여러 가지 구현이 있으며, C 사용에 대한 저작권, 특허 또는 상표 문제가 없으며, 가장 좋은 구현은 오픈 소스입니다.
  • C는 많은 추진력을 가지고 있습니다. 이 언어는 수십 년 동안 널리 사용되어 왔기 때문에 언어를 지원하기위한 수많은 응용 프로그램, 라이브러리, 도구 및 대부분의 커뮤니티가 있습니다.
  • C는 성숙하다. 큰 변화를 일으킨 마지막 표준은 C99이며 이전 표준과 대부분 호환됩니다. 최신 언어 (예 : Python)와 달리 언제든지 변경 사항을 적용 할 염려가 없습니다.
  • C는 호환됩니다. 대부분의 언어에는 C와 대화 할 수있는 바인딩이 있습니다. 이는 표준 호출 규칙을 사용하여 C로 라이브러리를 개발할 수 있으며 거의 ​​모든 다른 언어가 해당 라이브러리와 링크 될 수 있다고 확신합니다. 널리 사용되는 몇 가지 인기있는 언어를 C #, Java, Perl, Python, PHP 등으로 지정하면 많은 어려움없이 C 라이브러리에 모두 연결할 수 있습니다.
  • C는 강력하다 : 언어가 무언가를 할 수 없다면, 모든 유명한 컴파일러는 하드웨어가 할 수있는 모든 것을 할 수있는 어셈블러 코드를 내장 할 수있다. 호환성에 대해 위의 점과 전 이적으로 결합하면 C가 고급 언어와 어셈블리의 "베어 메탈"간의 연락 역할을 할 수 있습니다.

9
나는 당신의 모든 주장이 정확하다고 생각하지 않습니다. 1) C는 어디에나있다. C ++ 대 C 컴파일러가 있기 때문에 C ++는 C만큼 유비쿼터스입니다. 2) C는 휴대용이다. C ++와 동일합니다. 삼). C는 잠시 동안 주변에 있었다. C ++와 동일합니다. 4). C는 다목적입니다. C ++와 동일합니다. 5) C는 빠릅니다. C ++와 동일합니다. 6). C는 '무료'입니다. C ++와 동일합니다. 7). C는 많은 추진력을 가지고 있습니다. C ++에서도 마찬가지입니다. 8) C는 성숙하다. C ++와 동일합니다. 따라서 실제로 질문에 대답하지 않습니다.
Konstantin Solomatov

19
C11은 C99가 아닌 최신 표준입니다. 모두가 '89를 사용함에 따라 실제로 중요하지는 않습니다.
Pubby

53
@ KonstantinSolomatov : 다른 사람들이 사용할 라이브러리를 작성하는 경우 세계에 호의를 베풀고 C ++ 대신 C로 작성하십시오. 그렇게 할 수 없다면 최소한 C API를 작성하십시오. 우주의 모든 것은 보통 최소한의 노력으로 C 코드에 어떤 방식 으로든 연결될 수 있습니다. 대조적으로, 다른 언어는 물론 다른 C ++ 코드 에서 C ++ 코드를 호출하려고 할 때 주요 ABI 문제가 자주 발생 합니다.
Daniel Pryden

37
@KonstantinSolomatov-C ++에서 C로 컴파일러가 필요하다는 사실은 C가 유비쿼터스라는 것을 증명합니다.
detly

11
@ KonstantinSolomatov : C가 C ++라고 생각하지 마십시오. C에는 클로저가 없습니다. C의 일부 확장 (gcc 컴파일러 제품군에서 구현 된 확장)은 수행하지만 C 자체 는 그렇지 않습니다 (즉, 원래 K & R 사양이나 최종 C 표준에 포함되지 않음).
Donal Fellows

88

나는 항상 보편적 인 어셈블리 언어의 필요성에 대한 C의 인기를 비난하는 경향이 있었다. 기계 수준의 특수성, 표준화 및 극도의 이식성으로 인해 C는 사실상 범용 어셈블리 언어 로 기능 할 수 있으며, 그로 인해 그 역할이 무한정 계속 될 것으로 생각됩니다.

OOP가 프로그래밍 과정에서 좋은 프로그래밍을위한 유일한 엔드 포인트 인 일종의 "최종 모델"로 제시 될 때 나는 항상 약간 놀랐습니다. 프로그래밍의 다른 많은 측면과 마찬가지로 OOP의 가치는 인간의 두뇌가 정보를 구성하는 방법, 사회 그룹이 장기적으로 소프트웨어를 지원하는 방법 및 객체 지향 프로그래밍의 경우 매우 깊은 측면을 포함하여 많은 경쟁 요소 간의 절충입니다. 우주 자체가 어떻게 작동하는지

그리고 마지막 요점은 조금 망치는 것입니다. 특정 프로그래밍 스타일이 존재하는 이유, 함께 작동하는 방식 및 향후 이러한 개념에 대해 확장 할 때 세계가 향하는 위치에 대한 물리 수준 탐색에 관심이있는 경우 자세히 읽어보십시오.

물리학의 대상은 시간이 지남에 따라 인식 가능한 일관성을 유지하는 것입니다. 그것은 우리 자신과 같은 단순한 생물이 우리의 생존을 심각하게 위험에 빠뜨리지 않고 적은 수의 비트만을 사용하여 물체를 표현하는 것을 피할 수있게합니다. 그러나 물리학의 관점에서 볼 때, 그러한 단순화를 쉽고 일반적으로 만들기 위해 정확히 맞아야하는 것들의 수가 엄청나게 많습니다. 솔직히 말해서 인간으로서 우리는 그 모든 것에 대해 많이 생각하지 않습니다. 그것이 사실이 아니라면 우리는 여기에 없었을 것입니다.

너무 추상적 인 소리? 정말 그렇지 않습니다. 예를 들어 자동차 대신 플라즈마 필드가 빠르게 진동하고 거대한 속도로 움직이는 물질이 순간적으로 응축되는 경우 친구의 집으로가는 길을 탐색하려고한다고 상상해보십시오. 그러한 시나리오는 사회화의 기회에 다소 깊이 영향을 줄 수 있습니다. 우리는 우리가 객체가 필요 하다 객체와 객체의 존재는 우리 주변 환경의 단순화의 거대한 및 매우 중요한 수준으로 우리를 제공합니다.

모든 것을 소프트웨어로 되돌려 봅시다. 실제 세계의 객체는 프로그래밍 측면에서 객체에 대해 무엇을 말해야합니까?

소프트웨어에서 "좋은"객체를 정의하는 것은 실제로 처리하는 데이터 유형이 시간이 지남에 따라 인식 가능한 지속성 의 아이디어를 쉽게 지원하는지 여부를 의미해야합니다 .

정의를 통해 가장 쉬운 OOP 형식을 쉽게 식별 할 수 있습니다. 그것들은 이미 "첨부"되었거나 사람, 집 또는 자동차와 같은 실제적이고 실제적인 물체에 의해 정의 된 데이터만을 사용하여 조금씩 제거하는 것입니다. 오늘날에도 이것은 사람들이 소프트웨어 과정에서 얻는 객체에 대한 유일한 정의입니다. 사소한 객체 지향 프로그램조차도 그보다 더 넓은 정의가 필요하기 때문에 너무 나쁩니다.

두 번째로 흥미로운 객체 범주는 내가 불멸의 실제 이벤트 라고 부르는 것 입니다. "불멸의"라는 말 은 현실 세계에서 잘 정의 된 실체 또는 소장품으로서 최소한 잠깐 존재하지만 물리적으로 의미있는 소장품으로 존재하지 않는 것을 의미합니다. 심포지엄은 훌륭한 예입니다. 심포지엄은 장소와 사람이 잘 정의되어있는 짧은 기간 동안 존재합니다. 그러나 아쉽게도 최고의 회의조차 끝내야하며,이를 구성한 개별 부분은 다른 활동으로 넘어갑니다.

그러나 컴퓨터와 네트워크를 사용하여 일시적인 심포지엄을 소프트웨어 개체로 메모리를 캡처하고 유지함으로써 장기적인 개체처럼 보이게 할 수 있습니다 . 우리가 컴퓨터와 데이터베이스로하는 많은 것들이 이런 종류의 일시적인 사건에 대한 불멸화에 해당합니다. 실제로 우리는 실제 우주에는 존재하지 않는 방식으로 실제 우주를 포착하고 확장함으로써 실제 우주를 더욱 풍요롭게하려고합니다. 예를 들어, 최근 판도라를 본 적이 있습니까? 이러한 현실 세계의 포착과 확장은 우리의 삶, 경제 및 선택을 놀라 울 정도로 풍요롭게하고 확장하는 데 도움이됩니다. 이것이 나에게 가장 주목할만한 영향을 미쳤고, 계속 가지고있는 객체 지향 프로그래밍의 중심입니다.

OOP의 최종 범주는 외부 이벤트와 밀접한 관련이 없지만 대신 인프라 인 개체로 구성됩니다.현실 세계의 불멸의 물건을 사용하여 현실의 지속적인 확장을 지원해야했습니다. 여기에서 컴퓨터의 (반) 금속으로 내려갈 수 있으며, 실제 세계의 화학 요소와 같은 새로운 현실 세계를 만들기 위해 빠르고 재미있는 방법으로 결합 할 수있는 지속적인 현실 조각을 만듭니다. 모바일 컴퓨팅은 이러한 종류의 고도로 재조합적인 접근 방식의 성장을 촉진하는 데 도움이되었으며, 이는 다시 여러 가지 방법으로 물리적 세계의 재조합 특징을 모방합니다. 또한 어려운 선택입니다. 좋은 선택처럼 보일 수있는 것은 예상치 못한 나쁜 선택 이었음을 입증 할 수 있습니다. 일반적으로 지원하지 않고 다양성과 확장을 차단하기 때문입니다.

이 마지막 범주는 프로그래밍을 위해 하나의 모델을 사용하는 것의 위험도 지적합니다. 실제와 마찬가지로 프로그래밍 된 세계에도 그렇지 않은 프로세스가 필요하기 때문입니다비교적 변하지 않는 물체에 잘 맞습니다. 지구는 물체로 가득 차 있지만 태양은 에너지가 적은 지구에서 물체와 활동을 "구동"시키는 데 필요한 매우 역동적 인 에너지 흐름으로 가득합니다. 마찬가지로, 컴퓨팅 세계를 만들 때 흐름과 변형을 다루어야하고 급변하는 컨텍스트를 다루어야하는 경우가 있습니다. 그럼에도 불구하고 객체 자체는 아니지만 더 높은 수준에서보다 간단하고 인간 친화적 인 객체를 사용하는 것이 절대적으로 중요합니다. . 커널 수준에서 수행 된 많은 프로그래밍이 눈에 띄게 객체와 유사하지 않거나 더 처리 지향적 인 C와 같은 언어에 크게 의존하는 경향은 우연이 아닙니다. 이들은 컴퓨터 생성 세계에서 우리가 볼 수있는 매혹적인 다양성을 보완하는 더 깊은 영역입니다.

OOP가 잘못 될 수있는 다른 영역은 오래된 개체 개념 에 너무 집중하고 있습니다 .

현실 세계의 물체, 특히 살아있는 물체는 복잡하고 미묘한 방식으로 환경과 상호 작용할 수있는 놀라운 수준의 능력을 가지고 있습니다. 서로를 살펴보고 호환성과 온 전성 검사를 수행하고 상호 작용하는 새로운 방법을 알아내는 컴포저 블 위젯은 단순한 프레임 워크와 단순한 상속 체계보다 실제 생물학적 개념에 가깝습니다. 코드 수준에서 (보통 필요에 따라!) 집중하십시오. 이것은 사이버 세계에서 객체의 성장 영역 중 하나이며, 프로그래밍 자체 내에서도 환경에 대한 반응성이 표준 인 "에이전트와 유사한"접근 방식입니다.

그리고 OOP의 나의 "비평"을 위해 너무나! 그럼에도 불구하고 더 풍부한 사이버 월드를 만드는 것이 "단 하나"만 있으면 충분하다고 생각하기보다는 다양한 프로그래밍 스타일을 포괄 하는 이유를 지적했으면 합니다. 제 생각에는 우리가 지금하는 일이 얼마나 평범한 지에 상관없이 정말 흥미로운 것들이 아직 오지 않았습니다!


18
"물리적 수준의 탐험에 관심이있는 경우에만 더 읽어보십시오"부분에서 상당히 많은 사람들이 빠졌다고 확신합니다. 내가하지 않은 것이 기쁘다. 이것은 우리의 이해의 기초를 뒤 흔드는 일종의 사고이며 아마도 우리가 주목할만한 진보를 이루는 유일한 방법 일 것입니다. 읽어 주셔서 감사합니다.
Matt Esch

@Raynos, $ MattEsch, 당신에게 친절한 말을 해주셔서 감사합니다. 흥미 롭습니다.
Terry Bollinger

1
이 깊이 생각하고 웅장한 답변을 투표 할 수 있도록 사이트에 가입했습니다. =)
sgorozco

2
당신의 생각에 따라, 나는 꽤 오랫동안 프로그래밍을 해왔고, 그것을 채택 할 때 코딩 기술이 극적으로 향상되는 것을 보았 기 때문에 OOP 열성자가되었습니다. 그러나 경험에 따르면 모든 것이 물건이되도록 강요하는 것은 실제로 해를 끼칠 수 있습니다. 이제는 필요한 바이너리 데이터를 유선으로 전송하는 간단한 이진 프로토콜에 비해 1000 % 대역폭을 소비하는 객체-관계형 매핑 도구 (엉망) 또는 전체 객체-그래프 직렬화 체계를 시작합니다. 순간. 읽어 주셔서 감사합니다.
sgorozco

2
이 답변은 왜 여전히 SQL이 필요한지에 대한 답변입니다!
HLGEM

25

첫째, 이것에 관한 교리가 대중화되었지만 모든 것에 대해 OOP가 필요하지 않습니다. Java와 달리 C는 함수 포인터와 클로저 를 허용 하여 함수형 프로그래밍의 문을 열어주고 의존성 주입 수단을 제공하기 때문에 OOP 핸들링 문제를 해결합니다. 또한 매크로를 신중하게 사용하면 실제로 sglib이 증명하는 것처럼 아주 멋진 것을 만들 수 있습니다 .

이상한 방식으로 C는 Java와 C ++의 좋은 절충안으로 볼 수 있습니다. 내가주의 하지 C가 어떤 식 으로든 모두의 혼합이다라고 말하는. 그러나 Java와 달리 강력한 언어이지만 C ++과 달리 관리가 복잡합니다.

구식 언어는 믿을 수 있고 일관성이 있으며 실제로 더 복잡해지지는 않습니다. 그리고 모든 것을 제외하고, 그것은 거대한 생태계를 가지고 있으며 단순히 어디에서나 실행됩니다.


11
함수형 프로그래밍은 위대하지 않습니다. 그러나 C는 함수형 프로그래밍에있어 다소 나쁜 언어입니다. 클로저 / 블록은 이식 할 수없는 핵이며 추악한 구문과 함께 제공됩니다. 모든 것을 무시하더라도 여전히 메모리 관리에 관심을 가져야합니다. C는 유용한 언어이지만 다른 언어와 마찬가지로 의도하지 않은 패러다임을 사용하기 위해 남용하는 경우보다 인생을 힘들게 만들고 있습니다. Java에서도 기능 프로그래밍을 에뮬레이트 할 수 있지만 ( Guava 참조 ) 좋지 않습니다.

7
가비지 수집기가 없으면 기능적 스타일로 프로그래밍하기가 매우 어렵습니다.
Konstantin Solomatov

@ KonstantinSolomatov : 첫째, 그것은 매우 주관적입니다. 둘째, 필요한 경우 가비지 수집을 C에 추가 할 수 있습니다.
back2dos

Java와 C ++ 사이에 타협을 원한다면 Obj-C를 시도하십시오.
Sulthan

21

C에는 ABI (Application Binary Interface)가 있지만 C ++에는 없습니다. 특정 인스턴스에서 C가 C ++보다 유용합니다. 라이브러리를 작성하고 다른 사람들이 사용할 바이너리를 제공 할 수 있다면 C ++은 작업에 대한 잘못된 도구입니다. 다른 언어로 다시 사용될 라이브러리를 작성하려면 C가 작업에 적합한 도구입니다. 나는 C에 대한 FFI (Foreign Function interface)를 지원하지 않는 언어에 대해 들어 본 적이 없지만 다른 컴파일러를 사용하는 경우 C ++은 C ++로 작성된 라이브러리에서 작동하지 않습니다.

기본적으로 C ++이 부적합한 역할을 채우는 C로 요약됩니다.


2
음 .. C, 토마토, 치즈 롤!
DeadMG

3
C ++에는 ABI가 있습니다. C ABI가 바위처럼 단단하고 C ++ 하나가 너무 자주 바뀌는 것입니다. 또한 많은 C ++은 사용중인 응용 프로그램으로 컴파일 된 템플릿이므로 업데이트 할 수 없습니다. 모든 기능이 함수 호출 뒤에 숨겨지면 라이브러리를 수정하고 응용 프로그램을 계속 작동시킬 수 있습니다.
Jan Hudec

12

C ++ 또는 Java와 같은 언어에 비해 C를 사용하면 얻을 수있는 장점 중 하나는 실제로 많은 마법이 발생하지 않는다는 것입니다. 항목이 할당 될 때 생성자가 실행되지 않으며 개체가 범위를 벗어날 때 소멸자가 실행되지 않습니다. 이름 맹 글링과 vtables가 없습니다. 성능을 예측하기가 더 쉽습니다. 가비지 콜렉터가 루틴을 중단하고 타이밍을 버리는 것에 대해 걱정할 필요가 없습니다.

생성자, 소멸자, 이름 맹 글링, vtables, 가비지 수집기 등은 작성하는 코드의 복잡성을 완화시킬 수 있지만 그 복잡성은 언어 자체의 일부가되어 제어 할 수있는 권한이 거의 없습니다 . 빌드 시간이 길어 지거나 (성가 시지만 견딜 수 있음), 런타임 메모리 풋 프린트가 커지거나 (허용되지 않을 수도 있거나) 성능이 저하 될 수 있습니다. C를 사용하면 필요한 기능을 사용할 때까지 복잡한 부분을 제거 할 수 있습니다 .

예를 들어, C ++ string데이터 형식은 C 스타일 문자열보다 작업하기가 수년 더 쉽지만 상당히 무거운 코드 조각이며 이미지 크기에 약간의 여유를 더합니다. 어느 누구도 string하나의 프로그램에서의 기능을 최대한 활용하는 것을 거의 보지 못했습니다 . C 스타일 문자열은 작업하기가 어렵지만 런타임 및 이미지 크기 측면에서 페널티를 덜 부과하며 특정 문제로 인해 이러한 이유로 더 매력적일 수 있습니다.


2
런타임의 페널티는 말도 안됩니다. C- 문자열 (널로 종료 됨)은 C ++ 문자열보다 훨씬 덜 효율적입니다. 또한 문자열 클래스는 전체 std를 드래그하지 않는 한 C만큼
작을 수

1
stringCRT를 정적으로 연결하면 사용 되지 않는 기능을 제거하지 않는 툴체인은 가치가없는 툴체인입니다.
Billy ONeal

10
어리석은 일은 충분히std::string 정교하지 않은 라이브러리에서 작업한다는 것입니다 . 성능과 기능면에서 문자열에 대해 정말로 진지한 경우, 평범한 구식을 사용하지는 않지만 C를 사용하고 다시 직접 모든 작업을 수행합니다 . (문자열은 복잡 할 것으로 예상 되더라도 놀라 울 정도로 복잡합니다.)char*
Donal Fellows

1
@DonalFellow 재미있는. 이것이 바로 C 표준이 때로는 문자열과 해시 테이블과 같은 것들을 잊어 버린 이유입니다.
엔지니어

@ArcaneEngineer : C에서 근본적으로 누락 된 데이터 타입은 T *와 size_t를 결합하고 배열처럼 인덱스화할 수 있고 T *로 분해 될 수 있고 암시 적으로 변환 될 수있는 "T [slice of T []"타입입니다. 모든 T [n] 유형 (컴파일러가 자동으로 제공하는 크기). 이러한 유형은 불가능한 많은 경우에 자동 경계 검사를 허용하는 한편 많은 종류의 코드를 훨씬 깨끗하고 읽기 쉽게 만듭니다.
supercat

11

임베디드 시스템과 드라이버는 일반적으로 C로 프로그래밍됩니다. 그 외에도 여전히 유지되고 확장되는 수많은 레거시 C 시스템이 있습니다.


2
그렇습니다, C는 모든 것에 달려 있습니다. 그리고 언어를 배우는 것은 꽤 쉽습니다 (C ++에 비해).
BenjaminB

10

공압 해머 (에어 해머) 시대에 수동 해머를 대중적으로 만드는 것과 동일한 것 : C는 여전히 특정 작업에 적합한 도구입니다.


6

단순성, 일관성 및 정밀성.

간단합니다. 복잡한 개발 환경, 광범위한 라이브러리 또는 가상 머신이 필요하지 않습니다.

일관성이 있습니다. 10 년 전에 작성된 대부분의 C는 오늘 컴파일 할 수 있습니다.

정밀성-필요에 따라 메모리 위치를 알고 기계 수준으로 내려갈 수 있습니다. 이것은 성능 및 내장 하드웨어에 좋습니다.

그것은 모든 것이 아니며, 여전히 유용한 도구입니다.


5
더 좋은 방법은 10 년 전에 컴파일 된 코드 오늘 실행될 가능성이 있다는 입니다.
Donal Fellows

@DonalFellows : 플러그인을 사용하는 응용 프로그램의 경우 오늘날 작성, 빌드 및 릴리스 된 (실행 파일 형식) 응용 프로그램이 빌드 도구로 컴파일되지 않은 플러그인을 사용할 수도 있습니다. 아직 설계되었습니다.
supercat

6

나는 때때로 여전히 C를 사용하는 이유를 정확하게 포착하기 때문에 다른 대답에서 두 가지 요점을 인용합니다 (그러나 내 주요 언어는 아닙니다).

  • C는 간단하다. 정교한 OOP 또는 기능적 언어의 표현력이 부족하지만 단순성으로 인해 신속하게 선택할 수 있습니다.
  • C는 성숙하다. 큰 변화를 일으킨 마지막 표준은 C99이며 이전 표준과 대부분 호환됩니다. 최신 언어 (예 : Python)와 달리 조만간 변경 내용을 중단 할 염려가 없습니다.

나는 이것이 사실이라고 생각합니다. 나는 이른 밤에 C를 배웠습니다. 도서관에서 수행 한 대부분의 작업은 단순하고 키워드와 구성이 거의 없었습니다. 그런 다음 몇 년 동안 C를 사용하지 않았습니다. 2002 년경에는 알고리즘의 빠른 구현이 필요했고 C 컴파일러를 설치하고 구현했습니다. 나는 언어를 알고, 그것이 무엇인지, 그것이 무엇이 좋지 않은지 ( C로 웹 애플리케이션을 구현 하지 않을 것입니다 !), 그리고 필요할 때 바로 거기에 있습니다. 놀랍지 않습니다.

C ++에서는 다른 경험이있었습니다. 나는 1995 년경에 그것을 배웠고 명령형에서 OOP 로의 큰 패러다임 전환을 의미했습니다. 큰! 1999 년까지 여러 프로젝트에 사용했습니다. 몇 년 동안 저는 C ++을 사용하지 않았고 다시 (2008 년) 다시 집어 들었을 때 이미 언어로 된 많은 새로운 기능을 발견했으며 더 많은 계획을 세웠습니다. 11). 언어를 다시 배워야한다는 느낌이 들었습니다.

개발자로서 저는 성숙하고 안정적인 언어를 선호합니다. 나는 언어를 한 번 배우고, 그 디자인 원리, 그에 맞는 것이 무엇인지, 그리고 직업에 적합한 도구라고 생각할 때 언어를 사용하는 것을 좋아합니다. 또한 다른 언어를 배우고 필요에 맞는 언어 (C, C ++, Java, Scala, Haskell 등)를 선택하고 싶습니다. 내가 싫어하는 것은 점점 더 발전하고 결코 성숙해지지 않기 때문에 같은 언어를 계속해서 배우는 것입니다.

프로그래밍 언어 인 IMHO는 명확하고 일관되며 안정적인 디자인을 가져야합니다. 나는 Niklaus Wirth와 같은 디자이너의 접근 방식을 좋아합니다. 다른 언어에 대한 필요성을 느낄 때마다 새로운 언어를 설계했습니다 (Pascal, Modula-2, Modula-3, Oberon). 나는 5-10 년마다 중요한 변화를 겪는 언어를 좋아하지 않습니다. 그것들은 움직이는 목표와 같으며 깊이 배우기 위해 시간을 투자 할 가치가 있다고 생각하지 않습니다. 어쨌든.

이러한 의미에서 C는 IMO가 승자입니다. 특정 응용 프로그램에는 적합하고 다른 응용 프로그램에는 적합하지 않지만 간단하고 비교적 안정적이라는 장점이 있습니다.


4

아무도 Worse Is Better를 아직 언급하지 않은 것에 놀랐습니다 . 이 시점에서 20 세가 넘었지만 여전히 읽을 가치가 있습니다. 때때로 뺨에 약간 혀가 있지만, C (LISP와의 투구)를 중심 예제로 사용하여 어떻게 이상적인 방법을 통해 왜 이상적인 방법을 얻는 지 잘 설명합니다.


내가 '더 나쁘지만 더 나은'범주에 넣은 것 : 영어, PHP, Windows. .. 맥도날드일지도 모른다. 나는 여전히 스페인어, Python, Linux 및 장인 프랑스 요리를 부러워하고 선호하지만; 일반적으로 가능하지 않은 경우 가능한 한 많이.
ThorSummoner

1

C 컴파일러를 사용할 때 일반적으로 C ++ 컴파일러도 있다는 사실에도 불구하고 사람들이 C ++ 대신 C를 사용하는 이유를 묻고 싶을 것입니다.

  • C 언어는 C ++보다 훨씬 간단합니다. 코딩 규칙에 완전한 C ++ 표준을 사용하는 회사는 없습니다. 예를 들어 Google의 C ++ 코드 스타일을 살펴보십시오. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
  • C는 컴파일 속도가 훨씬 빠릅니다. 컴파일하기 어려운 구조 덕분에.

이 링크가 끊어졌습니다.
ar2015

0

아무것도. TIOBE는 쓸모없는 인덱스입니다. 실제로 측정을 보면 절대적인 추측입니다.


10
TIOBE가 무가치하다는 사실은 C가 인기가 없다는 것을 의미하지는 않습니다.
Raynos

그러나 C가 널리 사용되므로 반드시 사용해야한다는 OP-에 제시된 주장을 무시한다.
DeadMG

2
C의 인기의 더 나은 측정은 거의 모든 플랫폼은 C 컴파일러를 가지고 있다는 것입니다
Raynos

@Raynos : 전혀 측정되지 않습니다. 의미하는 것은 구현하기 쉽다는 것입니다. 얼마나 많은 사람들이 그것을 사용하는지, 왜 그런지에 대해서는 언급하지 않습니다.
DeadMG

2
전적으로, 나는 반대 의견을 기꺼이 받아들입니다. 한 줄로 된 대답은 거의 생각이 적용되지 않은 것으로 보이며, 당신은 당신의 응답에 대해 논쟁적이고 비 건설적입니다.
mattnz

0

많은 레거시 소프트웨어

많은 회사가 즉시 모든 코드를 C ++ 또는 이와 유사한 코드로 변경할 수 없습니다.

많은 회사에서 코드를 변경할 여유가 없습니다.

많은 회사에서 코드를 변경할 여유가 있지만 걱정하지 않거나 "저렴한"상태입니다.

많은 회사들이 마이그레이션을 진행하고 있지만 아직 완료되지 않았습니다.

숨겨진 개체 방향

(비 객체 지향) 객체 지향 C 소스 코드로 설계된 C 소스 코드, 객체 지향으로 모델링되고 "순수한 C"로 코딩 된 응용 프로그램 또는 "C ++"또는 기타 OO progr에서 번역 된 도구. C로 랭

나는 일부 비디오 게임이 그런 식으로 끝났다고 들었습니다. 일부 크로스 플랫폼 도구 및 GNome Linux OS 배포판을위한 GTK (GObject, GLibrary) 비주얼 인터페이스 라이브러리.


3
이 답변의 후반 부분은 난독 화되어야합니다.
aramis

@ 아라미스. 두 번째 부분은 의미 : 대부분의 코드는 "C"에 직접 donde 것 같다,하지만, 실제로 다른 언어로, 그리고에 "C"traslated
umlcat

0

나는 C가 가장 인기있는 이유, 오랫동안 주변에 있었고, 대부분의 플랫폼에서 무료로 사용할 수있는 이유에 대해 대답하는 사람들을 봅니다.

그러나 다른 언어, 예를 들어 무료 파스칼에 대해서도 마찬가지입니다. 무료이며 거의 모든 플랫폼에서 지원됩니다.

파스칼은 1970 년경에 발명되었고 C는 1972 년경에 발명 되었기 때문에 파스칼은 C만큼이나 오래전부터 존재했다고 생각합니다.

개인적으로 C는 가장 널리 사용되는 언어라고 생각합니다. 누구나 재사용 할 수있는 오픈 소스 코드가 더 많기 때문입니다. 그리고 그것은 파스칼보다 낮은 레벨이므로 어셈블리에 가까워 지지만 어셈블리보다 훨씬 더 읽기 쉽습니다.

프로그래밍 언어가 너무 많다고 생각합니다. 프로그래머로서 우리는 대부분의 중요한 것들을 알아야하지만, 결국에는 그럴 필요가 없습니다. 웹 사이트 구축부터 iOS 컴퓨터 게임에 이르기까지 하나의 프로그래밍 언어를 구현할 수 있습니다.

C는 그 글로벌 언어 인 것처럼 보이지만 Object Pascal과 같은 것이기를 바랍니다. Object Pascal이 더 읽기 쉬운 프로그래밍 언어 인 이유 OOP 코드는 C보다 재사용 성이 높고 버그가 발생하기 쉬운 경향이 있습니다.

C / C ++보다 Object Pascal로 매우 큰 응용 프로그램을 관리하기가 더 쉽습니다.

70 년대 이후로 일부 프로그래밍 언어를 사용하고 5 년 또는 10 년마다 바뀌는 언어를 좋아하지 않는 것에 관한 것입니다. 시간이 지남에 따라 기술이 발전하고 프로그래밍 방법이 개선되었습니다. 몇 년마다 언어가 크게 바뀌면 아마도 디자이너가 잘 생각하지 못했을 것입니다. 그러나 1970 년에서 2012 년은 거의 반세기 동안 소프트웨어 개발에 사용 된 고급 기능을 통합하기 위해 당시 언어를 변경해도 괜찮습니다.

C 자체는 여러 번 수정되었습니다. 따라서 다른 언어보다 관점이 좋지 않습니다.


3
Pascal의 한 가지 문제점은 "공식"언어 버전에 필요한 기능이 거의 없다는 것입니다. 꽤 오랫동안 PC와 Macintosh에는 당시에 존재했던 C 컴파일러보다 훨씬 더 유용한 Pascal 컴파일러가 있었지만 이러한 컴파일러에는 "공식"표준에서 지원하지 않는 언어 확장이 추가되었습니다. 그러한 확장을 체계화 한 공식 표준을 만들려는 노력이 있었다면 파스칼은 "C"로 알려진 언어의 핵을 대체했을 수 있습니다.
supercat

0

C는 거대한 사용자 기반을 가지고 있기 때문에. 예, 약간의 캐치 -22이지만 StackOverflow에서 C에 대해 질문하면 거의 즉시 답변을 얻습니다. 파이썬에 대한 동일한 질문에 답하는 데 몇 시간이 걸릴 수 있습니다.

C ++과 관련하여 배우기가 더 복잡합니다. 또한 OOP를 10 년 동안 사용해 본 결과 항상 유용한 것은 아니며 종종 절차 적 프로그래밍을 사용하는 것이 더 쉽다는 것을 알게되었습니다.


C # 또는 Java에 대한 SO 질문을 비교 했습니까?
gnat

@gnat 그것은 C v Python의 고립 된 예였습니다 (물론 더 많은 질문이 있습니다!). 나는 C #을 가진 경험이 없다 (당신은 나의 통지 않았다 하지 C # 또는 JAV에 대한 SO 질문을?)
PUK

Heh, StackOverflow의 #python 커뮤니티는 거의 항상 매우 빠릅니다. C 커뮤니티가 자바 스크립트 커뮤니티보다 속도가 빠르면 놀랍습니다. (대부분 볼륨 때문에)
ThorSummoner
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.