컴퓨터언어

C 언어는 무엇으로 만드나

일단 우리가 생각해 보아야 할 것은 "언어"가 실체인가 하는 점입니다. "너 영어 좀 하냐?", "난 국어는 제대로 알아요", "불어로 써봐" 등 일상의 표현에서는 마치 언어가 실제로 존재하는 대상 같습니다. 하지만 "그럼 국어는 도대체 어디에 있니?"라고 질문을 하게 되면 우리는 막막해 집니다. 국어사전에? 어문규정에? 문법책에? 우리 머리 속에? 아니면 이걸 모두 합한 것이 국어인가? C언어라는 것도 비슷한 면이 있습니다. 차이가 있다면 C 언어는 인공언어(Artificial Language)이기 때문에 규칙이 명확하다는 점 뿐이죠. 우리는 컴퓨터에서, 프로그래밍 언어와 그 언어의 구현(보통은 컴파일러), 그리고 그 언어로 표현된 소스코드, 이 세가지를 개념적으로 구분해야 합니다.

따라서, C언어는 C언어라는 추상적인 개념일 뿐, 어떤 프로그램이나 소스가 아닙니다. C언어는 문서로 정리하여 표준으로 인정받는 것으로 끝이며, C언어는 사람의 머리로 만듭니다. 사실 이 질문은 한국어는 무엇으로 만드나? 하는 질문과 같습니다. 한국어를 처음 만들 때 다른 언어를 통해 한국어를 정의한 것은 아니겠지요.

C 언어로 작성한 소스코드를 어떻게 실행 프로그램으로 만드나

C 컴파일러를 이용하여 특정 환경(platform)에서 실행할 수 있는 실행프로그램을 만듭니다. c compiler는 c언어로 작성된 소스코드를 읽어서 정해진 결과물(실행파일)을 생성해 내는 프로그램이고, 가장 널리 쓰이는 gcc(GNU C Compiler)의 경우 c언어로 작성되어 있으나, 어떤 언어를 이용해 c compiler를 만들어내어도 무방합니다.

C 컴파일러가 먼저냐, C 언어가 먼저냐

C 컴파일러를 C 언어로 작성한다면, 그럼 C compiler의 소스코드는 누가 compile하여 실행프로그램을 만들어내는지 의문을 갖게 됩니다. gcc의 경우, 거의 모든 플랫폼에 대해 이미 compile된 실행파일 형태의 gcc를 배포합니다. 새로운 platform A가 나타나는 경우, 그 환경에 맞는 실행프로그램을 이미 널리 쓰이는 platform B에서 만들어냅니다. 이것을 두고 cross-platform compile이라고 하는데, 예를 들어 windows용 gcc에서 linux용 gcc를 만들어낼 수 있고, linux용 gcc에서 solaris용 gcc를 만들어낼 수 있습니다.

태초의 C 컴파일러는 누군가 어떻게 만들었을 것 아닌가

cpu가 이해할 수 있는 실행파일, 즉 기계어코드를 거의 곧바로 만들어낼 수 있는 assembler를 이용해 간단한 c compiler를 만든 후, 이것을 이용해 제대로 된 c compiler를 만들어내면 될 것입니다. 아버지의 아버지의 아버지를 거슬러 올라가면 Computer Science/Engineering의 역사를 모두 훑어나가게 될 것입니다. 라고 보통 생각하기 쉽지만, 최초의 C 컴파일러는 켄 톰슨에 의해서 C 언어로 작성되었답니다.
그럼 어셈블러는 뭘로 만들었나

기계어란 무엇인가?
그럼 0과1은 뭐로 만들었나

• 선배들이 프로그래밍에 사용하는 언어 - 앞서가는 사람에게서 배우는 것은 효과가 큽니다.
  
• CLanguage - mid-level programming에 꼭 필요한 언어. (학자에 따라 mid-high level 이라 표현하기도 한다)
  
• Mathematica or MatLab - 복잡하지만 강력하고 유연한 만능 계산기.
  
• Perl - Unix환경에서 무엇인가를 할 일이 있다면, 만능 맥가이버 스위스칼처럼 쓰게 되는 스크립트 언어. 간단한 반복작업에서부터 상용 애플리케이션 개발까지 자유롭게 쓸 수 있는 언어.
  
• VisualBasic or Delphi - Windows환경에서 무엇인가를 할 일이 있다면, 간단한 프로그램에서 상용 애플리케이션 개발까지 자유롭게 쓸 수 있는 언어, 또는 개발환경.
  
• Scheme and/or CommonLisp - MIT에서는 StructureAndInterpretationOfComputerPrograms 때문에 꼭 배움.
  
• FORTRAN - 아직도 사용되는 가장 오래된 언어. 무엇에 사용할 수 있냐가 문제인데 광대하면서 최적화된 수학 라이브러리 덕에 수학 연산 관련 문제에 대해서는 경쟁력이 있는 언어.
  
  

• 문제를 해결하기 위한 도구의 발전이라고 생각하는 것이 더 좋을 것 같습니다. A라는 언어로 소프트웨어를 개발하여 보니 이런 저런 문제에 부딪히고 그것을 더 편리하게 해결하기 위해 새로운 언어 B를 만들어내고, 다시 다른 문제를 더 쉽게 해결하기 위해 C라는 언어를 만들어내는, 이런 식입니다. 그러니까 "해석하는 법" 발전이라기 보다는, "편의에 의해 만들어내는 규칙성"의 발전입니다. "기계에 맞게 해석하는 법의 발전"은 compiler software가 발전하여 같은 소스코드를 더 빠르고 효율적인 프로그램으로 만들어내는 기술의 발전이겠지요.
  
• 프로그래밍 언어들은 크게 두 그룹으로 나눌 수 있습니다. 처음부터 잘 설계해서 스스로 계속 진화할 수 있도록 된 언어들과 그렇지 못한 프로그래밍 언어들입니다. 후자의 경우는 질문자의 비유에 부합하게 설명하자면 부러져 나갈 수 있는 가지들이겠죠. 현존하는 프로그래밍 언어들중에는 이미 존재하는 프로그래밍 언어에서 주로 장점이라고 생각되는 것들만 짜집기한 것들도 있습니다. 문제는 이런 짜집기로 인해 결국 잘 설계할 기회를 스스로 잃기도 한다는 점입니다. 인간사와 마찬가지로 꼭 발전만 있는 법은 없으니까요?
  
  

• 질문 1의 답에 설명되어 있듯이 그럴 수도 있고 아닐 수도 있습니다. A언어로 만들어진 소스를 컴파일러가 A언어로 쓰여졌을 수도 있고 다른 언어로 쓰여졌을 수도 있습니다. 그리고 각 언어에 대한 컴파일러는 여러개가 존재합니다. C/C++만 예를 들어도 GCC, MS의 Visual C, 볼랜드의 CppBuilder 등 여러가지 컴파일러가 있습니다.
  
• 종종 최후의 구현물인 컴파일러와 그것을 구현하는 언어가 동일한 경우가 있습니다. 이것은 나르시즘의 일종으로 해커라고 불리거나 불리고 싶어하는 이들이라면 거의 반드시 이렇게 합니다. 거기에 덧붙여서 컴파일러 개발 초기단계 테스트중 하나로 그 언어 자체를 컴파일하게 하는 경우가 많습니다.
  
• 프로그래밍 언어는 일종의 추상적인 것이고, 컴파일러는 그 추상적인 것을 구체화 시킨 것이라고 할 수 있습니다. 마치 스포츠 카라는 개념과 포르쉐 911 하는 것과 마찬가지 입니다. 결국 A라는 언어는 보통 문서로 정해진 스펙으로 존재하고, A라는 언어를 특정 컴퓨터와 OS에서 구현한 것이 컴파일러 입니다. 컴파일러로는 그 언어로 작성된 프로그램을 다른 언어(보통의 경우 기계어)로 바꿀 수 있겠죠. 컴파일러는 자동차 종류만큼(?) 많답니다.
  

윈도우즈에서 개발을 하신다면

일단 C나 C++ 기초를 배운 후에, MFC 에 관련된 책을 보시면 되는데, 보통 MFC를 하기 전에 API 를 해야 한다고들 합니다. 정리하자면 C/C++ -> API -> MFC 입니다. 책은 어느 서점에든 다 있으니 직접 살펴보시거나 주위에 잘 아는 사람이 있다면 추천을 받아 읽어보시면 됩니다. --Nainu
왜 하필 텍스트 에디터?

전산을 전공하는 학생이 아니라면 왜 텍스트 에디터를 만들려고 하시나요? 자신이 가진 문제를 해결하기 위한 프로그램을 작성하는 것은 어떨까요? 예를 들어, 언어학과 학생이라면 문법에 대해 배운것이나 자신의 이론 등을 프로그래밍 언어를 통해서 어떻게 실제로 작동하는지 실험 해볼 수 있을 겁니다. 일반적으로, 알고 있다고 생각되는 것을 실제로 만들어 보았을 때 어떻게 돌아가는지 명확히 알게 됩니다! --LispM (see also WhatToProgram )

간단한 것부터

꼭 텍스트 에디터를 만들어야 한다면 일단은 가장 간단한 종류의 텍스트 에디터를 만들고 그걸 IncrementalDevelopment를 통해 조금씩 진화시켜 보는 것은 어떨까요? 일단은 ed 같은 라인 에디터를 만드는 겁니다. GUI나 화면 제어도 필요없습니다. 그냥 printf만 쓰면 됩니다. 그렇게 개발을 하되, 가능하면 최대한 잘 모듈화하고, 정보은닉을 하도록 하세요. 몇 번 째 줄을 새 줄로 대체하는 서비스를 제공하는 모듈은 그 줄이 어떤 자료구조로 이루어져 있는지를 몰라야 합니다. 이런식으로 모듈화를 잘 해놓으면 유저 인터페이스 부분을 아주 "얇게" 만들 수 있습니다. 그러면 나중에 스크린 에디터로(일단은 라인 에디터와 스크린 에디터의 중간점 -- 예컨대, 기본적으로는 라인 에디터이지만 지정한 라인에 대해서는 스크린 에디터처럼 작동하는 -- 에서 출발을 하세요) 전환을 하게 되어도 바꾸어야 할 코드가 팍 줄어듭니다. 전체 아키텍춰도 크게 변하지 않을 겁니다. 바뀌어야 할 부분이 많나요? 라인 에디터에서 스크린 에디터로 바꾸기가 힘이 드나요? 왜 그럴까요? 어떻게 했더라면 수월하게 전이할 수 있었을까요? 이런 질문을 던져보면 많이 배울 수 있을 겁니다. 텍스트 에디터의 본질에 대해 많이 배울 수 있을 겁니다. 그리고 이 지식은 나중에 다른 언어와 다른 기술을 통해 텍스트 에디터를 만들더라도 거의 고대로 활용할 수 있을 겁니다. (나중에 디자인 패턴을 공부하게 되신다면 라인 에디터 같이 비교적 간단한 시스템에 하나 하나 적용을 해보세요. 패턴을 하나씩 넣어보고, 또 빼보세요. 더 간단해 지나요, 더 복잡해 지나요? 어떤 사람은 라인 에디터 하나를 만들면서 열 개도 넘는 디자인 패턴을 사용할 것이고, 어떤 사람은 서너 개만 사용할 것입니다. 어느 쪽이 더 나을까요?) --김창준

• How to Design programs - SICP과 유사하게 Scheme이라는 프로그래밍 언어를 가지고 프로그래밍에 대해서 가르쳐 준다. 비전공자들도 따라할 수 있도록 매우 세세하게 차근차근 진정한 프로그래밍이란 무엇인지 알려주는 책.
  

See also 프로그래밍언어지도, 분야별컴퓨터관련추천웹사이트

컴퓨터분류 매뉴얼분류